Ist es heutzutage noch ein Hindernis, eine GenAI-App mal eben mit Python zu bauen, damit man hinter dem PoC ein grünes Häkchen setzen kann? Ich glaube nicht. Spätestens nach ein paar Codeanpassungen, die die letzten Vibe-Code-Kontaminierungen beseitigen, geht es ans Shipping…
…ja, aber wie? Wo? Wie wird denn der Spaß jetzt gehostet? Was muss dafür getan werden? Was muss beachtet werden? Wie kann ich den Ansturm an Usern handlen?
Ich glaube der größte Blindfleck, den Data Scientists, AI Engineers und Co. haben, ist die Kompetenz darüber, was für TODOs und Aufwände hinter einer production-ready Software stecken. Und warum sollte es AI Engineers interessieren, wie Software professionell gehostet werden? Aus dem gleichen Grund, warum sich Software Engineers reinziehen, wie Multiagenten gebaut werden – perspektivisch gesehen schadet es dem Profil ganz und gar nicht.
In dieser Artikelreihe soll es darum gehen, den Blindfleck anhand einer realen Infrastruktur, die so bei einem Kunden umgesetzt wurde, mindestens zu verkleinern oder für manche Use Cases vollständig zu beseitigen. Die Posts zeigen bewusst alle Dienste und Komponenten, die in diesem Fall in AWS als Cloud-Provider verwendet wurden. Ich drehe den Detailgrad hoch, damit bei der Adoption der gezeigten Infrastruktur so wenig Fragezeichen wie möglich bestehen bleiben. Ich werde mich so kurz wie möglich halten aber mit einem Artikel wird es nicht getan sein.
Use Case
Kurz zum Kontext: In dem Projekt ging es darum, eine GenAI-App zu erstellen, um die Informationen von Tierarzt-Rechnungen (pdfs) zu extrahieren. Die Rechnungspositionen wurden automatisch aufgelistet, extrahiert und kategorisiert (eine Impfung war eine Prävention, etc.). Zur Extraktion gehörten die Positionsbezeichnungen, Preise, Steuer etc. Außerdem wurden die Metadaten der Rechnung extrahiert: Tierarztklinik, Adresse von Versicherungsnehmer, Datum der Rechnungseinreichung, Name des Tieres, Rasse, etc.
Infrastruktur
Ich musste einen Weg finden, die Infrastruktur aufzugliedern. Das komplette Bild direkt zu zeigen, wäre didaktisch wahrscheinlich wenig sinnvoll gewesen. Ich habe die Architektur deshalb folgendermaßen unterteilt: Networking & Foundation, Compute & Containerisierung, Observability, LLM-Integration und Data Ingestion. Heute fangen wir mit dem ersten Thema an.
Sicherheitskäfig (Networking & Foundation)
In der unteren Darstellung werden die Networking-Services aufgelistet, die es benötigte, um den Multiagent in einem sicheren Rahmen bereitzustellen. Gehen wir mal alle Komponenten durch.
In der Cloud ist “Standard” oft das Gegenteil von “Sicher”. Man möchte den Entwicklern direkt eine barrierefreie Implementierung ermöglichen, weswegen man erstmal direkt auf Services ohne Probleme via Internet-Routing zugreifen kann. Gut für den Start aber ein digitaler Tresor schadet nicht, wenn es um hochsensible Kundendaten geht 💀. Introducing: VPC 🌈.
Von „Standard“ zu „Sicher“
Die VPC (Virtual Private Cloud) ist ein isoliertes logisches Netzwerk innerhalb der AWS-Cloud und definiert damit, was standardmäßig vom öffentlichen Internet abgeschirmt ist. Der Multiagent verarbeitete sensible Rechnungsdaten und hatte eine Verbindung zu Azure AI Foundry. Deshalb war ein VPC zwingend notwendig, um einen direkten Zugriff auf Container und Datenbanken zu verhindern.
Wenn wir schon bei VPCs sind, dann lasst uns direkt Public- und Private Subnets abhaken: Das Public Subnet ist ein Teil des VPCs und definiert Komponenten, die zwingend von außen erreichbar sein müssen oder Zugang zum Internet benötigen. Der Loadbalancer steht hier an vorderster Front und nimmt die User-Anfragen entgegen. Das Private Subnet hat dagegen keine direkte Route zum Internet. Das heißt, die Ressourcen können hier nicht direkt von IP-Adressen außerhalb der VPC aufgerufen werden. Die Logik sowie die verarbeitete Rechnungsdaten sind so bestens vor Angriffen geschützt. In der Grafik siehst du in dem Fall zwei Private Subnets. Keine IP von außen kann direkt auf den Multiagent zugreifen (as intended).
Gateways und Balancer
Unser Agent muss mit der Außenwelt reden, darf aber selbst nicht angesprochen werden. Hier kommt das NAT Gateway ins Spiel. Es maskiert private IP-Adressen und verhindert unerwünschte eingehende Verbindungen aus dem Internet. Das Internet Gateway ermöglicht die Kommunikation zwischen VPC und dem Internet im allgemeinen. Der ALB (Application Load Balancer) kümmert sich darum, dass der eingehende HTTP/HTTPS-Traffic (bspw. des Users via Browser) an den Container weiterleitet. Dieser kümmert sich auch um die Lastenverteilung bei hoher Anfrage – Load Balancer halt.
Modelle bauen > Server streicheln: Fargate
Auf was hat der AI Engineer kein Bock? Richtig: Skalierung und Wartung (Patching etc.) des OS, auf das die Docker-Images (Multiagent und weitere) laufen. Deshalb verwenden wir Fargate Nodes, damit sich schön AWS um den Betrieb kümmern darf. Es gäbe noch die Option EC2 Launch Types zu nehmen, um als Server die Container zu deployen. Aber für die Kundenoption haben wir uns für die Serverless-Variante entschieden: weniger Stress für uns und später auch für den Kunden.
Jedes Mal, wenn ein Fargate-Container startet, bekommt er eine ENI (Elastic Network Interface). Diese erlaubt dem Container, innerhalb der VPC zu kommunizieren, IP-Adressen zu erhalten und Security Groups anzuwenden. In den Groups definiert man, welche IPs mit welchem Port Zugriff auf die Services haben. Um das Thema Sicherheit/Foundation abzuschließen: In der Grafik erkennt man rechts ein Target Mount. Target Mounts sind Netzwerk-Endpunkte, über die Ressourcen innerhalb einer VPC auf ein Dateisystem (wie Amazon EFS) zugreifen können. Aber um EFS (Elastic File Storages) und alle weiteren Containerisierungskomponenten, kümmern wir uns im nächsten Blogpost.
