Capítulo 37 — Infraestrutura e Computação em Nuvem

37.1 Objetivo do Capítulo

Este capítulo detalha a arquitetura de infraestrutura da Plataforma de Relacionamento Digital com o Cidadão, descrevendo como recursos computacionais, de armazenamento e de rede são provisionados, organizados em topologias resilientes, e operados de forma consistente entre ambientes de desenvolvimento, homologação e produção.

A plataforma é projetada para executar em três modalidades de infraestrutura: cloud híbrida (infraestrutura PRODEMGE integrada com nuvem pública), nuvem pública externa (modalidade de contratação na qual o parceiro privado provisiona toda a infraestrutura em cloud pública), e on-premise (hospedagem em datacenter próprio do cliente). A decisão de modalidade é prerrogativa da PRODEMGE e do cliente contratante, registrada no Anexo I.

Independente da modalidade, a arquitetura segue princípios de alta disponibilidade, segurança, automação, e observabilidade detalhados neste capítulo.

37.2 Modalidades de Implantação

37.2.1 Cloud Híbrida

A modalidade cloud híbrida combina infraestrutura on-premise do contratante com serviços de nuvem pública para elasticidade:

┌─────────────────────────────────────────────┐
│            Cloud Híbrida                    │
│                                              │
│  ┌──────────────┐      ┌──────────────┐      │
│  │  On-Premise  │      │   Nuvem       │      │
│  │  Datacenter  │─────▶│   Pública     │      │
│  │              │      │               │      │
│  │ • Sensitive  │      │ • Elástico   │      │
│  │ • Compliance │      │ • Global CDN │      │
│  │ • Latência   │      │ • Multi-AZ   │      │
│  │   crítica    │      │   replicação │      │
│  └──────────────┘      └──────────────┘      │
│         │                     │               │
│         └─────────┬───────────┘               │
│                   │                            │
│          Conexão dedicada (Direct Connect      │
│          ou ExpressRoute)                     │
└─────────────────────────────────────────────┘

Dados sensíveis permanecem no datacenter privado; capacidade elástica para picos é provisionada em nuvem pública. Conexão dedicada garante baixa latência entre ambientes.

37.2.2 Nuvem Pública

Toda a infraestrutura provisionada em um provedor de cloud pública:

┌─────────────────────────────────────────────┐
│            Nuvem Pública                     │
│                                              │
│  Região principal (ex.: São Paulo)            │
│  ├─ Multi-AZ (3+ availability zones)         │
│  ├─ Kubernetes gerenciado (EKS/GKE/AKS)     │
│  ├─ RDS / banco gerenciado                  │
│  ├─ Object storage (S3 / Blob / GCS)         │
│  └─ CDN global                              │
│                                              │
│  Região secundária (ex.: Rio de Janeiro)     │
│  ├─ Réplicas de leitura                      │
│  ├─ Backup criptografado                    │
│  └─ Disaster Recovery                       │
└─────────────────────────────────────────────┘

Benefícios: agilidade de provisionamento, multiplicidade de serviços gerenciados, cobertura geográfica.

37.2.3 On-Premise

Infraestrutura em datacenter próprio:

┌─────────────────────────────────────────────┐
│            On-Premise                        │
│                                              │
│  ┌─────────────────────────────────────┐    │
│  │  Cluster Kubernetes                  │    │
│  │  ├─ 3+ master nodes                  │    │
│  │  ├─ Worker nodes (compute pool)      │    │
│  │  └─ Storage (NAS/SAN)                │    │
│  └─────────────────────────────────────┘    │
│                                              │
│  ┌─────────────────────────────────────┐    │
│  │  Banco de dados                      │    │
│  │  ├─ Primária                         │    │
│  │  └─ Réplicas assíncronas             │    │
│  └─────────────────────────────────────┘    │
│                                              │
│  ┌─────────────────────────────────────┐    │
│  │  Rede                                │    │
│  │  ├─ Firewall                         │    │
│  │  ├─ Load balancer                    │    │
│  │  └─ DNS interno                      │    │
│  └─────────────────────────────────────┘    │
└─────────────────────────────────────────────┘

Adequada para organizações com requisitos rígidos de soberania de dados ou que já possuem datacenter.

37.3 Princípios da Infraestrutura

A plataforma segue dez princípios de infraestrutura:

1. Infraestrutura como Código (IaC) — toda configuração é descrita em código versionado, não em cliques manuais. Mudanças são revisadas, testadas e aplicadas de forma controlada.

2. Imutabilidade — recursos são substituídos em vez de modificados. Em vez de atualizar um servidor, cria-se um novo a partir de imagem imutável e descarta-se o antigo.

3. Configuração Declarativa — declaramos o estado desejado (YAML, Terraform, Helm); ferramentas convergem para esse estado automaticamente.

4. Repetibilidade — mesmo código, mesmo resultado. Ambientes de desenvolvimento, homologação e produção usam pipelines idênticos.

5. Observabilidade — métricas, logs e traces são cidadãos de primeira ordem. Decisões são baseadas em dados.

6. Segurança por Design — segurança é incorporada desde o provisionamento, não adicionada depois.

7. Custo Otimizado — recursos são dimensionados conforme uso real; recursos ociosos são identificados e eliminados.

8. Resiliência — falhas são tratadas como normais. Sistema degrada graciosamente em vez de falhar catastroficamente.

9. Segregação por Tenant — recursos são organizados de modo a preservar isolamento multi-tenant (namespaces Kubernetes separados, redes dedicadas por tenant quando necessário).

10. Portabilidade — workloads são portáveis entre provedores via containers e Kubernetes. Decisões específicas de provedor ficam isoladas em camada de adaptadores.

37.4 Computação em Nuvem — Topologia

37.4.1 Regiões e Zonas de Disponibilidade

A infraestrutura é distribuída geograficamente:

Região primária (ex.: São Paulo)
├─ AZ-1 (zona de disponibilidade 1)
├─ AZ-2
└─ AZ-3

Região secundária (ex.: Rio de Janeiro) — backup/disaster recovery
├─ AZ-1
└─ AZ-2

Serviços críticos têm réplica em pelo menos 3 zonas de disponibilidade na região primária. Serviços de menor criticidade usam 2 zonas. A região secundária é usada apenas para disaster recovery.

37.4.2 Componentes Principais

┌──────────────────────────────────────────────────────┐
│  Camada de Borda                                     │
│  CDN (CloudFlare, CloudFront, Cloud CDN)             │
│  WAF (Web Application Firewall)                      │
│  DDoS protection                                     │
└──────────────────┬───────────────────────────────────┘
                   │
┌──────────────────▼───────────────────────────────────┐
│  Camada de Entrada                                  │
│  API Gateway (Kong, AWS API GW, Apigee)              │
│  Load Balancer (NLB / ALB)                          │
│  DNS (Route53, Azure DNS, Cloud DNS)                │
└──────────────────┬───────────────────────────────────┘
                   │
┌──────────────────▼───────────────────────────────────┐
│  Camada de Aplicação                                │
│  Kubernetes Cluster (EKS/GKE/AKS)                    │
│  ├─ API Services                                    │
│  ├─ Backend Services                                │
│  ├─ Workers assíncronos                              │
│  └─ CronJobs / Batch                                │
└──────────────────┬───────────────────────────────────┘
                   │
┌──────────────────▼───────────────────────────────────┐
│  Camada de Dados                                    │
│  PostgreSQL (gerenciado ou auto-hospedado)           │
│  Redis cluster                                      │
│  Object Storage (S3 / Blob / GCS)                   │
│  Search engine (ElasticSearch)                      │
│  Vector store                                       │
└──────────────────┬───────────────────────────────────┘
                   │
┌──────────────────▼───────────────────────────────────┐
│  Camada de Observabilidade                          │
│  Prometheus + Grafana                                │
│  Elasticsearch + Kibana / Loki                       │
│  Jaeger / Tempo / Zipkin                            │
│  Alertmanager                                       │
└──────────────────────────────────────────────────────┘

37.5 Kubernetes como Plataforma de Orquestração

37.5.1 Kubernetes como Padrão

A plataforma adota Kubernetes como runtime padrão para containers. Decisão registrada em ADR-501.

Kubernetes é um sistema open-source de orquestração de containers que automatiza deploy, escalonamento, e operação de aplicações containerizadas. Oferece:

orquestração declarativa (YAML manifests);
self-healing (containers que falham são reiniciados automaticamente);
horizontal scaling (réplicas conforme carga);
service discovery (DNS interno);
rolling updates e rollbacks;
gestão de configuração e secrets;
armazenamento persistente.

37.5.2 Cluster Architecture

┌─────────────────────────────────────────────────┐
│            Cluster Kubernetes                     │
│                                                  │
│  ┌───────────────────────────────────────┐      │
│  │  Control Plane (Master)               │      │
│  │  ├─ API Server (3 réplicas)           │      │
│  │  ├─ etcd cluster (3 réplicas)         │      │
│  │  ├─ Scheduler                         │      │
│  │  └─ Controller Manager                │      │
│  └───────────────────────────────────────┘      │
│                                                  │
│  ┌───────────────────────────────────────┐      │
│  │  Worker Nodes                         │      │
│  │                                        │      │
│  │  System Node Pool                      │      │
│  │  ├─ CoreDNS                            │      │
│  │  ├─ Metrics Server                     │      │
│  │  └─ Ingress Controller                 │      │
│  │                                        │      │
│  │  Application Node Pool                 │      │
│  │  ├─ Stateless services                 │      │
│  │  ├─ API gateway                        │      │
│  │  └─ Frontend                          │      │
│  │                                        │      │
│  │  Stateful Node Pool                    │      │
│  │  ├─ Stateful services                  │      │
│  │  └─ Workers com volumes               │      │
│  └───────────────────────────────────────┘      │
└─────────────────────────────────────────────────┘

37.5.3 Namespaces para Isolamento Multi-Tenant

Cada tenant tem seu próprio namespace Kubernetes:

namespace: tenant-org-a
  ├─ Deployments (microsserviços específicos)
  ├─ Services
  ├─ ConfigMaps
  ├─ Secrets (com criptografia)
  └─ Network Policies (isolamento de rede)

namespace: tenant-org-b
  ├─ ...
  └─ ...

Network Policies restringem comunicação entre namespaces, garantindo que um tenant não consegue acessar pods de outro tenant mesmo que estejam no mesmo cluster.

37.5.4 Resource Limits e Requests

Cada deployment declara recursos mínimos (requests) e máximos (limits):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-solicitacoes
  namespace: tenant-org-a
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: api
        image: registry.example.com/api-solicitacoes:1.2.3
        resources:
          requests:
            cpu: 250m
            memory: 512Mi
          limits:
            cpu: 1000m
            memory: 2Gi
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5

37.5.5 Auto-Scaling

Auto-scaling Horizontal (HPA) ajusta réplicas conforme carga:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-solicitacoes-hpa
  namespace: tenant-org-a
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-solicitacoes
  minReplicas: 3
  maxReplicas: 30
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Pods
    pods:
      metric:
        name: requests_per_second
      target:
        type: AverageValue
        averageValue: "100"

37.5.6 Auto-Scaling Vertical (VPA)

VPA ajusta requests/limits automaticamente conforme uso histórico. Útil para workloads estáveis (ex.: banco de dados gerenciado em cluster).

37.5.7 Cluster Autoscaler

Cluster Autoscaler provisiona novos nós quando pods ficam pendentes por falta de recursos:

Quando HPA escala Deployment para 10 réplicas
  └─ Cluster verifica se há nós suficientes
      └─ Se não, provisiona novo nó
          └─ Pods são agendados no novo nó

Em cloud pública, novos nós são criados a partir de imagens pré-configuradas em minutos. Em on-premise, há pool de nós standby.

37.6 Armazenamento

37.6.1 Armazenamento de Objetos

Para documentos, imagens, anexos, vídeos:

Object Storage (S3 / Azure Blob / GCS)
├─ Bucket: cidadao-documents
│  ├─ tenant-org-a/
│  ├─ tenant-org-b/
│  └─ tenant-org-c/
└─ Lifecycle policies:
   ├─ 30 dias: storage class Standard
   ├─ 90 dias: storage class Infrequent Access
   └─ 365 dias: storage class Glacier (cold)

Lifecycle policies movem objetos para classes de armazenamento mais baratas conforme envelhecem.

37.6.2 Volumes Persistentes em Kubernetes

Para bancos de dados e serviços com estado:

StorageClass: gp3 (General Purpose SSD)
  ├─ ReadWriteOnce (RWO) — usado por bancos
  └─ Provisionamento dinâmico

StorageClass: ssd-replicated
  ├─ Replicação síncrona entre AZs
  └─ ReadWriteOnce

PersistentVolumeClaim:
  apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
    name: postgres-data
    namespace: tenant-org-a
  spec:
    storageClassName: gp3
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 100Gi

37.6.3 Backup de Volumes

Snapshots de volumes persistentes:

VolumeSnapshot
├─ Frequência: 6h para dados críticos; 24h para outros
├─ Retenção: 7 dias local + 30 dias em storage separado
└─ Restore: testado trimestralmente em staging

37.7 Rede

37.7.1 Topologia de Rede

┌─────────────────────────────────────────────┐
│  Internet                                   │
└──────────────┬──────────────────────────────┘
               │
       ┌───────▼────────┐
       │  CDN (CloudFront│
       │  / CloudFlare)  │
       │  + WAF + DDoS   │
       └───────┬────────┘
               │
       ┌───────▼────────┐
       │  DNS (Route53)  │
       └───────┬────────┘
               │
       ┌───────▼────────┐
       │  Load Balancer  │
       │  (NLB / ALB)    │
       └───────┬────────┘
               │
       ┌───────▼────────┐
       │  API Gateway    │
       │  + Rate Limit   │
       └───────┬────────┘
               │
       ┌───────▼────────┐
       │  Kubernetes     │
       │  Services       │
       └────────────────┘

37.7.2 Subnets e Segurança

VPC (Virtual Private Cloud) com subnets segregadas:

VPC: 10.0.0.0/16
├─ Subnet Public (10.0.1.0/24)
│  ├─ NAT Gateway
│  ├─ Bastion host
│  └─ Load Balancers
│
├─ Subnet Private Application (10.0.10.0/24)
│  ├─ API Services
│  ├─ Backend Services
│  └─ Workers
│
├─ Subnet Private Data (10.0.20.0/24)
│  ├─ PostgreSQL
│  ├─ Redis
│  └─ ElasticSearch
│
└─ Subnet Management (10.0.100.0/24)
   ├─ Monitoring
   ├─ Logging
   └─ Backup

Database subnets não têm rota para internet. Application subnets acessam internet via NAT. Management subnets acessam serviços internos apenas.

37.7.3 Network Policies Kubernetes

Restrições granulares de comunicação:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: tenant-org-a-isolation
  namespace: tenant-org-a
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          tenant: org-a
    - namespaceSelector:
        matchLabels:
          name: ingress-nginx
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          tenant: org-a
    - namespaceSelector:
        matchLabels:
          name: kube-system

Apenas pods do mesmo tenant e pods de sistema podem se comunicar. Cross-tenant é bloqueado por padrão.

37.7.4 Conectividade Privada com Sistemas Externos

Para integrações com SEI!MG, GOV.BR, e sistemas legados:

Plataforma
    │
VPN Site-to-Site ou Direct Connect
    │
SEI!MG (rede privada PRODEMGE)
    │
GOV.BR (endpoint público com mTLS)

Conexões privadas evitam exposição à internet pública. mTLS garante autenticação mútua.

37.8 CDN e Edge Computing

37.8.1 CDN para Conteúdo Público

Conteúdo público (portal institucional, FAQ, ajuda) é servido via CDN:

Cliente em São Paulo
    │
    └─ DNS resolve para edge node mais próximo
         │
         └─ Edge node serve conteúdo cacheado
              │
              └─ Se miss, consulta origin (backend)

Latência cai de 200ms para 20ms em média.

37.8.2 WAF (Web Application Firewall)

WAF protege contra ataques comuns:

SQL injection;
Cross-site scripting (XSS);
Cross-site request forgery (CSRF);
Path traversal;
Bad bots.

Regras são gerenciadas via WAF gerenciado (AWS WAF, Cloudflare WAF) ou auto-hospedado (ModSecurity).

37.8.3 DDoS Protection

Proteção contra ataques de negação de serviço:

Rate limiting agressivo em edge;
Detecção de padrões de tráfego anômalo;
Absorção de tráfego via scrubbing center (cloud providers oferecem);
Blackhole routing em caso de ataque massivo (sacrifica origem, mas protege plataforma).

37.9 Segurança de Infraestrutura

37.9.1 Princípio de Zero Trust

A infraestrutura adopta Zero Trust: nenhum acesso é implicitamente confiado. Toda comunicação é autenticada, autorizada e encriptada.

Cilindro de Segurança:

┌─────────────────────────────────┐
│  Acesso ao cluster Kubernetes    │
│  ├─ RBAC (Role-Based Access)     │
│  ├─ ABAC (Attribute-Based)       │
│  └─ PSA (Pod Security Admission) │
│                                  │
│  Comunicação entre pods          │
│  ├─ mTLS obrigatório             │
│  ├─ Network policies             │
│  └─ Service mesh (Istio/Linkerd) │
│                                  │
│  Acesso a dados                  │
│  ├─ Credenciais rotacionadas     │
│  ├─ Criptografia em trânsito     │
│  └─ Criptografia em repouso      │
│                                  │
│  Acesso a infraestrutura         │
│  ├─ VPN necessária               │
│  ├─ Bastion host com MFA         │
│  └─ Auditoria de tudo            │
└─────────────────────────────────┘

37.9.2 Segredos e Configuração

Configuração armazenada como ConfigMaps e Secrets Kubernetes:

# ConfigMap — dados não-sensíveis
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  namespace: tenant-org-a
data:
  LOG_LEVEL: "INFO"
  SERVICE_NAME: "api-solicitacoes"

# Secret — dados sensíveis, criptografados em repouso
apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
  namespace: tenant-org-a
type: Opaque
data:
  username: dXNlcm5hbWU=  # base64 encoded
  password: cGFzc3dvcmQ=  # base64 encoded

Secrets são criptografados em repouso no etcd usando chave rotacionada. External Secrets Operator (ESO) sincroniza secrets de vault (HashiCorp, AWS Secrets Manager, Azure Key Vault) para Kubernetes, permitindo rotação centralizada.

37.9.3 Container Image Scanning

Imagens de container são escaneadas por vulnerabilidades:

Build pipeline
    │
    ├─ Build container image
    │
    ├─ Scan por CVEs (Trivy, Grype, Snyk)
    │
    ├─ Se vulnerabilidades críticas encontradas
    │  └─ Build rejeitado
    │
    └─ Se OK, push para registry com assinatura

Registry requer assinatura de imagem (Notary / Cosign) antes de permitir pull em produção.

37.9.4 Criptografia em Repouso

Dados sensíveis em repouso são criptografados:

Banco de dados    → Criptografia nativa (Transparent Data Encryption)
Volumes          → Criptografia em nível de storage (LUKS, EBS encryption)
Object Storage   → Criptografia por objeto (SSE-S3 / SSE-KMS)
Secrets Kubernetes → Criptografia envelope (KMS externo)
Backups          → AES-256 com chave de backup rotacionada

Chaves de criptografia são armazenadas em Key Management Service (KMS) gerenciado, nunca no application code.

37.9.5 Criptografia em Trânsito

Toda comunicação é criptografada:

Cliente → Edge / WAF    → TLS 1.3 obrigatório
Edge → Load Balancer    → TLS 1.3
LB → API Gateway        → TLS interna + mTLS
API GW → Serviços       → mTLS + Network encryption
Serviços → Banco        → SSL/TLS + Encryption layer

37.9.6 Conformidade de Patches

Patches de segurança são aplicados conforme SLA:

Severidade	SLA	Aplicação
Critical	24h	Janela de manutenção ou rolling update com zero downtime
High	3 dias	Próximo deployment agendado
Medium	7 dias	Próximo release planejado
Low	30 dias	Próximo release

Patches de Kubernetes são gerenciados por GKE/EKS/AKS para versão gerenciada, ou por operador em on-premise.

37.10 Monitoramento e Observabilidade de Infraestrutura

37.10.1 Métricas

Métricas de infraestrutura são coletadas via Prometheus:

Node Exporter (métricas do host)
├─ CPU utilization
├─ Memory usage
├─ Disk I/O
└─ Network throughput

Kubelet (métricas Kubernetes)
├─ Pod CPU/Memory
├─ Container restart count
└─ Volume usage

Custom metrics (via Prometheus SD)
├─ Database connections
├─ Cache hit rate
└─ API latency (p50, p95, p99)

Retenção de métricas: 15 dias local, 1 ano em storage frio (S3).

37.10.2 Alertas

Alertas são gerados por condições anômalas:

Node CPU > 85% por 5 min
    └─ Alertas para on-call
       └─ Auto-scaling HPA (mitigação automática)
       └─ Manual: adicionar workers ou otimizar

Database connections pool exhausted
    └─ Alertas críticos
    └─ Kill queries longas automaticamente
    └─ Escalar se persistir

Storage capacity < 10%
    └─ Alertas para provisioning team
    └─ Cleanup automático (lixo, logs antigos)

Alertas são roteados por severidade: crítico via PagerDuty, warning via Slack, info via log.

37.10.3 Logs

Logs de infraestrutura e aplicação são centralizados:

Kubelet logs
    │
Application logs (stdout/stderr)
    │
Cloud provider logs (VPC Flow Logs, ALB logs)
    │
        ├─ Agregação (Fluent Bit / Logstash)
        │
        └─ Elasticsearch / Loki / S3
            │
            └─ Kibana / Grafana / Athena (análise)

Retenção: 7 dias em hot storage (Elasticsearch), 90 dias em warm (S3), 1 ano em cold (Glacier).

37.10.4 Traces Distribuídos

Traces de requisição end-to-end para latência e erros:

Cliente (trace ID injected)
    │
API Gateway (trace começado)
    │
Serviço A (span para operação DB)
    │
RabbitMQ (propagação via headers)
    │
Serviço B (span para chamada a serviço externo)
    │
        └─ Trace completo enviado a Jaeger/Tempo/Zipkin

Query em Jaeger:
  "Requisições com latência > 500ms"
  └─ Exibe breakdown: API GW 50ms, Serviço A 300ms, RabbitMQ 100ms

37.11 Backup e Disaster Recovery

37.11.1 Estratégia de Backup

RPO (Recovery Point Objective): 1 hora
RTO (Recovery Time Objective): 4 horas

Banco de dados (PostgreSQL)
├─ Backup automático: 6h (point-in-time recovery até 7 dias)
├─ Backup full: semanal (retenção 30 dias)
└─ Replicação contínua para região secundária

Kubernetes manifests / Helm charts
├─ Versionados em Git
├─ Backup: 24h (CI/CD replicado para disaster recovery site)
└─ Reconstrução: redeploy a partir de Git

Object Storage (documentos, imagens)
├─ Replicação cross-region assíncrona
├─ Versioning ativo
└─ WORM (Write-Once-Read-Many) para documentos auditados

Secrets (credenciais, chaves)
├─ Armazenadas em KMS (nunca em Git)
├─ Backup: 24h para vault externo
└─ Rotação contínua: 90 dias

37.11.2 Teste de Restauração

Backups são inúteis se não puderem ser restaurados. Testes são mandatórios:

Banco de dados
├─ Restauração mensal em staging
├─ Verificação de integridade de dados
└─ Recalibração de snapshots se falhar

Kubernetes
├─ Redeploy trimestral a partir do Git
├─ Verificação de recursos críticos (Ingress, Secrets)
└─ Teste de failover entre regiões

Object Storage
├─ Teste de acesso a backups antigos (1 ano)
└─ Verificação de checksum para integridade

37.12 Custo e Otimização

37.12.1 Dimensionamento Apropriado

Recursos são dimensionados conforme padrão real de uso:

Peak load (14h-18h em dias úteis)
├─ Definir min replicas com base em baseline
└─ Max replicas com base em peak

Off-peak (22h-6h)
├─ Scale down para reduzir custo
└─ Manter mínimo para warmup rápido

Weekends / feriados
├─ Reduzir replicas permanentemente
└─ Considerar "scale-to-zero" para serviços não críticos

37.12.2 Rightsizing de Instâncias

Métricas de utilização informam se instâncias estão sobredimensionadas:

Métrica | Ação
CPU < 20% | Considerar downsizing
Memory < 40% | Considerar downsizing
Network < 10% | Considerar downsizing
Disk < 30% | Implementar cleanup

Revisão trimestral de rightsizing economiza até 30% do orçamento de infraestrutura.

37.12.3 Compras em Volume

Provadores de cloud oferecem descontos para compras antecipadas (Reserved Instances, Committed Use Discounts):

On-Demand (padrão)
├─ Custo: 100%
└─ Flexibilidade: máxima

1-Year Reserved Instance
├─ Desconto: 25-35%
└─ Flexibilidade: mínima

3-Year Reserved Instance
├─ Desconto: 50-70%
└─ Flexibilidade: mínima (melhor ROI)

Spot instances (desconto 70-90%)
├─ Custo: mínimo
└─ Risco: interrupção com 2 min de aviso
└─ Uso: workloads fault-tolerant (batch, cache warmup)

Estratégia híbrida: Reserved para baseline, On-Demand para elasticidade, Spot para adicional se disponível.

37.13 Operação e Runbooks

37.13.1 Procedimento de Deploy

1. Pull request com change (IaC, manifests, imagens)
2. Aprovação por 2+ arquitetos
3. CI/CD executa
   ├─ Testes automatizados
   ├─ Security scanning
   ├─ Deploy a staging
   └─ Testes de integração
4. Deploy a produção (canary 10% → 50% → 100%)
5. Monitoramento pós-deploy por 1h
6. Rollback automático se taxa de erro > threshold

37.13.2 Incident Response

Quando incidente crítico é detectado:

1. Alerta dispara (PagerDuty / Opsgenie)
2. On-call recebe notificação (SMS + push)
3. Investiga via Kibana / Grafana / kubectl
4. Executa runbook (ex.: "Banco sobrecarregado")
   ├─ Escalar manualmente
   ├─ Redirecionar tráfego
   ├─ Executar query para killer
   └─ Recolher dados para RCA
5. Pós-incidente: RCA em 24h, ação corretiva em 7 dias

37.13.3 Runbooks para Cenários Comuns

Runbook: Banco de dados respondendo lentamente

1. Verificar CPU/Memory de host
2. Listar queries longas
   SELECT * FROM pg_stat_statements ORDER BY mean_exec_time DESC
3. Executar ANALYZE em tabelas grandes
4. Se persistir, escalar para DBA

---

Runbook: Pod em CrashLoopBackOff

1. kubectl logs <pod> -n <namespace> --tail=50
2. Verificar events
   kubectl describe pod <pod> -n <namespace>
3. Verificar recursos
   kubectl top pod <pod> -n <namespace>
4. Se OOMKilled, aumentar memory limits
5. Se outros erros, revisar aplicação

37.14 Rastreabilidade com o Anexo III

O Capítulo 37 atende a itens transversais do Anexo III relacionados a infraestrutura:

Item ANX-III	Atendimento
6.1	Infraestrutura em nuvem pública, cloud híbrida ou on-premise com suporte a multi-tenant
6.2	Segregação de rede e recursos por tenant via namespaces Kubernetes e VPC
3.1	Arquitetura escalável e resiliente com auto-scaling e multi-AZ

37.16 Considerações Finais

A infraestrutura é a fundação invisível sobre a qual a plataforma opera. Quando bem desenhada, o usuário final nunca percebe sua existência — apenas sente a velocidade e a disponibilidade do sistema. Quando mal desenhada, cada falha se torna incidente, cada pico de carga vira indisponibilidade, e cada mês vira crise de custo.

A escolha de Kubernetes como runtime padrão, aliada a princípios de IaC, imutabilidade, configuração declarativa e observabilidade, garante que a plataforma escale de forma previsível e opere de forma consistente em qualquer modalidade de implantação — cloud híbrida, nuvem pública ou on-premise.

A separação rigorosa por tenant via namespaces Kubernetes e Network Policies, combinada com criptografia em trânsito e repouso, gerenciamento de secrets em KMS, e scanning contínuo de imagens, garante que a segurança não é um requisito adicional ao provisionamento, mas parte integrante dele.

O Capítulo 38 detalha CI/CD e DevSecOps, que automatiza o provisionamento e garante que mudanças sejam entregues com qualidade e velocidade.

37.17 Controle de Versão

Campo	Valor
Documento	Documento Mestre — Plataforma de Relacionamento Digital com o Cidadão
Capítulo	37 — Infraestrutura e Computação em Nuvem
Versão	1.0
Situação	Concluído
Última atualização	16/07/2026

37.18 Rastreabilidade PRODEMGE

[ANX-III] Bloco 6 — Segurança da infraestrutura (item 6.1): cloud híbrida, nuvem pública ou on-premise com suporte a multi-tenant.
[ANX-IV] Itens 3.1.3, 3.1.6, 3.1, 3.3.2 — arquitetura flexível, escalabilidade horizontal, alta disponibilidade, resiliência.
[ANX-V] Itens 2.4, 2.5 — continuidade de negócio via backup, disaster recovery; evolução facilitada por IaC.
[PNR] — Plano de Negócio Referencial: plataforma em cloud híbrida com Kubernetes gerenciado, multi-AZ, replicação cross-region.
[EDITAL] — Edital CP001/2026: requisitos de infraestrutura em cloud (item 3.1.3).

37.19 Decisões Arquiteturais

ADR	Tema
ADR-501	Kubernetes como plataforma padrão de orquestração
ADR-502	Isolamento de tenant via namespace Kubernetes + Network Policies
ADR-503	Backup: frequência, retenção, teste de restauração
ADR-504	Cloud provider: critérios de seleção (latência, conformidade, custo)
ADR-505	Auto-scaling: HPA para aplicação, CA para infraestrutura
ADR-506	Logging centralizado: Elasticsearch / Loki / S3 por tipo
ADR-507	Disaster Recovery: RPO/RTO por criticalidade de serviço
ADR-508	Criptografia: algoritmos, gestão de chaves, rotação
ADR-509	Networking: service mesh vs. network policies nativas
ADR-510	Armazenamento: object storage para documentos e logs

37.20 Benefícios da Infraestrutura

flexibilidade de implantação: cloud híbrida, nuvem pública ou on-premise;
escalabilidade horizontal automática conforme demanda;
alta disponibilidade com failover transparente;
isolamento de tenant estrutural via namespace e network policies;
observabilidade nativa via Prometheus, logs estruturados e tracing;
segurança por padrão: criptografia, secrets management, scanning de imagem;
disaster recovery automatizado com backup redundante;
custos previsíveis e otimizados via rightsizing e auto-scaling;
evolução facilitada por IaC — infraestrutura versionada e reproduzível.

37.21 Riscos e Mitigações

Risco	Consequência	Mitigação
Configuração incorreta de Network Policy	Cross-tenant communication	Validação de policies por ADR; testes automatizados de isolamento
Backup desatualizado	Perda de dados na recuperação	Backup testado regularmente; restore em ambiente de staging
Secret em log ou artifact	Exposição de credencial	Scanning de logs/artifacts; audit de acesso a secrets
Pod crash loop sem observabilidade	Tempo de diagnóstico longo	Alertas de crash; logs centralizados com traces; SLA de resolução
Cloud provider indisponível	Downtime completo	Multi-region, failover automático, exit strategy documentada
Auto-scaling trigger malconfigured	Cascata de sobre-provisionamento	Testing de políticas de escala; monitoramento de custos real-time
Imagem contaminada no registry	Malware em produção	Scanning obrigatório; assinatura de imagem; aprovação antes do deploy
Persistência de volume perdida	Dados transacionais perdidos	Volume replicado cross-AZ; snapshots frequentes

37.22 Próximo Capítulo

O Capítulo 38 detalha Kubernetes e Orquestração de Containers — como os componentes da plataforma são empacotados, orquestrados e operados no Kubernetes.

37.23 Resumo

A infraestrutura moderna é código. Kubernetes é o runtime padrão que permite escalabilidade, resiliência e observabilidade. Multi-tenant é garantido por isolamento estrutural, não por confiança. Segurança é integrada desde o provisionamento, não adicionada depois. Disaster recovery é testado continuamente, não apenas em crise.

Esses princípios transformam a infraestrutura de um problema operacional recorrente em um ativo estratégico previsível e escalável.

Capítulo 37 — Infraestrutura e Computação em Nuvem

Nesta página