DE
Die Erdkugel-Figur von Eco², für dieses Portfolio nach der neuesten offiziellen Hauptfigur überarbeitet: eine himmelblaue Erdkugel mit grünem Land, einem Spross obenauf und einem braunen lächelnden Gesicht
Zurück zum Saal

Eco²

Backend · Cloud infrastructure

Hinweise zur Mülltrennung aus einem Foto und einem Gespräch.

Ein All-in-one-KI-Assistent, der versteht, wie Mülltrennung in Korea funktioniert.

2025.10.31 — 2026.02.10

Teamprojekt · Infrastruktur- und Deployment-Basis → Domain-Backend → asynchrone Verarbeitung, Konversationsagent, Verifikation

2025 새싹 해커톤 (Saessak Hackathon)Exzellenzpreis · 2025.12.02

  • Web-AppDienst eingestellt

Wie die 24 Knoten tatsächlich verbunden sind, ein Ablauf nach dem anderen.

Selbst verwaltetes Kubernetes, aufgebaut mit kubeadm. Die Karte setzt die 24 physischen Knoten und die Workloads darauf in die fünf Schichten des README und verbindet sie mit ihren tatsächlichen Verbindungen. Wird ein Ablauf gewählt, ist nur dieser Pfad hervorgehoben, mit nummerierten Schritten.

Er erkennt Abfall auf einem Foto und erklärt, wie er zu entsorgen ist, und im Gespräch ruft er Tools für Orte, Wetter, Recyclingpreise und Websuche auf und erzeugt Bilder. In diesem Teamprojekt begann ich mit der Cluster- und Deployment-Basis und weitete meinen Bereich auf das Domain-Backend, die asynchrone Verarbeitung, den Konversationsagenten und die Verifikation aus.

Von der Entwicklung für den Wettbewerb bis zur Härtung von Backend und Betrieb

Der Dienst hat seinen Betrieb beendet; eine aufgezeichnete Demo und der technische Bericht zeigen ihn in Aktion.

Verbindungskarte des Clusters · neu gezeichnet nach den Manifeste und dem Code bei Commit a072127
Verbindungskarte des Eco²-Clusters · 24 KnotenEine Karte der 24 physischen Knoten in den fünf Schichtbändern des README. Der Browser schlägt in Route 53 nur den Namen nach; nachdem TLS am ALB auf 443 endet, schickt der Istio-Ingress-Envoy auf einem NodePort die Anfrage an eine Domain-API. Die Scan-API reiht die Arbeit in RabbitMQ ein und gibt sofort eine job_id zurück; scan-worker im AI-Pool schreibt Fortschrittsereignisse per XADD in Redis Streams. Der Event Router liest sie, aktualisiert State KV und veröffentlicht in Pub/Sub, und das SSE Gateway sendet sie an den Browser. checkpoint-syncer speichert Chat-Checkpoints, und der Persistence-Consumer auf dem Chat-Knoten speichert Nachrichten in PostgreSQL. Der Platform Layer ist kein Anfragepfad; er konfiguriert, skaliert und beobachtet.BrowserHTTPS · SSEAWS ALB443 · TLS endet hierRoute 53DNSGitHub Actions · Docker HubImage · Manifest-RevisionLLM APIOpenAI · GoogleLangSmithLLM-Lauf-TracingFluent BitDaemonSet · jeder Knotenk8s-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-memoryKubernetes-Cluster24 Knoten · kubeadmEdge Layer1 KnotenService Layer8 Knoten · Envoy-SidecarIntegration Layer7 KnotenPersistence Layer5 KnotenPlatform Layer3 Knoten · Konfigurieren · Skalieren · BeobachtenVon AWS verwaltetAI-Pooldomain: worker-aiStorage-Pooldomain: worker-storageKein fester Knoten1DNS-Abfrage2 HTTPS 443 · Browser → AWS ALB23HTTP · NodePort4VirtualService5Celery-Task6 consume · RabbitMQ → scan-worker67 HTTPS · AI-Pool → LLM API78XADD scan:events9XREADGROUP10SETEX state11PUBLISH12SUBSCRIBE13SSE-Stream14Wiederherstellung bei Wiederverbindung1 HTTPS 443 · Browser → AWS ALB12HTTP · NodePort3VirtualService4Taskiq-Task5 consume · RabbitMQ → chat-worker56 HTTPS · AI-Pool → LLM API67XADD chat:events8XREADGROUP9PUBLISH10SUBSCRIBE11SSE-Stream12checkpoint13Checkpoint lesen14mit PostgreSQL synchronisieren15chat-persistence group16Nachrichten speichern1DNS-Abfrage2 HTTPS 443 · Browser → AWS ALB23HTTP · NodePort4ext-authz · gRPC 500515Blacklist-Abfrage6VirtualService7gRPC8gRPC1outbox:blacklist2blacklist.events3 blacklist.events · RabbitMQ → auth-worker34Blacklist speichern5 Celery batch · RabbitMQ → users-worker56UPSERT1Image · Manifest-Revision2Ingress → ALB · DNS-Einträge3xDS-Konfiguration4Pod-Anzahl5 Pod-Anzahl · KEDA → Storage-Pool56Logs7 LLM-Lauf-Tracing · AI-Pool → LangSmith7

Scan-Anfrage → Live-Zustellung

Eine Fotoanalyse-Anfrage wird zu eingereihter Arbeit, und ihre Fortschrittsereignisse kommen zum selben Browser zurück.

  1. BrowserDNS-AbfrageRoute 53

    Nur der Name wird aus den Route-53-Einträgen aufgelöst. Anfragen laufen nicht durch DNS.

  2. BrowserHTTPS 443AWS ALB

    TLS endet am ALB.

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

    Über den NodePort des EC2-Instanzziels an den Istio-Ingress-Envoy übergeben.

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

    An die Scan-API geroutet, die die Arbeit einreiht und sofort eine job_id zurückgibt; eine Ergebnisabfrage antwortet mit 202, bis der Job fertig ist.

  5. Scan APIk8s-api-scanCelery-TaskRabbitMQk8s-rabbitmq

    Der Scan-Task kommt in RabbitMQ.

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

    scan-worker (Celery · gevent) im AI-Pool übernimmt ihn und führt Vision → Rule → Answer → Reward aus. Die vier Stufen sind verkettete Celery-Tasks, keine Knoten.

  7. AI-Poolk8s-worker-ai · k8s-worker-ai-2HTTPSLLM API

    Die Scan- und Chat-Worker rufen die APIs von OpenAI und Google auf.

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

    Fortschrittsereignisse werden in einen von vier Streams-Shards geschrieben.

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

    Der Event Router liest sie als Consumer Group und bestätigt sie nach der Verarbeitung per XACK; pending und reclaim halten die Zustellung at-least-once.

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

    Er schreibt den neuesten Zustand und eine Markierung gegen doppelte Verarbeitung in State KV auf demselben Redis-Knoten.

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

    In Echtzeit auf dem Kanal des Jobs im Shard-Pub/Sub zugestellt.

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

    Das SSE Gateway abonniert über einen gemeinsamen Listener pro Prozess und verteilt an jeden verbundenen Browser.

  13. SSE Gatewayk8s-sse-gatewaySSE-StreamBrowser

    Eine Verbindung, die über denselben ALB- und Ingress-Pfad geöffnet wird. Die Zustellung ist at-least-once; Duplikate werden idempotent behandelt.

  14. State KVk8s-redis-streamsWiederherstellung bei WiederverbindungSSE Gatewayk8s-sse-gateway

    Bei einer Wiederverbindung mit Last-Event-ID füllen State KV und die aufbewahrten Streams verpasste Ereignisse auf.

Chat · Tokens und Speicherung

Chat-Tokens nehmen denselben Ereignispfad wie Scan; Checkpoints und Nachrichten werden von zwei verschiedenen Workloads gespeichert.

  1. BrowserHTTPS 443AWS ALB

    TLS endet am ALB.

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

    Über den NodePort des EC2-Instanzziels an den Istio-Ingress-Envoy übergeben.

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

    An die Chat-API geroutet.

  4. Chat APIk8s-api-chatTaskiq-TaskRabbitMQk8s-rabbitmq

    Der Chat-Task kommt in RabbitMQ.

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

    chat-worker (Taskiq · asyncio) klassifiziert die Absicht mit LangGraph, führt dann bei Bedarf vision, die gewählten Tools, aggregator und bei Bedarf eine Zusammenfassung aus und antwortet. Jede Anfrage führt nur die Zweige aus, die sie braucht.

  6. AI-Poolk8s-worker-ai · k8s-worker-ai-2HTTPSLLM API

    Die Scan- und Chat-Worker rufen die APIs von OpenAI und Google auf.

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

    Tokens und Stufenereignisse werden in vier Streams-Shards geschrieben; ab dort ist der Zustellpfad derselbe wie bei Scan.

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

    Der Event Router liest sie als Consumer Group und bestätigt sie nach der Verarbeitung per XACK; pending und reclaim halten die Zustellung at-least-once.

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

    In Echtzeit auf dem Kanal des Jobs im Shard-Pub/Sub zugestellt.

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

    Das SSE Gateway abonniert über einen gemeinsamen Listener pro Prozess und verteilt an jeden verbundenen Browser.

  11. SSE Gatewayk8s-sse-gatewaySSE-StreamBrowser

    Eine Verbindung, die über denselben ALB- und Ingress-Pfad geöffnet wird. Die Zustellung ist at-least-once; Duplikate werden idempotent behandelt.

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

    Der LangGraph-Checkpoint liegt in Redis Cache.

  13. Cachek8s-redis-cacheCheckpoint lesencheckpoint-syncerk8s-worker-ai · k8s-worker-ai-2

    checkpoint-syncer liest den Checkpoint aus Redis.

  14. checkpoint-syncerk8s-worker-ai · k8s-worker-ai-2mit PostgreSQL synchronisierenPostgreSQLk8s-postgresql

    AsyncPostgresSaver speichert ihn asynchron in PostgreSQL.

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

    Der Persistence-Consumer auf dem Chat-Knoten liest done-Ereignisse als Consumer Group.

  16. persistence consumerk8s-api-chatNachrichten speichernPostgreSQLk8s-postgresql

    Chat-Nachrichten werden in PostgreSQL gespeichert. Das ist ein anderer Workload als checkpoint-syncer.

Eingang · Auth

Der synchrone Pfad vom Eingang des Clusters bis zu einer Domain-API. Nur Policy-geschützte Pfade durchlaufen zuerst die Auth-Prüfung; Pod-Verkehr zwischen Knoten läuft über Calico VXLAN.

  1. BrowserDNS-AbfrageRoute 53

    Nur der Name wird aus den Route-53-Einträgen aufgelöst. Anfragen laufen nicht durch DNS.

  2. BrowserHTTPS 443AWS ALB

    TLS endet am ALB.

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

    Über den NodePort des EC2-Instanzziels an den Istio-Ingress-Envoy übergeben.

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

    Nur Pfade unter einer CUSTOM-Policy fragen zuerst den Go-ext-authz (Timeout 2 s, failOpen false). Pfade wie Login, Health und Docs sind ausgenommen.

  5. ext-authzk8s-api-authBlacklist-Abfrageblacklistk8s-redis-auth

    Das Token wird gegen die Redis-Blacklist geprüft.

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

    An die Chat-API geroutet.

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

    Der synchrone Aufruf chat → images, der im README genannt ist.

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

    Der synchrone Aufruf auth → users, der im README genannt ist.

Storage-Pool · asynchrones Speichern

Die Auth-Blacklist und der Charakterbesitz werden von Workern im Storage-Pool gespeichert, die ihre Arbeit aus RabbitMQ beziehen.

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

    auth-relay (der auth-Bus des README) liest die Redis-Outbox.

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

    Er veröffentlicht erneut in RabbitMQ, mit Wiederholungen und einer DLQ.

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

    auth-worker empfängt die Blacklist-Ereignisse.

  4. auth-workerk8s-worker-storage · k8s-worker-storage-2Blacklist speichernblacklistk8s-redis-auth

    Sie werden in der Redis-Blacklist gespeichert.

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

    users-worker empfängt Arbeit zum Charakterbesitz in Batches.

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

    Sie wird auf PostgreSQL angewandt.

Konfigurieren · Skalieren · Beobachten

Der Platform Layer ist kein Schritt, den Anfragen durchlaufen; er deployt, konfiguriert, skaliert und beobachtet die anderen Schichten. Die Knoten sind mit Terraform erstellte EC2-Instanzen, auf denen Ansible kubeadm und Calico installiert hat; CI validiert Terraform nur und wendet es nie automatisch an.

  1. GitHub Actions · Docker HubImage · Manifest-RevisionArgo CD image updaterk8s-master

    Argo CD gleicht die Cluster-Konfiguration über App-of-Apps und Sync Waves an. Bestätigt wurde nur die Control-Plane-Platzierung des Image Updaters.

  2. ALB Controller · ExternalDNSk8s-masterIngress → ALB · DNS-EinträgeVon AWS verwaltet

    ALB Controller und ExternalDNS konfigurieren Ressourcen auf AWS-Seite. Das ist kein Pfad, den Anfragen nehmen.

  3. Istiodk8s-masterxDS-KonfigurationIstio ingress Envoyk8s-ingress-gateway

    Istiod verteilt die Konfiguration von Gateway, VirtualService und EnvoyFilter per xDS an den Ingress-Envoy und an den Envoy-Sidecar jeder API.

  4. KEDAk8s-monitoringPod-AnzahlAI-Poolk8s-worker-ai · k8s-worker-ai-2

    KEDA passt die Anzahl der Worker-Pods an. Die Knotenzahl ändert sich nicht.

  5. KEDAk8s-monitoringPod-AnzahlStorage-Poolk8s-worker-storage · k8s-worker-storage-2

    Worker-Pods im Storage-Pool werden auf dieselbe Weise skaliert.

  6. Fluent BitLogsElasticsearchk8s-logging

    Fluent Bit ist ein DaemonSet auf jedem Knoten und sendet Logs an Elasticsearch.

  7. AI-Poolk8s-worker-ai · k8s-worker-ai-2LLM-Lauf-TracingLangSmith

    LLM-Aufruf-Traces gehen an LangSmith, ein externes SaaS.

Alle Verbindungen in gleicher Stärke. Wird ein Ablauf gewählt, ist nur sein Pfad hervorgehoben, mit nummerierten Schritten.

  • Durchgezogen · Richtung, in der Anfragen, Arbeit, Ereignisse und Schreibvorgänge fließen
  • Gepunktet · DNS-Abfrage; Anfragen laufen nicht hindurch
  • Gestrichelt · Konfigurieren oder Skalieren; kein Datenpfad
  • Lang strichpunktiert · Logs und Ausführungs-Tracing
  • Dicke schwarze Linie · der gewählte Ablauf; Nummern geben die Reihenfolge an
  • Kasten · ein physischer Knoten, Hostname in der Kopfzeile
  • Innerer Chip · ein Workload auf diesem Knoten
  • Gestrichelter Rahmen · ein Scheduling-Pool aus zwei Knoten
  • Gestrichelter Kasten · außerhalb des Clusters, nicht als Knoten gezählt
  • Orange Umrandung · wo ein Modell entscheidet
  • Control plane1 Knoten
  • Domain API8 Knoten
  • AI-Pool2 Knoten
  • Storage-Pool2 Knoten
  • Data5 Knoten
  • Platform6 Knoten

Die fünf Schichten des README (die Bänder) und die physischen Gruppen (der Farbton der Kopfzeile jedes Knotens) gruppieren dieselben 24 Knoten unterschiedlich. State KV teilt sich den Streams-Knoten und wird nicht separat gezählt; Route 53, der ALB und Dienste außerhalb des Clusters sind keine Knoten. Ein Pool ist ein Scheduling-Bereich, keine Behauptung, dass jeder Pod auf beiden Knoten läuft.

Aufbau mit 24 Knoten · nach der Knotenliste des Dashboards vom January 21, 2026

24Knoten

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

  1. 1Control plane

    role: control-plane

    kube-apiserver · scheduler · controller-manager · etcd sowie die Plattform-Controller.

    1. k8s-master

  2. 8Domain API

    domain: <Dienst>

    Ein Knoten pro Domain. Interne Aufrufe nutzen 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

    Zwei Scheduling-Pools mit je zwei Knoten. KEDA ändert die Pod-Anzahl; die Knotenzahl bleibt gleich.

    Storage-Pooldomain: worker-storage
    1. k8s-worker-storage
    2. k8s-worker-storage-2
    AI-Pooldomain: worker-ai
    1. k8s-worker-ai
    2. k8s-worker-ai-2

  4. 5Data

    Redis ist nach Zweck auf vier Knoten aufgeteilt. Der Speicher für PostgreSQL ist EBS CSI · gp3.

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

  5. 6Platform

    Messaging, Beobachtung, Ingress und Echtzeit-Zustellung haben jeweils einen eigenen Knoten.

    1. k8s-rabbitmq
    2. k8s-monitoring
    3. k8s-logging
    4. k8s-ingress-gateway
    5. k8s-sse-gateway
    6. k8s-event-router
Jeder Knoten
  • Fluent Bit · DaemonSet
  • Calico

Konfigurierte Modelle · nach Anbieter

Der Dienst wurde eingestellt, daher sind dies die im Repository konfigurierten Modelle, keine heute verfügbare Auswahl. Jede Rolle ist separat aufgeführt; es ist keine Liste verifizierter Läufe.

  • OpenAI

    Standardanbieter für Chat

    Chat

    • openai/gpt-5.2Standard

    Das Standardmodell ist gpt-5.2; ein in der Anfrage genanntes Modell wird stattdessen verwendet.

    Scan

    • gpt-5.2Standard
    • gpt-5.2-pro
    • gpt-5.1
    • gpt-5
    • gpt-5-pro
    • gpt-5-mini

    Modelle außerhalb der Zuordnung von 13 Modellen werden abgelehnt.

    Bildzuordnung

    • gpt-image-1.5

    Getrennt von gpt-5.2, dem Orchestrierungsmodell für Responses. Bildgenerierung ist standardmäßig aus.

    Bewertung

    • gpt-4o-miniStandard

    Der LLM-Grader für die Gesprächsbewertung, getrennt vom Chat-Modell.

  • Google

    Wenn Chat Google wählt

    Chat

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

    Ist Google gewählt, ist gemini-3-flash-preview der Standard.

    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

    Bildzuordnung

    • gemini-3-pro-image-preview

Quellebackend main d8840c7Öffentlicher Commit September 29, 2026 · geprüft October 8, 2026