Rodar workloads de produção em OCI Container Instances (CI) oferece a agilidade do modelo serverless combinada com a profundidade dos serviços core da Oracle Cloud Infrastructure. No entanto, para empresas brasileiras que confiam na tecnologia para crescer, o desafio vai além da implementação: trata-se de garantir a resiliência. Em cenários de desastre regional ou interrupções severas de serviço, a capacidade de migrar o tráfego e restabelecer a operação em uma região secundária não é apenas um requisito técnico, é uma necessidade de continuidade de negócios.
Construir um plano de Disaster Recovery (DR) robusto para Container Instances exige uma visão holística que vai além da simples replicação. É necessário orquestrar a infraestrutura computacional, as políticas de IAM, o controle de segredos e, fundamentalmente, a camada de dados.
Pré-requisitos para a Resiliência
A eficácia do seu plano de DR depende da consistência entre as regiões. Não basta que a aplicação rode; todo o ecossistema deve ser espelhado:
- OCI Networking: VCNs, subnets, Security Lists/NSGs e gateways devem estar mapeados em ambos os ambientes. O uso de Private DNS é crítico aqui: garanta que as zonas e caminhos de resolução sejam replicados.
- Governança de IAM: Políticas, compartimentos e grupos dinâmicos precisam ter paridade entre as regiões para que a automação não falhe por falta de permissão.
- Service Limits: Um erro comum é ignorar as cotas de consumo. Valide se a região DR possui capacidade de processamento, memória e limites de balanceamento de carga suficientes para absorver o tráfego da produção.
- Vault e Secrets: A gestão de chaves deve ser regional, mas com mecanismos de acesso previsíveis que permitam à aplicação autenticar-se em qualquer uma das regiões de destino.
Estratégias de Failover
Ao desenhar o DR, você deve optar pelo modelo de custo-efetividade alinhado à sua criticidade:
- Active/Passive (Warm Standby): A região DR permanece subutilizada ou pronta para escala. É a via mais simples e econômica, porém aceita algum RTO (Recovery Time Objective) e possíveis lacunas de dados.
- Active/Active: Ambas as regiões servem tráfego. Oferece o menor RTO e latência otimizada, mas exige uma sofisticação muito maior na gestão de consistência de dados e controle de estado.
Governança de Artefatos e Dados
O uso do OCI Container Registry (OCIR) com políticas de replicação cross-region é mandatório. Recomenda-se o uso de digests imutáveis, evitando o uso de tags que podem causar ambiguidades em momentos de crise. Para a camada de persistência, utilize replicação nativa dos serviços de banco de dados (ex: Autonomous Database) e, no caso de Object Storage, configure a replicação de buckets entre as regiões para garantir que blobs e artefatos essenciais não sejam perdidos.
Automação via IaC
O uso de Infrastructure as Code (IaC), através de ferramentas como Terraform, é o divisor de águas. Ao modularizar sua infraestrutura — separando redes, IAM e CI deployments — você reduz drasticamente o "configuration drift". A parametrização por região permite que o mesmo blueprint seja implantado com segurança em qualquer lugar, eliminando a dependência do conhecimento tribal de um único engenheiro no momento da falha.
Validação Contínua
Um plano de DR que não é testado é, na prática, um plano inexistente. Exercícios de DR, sejam eles planejados ou baseados em simulações de isolamento regional, são essenciais para verificar se o RPO/RTO condiz com a realidade técnica do seu ambiente.
Artigo originalmente publicado por Kevin Liu em cloud-infrastructure.
