Migrando Workloads Financeiros para EC2 R8i: Decisões e Trade-offs

Em ambientes financeiros de alta frequência, plataformas de liquidação em tempo real, motores de precificação de derivativos, caches de dados de mercado, o R6in era o teto prático durante anos. Com 100 Gbps de largura de banda de rede no tamanho 32xlarge, ele era suficiente para a maioria dos clusters Kafka/MSK de 2022. Mas o mercado não ficou parado.

O problema surgiu em três frentes simultâneas. Primeiro, os clusters MSK cresceram: tópicos de market data com retenção de 72 horas e fatores de replicação 3 começaram a saturar a largura de banda de rede dos brokers em horários de pico de volatilidade, exatamente quando você menos quer throttling. Segundo, os índices de banco de dados NoSQL (DynamoDB Accelerator em modo cluster, ScyllaDB auto-gerenciado) passaram a exigir IOPS de EBS na faixa de 256.000 por instância, e o R6ib com seu teto de ~260 Gbps de EBS começou a mostrar latências de leitura acima de 500µs no P99, inaceitável para um motor de risco intraday. Terceiro, os pipelines de ML para detecção de fraude em tempo real, rodando em instâncias do mesmo cluster, precisavam de largura de banda de rede suficiente para trafegar feature vectors de alta dimensão entre nós sem introduzir jitter mensurável.

A combinação dessas três pressões criou um cenário claro: a geração R6i estava sendo usada no limite do envelope de performance, sem margem para crescimento orgânico. A expansão regional do R8i para os datacenters onde essas plataformas operam: Tokyo para mercados asiáticos, Frankfurt e Irlanda para compliance europeu sob MiFID II, tornou a migração não apenas desejável, mas necessária.

O número 600 Gbps de largura de banda de rede no R8in/R8idn precisa de contexto para ser útil. Em termos práticos, isso é 75 GB/s de throughput sustentado, suficiente para replicar um snapshot de 1 TB em menos de 14 segundos entre instâncias no mesmo placement group. Para um broker MSK com retenção de 72 horas e 50 partições por tópico, isso significa que o rebalanceamento de partições após uma falha de broker pode completar em segundos em vez de minutos, reduzindo drasticamente a janela de exposição a lag de consumidor.

Mas o número bruto esconde uma nuance importante: a largura de banda é compartilhada entre todas as interfaces de rede da instância, incluindo tráfego de replicação intra-cluster, tráfego de dados de aplicação e tráfego de gerenciamento. Em clusters MSK com alto volume de replicação, vi cenários onde 40% da largura de banda disponível era consumida por replicação interna, deixando 360 Gbps para tráfego de produção. Ainda assim, 360 Gbps é 3,6x o teto do R6in, o que representa uma margem operacional completamente diferente.

O suporte a EFA nos tamanhos maiores adiciona uma dimensão qualitativa, não apenas quantitativa. EFA bypassa o kernel TCP/IP para comunicação inter-nó usando RDMA-like semantics via libfabric, reduzindo latência de comunicação de dezenas de microssegundos para sub-10µs em condições ideais. Para um motor de precificação de opções que executa Monte Carlo distribuído entre 96 vCPUs em múltiplas instâncias, essa redução de latência de comunicação se traduz diretamente em redução do tempo de ciclo de simulação, o que, em um contexto de trading, pode ser a diferença entre uma cotação chegando dentro ou fora da janela de validade.

A configuração prática para EFA em clusters de computação financeira: use placement group do tipo 'cluster', habilite enhanced networking com ENA Express (disponível no R8i), e configure o MTU para 9001 bytes (jumbo frames) em toda a VPC subnet usada pelo cluster. Sem jumbo frames, você deixa throughput na mesa.

A expansão do R8i para Frankfurt (eu-central-1) e Irlanda (eu-west-1) não é geograficamente trivial para plataformas financeiras europeias. Sob MiFID II e DORA (Digital Operational Resilience Act, vigente desde janeiro de 2025), instituições financeiras que operam em mercados europeus precisam demonstrar que seus sistemas críticos têm resiliência operacional documentada, com RTO e RPO definidos e testados. A escolha de região não é apenas de latência, é de soberania de dados e conformidade regulatória.

Frankfurt é a região preferida para dados de clientes alemães e austríacos sob o BDSG (Bundesdatenschutzgesetz) e para operações que precisam permanecer dentro da jurisdição do Regulamento Geral de Proteção de Dados (RGPD) alemão. Irlanda cobre o restante da União Europeia com menor custo operacional. A disponibilidade do R8i em ambas as regiões significa que posso construir uma arquitetura ativa-ativa entre eu-central-1 e eu-west-1 usando R8in para os brokers MSK de cada região, com replicação cross-region via MirrorMaker 2, e agora com hardware homogêneo nas duas pontas, o que elimina assimetrias de performance que antes complicavam o capacity planning.

Um detalhe operacional crítico para compliance: os volumes EBS io2 Block Express criptografados com CMK regional não podem ser copiados cross-region sem re-criptografia explícita. O processo correto é usar AWS Backup com planos de backup cross-region, garantindo que a chave de destino em eu-west-1 seja uma CMK separada com política de acesso auditada. Isso deve estar documentado em um ADR (Architecture Decision Record) com a justificativa regulatória, auditores do DORA vão perguntar especificamente sobre esse fluxo.

Para Tokyo (ap-northeast-1), o contexto é diferente: a FSA (Financial Services Agency) japonesa exige que dados de transações de clientes japoneses residam em território japonês. A disponibilidade do R8i em Tokyo significa que plataformas que antes usavam R6in em ap-northeast-1 com workarounds de capacidade podem agora operar com o mesmo envelope de hardware disponível nas regiões americanas e europeias, paridade que tem impacto direto na capacidade de oferecer SLAs consistentes globalmente.

Uma migração de geração de instância em ambiente financeiro sem observabilidade adequada é uma operação cega. O que aprendi ao longo de múltiplas migrações similares é que os problemas raramente aparecem no momento da virada, eles emergem 6 a 18 horas depois, quando padrões de carga que não estavam presentes durante o teste de smoke começam a se manifestar.

A stack de observabilidade que uso para esse tipo de migração combina três camadas. Na camada de infraestrutura, CloudWatch Container Insights (para workloads containerizados) e CloudWatch Agent com configuração de métricas de alta resolução (1 segundo) para as métricas críticas: NetworkIn, NetworkOut, EBSReadBytes, EBSWriteBytes, EBSReadOps, EBSWriteOps e o frequentemente ignorado BurstBalance, que em instâncias com créditos de burst pode mascarar um problema de throughput por horas antes de colapsar.

Na camada de aplicação, uso OpenTelemetry com exportação para CloudWatch Logs via OTLP, capturando spans de latência de operações críticas: tempo de produção de mensagem Kafka, tempo de leitura de ScyllaDB por operação, e tempo de ciclo de simulação do motor de risco. Esses spans são correlacionados com as métricas de infraestrutura via trace_id propagado como atributo de métrica customizada, o que permite, em um único dashboard, ver que um spike de latência de aplicação coincide com um evento de throttling de EBS.

Na camada de negócio, defino SLIs específicos para o contexto financeiro: taxa de ordens processadas por segundo, latência de confirmação de ordem (P50/P95/P99/P99.9), e taxa de rejeição por timeout. Esses SLIs são os critérios finais de sucesso da migração, não métricas de infraestrutura. Uma migração que melhora o throughput de EBS mas aumenta a taxa de timeout de ordens é uma migração que falhou, independentemente dos números de hardware.

Para o R8i especificamente, adicionei um alarme em NetworkBandwidthOutAllowanceExceeded, uma métrica que indica quando a instância está sendo throttled na saída de rede. Com 600 Gbps disponíveis, esse alarme raramente deveria disparar, mas sua ausência de configuração é um ponto cego clássico que só se descobre em incidentes.