🚀 Viabilidade de Migração CSuite para AWS Serverless/Lambda

Data: 2025-01-03
Versão: 1.0
Status: Análise Técnica

📋 Resumo Executivo

A migração do CSuite para AWS Serverless (Lambda + API Gateway + outros serviços gerenciados) é PARCIALMENTE VIÁVEL, com desafios significativos que requerem refatoração arquitetural substancial.

Avaliação Geral

Conclusão: ~60% dos serviços podem migrar diretamente, ~30% requerem refatoração significativa, ~10% são incompatíveis.

🏗️ Arquitetura Atual do CSuite

Componentes Principais

1. 11+ Microserviços FastAPI
2. csuite-gateway - API Gateway
3. csuite-executive - Agentes executivos
4. csuite-context - Context API
5. csuite-cashflow - Operações financeiras
6. csuite-cfo-ops - CFO Operations
7. csuite-sales-manager - Gestão de vendas
8. csuite-customer-decisions - Decisões de cliente
9. csuite-feature-store - Feature Store ML
10. csuite-model-registry - Model Registry
11. csuite-operations - Operações gerais

12. 4c - Córtex comercial (múltiplos serviços)

13. Infraestrutura

14. Docker Swarm - Orquestração de containers
15. Traefik - API Gateway/Reverse Proxy
16. MySQL (RDS) - Banco de dados principal
17. Redis - Cache e sessões
18. ClickHouse - Analytics/Telemetria

19. Kafka/Debezium - Eventos CDC

20. Jobs e Processos de Longa Duração

21. APScheduler - Jobs agendados (csuite-executive)
22. Cron Jobs - Jobs periódicos (cfo-ops, agent-loop)
23. Workers - Processamento assíncrono (4c feedback worker)
24. Schedulers - Agendamento de agentes executivos

✅ Componentes COMPATÍVEIS com Lambda

1. APIs REST Stateless (🟢 Alta Viabilidade)

Serviços candidatos:
- csuite-gateway - Rotas de documentação
- csuite-context - Endpoints de consulta
- csuite-feature-store - APIs de features
- csuite-model-registry - APIs de modelos
- 4c Feature Service - Agregação de features
- 4c Scoring Service - Scoring de modelos

Vantagens:
- ✅ Stateless por natureza
- ✅ Respostas rápidas (< 30s)
- ✅ Integração direta com RDS
- ✅ Fácil migração de FastAPI → Lambda

Exemplo de Migração:

# FastAPI atual
@app.get("/api/features/{customer_id}")
async def get_features(customer_id: int):
    # Query RDS
    return features

# Lambda equivalente
def lambda_handler(event, context):
    customer_id = event['pathParameters']['customer_id']
    # Mesma query RDS
    return {'statusCode': 200, 'body': json.dumps(features)}

Custo Estimado:
- Atual: EC2 t3.medium (~$30/mês) + Docker Swarm overhead
- Lambda: ~$0.20 por 1M requisições + RDS (mesmo)
- Economia: ~40-60% para tráfego variável

2. Processamento de Eventos (🟢 Alta Viabilidade)

Candidatos:
- Webhooks de integração
- Processamento de eventos Kafka → Lambda
- Transformação de dados
- Validação de payloads

Solução AWS:
- EventBridge - Agendamento de jobs
- SQS - Fila de mensagens
- Kinesis - Stream de eventos
- Lambda Triggers - Processamento automático

⚠️ Componentes com DESAFIOS (Requerem Refatoração)

1. Jobs Agendados (🟡 Viabilidade Média)

Problema Atual:

# APScheduler rodando dentro do container
scheduler = AsyncIOScheduler()
scheduler.add_job(
    func=run_cfo_agent,
    trigger=CronTrigger(hour="*/6"),
    id="cfo_agent"
)

Limitações Lambda:
- ❌ Lambda não mantém estado entre invocações
- ❌ Não pode rodar processos contínuos
- ❌ Timeout máximo: 15 minutos (configurável até 15min)

Soluções AWS:

Opção A: EventBridge + Lambda (Recomendado)

# Lambda function
def lambda_handler(event, context):
    # Executa job uma vez
    run_cfo_agent()
    return {'statusCode': 200}

# EventBridge Rule (substitui APScheduler)
# Schedule: cron(0 */6 * * ? *)  # A cada 6 horas

Vantagens:
- ✅ Escalável e confiável
- ✅ Não requer container rodando
- ✅ Custo por execução

Desvantagens:
- ⚠️ Refatoração necessária (remover APScheduler)
- ⚠️ Jobs muito longos (>15min) precisam Step Functions

Opção B: ECS Fargate Scheduled Tasks

# Para jobs que não cabem em Lambda
# Executa container sob demanda via EventBridge

Quando usar:
- Jobs > 15 minutos
- Processos que precisam de estado persistente
- Workers que processam filas longas

2. Processos de Longa Duração (🔴 Baixa Viabilidade)

Problemas:
- Agent Loop Detection - Processa grandes volumes de dados
- CFO Ops Rollup - Cálculos complexos que podem levar horas
- Policy Guardian Analysis - Análise profunda de violações

Solução: Step Functions

# Lambda 1: Inicia processamento
def start_analysis(event, context):
    job_id = create_job()
    return {'jobId': job_id, 'status': 'running'}

# Lambda 2: Processa chunk
def process_chunk(event, context):
    chunk = event['chunk']
    result = process_data(chunk)
    return {'result': result, 'nextChunk': chunk + 1}

# Step Functions: Orquestra
{
  "StartAt": "ProcessChunk",
  "States": {
    "ProcessChunk": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:process_chunk",
      "Next": "CheckComplete"
    },
    "CheckComplete": {
      "Type": "Choice",
      "Choices": [{
        "Variable": "$.complete",
        "BooleanEquals": false,
        "Next": "ProcessChunk"
      }],
      "Default": "Success"
    }
  }
}

Custo:
- Step Functions: $25 por 1M transições
- Lambda: Custo normal
- Total: Geralmente mais caro que ECS para jobs longos

3. WebSockets e Server-Sent Events (🔴 Baixa Viabilidade)

Problema:
- Lambda não mantém conexões persistentes
- WebSockets requerem estado de conexão

Solução: API Gateway WebSocket API

# Lambda para conexão
def connect_handler(event, context):
    connection_id = event['requestContext']['connectionId']
    # Salva connection_id no DynamoDB
    return {'statusCode': 200}

# Lambda para mensagens
def message_handler(event, context):
    connection_id = event['requestContext']['connectionId']
    # Processa e envia resposta
    return {'statusCode': 200}

Limitações:
- ⚠️ Refatoração significativa necessária
- ⚠️ Custo pode ser alto para muitas conexões
- ⚠️ Complexidade de gerenciamento de estado

Alternativa:
- Manter WebSockets em ECS Fargate ou App Runner
- Usar Lambda apenas para APIs REST

4. Cache e Estado Compartilhado (🟡 Viabilidade Média)

Problema Atual:
- Redis para cache de features
- Sessões em memória
- Estado compartilhado entre requisições

Soluções AWS:

Opção A: ElastiCache Redis (Recomendado)

• ✅ Mesma API do Redis atual
• ✅ Gerenciado pela AWS
• ✅ Alta disponibilidade
• ⚠️ Custo: ~$15-50/mês (dependendo do tamanho)

Opção B: DynamoDB

• ✅ Serverless nativo
• ✅ Escalável automaticamente
• ⚠️ Requer refatoração (não é Redis)

Opção C: Lambda Provisioned Concurrency

• Para cache em memória dentro do Lambda
• ⚠️ Custo alto (~$0.015/hora por GB-RAM)
• ⚠️ Limitado a 10GB por função

Recomendação: ElastiCache Redis (menor refatoração)

🔴 Componentes INCOMPATÍVEIS

1. Workers de Processamento Contínuo

Exemplos:
- 4c Feedback Worker - Processa fila continuamente
- Kafka Consumers - Consome eventos em tempo real

Solução:
- ECS Fargate - Containers serverless
- Kinesis + Lambda - Para streams (substitui Kafka consumers)

2. Serviços com Estado Persistente

Exemplos:
- Schedulers com estado em memória
- Conexões persistentes com serviços externos
- WebSockets com estado de sessão

Solução:
- Manter em ECS Fargate ou App Runner
- Ou refatorar para arquitetura stateless

💰 Análise de Custos

Cenário Atual (Docker Swarm em EC2)

Infraestrutura:
- EC2 Instances: ~$200-400/mês (dependendo do tamanho)
- RDS MySQL: ~$100-200/mês
- Redis (self-hosted): Incluído no EC2
- ClickHouse: Incluído no EC2
- Tráfego: ~$20-50/mês

Total Estimado: ~$320-650/mês

Cenário Serverless (Híbrido Recomendado)

Lambda + API Gateway

• 1M requisições/mês: ~$0.20 (API Gateway) + ~$0.20 (Lambda) = $0.40
• 10M requisições/mês: ~$4.00
• 100M requisições/mês: ~$40.00

RDS (mesmo)

• MySQL: ~$100-200/mês

ElastiCache Redis

• cache.t3.micro: ~$15/mês
• cache.t3.small: ~$30/mês

ECS Fargate (para jobs longos)

• 0.5 vCPU, 1GB RAM: ~$15/mês por task
• Para 3-5 tasks: ~$45-75/mês

EventBridge

• 1M eventos/mês: ~$1.00

Step Functions (se necessário)

• 1M transições/mês: ~$25.00

Total Estimado (10M req/mês):
- Lambda/API Gateway: $4
- RDS: $150
- ElastiCache: $30
- ECS Fargate: $60
- EventBridge: $1
- Total: ~$245/mês

Economia: ~25-40% comparado ao cenário atual

Observação: Para tráfego muito alto (>100M req/mês), EC2 pode ser mais econômico.

📊 Plano de Migração Recomendado

Fase 1: APIs Stateless (🟢 Baixo Risco)

Serviços:
1. csuite-gateway - Documentação
2. csuite-feature-store - APIs de features
3. csuite-model-registry - APIs de modelos
4. 4c Feature Service - Agregação

Esforço: 2-4 semanas
Risco: Baixo
Economia: ~20-30% dos custos de infraestrutura

Fase 2: Jobs Agendados (🟡 Médio Risco)

Serviços:
1. Migrar APScheduler → EventBridge + Lambda
2. Migrar Cron Jobs → EventBridge Rules
3. Jobs longos → Step Functions ou ECS Fargate

Esforço: 4-6 semanas
Risco: Médio
Refatoração: Substancial (remover schedulers internos)

Fase 3: Processamento Assíncrono (🟡 Médio Risco)

Serviços:
1. Workers → ECS Fargate ou Kinesis + Lambda
2. Kafka Consumers → Kinesis + Lambda
3. Processamento de filas → SQS + Lambda

Esforço: 6-8 semanas
Risco: Médio-Alto
Refatoração: Significativa

Fase 4: WebSockets e SSE (🔴 Alto Risco)

Serviços:
1. WebSockets → API Gateway WebSocket API
2. SSE → Manter em ECS Fargate (recomendado)

Esforço: 8-12 semanas
Risco: Alto
Recomendação: Considerar manter em ECS Fargate

🎯 Recomendação Final

Arquitetura Híbrida (Recomendada)

┌─────────────────────────────────────────┐
│  API Gateway + Lambda                   │
│  - APIs REST Stateless                  │
│  - Endpoints de consulta                 │
│  - Processamento rápido                 │
└─────────────────────────────────────────┘
           │
           ├─── RDS MySQL (mesmo)
           ├─── ElastiCache Redis
           │
┌─────────────────────────────────────────┐
│  ECS Fargate / App Runner               │
│  - Jobs longos (>15min)                 │
│  - Workers contínuos                    │
│  - WebSockets                           │
│  - Schedulers com estado                │
└─────────────────────────────────────────┘
           │
           ├─── EventBridge (agendamento)
           ├─── Step Functions (orquestração)
           └─── SQS/Kinesis (filas/streams)

Vantagens da Abordagem Híbrida

1. ✅ Economia de custos para APIs stateless
2. ✅ Flexibilidade para processos complexos
3. ✅ Menor risco - migração gradual
4. ✅ Melhor custo-benefício - usar cada serviço onde faz sentido

Quando NÃO Migrar

• ❌ Tráfego muito alto e constante (>100M req/mês)
• ❌ Aplicações com muita lógica stateful
• ❌ Equipe sem experiência com Serverless
• ❌ Requisitos de latência muito baixa (<10ms)

📝 Checklist de Viabilidade por Serviço

🔗 Referências e Próximos Passos

Documentação AWS

• AWS Lambda Best Practices
• Serverless Application Lens
• Lambda Pricing

Ferramentas de Migração

• SAM (Serverless Application Model) - Para definir infraestrutura
• Serverless Framework - Alternativa ao SAM
• Terraform - Para IaC (já usado no projeto)

Próximos Passos Recomendados

1. POC (Proof of Concept)
2. Migrar 1-2 APIs simples para Lambda
3. Medir custo e performance

4. Validar integração com RDS

5. Análise Detalhada

6. Profiling de cada serviço
7. Identificar dependências críticas

8. Mapear jobs e processos

9. Plano de Migração Detalhado

10. Roadmap por fase
11. Estimativas de esforço
12. Plano de rollback

Conclusão: A migração é viável e recomendada para ~60% dos serviços, com economia de custos significativa. A abordagem híbrida (Lambda + ECS Fargate) oferece o melhor equilíbrio entre custo, complexidade e funcionalidade.