Migração para Plataformas Stateful Cloud Native no AWS EKS

A plataforma original rodava em instâncias EC2 r6i.4xlarge com discos EBS gp2 montados diretamente, um banco de dados PostgreSQL por tenant em RDS Single-AZ, e uma camada de cache Redis gerenciada manualmente via scripts de bootstrap. O modelo funcionava, até não funcionar. Cada tenant tinha seu próprio conjunto de instâncias, o que garantia isolamento forte mas tornava o custo operacional proibitivo: 40 tenants significavam 40 stacks de infraestrutura, 40 pipelines de patch, 40 runbooks de failover. A equipe de operações passava mais tempo gerenciando infraestrutura do que entregando valor.

O estado era implícito em toda parte: sessões de usuário em memória local, filas de processamento em tabelas PostgreSQL sem particionamento adequado, e configurações de tenant espalhadas em arquivos .env versionados manualmente. Não havia um inventário confiável de qual instância servia qual tenant em um dado momento. Quando um nó falhava, o processo de recuperação envolvia SSH, verificação manual de logs e restauração de snapshots EBS, um MTTR médio de 47 minutos para incidentes de dados.

A pressão para migrar veio de dois lados: custo (a conta EC2 crescia linearmente com o número de tenants) e compliance (um audit de SOC 2 Type II identificou a falta de separação lógica auditável entre tenants como um achado de alto risco). A decisão de ir para EKS não foi tomada por modismo, foi tomada porque o modelo de operadores Kubernetes oferecia a automação de ciclo de vida que a equipe precisava para escalar sem crescer o headcount de operações proporcionalmente.

Namespace por tenant é necessário, mas longe de suficiente em um ambiente financeiro. O namespace é uma fronteira de nomenclatura e RBAC, ele não impede que um pod mal configurado acesse a rede de outro tenant, nem que uma chave de criptografia seja compartilhada inadvertidamente.

O modelo de isolamento que implementamos tem quatro camadas:

1. Isolamento de rede: NetworkPolicy padrão nega todo tráfego ingress e egress dentro do cluster, exceto rotas explicitamente permitidas. Cada tenant só pode se comunicar com seu próprio namespace e com o namespace platform-services (que contém o proxy de saída e o serviço de autenticação). Usamos Calico como CNI para suporte a GlobalNetworkPolicy, que aplica regras antes mesmo das políticas de namespace.

2. Isolamento de identidade: Cada ServiceAccount de tenant tem uma IAM Role dedicada via IRSA (eks.amazonaws.com/role-arn annotation). A IAM Role tem uma condition StringEquals no sts:AssumeRoleWithWebIdentity que verifica o sub do token OIDC, garantindo que apenas pods do namespace correto possam assumir aquela role. Isso previne privilege escalation mesmo que um pod consiga criar um ServiceAccount em outro namespace.

3. Isolamento de criptografia: Cada tenant tem uma KMS Customer Managed Key (CMK) própria. Os volumes EBS, os segredos no Secrets Manager e os dados no S3 de cada tenant são criptografados com a CMK do tenant. A key policy da CMK usa kms:ViaService e aws:SourceAccount conditions para garantir que apenas chamadas originadas dos serviços corretos possam usar a chave.

4. Isolamento de recursos: ResourceQuota e LimitRange por namespace previnem que um tenant monopolize CPU ou memória do node group compartilhado. Para tenants Gold, os taints nos nodes dedicados garantem que nenhum pod de outro tenant seja agendado lá, mesmo em situações de pressão de scheduling.

A decisão de investir em um operador customizado em vez de scripts Helm + kubectl foi a que mais gerou debate interno. O argumento contra era legítimo: operadores têm custo de desenvolvimento alto, introduzem um componente crítico no plano de controle e são difíceis de depurar quando o reconciliation loop entra em estado inconsistente.

O argumento a favor, que prevaleceu, foi baseado em três propriedades que scripts não têm:

Reconciliação contínua: Um script roda uma vez. Um operador observa continuamente o estado desejado versus o estado atual. Quando um engenheiro acidentalmente deletou uma NetworkPolicy de um tenant em produção (aconteceu), o operador a recriou em menos de 30 segundos, antes que qualquer tráfego não autorizado pudesse ocorrer. Com scripts, isso seria um incidente de segurança.

Gestão de ciclo de vida completo: O operador gerencia criação, atualização e deleção (com finalizers para garantir que dados não sejam deletados antes do backup). Um script de provisionamento raramente inclui lógica de deprovisioning segura, e quando inclui, é testada com muito menos rigor.

Status e observabilidade nativos: O CRD TenantWorkspace tem um campo .status.conditions com condições como StorageProvisioned, NetworkPolicyApplied, SecretsSync. Qualquer ferramenta que consuma a API do Kubernetes pode observar o estado de cada tenant em tempo real. Isso foi fundamental para o time de suporte: em vez de SSH em nodes, eles fazem kubectl get tenantworkspace -n platform-ops e veem o estado de todos os tenants em segundos.

O custo real do operador foi de aproximadamente 3 sprints de desenvolvimento e 1 sprint de hardening de testes de integração. O break-even operacional foi atingido no quarto mês, quando o número de tenants ultrapassou 60 e a complexidade de gerenciamento teria exigido contratar mais um engenheiro de operações.

PersistentVolumeClaims com EBS têm uma limitação fundamental que frequentemente surpreende equipes em migração: um volume EBS só pode ser montado em um único node por vez (ReadWriteOnce). Isso tem implicações diretas em estratégias de deployment.

Com Deployment (não StatefulSet), um rolling update pode tentar criar o novo pod em um node diferente antes que o pod antigo libere o volume, resultando em um estado onde o novo pod fica em ContainerCreating indefinidamente, aguardando o volume ser desanexado. Em ambientes financeiros com janelas de manutenção curtas, isso pode ser catastrófico.

A solução que adotamos foi tripla: (1) usar StatefulSet para todos os workloads com PVCs EBS, o que garante que o pod antigo seja terminado antes do novo ser criado; (2) configurar podManagementPolicy: Parallel apenas para StatefulSets onde a ordem de startup não importa (cache Redis), mantendo OrderedReady para os que têm dependências de inicialização; (3) implementar PodDisruptionBudget com minAvailable: 1 para garantir que drenos de node (durante upgrades do EKS) não removam o único pod de um tenant crítico sem um substituto pronto.

Para o caso de uso de artefatos compartilhados entre múltiplos pods do mesmo tenant (relatórios gerados assincronamente, por exemplo), EFS com ReadWriteMany foi a escolha correta, mas com uma ressalva importante: EFS tem latência de escrita significativamente maior que EBS para operações síncronas (tipicamente 1-5ms vs. 0.1-0.5ms para gp3). Qualquer path de código que escrevia no EFS de forma síncrona foi refatorado para escrita assíncrona via SQS, com o EFS sendo o destino final após processamento.

O erro mais comum que vejo em plataformas multitenant é tratar observabilidade como uma preocupação de infraestrutura, métricas de CPU, memória e latência agregadas no nível do cluster. Isso é inútil quando um cliente liga reclamando de lentidão: você não consegue isolar o problema sem dimensões de tenant.

A decisão arquitetural mais impactante na fase de observabilidade foi definir tenant_id como uma dimensão obrigatória em todas as métricas, traces e logs da plataforma. Isso foi implementado em três camadas:

Aplicação: O OTel SDK foi configurado com um Resource que inclui tenant.id e tenant.tier como atributos. Todos os spans herdam esses atributos automaticamente. No lado de métricas, usamos exemplars para vincular métricas de alta cardinalidade a traces específicos, fundamental para investigar P99 de um tenant específico.

Infraestrutura: CloudWatch Container Insights foi configurado com enhanced observability no EKS, que coleta métricas por pod com labels de Kubernetes. Um filtro de métricas no CloudWatch Logs Insights extrai tenant_id dos logs estruturados e cria métricas customizadas com essa dimensão.

SLO por tenant: No Datadog, cada tenant tem um SLO monitor independente. O burn rate alert usa uma janela de 1 hora (alerta rápido) e 6 horas (alerta de tendência). Quando o burn rate de 1 hora ultrapassa 14,4x (consumindo 2% do budget em 1 hora), um PagerDuty alert é criado com o tenant_id no título, o on-call sabe imediatamente qual tenant está impactado sem precisar investigar dashboards.

O custo de ingestão de métricas com alta cardinalidade foi uma preocupação real. A solução foi usar histogram_quantile no Prometheus (rodando como Managed Service via AMP) para métricas de latência, em vez de gauges por percentil, reduzindo a cardinalidade em 80% com precisão equivalente para SLOs.