Observabilidade com sidecars em microsserviços: conceitos e aplicação prática

No mundo de arquiteturas modernas baseadas em microsserviços, a observabilidade é um componente fundamental. Garantir que você tenha visibilidade total do comportamento e estado de suas aplicações é essencial para identificar problemas e garantir que seus serviços estejam operando corretamente.

Uma abordagem comum para adicionar observabilidade a microsserviços é a utilização do padrão de design chamado “sidecar”. Este post explorará o conceito de um sidecar de observabilidade, seguido de um exemplo prático de como implementá-lo com uma aplicação simples de To-do List na AWS usando Python para a lógica do aplicativo e Terraform para provisionar a infraestrutura.

O que é um sidecar de Observabilidade?

O termo “sidecar” faz referência à ideia de adicionar funcionalidades extras a um contêiner de aplicação principal sem modificar diretamente seu código. Assim como um sidecar de moto anda ao lado da moto, um sidecar em uma aplicação corre paralelamente ao microsserviço que ele está observando. O sidecar pode ser responsável por diversas funções, como:

• Logs: Capturar e enviar logs estruturados para ferramentas centralizadas de observabilidade.
• Métricas: Coletar métricas de desempenho e expô-las para serviços de monitoramento.
• Tracing: Adicionar funcionalidades de tracing distribuído para facilitar a identificação de problemas na aplicação.

O sidecar é normalmente implementado como um contêiner separado que é implantado junto com o contêiner principal (aplicação) e opera como uma camada de observabilidade.

Aplicação prática: uma “to-do list” com um sidecar de Observabilidade

Neste exemplo, vamos criar uma aplicação simples de To-do List em Python e configurar um sidecar de observabilidade que monitora métricas de requisições HTTP feitas ao microsserviço. Usaremos AWS como provedor de nuvem, implementando a infraestrutura com Terraform e utilizando Prometheus para métricas.

Estrutura da solução

• Aplicação principal: Uma aplicação Flask em Python que oferece uma API RESTful para gerenciar To-dos.
• Sidecar: Um serviço paralelo para coleta de métricas, que serão expostas para um Prometheus.
• Infraestrutura AWS: Serviços como ECS (Elastic Container Service) para orquestração de contêineres, CloudWatch para logs, e um Application Load Balancer (ALB) para rotear as requisições.

Passo a passo

1. Criando a aplicação to-do list

A aplicação será uma API simples com Flask:

# todo_app.py
from flask import Flask, request, jsonify

app = Flask(__name__)
todos = []
@app.route('/todos', methods=['GET'])
def get_todos():
    return jsonify(todos), 200
@app.route('/todos', methods=['POST'])
def create_todo():
    data = request.json
    todos.append(data)
    return jsonify(data), 201
@app.route('/todos/<int:todo_id>', methods=['DELETE'])
def delete_todo(todo_id):
    if 0 <= todo_id < len(todos):
        todos.pop(todo_id)
        return '', 204
    return 'Not found', 404
if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

Esse código implementa uma API básica com três endpoints:

• GET /todos para listar To-dos.
• POST /todos para adicionar uma nova To-do.
• DELETE /todos/<id> para remover uma To-do pelo ID.

2. Criando o sidecar para Observabilidade

Usaremos um contêiner separado para capturar métricas das requisições HTTP, que serão expostas para coleta pelo Prometheus.

# sidecar.py
from flask import Flask, request
from prometheus_client import Counter, generate_latest

app = Flask(__name__)

# Definindo métricas de requisições
REQUEST_COUNT = Counter('request_count', 'Total number of requests', ['method', 'endpoint'])

@app.before_request
def before_request():
    REQUEST_COUNT.labels(method=request.method, endpoint=request.path).inc()

@app.route('/metrics')
def metrics():
    return generate_latest(), 200

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=9000)

Neste sidecar, adicionamos um contador (Counter) para cada requisição recebida pelo microsserviço principal, expondo as métricas no endpoint /metrics.

3. Provisionando a infraestrutura com Terraform

Vamos configurar a infraestrutura na AWS usando o Terraform para criar um ECS Cluster, definir as tasks para os contêineres, e provisionar os recursos necessários como VPC, subnets, ALB, etc.

# main.tf
provider "aws" {
  region = "us-west-2"
}

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  tags = {
    Name = "observability-vpc"
  }
}

resource "aws_subnet" "main" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
  availability_zone = "us-west-2a"
}

resource "aws_ecs_cluster" "main" {
  name = "observability-ecs"
}

resource "aws_ecs_task_definition" "todo" {
  family = "todo-sidecar"
  network_mode = "awsvpc"

  container_definitions = jsonencode([
    {
      name      = "todo-app"
      image     = "python:3.9-slim" # substitua pela sua imagem Docker da aplicação
      cpu       = 256
      memory    = 512
      essential = true
      portMappings = [
        {
          containerPort = 5000
        }
      ]
    },
    {
      name      = "sidecar"
      image     = "python:3.9-slim" # substitua pela sua imagem Docker do sidecar
      cpu       = 128
      memory    = 256
      essential = true
      portMappings = [
        {
          containerPort = 9000
        }
      ]
    }
  ])

  requires_compatibilities = ["FARGATE"]
  memory = "1GB"
  cpu    = "512"
}

resource "aws_ecs_service" "todo" {
  name            = "todo-service"
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.todo.arn
  desired_count   = 1
  launch_type     = "FARGATE"

  network_configuration {
    subnets         = [aws_subnet.main.id]
    assign_public_ip = true
  }
}

Este exemplo básico de Terraform cria uma VPC, subnets, um ECS Cluster, uma task definition para a aplicação e o sidecar, e configura o serviço com uma task rodando em Fargate.

4. Conectando a aplicação com o sidecar

No exemplo, o sidecar é implementado como um contêiner separado que será implantado ao lado do microsserviço da To-do List no ECS. Prometheus pode então ser configurado para coletar as métricas do endpoint /metrics exposto pelo sidecar.

Considerações finais

A implementação de sidecars em uma arquitetura de microsserviços permite adicionar facilmente observabilidade sem modificar o código da aplicação principal. A solução proposta fornece visibilidade para métricas HTTP e pode ser expandida para incluir logs e tracing. A combinação de Python para a lógica do microsserviço, Prometheus para coleta de métricas, e Terraform para provisionamento da infraestrutura AWS facilita a automação e escalabilidade dessa solução.

Até o próximo post! =)