architektur eines serverlosen, ki-gesteuerten multi-domain-cms auf google cloud

der grundlegende konflikt, dem ich gegenüberstand, war die natur der inhaltsgenerierung im vergleich zum inhaltsverbrauch. die ki-gesteuerte artikelgenerierung umfasst eine komplexe abfolge von operationen: echtzeit-webrecherche, entwurfserstellung mit großen sprachmodellen, bilderstellung mit diffusionsmodellen und mehrsprachige übersetzung. dieser gesamte prozess ist von natur aus i/o-gebunden und cpu-intensiv und dauert oft mehrere minuten. mein design musste dieses „schwere heben“ vollständig von der endbenutzererfahrung trennen. leser erwarten, dass statische webseiten in einstelligen millisekunden geladen werden, die von einem nahegelegenen edge-standort bereitgestellt werden.

dies führte mich zur implementierung eines hybriden modells: dynamische generierung für autoren und redakteure und statische, am edge zwischengespeicherte bereitstellung für leser. die ki-pipeline ist asynchron und entkoppelt und schiebt fertiggestellte inhalte an eine schnelle bereitstellungsschicht. dies stellt sicher, dass die rechenintensive ki-arbeit niemals die benutzerorientierte latenz beeinträchtigt.

meine wahl für die compute-schicht war google cloud run. ich fand es eine leistungsstarke, vollständig verwaltete serverlose plattform, die es mir ermöglichte, containerisierte anwendungen bereitzustellen, die automatisch von null auf tausende von instanzen skalieren. das bedeutete, dass ich nur für die genutzte rechenleistung bezahlte, was perfekt zu unseren finops-zielen passte. für mich liegt die schönheit von cloud run in seiner einfachheit, microservices bereitzustellen, ohne die zugrunde liegende infrastruktur verwalten zu müssen.

das cms selbst läuft als mehrere eigenständige cloud run-dienste, von denen jeder einen bestimmten teil des systems verwaltet:

• backend (backend-svc-prod): ein fastapi rest api-dienst, der die kern-content-pipelines verarbeitet, webhooks aufnimmt und die asynchrone aufgabenausführung verwaltet. hier befindet sich die ki-orchestrierungslogik.
• frontend (frontend-admin-svc-prod): eine nicegui-basierte verwaltungsoberfläche. dies ermöglicht meinem team, die ki-inhaltsgenerierung zu überwachen, zu überprüfen und manuell auszulösen, was uns eine feingranulare kontrolle über den redaktionellen prozess gibt.
• dokumentationsserver (mcp-docs-svc-prod): ein model context protocol (mcp)-server. ich habe diesen erstellt, um die kontextabfrage für das backend bereitzustellen, im wesentlichen als retrieval augmented generation (rag)-dienst für unsere ki-modelle, der ihnen aktuelle, relevante marktinformationen zuführt.

durch die verpackung dieser komponenten als containerisierte microservices aus einem einzigen docker-image habe ich die konsistenz über umgebungen hinweg sichergestellt und unsere bereitstellungs-workflows erheblich vereinfacht.

die größte technische herausforderung, der ich begegnete, war die verwaltung von ausführungs-timeouts. eine vollständige artikelgenerierungspipeline kann die typische synchrone anfrage-timeout eines webdienstes (z. b. cloud run hat ein maximales anfrage-timeout von 900 sekunden) leicht überschreiten. um dies zu umgehen, implementierte ich eine asynchrone, ereignisgesteuerte pipeline mithilfe von cloud scheduler und google cloud pub/sub.

dieses muster ermöglichte es mir, die arbeitslast in einen schnellen, synchronen trigger und eine entkoppelte, asynchrone verarbeitungsphase aufzuteilen. cloud scheduler fungiert als zeitgesteuerter trigger, der in vordefinierten intervallen eine authentifizierte anfrage an unser backend sendet. das backend initiiert schnell den content-erstellungsprozess, speichert seinen zustand und veröffentlicht dann eine nachricht an ein pub/sub-thema. dies ermöglicht es der ursprünglichen anfrage, schnell abgeschlossen zu werden, wodurch das frontend oder der scheduler entlastet wird.

pub/sub liefert diese nachricht dann zuverlässig an eine andere instanz unseres backend-dienstes (konfiguriert als push-abonnement), die die langwierigen aufgaben wie das abrufen von recherchedaten, das generieren von bildern und das übersetzen von inhalten übernimmt. dies löst nicht nur das timeout-problem, sondern bietet auch eine resiliente und skalierbare möglichkeit, unsere content-generierungsaufgaben zu verarbeiten.

für die öffentliche inhaltsbereitstellung werden die statischen html-, css- und bilddateien, die durch die ki-pipeline generiert werden, direkt in google cloud storage (gcs)-buckets geschrieben. ich habe einen global external application load balancer konfiguriert, um den öffentlichen traffic (/*) direkt an dieses gcs-backend weiterzuleiten. entscheidend ist, dass cloud cdn diesen inhalt global zwischenspeichert, wodurch eine latenz im einstelligen millisekundenbereich für endbenutzer gewährleistet wird, unabhängig von ihrem geografischen standort. dieses design entkoppelt die dynamische ki-verarbeitung vollständig von der inhaltsbereitstellung und erfüllt somit effektiv unsere anforderung an geringe latenz.

für den administrativen zugriff auf das cms habe ich ein zero-trust-modell mit identity-aware proxy (iap) implementiert. administrative endpunkte (z. b. admin.thecloudarchitect.io) teilen sich denselben load balancer, leiten den traffic jedoch an die cloud run serverless network endpoint groups (negs) weiter. bevor eine anfrage den cloud run-dienst erreicht, fängt iap sie ab, erzwingt die google-konto-authentifizierung und granulare iam-richtlinien. dies bietet eine robuste sicherheitsperimeter, die die angriffsfläche erheblich reduziert. um sensible zugangsdaten, wie api-schlüssel für gemini oder tavily, zu schützen, speichere ich sie sicher im secret manager und injiziere sie zur laufzeit in die cloud run-dienste, wodurch unsere sicherheitsposition weiter verbessert wird.

architektonische übersicht

ich habe das cms so aufgebaut, dass es ki nicht nur als einfachen api-aufruf, sondern als komplexen, mehrstufigen workflow behandelt, der komplett innerhalb des cloudrunbackend-dienstes orchestriert wird. dies ermöglichte es mir, die komplexe artikelgenerierung in überschaubare, beobachtbare schritte zu unterteilen:

1. datenaufnahme & fundierung: zunächst injiziere ich relevante marktdaten (z. b. top-gewinner/-verlierer, ochlv-daten) in das kontextfenster der eingabeaufforderung. diese daten stammen typischerweise von unserer internen ta-api oder einem speziellen marktdatendienst und liefern dem ki-modell aktuelle, präzise informationen, mit denen es arbeiten kann.
2. recherche (tavily): je nach artikeltyp habe ich das system so konfiguriert, dass es 1 bis 10 tavily api-aufrufe durchführt. bei einem „sector spotlight“ hilft dies beispielsweise, echtzeit-katalysatoren, übernachtnachrichten oder spezifische unternehmensmeldungen abzurufen, um sicherzustellen, dass die ki-modelle über die aktuellsten externen informationen verfügen.
3. verfasser (gemini 2.5 flash): ich verwende eine anfängliche prompt-vorlage (typischerweise jinja2-basiert), um gemini 2.5 flash anzuweisen, die rohe json-nutzlast des artikels zu verfassen. gemini 2.5 flash bietet ein hervorragendes gleichgewicht zwischen leistung und kosteneffizienz, was es ideal für die schnelle und kostengünstige generierung erster entwürfe macht.
4. redakteur (gemini 2.5 pro): sobald der entwurf fertig ist, überprüft ein stärkeres, leistungsfähigeres modell, gemini 2.5 pro, ihn. dieser kritische schritt prüft ton, genauigkeit, faktische konsistenz und die richtige formatierung. dieser multi-modell-ansatz ermöglicht es mir, die spezifischen stärken jedes modells zu nutzen und gleichzeitig die gesamtkosten zu optimieren.
5. visuelles (imagen 3): während des entwurfsprozesses generiert gemini 2.5 flash auch eigenständige, beschreibende prompts für visuelle elemente – typischerweise ein 16:9-hero-bild und ein 1:1-unterstützungsbild. diese prompts werden dann an imagen 3, googles fortschrittliches text-zu-bild-diffusionsmodell, weitergegeben, um hochwertige visuals für den artikel zu generieren.
6. übersetzung: schließlich wird der englische text an gemini (entweder flash oder pro, je nach erforderlichem qualität-kosten-kompromiss für die übersetzung) zur lokalisierung in zielsprachen wie deutsch (de), spanisch (es), französisch (fr), italienisch (it) und niederländisch (nl) zurückgegeben. diese übersetzten versionen sind ebenfalls teil des statischen inhalts, der über cloud cdn bereitgestellt wird.

der betrieb großer sprachmodelle und globaler cloud-infrastrukturen kann schnell kostspielig werden, wenn er nicht sorgfältig verwaltet wird. meine architektur verwendet strenge finops-kontrollen, um die effizienz aufrechtzuerhalten und sicherzustellen, dass wir den maximalen wert für unsere ausgaben erhalten.

6.1. stückkosten eines ki-artikels

durch sorgfältige auswahl der modelle und optimierung der api-aufrufe konnte ich die kosten pro artikel außergewöhnlich niedrig halten. die verwendung von gemini 2.5 flash für die massenentwurfserstellung und das prompt-engineering sowie die reservierung von gemini 2.5 pro nur für den kritischen redaktionellen durchgang wirken sich erheblich auf die gesamtkosten aus. hier ist eine aufschlüsselung basierend auf den aktuellen preisen (ungefähr 1 $ ≈ 0,92 €):

• tavily (recherche): typischerweise ~0,02 € – 0,07 € (~0,02 $ – 0,08 $) pro artikel, abhängig von der anzahl der suchanfragen.
• gemini (autor/redakteur/prompts/übersetzungen): ca. ~0,05 € (~0,055 $) für alle gemini-interaktionen.
• imagen (2 bilder): die generierung von zwei hochauflösenden bildern kostet ~0,05 € – 0,07 € (~0,06 $ – 0,08 $).
• gesamtkosten pro vollständig veröffentlichtem, mehrsprachigem artikel: ~0,13 € – 0,15 € (~0,14 $ – 0,16 $).

dies zeigt die leistungsfähigkeit einer fein abgestimmten ki-pipeline, um eine bemerkenswerte kosteneffizienz zu erzielen.

6.2. scale-to-zero und kaltstart-mitigation

die fähigkeit von cloud run, im leerlauf auf null instanzen zu skalieren, ist ein enormer finops-gewinn, da die computekosten außerhalb der spitzenzeiten erheblich gesenkt werden. dies birgt jedoch das potenzial für kaltstarts (typischerweise 5-15 sekunden latenz) für benutzerorientierte dienste, insbesondere unser admin-frontend oder intraday-api-trigger. um dies zu mindern, ohne kontinuierliche kosten durch ständig aktive instanzen zu verursachen, habe ich einen dedizierten cloud scheduler „keep-warm“-job eingesetzt.

dieser job pingt sowohl das backend (/health?deep=true) als auch das frontend (/health) alle 14 minuten an, und zwar streng während der europäischen geschäftszeiten (06:00 – 22:00 cet). dies stellt sicher, dass während unserer betriebszeiten kritische dienste warm und reaktionsschnell sind, während sie nachts und an wochenenden weiterhin auf null skalieren können, wodurch die kosteneinsparungen maximiert werden.