Eu Tentei Redis. Não Resolvi o MCP Stateful no ECS Fargate
No meu post anterior, mostrei como um servidor MCP stateful rodando no ECS Fargate perde toda a sua sessão quando uma implantação em andamento substitui a tarefa. A falha era invisível — ALB saudável, ECS saudável, CloudWatch limpo — mas o cliente estava recebendo erros Session not found a partir da chamada 39. A solução que todos buscam é o Redis. Eu realizei o experimento. Não funcionou.
Este post explica exatamente por que o Redis falhou, o que está realmente acontecendo na camada de transporte e por que o candidato a release da especificação MCP 2026-07-28 acabou de resolver esse problema no nível do protocolo.
O que eu esperava que o Redis resolvesse
A hipótese era simples. Quando uma tarefa Fargate morre durante uma implantação em andamento, o estado da sessão em memória morre com ela. Se eu mover o estado da sessão para o ElastiCache Redis, qualquer tarefa de substituição pode lê-lo. A sessão sobrevive.
Eu configurei o experimento com duas fases:
Servidor Python FastMCP (transporte HTTP streamable,
mcpSDK,protocolVersion: 2025-03-26)Serviço ECS Fargate, 2 tarefas, atrás do ALB com sessões persistentes habilitadas
ElastiCache Redis (
cache.t3.micro) na mesma VPC, sub-rede privadaCliente de teste rodando localmente no meu laptop, acessando o ALB público
Registro estruturado em JSON em cada chamada de ferramenta:
task_id,backend,session_idFase 1:
USE_REDIS=false— linha de base, estado da sessão em memóriaFase 2:
USE_REDIS=true— estado da sessão baseado em Redis
O diagrama abaixo mostra como os componentes estavam conectados.
As duas tarefas Fargate compartilham a mesma instância do ElastiCache Redis. O ALB roteia o tráfego — primeiro para a tarefa antiga via sessão persistente, depois para a tarefa de substituição após a implantação em andamento. O cliente de teste está fora da AWS, acessando o ALB público.
O que observar: A tarefa verde (c272a920) é a tarefa original escrevendo no Redis. A tarefa vermelha (38aabc01) é a substituta — ela se conecta ao Redis com sucesso na inicialização, mas nunca realmente lê ou escreve nele durante o experimento. Essa lacuna entre "Redis conectado" e "Redis consultado" é o que este post explica.
A fase 1 confirmou a linha de base: chamadas 1–46 sucederam, a chamada 47 retornou Session not found, chamadas 47–50 todas 404. Esperado.
A fase 2 deveria ser a solução.
O que os logs realmente mostraram
Logs do CloudWatch para a tarefa da Fase 2 (c272a920) na inicialização:
{"event": "redis_connected", "endpoint": "mcp-fargate-redis.xzj9gr.0001.aps1.cache.amazonaws.com", "port": 6379}
{"event": "session_backend_selected", "backend": "redis"}
Cada chamada de ferramenta para as próximas 44 chamadas:
{"event": "tool_call", "tool_name": "set_session_value", "session_id": "8d302da7-828e-4e16-b62a-7b3b3a327d97", "task_id": "c272a920a3434f9b9446d837c21ecb7f", "backend": "redis"}
{"event": "tool_call", "tool_name": "get_session_state", "session_id": "8d302da7-828e-4e16-b62a-7b3b3a327d97", "task_id": "c272a920a3434f9b9446d837c21ecb7f", "backend": "redis"}
O Redis estava ativo. Dados estavam sendo escritos em cada chamada de set_session_value. A tarefa estava saudável.
Então eu desencadeei uma implantação em andamento. O ALB começou a rotear para uma tarefa de substituição (38aabc01). Aqui estão os logs de inicialização dessa tarefa:
{"event": "redis_connected", "endpoint": "mcp-fargate-redis.xzj9gr.0001.aps1.cache.amazonaws.com", "port": 6379}
{"event": "session_backend_selected", "backend": "redis"}
{"message": "Gerenciador de sessão StreamableHTTP iniciado"}
E então as requisições começaram a chegar do cliente:
Empresas brasileiras que utilizam ECS Fargate podem enfrentar desafios com a gestão de estado em suas aplicações. A falha do Redis em manter sessões pode levar a erros críticos, impactando a experiência do usuário e a confiabilidade do serviço.
