PT
O personagem-globo do Eco², refinado para este portfólio a partir do mais recente personagem principal oficial: um globo azul-celeste com terras verdes, um broto no topo e um rosto sorridente marrom
Voltar à sala

Eco²

Backend · Cloud infrastructure

Orientação de reciclagem a partir de uma foto e de uma conversa.

Um assistente de IA tudo-em-um que entende como funciona a reciclagem na Coreia.

2025.10.31 — 2026.02.10

Projeto em equipe · base de infraestrutura e implantação → backend de domínio → processamento assíncrono, agente conversacional, verificação

2025 새싹 해커톤 (Hackathon Saessak)Prêmio de excelência · 2025.12.02

  • App webServiço encerrado

Como os 24 nós se conectam de fato, um fluxo de cada vez.

Kubernetes autogerenciado, construído com kubeadm. O mapa coloca os 24 nós físicos e seus workloads dentro das cinco camadas do README e os liga por suas conexões reais. Ao escolher um fluxo, só esse caminho é destacado, com etapas numeradas.

Ele identifica o resíduo a partir de uma foto e explica como descartá-lo, e na conversa chama ferramentas de locais, clima, preços de recicláveis e busca na web, e gera imagens. Neste projeto em equipe, comecei pelo cluster e pela base de implantação e ampliei meu escopo para o backend de domínio, o processamento assíncrono, o agente conversacional e a verificação.

Do desenvolvimento para a competição ao reforço do backend e da operação

O serviço encerrou sua operação; uma demo gravada e o relatório técnico o mostram em funcionamento.

Mapa de conexões do cluster · redesenhado a partir dos manifests e do código no commit a072127
Mapa de conexões do cluster do Eco² · 24 nósUm mapa dos 24 nós físicos dentro das cinco faixas de camadas do README. O navegador só resolve o nome no Route 53; depois que o TLS termina no ALB na porta 443, o Envoy de ingress do Istio em um NodePort envia a requisição a uma API de domínio. A API do Scan enfileira o trabalho no RabbitMQ e devolve um job_id na hora; o scan-worker, no pool de IA, grava com XADD os eventos de progresso no Redis Streams. O Event Router os lê, atualiza o State KV e publica no Pub/Sub, e o SSE Gateway os envia ao navegador. O checkpoint-syncer armazena os checkpoints do Chat e o persistence consumer do nó do Chat armazena as mensagens no PostgreSQL. A Platform Layer não é um caminho de requisição; ela configura, escala e observa.NavegadorHTTPS · SSEAWS ALB443 · o TLS termina aquiRoute 53DNSGitHub Actions · Docker Hubimagem · revisão de manifestLLM APIOpenAI · GoogleLangSmithrastreamento de execuções de LLMFluent BitDaemonSet · todos os nósk8s-masterALB Controller · ExternalDNSArgo CD image updaterIstiodcontrol planek8s-ingress-gatewayIstio ingress Envoyk8s-api-scanScan APIk8s-api-chatChat APImessage consumerpersistence consumerk8s-api-authauth APIext-authzk8s-api-infoInfo APIinfo-workerk8s-api-charactercharacter APIk8s-api-imageimages APIk8s-api-usersusers APIk8s-api-locationlocation APIk8s-sse-gatewaySSE Gatewayk8s-event-routerEvent Routerk8s-rabbitmqRabbitMQk8s-worker-aik8s-worker-ai-2k8s-worker-storagek8s-worker-storage-2k8s-redis-pubsubPub/Subk8s-redis-streamsStreamsState KVk8s-redis-cacheCachek8s-postgresqlPostgreSQLk8s-redis-authblacklistk8s-monitoringKEDAPrometheusGrafanaAlertmanagerk8s-loggingElasticsearchKibanascan-workerchat-workercheckpoint-syncerauth-relayauth-workerusers-workercharacter-workercharacter-match-workerKialiJaeger · dev in-memoryCluster Kubernetes24 nós · kubeadmEdge Layer1 nóService Layer8 nós · sidecar EnvoyIntegration Layer7 nósPersistence Layer5 nósPlatform Layer3 nós · configurar · escalar · observarGerenciado pela AWSPool de IAdomain: worker-aipool de armazenamentodomain: worker-storageNenhum nó fixado1Consulta DNS2 HTTPS 443 · Navegador → AWS ALB23HTTP · NodePort4VirtualService5Tarefa Celery6 consume · RabbitMQ → scan-worker67 HTTPS · Pool de IA → LLM API78XADD scan:events9XREADGROUP10SETEX state11PUBLISH12SUBSCRIBE13Stream SSE14Recuperação na reconexão1 HTTPS 443 · Navegador → AWS ALB12HTTP · NodePort3VirtualService4Tarefa Taskiq5 consume · RabbitMQ → chat-worker56 HTTPS · Pool de IA → LLM API67XADD chat:events8XREADGROUP9PUBLISH10SUBSCRIBE11Stream SSE12checkpoint13ler o checkpoint14sincronizar com o PostgreSQL15chat-persistence group16salvar mensagens1Consulta DNS2 HTTPS 443 · Navegador → AWS ALB23HTTP · NodePort4ext-authz · gRPC 500515consulta à blacklist6VirtualService7gRPC8gRPC1outbox:blacklist2blacklist.events3 blacklist.events · RabbitMQ → auth-worker34armazenar a blacklist5 Celery batch · RabbitMQ → users-worker56UPSERT1imagem · revisão de manifest2Ingress → ALB · registros DNS3Configuração xDS4número de pods5 número de pods · KEDA → pool de armazenamento56logs7 rastreamento de execuções de LLM · Pool de IA → LangSmith7

Requisição do Scan → entrega ao vivo

Uma requisição de análise de foto vira trabalho na fila, e seus eventos de progresso voltam ao mesmo navegador.

  1. NavegadorConsulta DNSRoute 53

    Só o nome é resolvido a partir dos registros do Route 53. As requisições não passam pelo DNS.

  2. NavegadorHTTPS 443AWS ALB

    O TLS termina no ALB.

  3. AWS ALBHTTP · NodePortIstio ingress Envoyk8s-ingress-gateway

    Entregue ao Envoy de ingress do Istio pelo NodePort do destino de instância EC2.

  4. Istio ingress Envoyk8s-ingress-gatewayVirtualServiceScan APIk8s-api-scan

    Roteado para a API do Scan, que enfileira o trabalho e devolve um job_id na hora; a consulta do resultado responde 202 até o job terminar.

  5. Scan APIk8s-api-scanTarefa CeleryRabbitMQk8s-rabbitmq

    A tarefa do Scan vai para o RabbitMQ.

  6. RabbitMQk8s-rabbitmqconsumescan-workerk8s-worker-ai · k8s-worker-ai-2

    O scan-worker (Celery · gevent), no pool de IA, a recebe e executa Vision → Rule → Answer → Reward. As quatro etapas são tarefas do Celery encadeadas, não nós.

  7. Pool de IAk8s-worker-ai · k8s-worker-ai-2HTTPSLLM API

    Os workers de scan e chat chamam as APIs da OpenAI e do Google.

  8. scan-workerk8s-worker-ai · k8s-worker-ai-2XADD scan:eventsStreamsk8s-redis-streams

    Os eventos de progresso são gravados em um dos quatro shards do Streams.

  9. Streamsk8s-redis-streamsXREADGROUPEvent Routerk8s-event-router

    O Event Router os lê como consumer group e faz XACK após processá-los; pending e reclaim mantêm a entrega at-least-once.

  10. Event Routerk8s-event-routerSETEX stateState KVk8s-redis-streams

    Grava o estado mais recente e um marcador de processamento duplicado no State KV, no mesmo nó Redis.

  11. Event Routerk8s-event-routerPUBLISHPub/Subk8s-redis-pubsub

    Entregue em tempo real no canal do job, no Pub/Sub de shard.

  12. Pub/Subk8s-redis-pubsubSUBSCRIBESSE Gatewayk8s-sse-gateway

    O SSE Gateway assina por meio de um único listener compartilhado por processo e distribui para cada navegador conectado.

  13. SSE Gatewayk8s-sse-gatewayStream SSENavegador

    Uma conexão aberta pelo mesmo caminho de ALB e ingress. A entrega é at-least-once; duplicatas são tratadas de forma idempotente.

  14. State KVk8s-redis-streamsRecuperação na reconexãoSSE Gatewayk8s-sse-gateway

    Na reconexão com Last-Event-ID, o State KV e os Streams retidos preenchem os eventos perdidos.

Chat · tokens e armazenamento

Os tokens do Chat seguem o mesmo caminho de eventos do Scan; checkpoints e mensagens são armazenados por dois workloads diferentes.

  1. NavegadorHTTPS 443AWS ALB

    O TLS termina no ALB.

  2. AWS ALBHTTP · NodePortIstio ingress Envoyk8s-ingress-gateway

    Entregue ao Envoy de ingress do Istio pelo NodePort do destino de instância EC2.

  3. Istio ingress Envoyk8s-ingress-gatewayVirtualServiceChat APIk8s-api-chat

    Roteado para a API do Chat.

  4. Chat APIk8s-api-chatTarefa TaskiqRabbitMQk8s-rabbitmq

    A tarefa do Chat vai para o RabbitMQ.

  5. RabbitMQk8s-rabbitmqconsumechat-workerk8s-worker-ai · k8s-worker-ai-2

    O chat-worker (Taskiq · asyncio) classifica a intenção com LangGraph, depois executa a visão se necessário, as ferramentas selecionadas, o agregador e um resumo se necessário, e responde. Cada requisição executa só os ramos de que precisa.

  6. Pool de IAk8s-worker-ai · k8s-worker-ai-2HTTPSLLM API

    Os workers de scan e chat chamam as APIs da OpenAI e do Google.

  7. chat-workerk8s-worker-ai · k8s-worker-ai-2XADD chat:eventsStreamsk8s-redis-streams

    Tokens e eventos de etapa são gravados em quatro shards do Streams; dali em diante, o caminho de entrega é o mesmo do Scan.

  8. Streamsk8s-redis-streamsXREADGROUPEvent Routerk8s-event-router

    O Event Router os lê como consumer group e faz XACK após processá-los; pending e reclaim mantêm a entrega at-least-once.

  9. Event Routerk8s-event-routerPUBLISHPub/Subk8s-redis-pubsub

    Entregue em tempo real no canal do job, no Pub/Sub de shard.

  10. Pub/Subk8s-redis-pubsubSUBSCRIBESSE Gatewayk8s-sse-gateway

    O SSE Gateway assina por meio de um único listener compartilhado por processo e distribui para cada navegador conectado.

  11. SSE Gatewayk8s-sse-gatewayStream SSENavegador

    Uma conexão aberta pelo mesmo caminho de ALB e ingress. A entrega é at-least-once; duplicatas são tratadas de forma idempotente.

  12. chat-workerk8s-worker-ai · k8s-worker-ai-2checkpointCachek8s-redis-cache

    O checkpoint do LangGraph fica no Redis Cache.

  13. Cachek8s-redis-cacheler o checkpointcheckpoint-syncerk8s-worker-ai · k8s-worker-ai-2

    O checkpoint-syncer lê o checkpoint do Redis.

  14. checkpoint-syncerk8s-worker-ai · k8s-worker-ai-2sincronizar com o PostgreSQLPostgreSQLk8s-postgresql

    O AsyncPostgresSaver o armazena no PostgreSQL de forma assíncrona.

  15. Streamsk8s-redis-streamschat-persistence grouppersistence consumerk8s-api-chat

    O persistence consumer do nó do Chat lê os eventos done como consumer group.

  16. persistence consumerk8s-api-chatsalvar mensagensPostgreSQLk8s-postgresql

    As mensagens do Chat são salvas no PostgreSQL. É um workload diferente do checkpoint-syncer.

Entrada · autenticação

O caminho síncrono da entrada do cluster até uma API de domínio. Só os caminhos protegidos por política verificam a autenticação primeiro; o tráfego de pods entre nós passa pelo Calico VXLAN.

  1. NavegadorConsulta DNSRoute 53

    Só o nome é resolvido a partir dos registros do Route 53. As requisições não passam pelo DNS.

  2. NavegadorHTTPS 443AWS ALB

    O TLS termina no ALB.

  3. AWS ALBHTTP · NodePortIstio ingress Envoyk8s-ingress-gateway

    Entregue ao Envoy de ingress do Istio pelo NodePort do destino de instância EC2.

  4. Istio ingress Envoyk8s-ingress-gatewayext-authz · gRPC 50051ext-authzk8s-api-auth

    Só os caminhos sob uma política CUSTOM consultam primeiro o ext-authz em Go (timeout de 2 s, failOpen false). Caminhos como login, health e docs ficam de fora.

  5. ext-authzk8s-api-authconsulta à blacklistblacklistk8s-redis-auth

    O token é verificado na blacklist do Redis.

  6. Istio ingress Envoyk8s-ingress-gatewayVirtualServiceChat APIk8s-api-chat

    Roteado para a API do Chat.

  7. Chat APIk8s-api-chatgRPCimages APIk8s-api-image

    A chamada síncrona chat → images citada no README.

  8. auth APIk8s-api-authgRPCusers APIk8s-api-users

    A chamada síncrona auth → users citada no README.

Pool de armazenamento · gravações assíncronas

A blacklist de autenticação e a posse dos personagens são armazenadas pelos workers do pool de armazenamento, que recebem o trabalho do RabbitMQ.

  1. blacklistk8s-redis-authoutbox:blacklistauth-relayk8s-worker-storage · k8s-worker-storage-2

    O auth-relay (o auth-Bus do README) lê o outbox do Redis.

  2. auth-relayk8s-worker-storage · k8s-worker-storage-2blacklist.eventsRabbitMQk8s-rabbitmq

    Ele republica no RabbitMQ, com novas tentativas e uma DLQ.

  3. RabbitMQk8s-rabbitmqblacklist.eventsauth-workerk8s-worker-storage · k8s-worker-storage-2

    O auth-worker recebe os eventos da blacklist.

  4. auth-workerk8s-worker-storage · k8s-worker-storage-2armazenar a blacklistblacklistk8s-redis-auth

    Eles são armazenados na blacklist do Redis.

  5. RabbitMQk8s-rabbitmqCelery batchusers-workerk8s-worker-storage · k8s-worker-storage-2

    O users-worker recebe em lotes o trabalho de posse de personagens.

  6. users-workerk8s-worker-storage · k8s-worker-storage-2UPSERTPostgreSQLk8s-postgresql

    É aplicado ao PostgreSQL.

Configurar · escalar · observar

A Platform Layer não é uma etapa pela qual as requisições passam; ela implanta, configura, escala e observa as outras camadas. Os nós são instâncias EC2 criadas com Terraform, com kubeadm e Calico instalados pelo Ansible; a CI só valida o Terraform e nunca o aplica automaticamente.

  1. GitHub Actions · Docker Hubimagem · revisão de manifestArgo CD image updaterk8s-master

    O Argo CD alinha a configuração do cluster por App-of-Apps e Sync Waves. Só a alocação do image updater no control plane foi confirmada.

  2. ALB Controller · ExternalDNSk8s-masterIngress → ALB · registros DNSGerenciado pela AWS

    O ALB Controller e o ExternalDNS configuram os recursos do lado da AWS. Não é um caminho pelo qual as requisições passam.

  3. Istiodk8s-masterConfiguração xDSIstio ingress Envoyk8s-ingress-gateway

    O Istiod envia via xDS a configuração de Gateway, VirtualService e EnvoyFilter ao Envoy de ingress e ao sidecar Envoy de cada API.

  4. KEDAk8s-monitoringnúmero de podsPool de IAk8s-worker-ai · k8s-worker-ai-2

    O KEDA ajusta o número de pods dos workers. O número de nós não muda.

  5. KEDAk8s-monitoringnúmero de podspool de armazenamentok8s-worker-storage · k8s-worker-storage-2

    Os pods dos workers do pool de armazenamento são escalados da mesma forma.

  6. Fluent BitlogsElasticsearchk8s-logging

    O Fluent Bit é um DaemonSet em todos os nós e envia os logs ao Elasticsearch.

  7. Pool de IAk8s-worker-ai · k8s-worker-ai-2rastreamento de execuções de LLMLangSmith

    Os traces das chamadas de LLM vão para o LangSmith, um SaaS externo.

Todas as conexões com a mesma espessura. Escolha um fluxo para destacar só o caminho dele, com etapas numeradas.

  • Contínua · direção em que fluem requisições, trabalho, eventos e gravações
  • Pontilhada · consulta DNS; as requisições não passam por ela
  • Tracejada · configuração ou escala; não é um caminho de dados
  • Traço e ponto longos · logs e rastreamento de execuções
  • Linha preta grossa · o fluxo selecionado; os números dão a ordem
  • Caixa · um nó físico, com o nome do host no cabeçalho
  • Chip interno · uma carga de trabalho rodando nesse nó
  • Moldura tracejada · um pool de agendamento de dois nós
  • Caixa tracejada · fora do cluster, não contada como nó
  • Contorno laranja · onde um modelo decide
  • Control plane1 nó
  • Domain API8 nós
  • Pool de IA2 nós
  • pool de armazenamento2 nós
  • Data5 nós
  • Platform6 nós

As cinco camadas do README (as faixas) e os grupos físicos (o tom do cabeçalho de cada nó) agrupam de forma diferente os mesmos 24 nós. O State KV compartilha o nó do Streams e não é contado à parte; Route 53, o ALB e os serviços fora do cluster não são nós. Um pool é um intervalo de scheduling, não a afirmação de que todo pod roda nos dois nós.

Arranjo de 24 nós · a partir da lista de nós do painel de January 21, 2026

24nós

24 = 1 control plane + 8 API + 4 worker + 5 data + 6 platform

  1. 1Control plane

    role: control-plane

    kube-apiserver · scheduler · controller-manager · etcd, além dos controladores da plataforma.

    1. k8s-master

  2. 8Domain API

    domain: <serviço>

    Um nó por domínio. As chamadas internas usam gRPC.

    1. k8s-api-auth
    2. k8s-api-users
    3. k8s-api-scan
    4. k8s-api-character
    5. k8s-api-location
    6. k8s-api-image
    7. k8s-api-chat
    8. k8s-api-info

  3. 4Execution worker

    Dois pools de scheduling de dois nós cada. O KEDA muda o número de pods; o número de nós continua o mesmo.

    pool de armazenamentodomain: worker-storage
    1. k8s-worker-storage
    2. k8s-worker-storage-2
    Pool de IAdomain: worker-ai
    1. k8s-worker-ai
    2. k8s-worker-ai-2

  4. 5Data

    O Redis é dividido em quatro nós por finalidade. O armazenamento do PostgreSQL é EBS CSI · gp3.

    1. k8s-postgresql
    2. k8s-redis-auth
    3. k8s-redis-streams
    4. k8s-redis-cache
    5. k8s-redis-pubsub

  5. 6Platform

    Mensageria, observabilidade, ingress e entrega em tempo real têm cada um seu próprio nó.

    1. k8s-rabbitmq
    2. k8s-monitoring
    3. k8s-logging
    4. k8s-ingress-gateway
    5. k8s-sse-gateway
    6. k8s-event-router
Todos os nós
  • Fluent Bit · DaemonSet
  • Calico

Modelos configurados · por provedor

O serviço foi encerrado, então estes são os modelos configurados no repositório, não opções disponíveis hoje. Cada papel aparece separado; não é uma lista de execuções verificadas.

  • OpenAI

    Provedor padrão do Chat

    Chat

    • openai/gpt-5.2padrão

    O modelo padrão é gpt-5.2; um modelo indicado na requisição é usado no lugar.

    Scan

    • gpt-5.2padrão
    • gpt-5.2-pro
    • gpt-5.1
    • gpt-5
    • gpt-5-pro
    • gpt-5-mini

    Modelos fora do mapeamento de 13 modelos são rejeitados.

    Mapeamento de imagens

    • gpt-image-1.5

    Separado do gpt-5.2, o modelo de orquestração do Responses. A geração de imagens fica desligada por padrão.

    Avaliação

    • gpt-4o-minipadrão

    O corretor LLM da avaliação de conversas, separado do modelo do Chat.

  • Google

    Quando o Chat escolhe o Google

    Chat

    • google/gemini-3-pro-preview
    • google/gemini-3-flash-preview

    Com o Google selecionado, gemini-3-flash-preview é o padrão.

    Scan

    • gemini-3-pro-preview
    • gemini-3-flash-preview
    • gemini-2.5-pro
    • gemini-2.5-flash
    • gemini-2.5-flash-lite
    • gemini-2.0-flash
    • gemini-2.0-flash-lite

    Mapeamento de imagens

    • gemini-3-pro-image-preview

Fontebackend main d8840c7Commit público de September 29, 2026 · verificado em October 8, 2026