Lab 15 — Aurora de verdade: endpoint, Serverless v2 e failover

# Rode por pelo menos 7 dias corridos antes de decidir piso e teto.
CLUSTER=ffv-lab-aurora
INSTANCIA_WRITER=ffv-lab-aurora-writer

aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS --metric-name CPUUtilization \
  --dimensions Name=DBInstanceIdentifier,Value="$INSTANCIA_WRITER" \
  --start-time "$(date -u -d '7 days ago' +%FT%TZ)" --end-time "$(date -u +%FT%TZ)" \
  --period 3600 --statistics Average Maximum --output table

# Na Cadencia: media de 4% entre 2h e 5h, picos de 82% em tres janelas de
# 40 min por dia de campanha. A instancia e a MESMA nos dois horarios — o
# preco por hora tambem e o mesmo, e e essa igualdade que este modulo quebra.

{
  "source": "aws.rds",
  "detail-type": "RDS DB Cluster Event",
  "resources": ["arn:aws:rds:us-east-1:111122223333:cluster:ffv-lab-aurora"],
  "detail": {
    "EventCategories": ["failover"],
    "SourceType": "CLUSTER",
    "Message": "A Multi-AZ failover for cluster ffv-lab-aurora has completed.",
    "Date": "2026-08-07T14:12:04.000Z"
  }
}

# aurora-serverless.tf — troca db.r6g.large por db.serverless, com piso e teto
# derivados de medicao (ver medir-a-ociosidade.sh) e o reader em tier de promocao 0.

variable "acu_minimo" {
  description = "Piso de ACU, derivado do conjunto de dados quente (indice do historico)"
  type        = number
  default     = 2 # ~4 GiB — cabe o indice do L14 sem descartar cache a cada ociosidade
}

variable "acu_maximo" {
  description = "Teto de ACU, derivado do pico medido (15 ACU) com margem de 2x"
  type        = number
  default     = 32
}

resource "aws_rds_cluster" "pedidos" {
  cluster_identifier = "${var.projeto}-aurora"
  engine              = "aurora-postgresql"
  # 16.3+ e o piso de versao para a faixa 0-256 ACU; confira a sua antes de aplicar.
  engine_version      = "16.4"
  database_name       = "pedidos"
  master_username      = "app_admin"
  manage_master_user_password = true

  db_subnet_group_name   = aws_db_subnet_group.privada.name
  vpc_security_group_ids = [aws_security_group.banco.id]

  storage_encrypted = true
  kms_key_id         = aws_kms_key.app.arn

  backup_retention_period = 7
  preferred_backup_window = "03:00-04:00"

  # O piso e o teto do CLUSTER. Cada instancia (writer, reader) tambem escala
  # dentro desta faixa — nao existe faixa separada por instancia.
  serverlessv2_scaling_configuration {
    min_capacity = var.acu_minimo
    max_capacity = var.acu_maximo
  }

  final_snapshot_identifier = "${var.projeto}-aurora-final-${formatdate("YYYYMMDD", timestamp())}"
  skip_final_snapshot       = false
  deletion_protection       = true # removido explicitamente antes do destroy, de proposito
}

resource "aws_rds_cluster_instance" "writer" {
  identifier          = "${var.projeto}-aurora-writer"
  cluster_identifier  = aws_rds_cluster.pedidos.id
  # A troca central deste modulo: nao ha mais classe fixa. `db.serverless` diz
  # ao Aurora para usar a faixa declarada acima em vez de uma classe da familia.
  instance_class      = "db.serverless"
  engine              = aws_rds_cluster.pedidos.engine
  engine_version      = aws_rds_cluster.pedidos.engine_version
  publicly_accessible = false
}

resource "aws_rds_cluster_instance" "reader" {
  identifier          = "${var.projeto}-aurora-reader"
  cluster_identifier  = aws_rds_cluster.pedidos.id
  instance_class      = "db.serverless"
  engine              = aws_rds_cluster.pedidos.engine
  engine_version      = aws_rds_cluster.pedidos.engine_version
  publicly_accessible = false

  # Tier 0: o piso deste reader passa a ser a capacidade ATUAL do writer, nao
  # o var.acu_minimo do cluster. E o que o deixa pronto para assumir sem
  # precisar escalar depois de ja ser o writer.
  promotion_tier = 0
}

output "endpoint_escrita" {
  value       = aws_rds_cluster.pedidos.endpoint
  description = "cluster endpoint — sempre aponta para o writer atual, mesmo apos failover"
}

output "endpoint_leitura" {
  value       = aws_rds_cluster.pedidos.reader_endpoint
  description = "reader endpoint — round-robin entre leitoras disponiveis; NUNCA aceita escrita"
}

# alarmes-capacidade.tf — o teto tecnico (max_capacity) nao e um teto de custo.
# Uma query em laco pode sustentar 32 ACU por horas sem violar nenhum limite do
# Aurora — o alarme abaixo e o que transforma isso em um aviso, nao numa
# surpresa na fatura do mes seguinte.

resource "aws_cloudwatch_metric_alarm" "acu_sustentado_no_teto" {
  alarm_name          = "${var.projeto}-aurora-acu-no-teto"
  namespace           = "AWS/RDS"
  metric_name         = "ServerlessDatabaseCapacity"
  statistic           = "Average"
  period              = 300
  evaluation_periods  = 6 # 30 minutos sustentados — campanha legitima nao passa disso
  threshold           = var.acu_maximo * 0.9
  comparison_operator = "GreaterThanOrEqualToThreshold"
  treat_missing_data  = "notBreaching"

  dimensions = {
    DBClusterIdentifier = aws_rds_cluster.pedidos.cluster_identifier
  }

  alarm_actions = [aws_sns_topic.alertas.arn]
}

# rds:FailoverDBCluster e escopavel por ARN — nao e o `*` que precisa de
# justificativa. cloudwatch:GetMetricData e as duas acoes de metrica abaixo
# NAO aceitam recurso especifico: sao operacoes de leitura sobre o namespace
# inteiro da conta, entao `Resource = "*"` aqui e a unica forma de conceder a
# acao, nao uma escolha por preguica.
data "aws_iam_policy_document" "operar_failover" {
  statement {
    effect    = "Allow"
    actions   = ["rds:FailoverDBCluster", "rds:DescribeDBClusters"]
    resources = [aws_rds_cluster.pedidos.arn]
  }
  statement {
    effect    = "Allow"
    actions   = ["cloudwatch:GetMetricData", "cloudwatch:GetMetricStatistics"]
    resources = ["*"]
  }
}

// DataSources.cs — dois pools, dois enderecos, e o motivo de nunca compartilhar

var builder = WebApplication.CreateBuilder(args);

// Escrita: sempre o CLUSTER endpoint. Ele resolve para o writer atual — antes
// e depois de qualquer failover, sem a aplicacao saber ou precisar saber.
var enderecoEscrita = builder.Configuration.GetConnectionString("AuroraEscrita")!;
builder.Services.AddNpgsqlDataSource(enderecoEscrita, name: "escrita", dataSourceBuilder =>
{
    // Timeout de conexao curto: se o writer esta indisponivel (failover em
    // andamento), falhar rapido e deixar o Polly (abaixo) decidir o retry e
    // por o registrar como o e melhor do que ficar pendurado no pool.
    dataSourceBuilder.ConnectionStringBuilder.Timeout = 5;
});

// Leitura: o READER endpoint. Ele distribui entre as leitoras disponiveis por
// DNS round-robin — e cada leitora esta aberta em modo somente leitura no
// proprio PostgreSQL, entao um INSERT aqui falha no banco, nao na aplicacao.
var enderecoLeitura = builder.Configuration.GetConnectionString("AuroraLeitura")!;
builder.Services.AddNpgsqlDataSource(enderecoLeitura, name: "leitura", dataSourceBuilder =>
{
    dataSourceBuilder.ConnectionStringBuilder.Timeout = 5;
});

// Resiliencia com retry e jitter, especifica para o intervalo de failover.
// Sem jitter, todas as instancias do servico tentariam reconectar no MESMO
// instante apos a promocao do reader, multiplicando a carga de reconexao
// exatamente quando o writer novo mais precisa de folga.
builder.Services.AddResiliencePipeline("aurora-escrita", pb =>
{
    pb.AddRetry(new Polly.Retry.RetryStrategyOptions
    {
        ShouldHandle = new Polly.PredicateBuilder().Handle<NpgsqlException>(),
        MaxRetryAttempts = 4,
        BackoffType = Polly.DelayBackoffType.Exponential,
        UseJitter = true,
        Delay = TimeSpan.FromMilliseconds(200),
    });
});

var app = builder.Build();
app.Run();

// PedidoRepositorio.cs — o caminho de escrita, com o pool de escrita e a
// pipeline de resiliencia amarrados desde a injecao de dependencia.

public sealed class PedidoRepositorio
{
    private readonly NpgsqlDataSource _escrita;
    private readonly ResiliencePipeline _resiliencia;

    public PedidoRepositorio(
        [FromKeyedServices("escrita")] NpgsqlDataSource escrita,
        [FromKeyedServices("aurora-escrita")] ResiliencePipeline resiliencia)
    {
        _escrita = escrita;
        _resiliencia = resiliencia;
    }

    public async Task<Guid> CriarAsync(NovoPedido pedido, CancellationToken ct) =>
        await _resiliencia.ExecuteAsync(async token =>
        {
            // Se um failover estiver em andamento, a primeira tentativa aqui
            // recebe uma excecao de conexao — nao um erro de negocio. A
            // pipeline reexecuta com backoff; NAO reexecute manualmente por
            // fora dela, ou o jitter perde o efeito.
            await using var conexao = await _escrita.OpenConnectionAsync(token);
            await using var transacao = await conexao.BeginTransactionAsync(token);

            const string sql = """
                INSERT INTO pedidos (id, cliente_id, loja_id, total, status, criado_em)
                VALUES (@id, @cliente, @loja, @total, 'confirmado', now())
                """;
            await using var comando = new NpgsqlCommand(sql, conexao, transacao);
            comando.Parameters.AddWithValue("id", pedido.Id);
            comando.Parameters.AddWithValue("cliente", pedido.ClienteId);
            comando.Parameters.AddWithValue("loja", pedido.LojaId);
            comando.Parameters.AddWithValue("total", pedido.Total);
            await comando.ExecuteNonQueryAsync(token);

            await transacao.CommitAsync(token);
            return pedido.Id;
        }, ct);
}

// HistoricoRepositorio.cs — o caminho de leitura, deliberadamente incapaz de
// escrever: o pool aponta para o reader endpoint, e nao ha metodo de escrita
// nesta classe. O compilador nao impede um INSERT por engano; o Postgres impede.
public sealed class HistoricoRepositorio
{
    private readonly NpgsqlDataSource _leitura;

    public HistoricoRepositorio([FromKeyedServices("leitura")] NpgsqlDataSource leitura) =>
        _leitura = leitura;

    public async Task<IReadOnlyList<PedidoResumo>> PorClienteAsync(
        Guid clienteId, int tamanho, CancellationToken ct)
    {
        await using var conexao = await _leitura.OpenConnectionAsync(ct);
        const string sql = """
            SELECT id, loja_id, total, status, criado_em
            FROM pedidos
            WHERE cliente_id = @cliente
            ORDER BY criado_em DESC
            LIMIT @tamanho
            """;
        await using var comando = new NpgsqlCommand(sql, conexao);
        comando.Parameters.AddWithValue("cliente", clienteId);
        comando.Parameters.AddWithValue("tamanho", tamanho);

        var linhas = new List<PedidoResumo>();
        await using var leitor = await comando.ExecuteReaderAsync(ct);
        while (await leitor.ReadAsync(ct))
            linhas.Add(new PedidoResumo(
                leitor.GetGuid(0), leitor.GetGuid(1), leitor.GetDecimal(2),
                leitor.GetString(3), leitor.GetDateTime(4)));
        return linhas;
    }
}

#!/usr/bin/env bash
set -euo pipefail

# 1. Aplica a troca para Serverless v2 com o piso e o teto medidos.
terraform apply -var="acu_minimo=2" -var="acu_maximo=32" -auto-approve

# 2. Confirma a faixa de capacidade ATIVA no cluster.
aws rds describe-db-clusters --db-cluster-identifier ffv-lab-aurora \
  --query "DBClusters[0].ServerlessV2ScalingConfiguration"

# 3. Confirma o tier de promocao do reader.
aws rds describe-db-instances --db-instance-identifier ffv-lab-aurora-reader \
  --query "DBInstances[0].PromotionTier"

# provas.sh — cinco medicoes; nenhuma conclusao vem de "parece que funcionou".
set -euo pipefail
CLUSTER=ffv-lab-aurora

# -- Prova 1: a capacidade acompanha a carga, nao fica fixa ------------------
# Gere trafego crescente por 10 min e observe ServerlessDatabaseCapacity subir
# em incrementos — nao em um unico salto.
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS --metric-name ServerlessDatabaseCapacity \
  --dimensions Name=DBClusterIdentifier,Value="$CLUSTER" \
  --start-time "$(date -u -d '15 min ago' +%FT%TZ)" --end-time "$(date -u +%FT%TZ)" \
  --period 60 --statistics Average Maximum --output table

# -- Prova 2: escrever no reader endpoint falha no banco, nao na aplicacao ---
# Deve falhar com erro de transacao somente leitura do proprio PostgreSQL.
ENDPOINT_LEITURA=$(terraform output -raw endpoint_leitura)
psql "host=$ENDPOINT_LEITURA dbname=pedidos user=app_admin sslmode=require" \
  -c "INSERT INTO pedidos (id) VALUES (gen_random_uuid());" 2>&1 \
  | grep -qi "read-only transaction" \
  && echo "OK: o reader recusou a escrita" \
  || echo "FALHA DA PROVA: a escrita nao deveria ter sido aceita"

# -- Prova 3: o failover ensaiado, com carga real em andamento ---------------
# Um laco de escrita roda enquanto o failover e disparado a mao. O que importa
# e o intervalo entre a ULTIMA escrita aceita e a PRIMEIRA aceita depois.
( i=0; while true; do
    if psql "$(terraform output -raw endpoint_escrita)" -c \
        "INSERT INTO pedidos (id) VALUES (gen_random_uuid());" >/dev/null 2>&1; then
      echo "$(date +%T.%N) OK $i"
    else
      echo "$(date +%T.%N) FALHA $i"
    fi
    i=$((i+1)); sleep 0.2
  done ) > /tmp/janela-failover.log &
LACO=$!
aws rds failover-db-cluster --db-cluster-identifier "$CLUSTER"
aws rds wait db-cluster-available --db-cluster-identifier "$CLUSTER"
sleep 30; kill $LACO
# Conte as linhas "FALHA" consecutivas no log — multiplicado por 0,2 s, isso
# e a janela de indisponibilidade medida. Na Cadencia: 9 falhas seguidas,
# cerca de 1,8 s — dentro dos "tipicamente abaixo de 30 s" da documentacao,
# mas o numero exato so existe porque foi medido, nao presumido.
grep -c FALHA /tmp/janela-failover.log || true

# -- Prova 4: o reader promovido ja nasceu do tamanho certo -------------------
# Apos o failover, confira que o NOVO writer (o reader promovido) nao passou
# por um salto de ACU logo em seguida — ele ja estava no tamanho do writer antigo.
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS --metric-name ServerlessDatabaseCapacity \
  --dimensions Name=DBClusterIdentifier,Value="$CLUSTER" \
  --start-time "$(date -u -d '5 min ago' +%FT%TZ)" --end-time "$(date -u +%FT%TZ)" \
  --period 30 --statistics Average --output table

# -- Prova 5: o alarme de teto sustentado dispara de verdade ------------------
# Gere carga sintetica que sustente 90% do teto por 30 min (ou reduza o teto
# temporariamente para testar) e confirme o estado do alarme.
aws cloudwatch describe-alarms \
  --alarm-names "ffv-lab-aurora-acu-no-teto" \
  --query "MetricAlarms[0].StateValue" --output text

# 1. Remova o deletion_protection ANTES do destroy — ele existe para impedir
#    exclusao acidental, nao para bloquear uma limpeza deliberada.
terraform apply -var="deletion_protection=false" -auto-approve

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

# 3. SNAPSHOT FINAL: o destroy CRIA um, por causa de skip_final_snapshot=false.
#    Ele sobrevive ao destroy de proposito, e cobra armazenamento enquanto existir.
aws rds describe-db-cluster-snapshots \
  --query "DBClusterSnapshots[?contains(DBClusterSnapshotIdentifier, 'ffv-lab-aurora')].DBClusterSnapshotIdentifier" \
  --output table
# Apague so depois de confirmar que ninguem precisa dele:
# aws rds delete-db-cluster-snapshot --db-cluster-snapshot-identifier <nome>

# 4. ALARMES criados fora do Terraform, se algum foi ajustado a mao no console.
aws cloudwatch delete-alarms --alarm-names ffv-lab-aurora-acu-no-teto 2>/dev/null || true

# 5. SEGREDO NO SECRETS MANAGER: o gerenciado pelo cluster tem exclusao propria,
#    com periodo de retencao antes de apagar de verdade.
aws secretsmanager list-secrets \
  --query "SecretList[?contains(Name, 'ffv-lab-aurora')].Name" --output table

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