Lab 30 — Os limites do serverless, medidos

# CloudWatch Logs, primeira execucao em producao, mes de agosto de 2026:
REPORT RequestId: 8f2c1a... Duration: 900002.14 ms Billed Duration: 900000 ms Memory Size: 1024 MB Max Memory Used: 743 MB
Task timed out after 900.00 seconds

# A "correcao" de uma tarde: a funcao passa a se auto-invocar de forma assincrona
# aos 800s, gravando o progresso numa tabela. O log seguinte parece bem-sucedido:
REPORT RequestId: 3a91f0... Duration: 803441.02 ms Billed Duration: 803500 ms
(async invoke) -> nova invocacao iniciada, checkpoint = loja 17 de 30

{
  "datasetUri": "s3://ffv-lab-fechamento/bruto/2026-08/consolidado.parquet",
  "relatorioDestinoUri": "s3://ffv-lab-fechamento/saida/2026-08/fechamento.pdf",
  "mesReferencia": "2026-08",
  "lojas": 30
}

# state_machine.tf — o orquestrador declarativo, e por que STANDARD é a decisão

# A definição em si. type = "STANDARD" e nao "EXPRESS" e a linha mais importante
# deste arquivo: Express tem teto de execucao de 5 minutos, menor que os 15 do
# Lambda que este modulo inteiro existe para superar. Escolher Express aqui
# reproduziria o mesmo defeito com um nome mais moderno.
resource "aws_sfn_state_machine" "fechamento_mensal" {
  name     = "${var.projeto}-fechamento-mensal"
  role_arn = aws_iam_role.step_functions.arn
  type     = "STANDARD"

  definition = jsonencode({
    Comment = "Consolida o fechamento mensal via task Fargate, sem teto de 900s"
    StartAt = "GerarRelatorio"
    States = {
      GerarRelatorio = {
        Type     = "Task"
        Resource = "arn:aws:states:::ecs:runTask.sync"
        Arguments = {
          Cluster        = aws_ecs_cluster.principal.arn
          TaskDefinition = aws_ecs_task_definition.fechamento.arn
          LaunchType     = "FARGATE"
          NetworkConfiguration = {
            AwsvpcConfiguration = {
              Subnets        = aws_subnet.privada[*].id
              SecurityGroups = [aws_security_group.task.id]
            }
          }
          # So a URI atravessa a maquina de estados — nunca o dado. O relatorio
          # de 45 MB estouraria os 256 KiB de input/output de um estado.
          Overrides = {
            ContainerOverrides = [{
              Name = "fechamento"
              Environment = [
                { Name = "DATASET_URI", "Value.$" = "$.datasetUri" },
                { Name = "DESTINO_URI", "Value.$" = "$.relatorioDestinoUri" },
              ]
            }]
          }
        }
        # Falha transiente de infraestrutura (task nao provisionou) tenta de
        # novo; falha do PROCESSO (exitCode != 0) cai direto no Catch — retry
        # em erro de logica de negocio so atrasaria a descoberta do problema.
        Retry = [{
          ErrorEquals     = ["States.Timeout", "ECS.AmazonECSException"]
          IntervalSeconds = 30
          MaxAttempts     = 2
          BackoffRate     = 2.0
        }]
        Catch = [{
          ErrorEquals = ["States.ALL"]
          Next        = "NotificarFalha"
        }]
        Next = "NotificarSucesso"
      }
      NotificarSucesso = {
        Type     = "Task"
        Resource = "arn:aws:states:::sns:publish"
        Arguments = {
          TopicArn = aws_sns_topic.fechamento.arn
          Message  = "Fechamento mensal concluido"
        }
        End = true
      }
      NotificarFalha = {
        Type     = "Task"
        Resource = "arn:aws:states:::sns:publish"
        Arguments = {
          TopicArn = aws_sns_topic.fechamento.arn
          Message  = "Fechamento mensal FALHOU — ver historico de execucao"
        }
        End = true
      }
    }
  })
}

# A politica que o Step Functions realmente precisa para RunTask.sync — nao e
# "acesso total ao ECS". `RunTask` e restrito a UMA revisao de task definition;
# `StopTask`/`DescribeTasks` vao com Resource "*" porque o TaskId so existe
# depois de a task ja ter subido, e a AWS documenta essa restricao como
# necessaria (nao e preguica: e o unico jeito de expressar "a task que EU
# criei", sem saber o ID de antemao). O bloco de events e o que sustenta o
# ".sync": o Step Functions cria uma regra gerenciada do EventBridge para saber
# quando a task termina, e sem essas tres acoes o RunTask.sync nunca retorna.
data "aws_iam_policy_document" "step_functions_ecs" {
  statement {
    effect    = "Allow"
    actions   = ["ecs:RunTask"]
    resources = ["${aws_ecs_task_definition.fechamento.arn_without_revision}:*"]
  }
  statement {
    effect    = "Allow"
    actions   = ["ecs:StopTask", "ecs:DescribeTasks"]
    resources = ["*"]
  }
  statement {
    effect  = "Allow"
    actions = ["events:PutTargets", "events:PutRule", "events:DescribeRule"]
    resources = [
      "arn:aws:events:${var.regiao}:${data.aws_caller_identity.atual.account_id}:rule/StepFunctionsGetEventsForECSTaskRule"
    ]
  }
  statement {
    effect    = "Allow"
    actions   = ["iam:PassRole"]
    resources = [aws_iam_role.execucao_task.arn, aws_iam_role.task.arn]
    # PassRole tem de ser restrito as DUAS roles que a task realmente usa —
    # sem isso, o Step Functions poderia entregar a task para rodar com
    # QUALQUER role da conta que aceitasse ser assumida por ecs-tasks.
  }
}

output "state_machine_arn" {
  value       = aws_sfn_state_machine.fechamento_mensal.arn
  description = "ARN da maquina de estados; StartExecution aceita so datasetUri e relatorioDestinoUri"
}

# task_definition.tf — a task sem teto de 900s, e o disco que o Lambda nao dá

resource "aws_ecs_task_definition" "fechamento" {
  family                   = "${var.projeto}-fechamento"
  requires_compatibilities = ["FARGATE"]
  network_mode             = "awsvpc"

  # 4 vCPU / 8 GB: acima do 1 vCPU-equivalente do Lambda (que so chega la a
  # 1.769 MB de memoria) e sem o teto de 10.240 MB. O par e uma combinacao
  # valida da tabela de tamanhos Fargate — confira a tabela antes de escolher
  # outra, porque nem todo par CPU x memoria e aceito.
  cpu    = 4096
  memory = 8192

  # 30 GB: confortavel acima do padrao de 20 GB do Fargate e MUITO acima do
  # teto de 10 GB do /tmp do Lambda, mesmo configurado no maximo. E o limite
  # que o dataset intermediario do fechamento (na ordem de 10 a 15 GB antes de
  # compactar) bateria se este job ainda estivesse forcado em Lambda.
  ephemeral_storage {
    size_in_gib = 30
  }

  execution_role_arn = aws_iam_role.execucao_task.arn
  task_role_arn       = aws_iam_role.task.arn

  container_definitions = jsonencode([{
    name      = "fechamento"
    image     = "${aws_ecr_repository.fechamento.repository_url}:${var.sha_da_imagem}"
    essential = true

    # As duas URIs chegam por variavel de ambiente, sobrescritas pelo
    # ContainerOverride do Step Functions — nunca o conteudo do relatorio.
    environment = [
      { name = "DATASET_URI", value = "" },
      { name = "DESTINO_URI", value = "" },
    ]

    logConfiguration = {
      logDriver = "awslogs"
      options = {
        "awslogs-group"         = aws_cloudwatch_log_group.fechamento.name
        "awslogs-region"        = var.regiao
        "awslogs-stream-prefix" = "fechamento"
      }
    }
  }])
}

resource "aws_sns_topic" "fechamento" {
  name = "${var.projeto}-fechamento-mensal"
}

// Program.cs — o processo que roda ate terminar, nao ate um relogio de servico mandar parar

using Amazon.S3;
using Amazon.S3.Transfer;

var datasetUri = Environment.GetEnvironmentVariable("DATASET_URI")
    ?? throw new InvalidOperationException("DATASET_URI ausente");
var destinoUri = Environment.GetEnvironmentVariable("DESTINO_URI")
    ?? throw new InvalidOperationException("DESTINO_URI ausente");

using var s3 = new AmazonS3Client();
using var transfer = new TransferUtility(s3);

// Aqui, ao contrario do Lambda, nao existe um teto de tempo documentado pela
// AWS para esta chamada terminar. O que limita a duracao e o que VOCE decide
// — um temporizador proprio, se quiser um — e o custo por segundo de CPU e
// memoria rodando, nunca uma cota de servico.
var (bucketOrigem, chaveOrigem) = AnalisarUriS3(datasetUri);
var caminhoLocal = Path.Combine("/tmp", "dataset.parquet"); // /tmp aqui tem 30 GiB, nao 10
await transfer.DownloadAsync(caminhoLocal, bucketOrigem, chaveOrigem);

var pedidos = await CarregarPedidosDasTrintaLojas(caminhoLocal);

// O trabalho pesado de verdade: 20 a 35 minutos consolidando e renderizando.
// Nenhuma chamada de "continue de onde parei" — o processo e uma unidade so.
var caminhoRelatorio = await GerarRelatorioConsolidado(pedidos); // ~45 MB de PDF

var (bucketDestino, chaveDestino) = AnalisarUriS3(destinoUri);
await transfer.UploadAsync(caminhoRelatorio, bucketDestino, chaveDestino);

// O exitCode e o que o RunTask.sync le para decidir Retry, Catch ou seguir —
// e substitui, de forma nativa, tudo o que a cadeia de Lambda tinha de
// reconstruir a partir de linhas de log.
Console.WriteLine($"fechamento gravado em {destinoUri}");
return 0;

static (string bucket, string chave) AnalisarUriS3(string uri)
{
    var semEsquema = uri.Replace("s3://", string.Empty);
    var indice = semEsquema.IndexOf('/');
    return (semEsquema[..indice], semEsquema[(indice + 1)..]);
}

#!/usr/bin/env bash
# medir-antes-de-decidir.sh — cinco números, não uma sensação de "não coube"

PROJETO=ffv-lab-fechamento
REGIAO=us-east-1

# ── Medição 1: duração real do job, fora de qualquer teto ────────────────────
# Roda o MESMO binário como processo local, sem Lambda no caminho. O número
# que sai daqui é a linha de base contra a qual todo limite abaixo é comparado.
time dotnet Fechamento.dll --dataset ./amostra-30-lojas.parquet --destino ./saida.pdf
# Na Cadência: 23 min 40 s no dado de agosto de 2026 — acima dos 900 s do
# Lambda por um fator de 1,6, sozinho já suficiente para reprovar a arquitetura.

# ── Medição 2: tamanho real do dataset intermediário ─────────────────────────
du -sh ./tmp-intermediario/
# Na Cadência: 11 GB antes de compactar — dentro do teto de 10.240 MB do
# /tmp do Lambda configurado no máximo, mas sem nenhuma folga para crescer.

# ── Medição 3: tamanho real do relatório final ────────────────────────────────
du -sh ./saida.pdf
# Na Cadência: 45 MB — sete vezes o teto de 6 MB de resposta síncrona do
# Lambda, e cento e oitenta vezes o teto de 256 KiB de um estado do Step Functions.

# ── Medição 4: quantas execuções concorrentes o pico realmente gera ──────────
aws logs filter-log-events --log-group-name "/ecs/${PROJETO}" \
  --start-time "$(date -d '3 months ago' +%s000)" \
  --filter-pattern "fechamento gravado" --query 'length(events)' --output text
# Na Cadência: até 3 execuções no mesmo dia em virada de trimestre — contra o
# teto COMPARTILHADO de 1.000 execuções simultâneas do Lambda por conta e por
# região, que a cadeia de auto-invocação disputaria com toda função não relacionada.

# ── Medição 5: cota atual de execuções concorrentes da conta ─────────────────
aws service-quotas get-service-quota --service-code lambda \
  --quota-code L-B99A9384 --region "$REGIAO" \
  --query 'Quota.Value' --output text
# Confirma o teto que a Medição 4 compara. O valor padrão documentado é 1.000;
# meça o seu, porque cotas sobem com uso e este número muda por conta.

# provas.sh — cinco medições; nenhuma decisão fica só na afirmação

PROJETO=ffv-lab-fechamento
REGIAO=us-east-1

# ── Prova 1: o timeout do Lambda é hard quota, não é possível pedir aumento ──
# Tenta reconfigurar o timeout acima do teto. Deve falhar com erro do
# parâmetro, não com "aguarde aprovação" como aconteceria com concorrência.
aws lambda update-function-configuration --function-name "${PROJETO}-orquestrador" \
  --timeout 901 2>&1 | grep -i "InvalidParameterValueException" \
  && echo "OK: confirmado — 900s é o teto e não aceita valor maior" \
  || echo "FALHA DA PROVA: se aceitou, o teto documentado mudou — reconfirme na doc oficial"

# ── Prova 2: RunTask.sync aguarda o exitCode, não dispara e esquece ──────────
aws stepfunctions start-execution --state-machine-arn "$(terraform output -raw state_machine_arn)" \
  --input '{"datasetUri":"s3://ffv-lab-fechamento/bruto/teste.parquet","relatorioDestinoUri":"s3://ffv-lab-fechamento/saida/teste.pdf"}' \
  --query 'executionArn' --output text
# Espere e confira o status:
aws stepfunctions describe-execution --execution-arn "<ARN acima>" \
  --query '{status:status,duracao_s:(stopDate-startDate)}' --output table
# Esperado: status SUCCEEDED, e a duração bate com o tempo real do processo —
# não com nenhum múltiplo de 900 s.

# ── Prova 3: o limite de 256 KiB de payload por estado é real, não teórico ───
# Tenta passar um trecho grande como output de um estado de teste.
aws stepfunctions test-state --state-definition '{
  "Type":"Pass",
  "Result": "'"$(head -c 300000 /dev/urandom | base64)"'"
}' --role-arn "$(terraform output -raw sfn_role_arn)" 2>&1 \
  | grep -i "States.DataLimitExceeded" \
  && echo "OK: o limite de 256 KiB rejeitou o payload — é por isso que só a URI atravessa" \
  || echo "confira manualmente: o teste pode ter usado payload abaixo do teto"

# ── Prova 4: a concorrência da conta é compartilhada, não é sua sozinho ──────
# Dispara 20 invocações em paralelo de uma função QUALQUER e mede throttle.
for i in $(seq 1 20); do
  aws lambda invoke --function-name "${PROJETO}-qualquer-outra-funcao" \
    --invocation-type Event /dev/null &
done; wait
aws cloudwatch get-metric-statistics --namespace AWS/Lambda --metric-name Throttles \
  --dimensions Name=FunctionName,Value="${PROJETO}-qualquer-outra-funcao" \
  --start-time "$(date -u -d '5 min ago' +%FT%TZ)" --end-time "$(date -u +%FT%TZ)" \
  --period 60 --statistics Sum --query 'Datapoints[].Sum' --output text
# Se a cadeia de auto-invocação do desenho mínimo estivesse rodando ao mesmo
# tempo, este número tende a subir — a prova de que o teto é da CONTA, não da função.

# ── Prova 5: o exitCode diferente de zero realmente cai no Catch ─────────────
# Force o contêiner a sair com erro (ex.: dataset corrompido de propósito) e
# confira o histórico de execução.
aws stepfunctions get-execution-history --execution-arn "<ARN de uma execução forçada a falhar>" \
  --query "events[?type=='ExecutionFailed' || type=='TaskStateExited']" --output table
# Esperado: o Catch levou a execução a "NotificarFalha" — sem nenhum try/catch
# escrito à mão para isso.

# 1. Derrube o que o Terraform administra.
terraform destroy -auto-approve

# 2. OBJETOS NO S3: o bucket pode sobreviver vazio, mas o dataset bruto e os
#    relatorios gerados durante os testes NAO saem sozinhos.
aws s3 ls s3://ffv-lab-fechamento/ --recursive --summarize | tail -3
aws s3 rm s3://ffv-lab-fechamento/ --recursive

# 3. GRUPO DE LOGS da task: tem retencao propria, independente do ciclo do
#    Step Functions ou da task definition.
aws logs delete-log-group --log-group-name /ecs/ffv-lab-fechamento 2>/dev/null || true

# 4. TASKS AINDA RODANDO: se voce interrompeu um teste no meio, a task Fargate
#    continua cobrando por vCPU e memoria ate terminar ou ser parada.
aws ecs list-tasks --cluster ffv-lab --query "taskArns" --output text
aws ecs stop-task --cluster ffv-lab --task "<arn-de-cada-task-listada>" \
  --reason "limpeza do laboratorio" 2>/dev/null || true

# 5. EXECUCOES ABERTAS do Step Functions: nao cobram por hora, mas ficam
#    "rodando" indefinidamente se a task associada nunca voltar um exitCode.
aws stepfunctions list-executions \
  --state-machine-arn "$(terraform output -raw state_machine_arn)" \
  --status-filter RUNNING --query "executions[].executionArn" --output text

# 6. Prova final: nada com a tag do projeto de pe.
aws resourcegroupstaggingapi get-resources \
  --tag-filters Key=Projeto,Values=ffv-lab-fechamento \
  --query "ResourceTagMappingList[].ResourceARN" --output table