Zielarchitektur und Wirtschaftlichkeit

Zielarchitektur und Wirtschaftlichkeit

0:00 Willkommen zu Modul drei. Sie haben jetzt einen Anwendungsfall mit Kriterien und eine Governance-Matrix, die festlegt, welche Daten wohin dürfen. Was noch fehlt, ist das Gebäude, in dem das alles stattfindet. In diesem Modul entwerfen wir die Zielarchitektur von Lotsenhaus. Wir wählen ein Betriebsmodell, ordnen Komponenten in Schichten und Netzwerkzonen, schätzen die Last und rechnen Kosten und Ausfälle durch.

0:24 Dabei geht es weniger um die eine richtige Lösung als um begründete Entscheidungen. Denn eine Architektur, deren Gründe niemand mehr kennt, wird beim ersten Problem einfach umgebaut, und meistens nicht zum Besseren.

Zielarchitektur und Wirtschaftlichkeit

0:37 Der erste Tag endet mit der Architektur, und der Satz auf der Folie gibt den Maßstab vor. Eine gute Architektur trägt den Pilot, ohne den Ausbau zu verbauen. Das klingt nach einem Widerspruch, ist aber eine Frage kluger Weichenstellungen. Manche Entscheidungen lassen sich später leicht ändern, andere praktisch gar nicht.

0:55 Genau die zweite Sorte schauen wir uns heute besonders genau an.

Betriebsmodelle

1:00 Die erste Weichenstellung betrifft den Ort. Wo läuft Lotsenhaus überhaupt? Die Antwort entscheidet sich nicht am Geschmack, sondern an der Vertrauensgrenze, die Sie im letzten Modul gezogen haben. Die Doku beschreibt vier Betriebsmodelle, und die rechte Spalte ist die eigentliche Entscheidungshilfe. On-Premises lohnt sich, wenn Hardware und GPU-Betrieb im Haus schon vorhanden sind. Die Private Cloud passt, wenn eine Cloud-Plattform ohnehin Standard ist.

1:27 Der abgeschottete Betrieb ist für die strengsten Anforderungen gedacht, verlangt aber, dass alles vorab bereitliegt. Und dann gibt es das Hybridmodell, bei dem die Anwendung intern läuft und die Modelle je nach Gruppe intern oder extern sind. Genau das wählt Brandtner, und zwar nicht aus Bequemlichkeit, sondern weil die Datenklassen es verlangen. Das externe Modell bekommt eben nur Daten bis intern.

1:51 Eine Grundentscheidung, die sich durch das ganze Seminar zieht: Oberfläche und Modelle laufen getrennt. Das ist kein Selbstzweck. Die beiden haben einfach völlig verschiedene Bedürfnisse. Die Inferenz will GPU-Speicher, Open WebUI braucht CPU, Arbeitsspeicher und schnellen Speicher. Stellen Sie sich eine Werkstatt vor, in der Empfangstresen und Schwerlastkran am selben Stromkreis hängen.

2:14 Getrennt können Sie beides unabhängig aktualisieren, austauschen und skalieren. Es gibt zwar ein Image, das Ollama gleich mitbringt, und zum Testen ist das bequem. Im Betrieb aber heißt es: Fällt einer aus, fallen beide aus. Dieser Vergleich zeigt, was sich ändert, wenn aus einer Instanz mehrere werden, und es ist mehr, als man denkt.

2:36 Mit einer Instanz genügen SQLite oder PostgreSQL, die eingebaute Vektordatenbank und ein lokales Volume für Dateien. Redis ist optional, aber empfohlen. Sobald mehrere Instanzen laufen, braucht jede denselben Zustand. Dann werden PostgreSQL, eine serverbasierte Vektordatenbank, ein gemeinsamer Dateispeicher und Redis zur Pflicht, und alle Replikate brauchen denselben Secret Key.

2:59 Die untere Zeile zeigt den Preis der Einfachheit. Beim Pilot mit einem Container ist jeder Neustart ein Ausfall. Für Bürozeiten mit einem tragbaren Ausfalltag ist das vertretbar. Hier sitzen gleich mehrere Entscheidungen, die sich später kaum korrigieren lassen. Wer produktiv mit SQLite startet und später auf PostgreSQL umziehen will, steht vor einem Problem. Open WebUI migriert nicht zwischen Datenbanken.

3:25 SQLite auf Netzwerkspeicher ist seit dem asynchronen Backend der Version null Punkt neun ein häufiger Ausfallgrund. Dann das bequeme Image mit eingebautem Ollama, das aus dem Labor in die Produktion rutscht. Und schließlich der abgeschottete Betrieb, geplant ohne Modelle, Embeddings und Images vorab bereitzustellen. Dann steht die Plattform hinter ihrer Firewall und kann nichts.

Architekturkomponenten und Netzwerk

3:48 Jetzt zoomen wir hinein. Aus welchen Bausteinen besteht Lotsenhaus, in welchen Zonen stehen sie, und welche Verbindungen sind erlaubt? Am Ende steht eine Liste, die jede Firewall versteht. Erinnern Sie sich an die fünf Schichten aus dem ersten Modul? Hier werden sie konkret. Ganz oben der Zugang, ein Reverse Proxy mit TLS, WebSockets und langen Timeouts, denn Antworten von Sprachmodellen tröpfeln oft lange.

4:15 Darunter die Identität, im Labor Keycloak, produktiv später Microsoft Entra ID. Dann Open WebUI als Anwendung. Darunter der Zustand mit lh-db, lh-redis, Vektordatenbank und Dateispeicher. Und ganz unten die Inferenz, lokal auf inferenz-01 und extern über einen OpenAI-kompatiblen Endpunkt. Der Wert dieser Schichtung liegt darin, dass jede Schicht für sich austauschbar bleibt. Der Wechsel des Identitätsanbieters berührt die Inferenz nicht.

4:44 Diese Tabelle ordnet jeder Komponente ihre Aufgabe zu und zeigt, wie Lotsenhaus sie besetzt. Einige Einträge verdienen einen zweiten Blick. Open WebUI terminiert TLS nicht selbst, deshalb ist der Proxy keine Kür, sondern Pflicht. Die Vektordatenbank ist im Pilot die eingebaute, später pgvector in derselben Datenbank lh-db.

5:05 Die Extraktion von PDFs und Office-Dateien läuft als eigener Dienst, bei Brandtner mit Apache Tika. Und die Fußzeile räumt ein verbreitetes Missverständnis aus. Die Konfiguration teilen sich mehrere Instanzen über PostgreSQL, nicht über Redis. Redis koordiniert, die Datenbank merkt sich. Hier wird die Governance-Matrix zur Firewall-Regel. Lesen Sie die Tabelle als vollständige Liste. Was nicht drinsteht, ist verboten.

5:33 Die Arbeitsplätze erreichen nur den Proxy auf Port vier-vier-drei. Der Proxy erreicht Open WebUI, und nur aus der Anwendungszone. Open WebUI spricht mit den Zustandsdiensten, mit inferenz-01, mit Keycloak und später mit den Störmelder-Werkzeugen. Der externe Modellendpunkt ist nur über eine Allowlist erreichbar. Und die Fußzeile warnt vor einer falschen Sicherheit.

5:56 Der Offline-Modus verhindert nur eigene Downloads und Versionsprüfungen. Konfigurierte Dienste sperrt er nicht. Das bleibt Aufgabe der Firewall. Bevor installiert wird, braucht es Vorarbeit im Netz, und die Reihenfolge hat Gründe. Zuerst die DNS-Namen für Produktion und Test, dann die Zertifikate für den Proxy, öffentlich oder aus der internen CA.

6:18 Kommt die interne CA zum Einsatz, hinterlegen Sie deren Zertifikat in Open WebUI, statt die Prüfung einfach abzuschalten. Das ist der Moment, in dem viele aus Frust den falschen Schalter umlegen. Danach geben Sie die ausgehenden Ziele aus der Governance-Matrix per Allowlist frei. Und die öffentliche HTTPS-Adresse muss feststehen, bevor SSO eingerichtet wird, denn die Anmeldung baut darauf auf.

Kapazität planen

6:42 Wie groß muss das alles sein? Eine überraschend häufige Fehleinschätzung lautet: so groß wie die Zahl der Nutzer. Tatsächlich entsteht die Last aber beim Modell, nicht bei der Anmeldung. Vier Dinge treiben die Last, und keins davon ist die Zahl der angemeldeten Personen. Erstens die gleichzeitigen Antworten, denn jede belegt den Modellserver, bis das letzte Token gestreamt ist.

7:05 Zweitens die Dokumentverarbeitung, die beim Hochladen in Spitzen auftritt, etwa wenn jemand morgens zwanzig Berichte in eine Wissensbasis wirft. Drittens Werkzeugaufrufe, weil jede Runde ein weiterer Modellaufruf mit wachsendem Kontext ist. Und viertens die Kontextlänge, die GPU-Speicher frisst und die Antwortzeit verlängert. Das ist wie in einer Kantine.

7:26 Entscheidend ist nicht, wie viele Leute einen Ausweis haben, sondern wie viele gleichzeitig an der Ausgabe stehen. Diese Tabelle zeigt, wo jeder Baustein zuerst an seine Grenze stößt. Bei Open WebUI ist es der Arbeitsspeicher, denn die eingebauten Embedding-Modelle belegen rund fünfhundert Megabyte je Worker. Bei der Extraktion verliert der Standard Speicher, ein eigener Dienst wie Tika oder Docling kapselt das. Beim Modellserver zählen GPU-Speicher und Kontextlänge.

7:54 PostgreSQL begrenzt die Verbindungen, und hier multipliziert sich der Pool mit der Zahl der Instanzen. Der Thread-Pool hat ab Werk eine niedrige Grenze, die bei Skalierung angehoben werden muss. Die Fußzeile zeigt, wie Ollama die Kontextlänge abhängig vom Grafikspeicher selbst wählt. Hier stehen die Zahlen, mit denen Lotsenhaus plant, und die rechte Spalte sagt ehrlich, woher sie stammen.

8:18 Manche sind Anforderungen aus dem ersten Modul, etwa sechzig Nutzer, fünfzehn gleichzeitig aktiv, erstes Token unter drei Sekunden. Andere sind Annahmen, die im Pilot gemessen werden müssen. Die wichtigste davon: Von fünfzehn aktiven Personen generieren nur drei bis fünf gleichzeitig, weil Lesen länger dauert als Generieren. Diese Unterscheidung spart viel Geld.

8:40 Die Fußzeile fasst es zusammen. Die Zahl gleichzeitiger Generierungen bestimmt die GPU, nicht die Zahl der Nutzer. Wer nach Köpfen dimensioniert, kauft zu groß ein. Diese Folie erklärt, warum der Pilot-Aufbau nicht einfach mitwächst. SQLite verträgt kein paralleles Schreiben mehrerer Prozesse. Dann folgen Sperrfehler und im schlimmsten Fall beschädigte Daten.

9:03 Die eingebaute ChromaDB nutzt intern ebenfalls SQLite und ist nicht fork-sicher, Worker sterben dann ausgerechnet beim Upload. Besonders tückisch sind Replikate, die sich über ein gemeinsames Volume verbinden. Der Fehler zeigt sich nicht im Test, sondern erst unter Last. Und eine Kleinigkeit mit großer Wirkung: Wer die Kontextlänge in Open WebUI aktiviert, übersieht leicht den vorbelegten, sehr kleinen Wert, der die Einstellung des Servers überstimmt.

Kosten und Verfügbarkeit

9:31 Bleiben zwei Fragen, die jede Geschäftsführung stellt. Was kostet der Betrieb? Und was kostet es, wenn er ausfällt? Beides lässt sich vorher erstaunlich gut abschätzen. Die Kostenblöcke dieser Tabelle zeigen, dass Hardware nur ein Teil der Rechnung ist. Infrastruktur ist sichtbar: Server, GPU, Speicher, Backups. Modellnutzung hängt am Tokenverbrauch je Vorgang, multipliziert mit der Zahl der Vorgänge. Integrationen wie die Störmelder-Werkzeuge kosten Entwicklung und Pflege.

10:01 Administration bindet einen Teil einer Stelle, und Support kostet entweder Zeit in der Community oder Geld für die Enterprise-Lizenz. Die Fußzeile ist für die Abrechnung wichtig. Gezählt werden die Token aller Werkzeugrunden einer Antwort, nicht nur der letzten. Eine Antwort mit drei Werkzeugaufrufen kostet also deutlich mehr, als sie aussieht.

10:23 Zwei Kennzahlen machen Verfügbarkeit greifbar. RTO sagt, wie lange ein Ausfall dauern darf, RPO, wie viel Datenverlust tragbar ist. Spannend wird die Tabelle, wenn Sie die Gegenmaßnahmen lesen. Fällt inferenz-01 aus, gibt es ein Banner und das externe Modell als Notlösung, aber eben nur bis intern. Stürzt der Container ab, startet ihn die Restart-Policy neu. Ist die Datenbank beschädigt, hilft das nächtliche Backup, mit maximal einem Tag Datenverlust.

10:50 Und bei einem gescheiterten Update mit Migration brauchen Sie das Backup von vorher, denn die alte Version läuft nur mit dem alten Datenstand. Diese Tabelle ist eine Art Größentabelle wie beim Schuhkauf. Zur Evaluation genügt ein einzelner Container mit SQLite. Für ein kleines Team unter fünfzig Personen empfiehlt sich schon ein Container hinter einem Proxy, mit PostgreSQL, Redis und externer Extraktion.

11:16 Bei mehreren Workern oder Instanzen werden Replikate und eine externe Vektordatenbank Pflicht. Und ab tausend Nutzern kommt Orchestrierung ins Spiel, etwa Kubernetes mit Helm. Der Pilot von Lotsenhaus liegt bewusst in der zweiten Zeile, mit lh-db und lh-redis von Anfang an. Damit braucht der spätere Ausbau vor allem Replikate, aber keinen Umbau der Datenhaltung.

11:38 Der erste Stolperstein ist eine unvollständige Rechnung. Wer nur Infrastruktur kalkuliert, vergisst Administration, Freigaben und Support, also die Kosten, die jeden Monat wiederkommen. Der zweite betrifft Updates. Rollierende Updates, bei denen eine Instanz nach der anderen wechselt, klingen elegant, funktionieren aber nicht, wenn sich das Datenbankschema ändert.

12:00 Dann müssen alle gleichzeitig wechseln. Drittens ein RPO zuzusagen, ohne die Wiederherstellung je geübt zu haben, ist ein Versprechen ohne Deckung. Und viertens: Wer die Vektordatenbank später wechselt, muss die Wissensbasen migrieren oder neu indizieren. Das sollte im Plan stehen, nicht im Notfall auffallen.

Übung

12:20 Jetzt entwerfen Sie selbst. Sie haben Steckbrief und Governance-Matrix, nun entsteht daraus eine Zielarchitektur, deren Entscheidungen sich begründen lassen. Ihre Aufgabe ist der Architekturentwurf für Lotsenhaus. Die geübte Fähigkeit ist dabei nicht das Zeichnen von Kästchen, sondern das Ableiten: aus Anforderungen, Datenklassen und Lastannahmen eine Architektur entwickeln und jede Entscheidung gegen ihre Alternative abwägen.

12:45 Gelungen ist der Entwurf, wenn er Komponenten, Zonen und Datenflüsse zeigt, fünf Ressourcenannahmen nennt und vier Entscheidungen samt verworfener Alternative begründet. Gerade die verworfene Alternative ist wertvoll. Sie beantwortet in einem halben Jahr die Frage, warum man es eigentlich nicht anders gemacht hat. Nutzen Sie dafür alles, was Sie in den ersten beiden Modulen erarbeitet haben.

13:07 Fünf Entscheidungen muss Ihr Entwurf treffen, und zu jeder liefert die Doku einen Hinweis, der die Wahl erleichtert. Bei der Datenbank zählt, dass es keinen eingebauten Umzug gibt, die Wahl ist also endgültiger, als sie aussieht. pgvector nutzt die PostgreSQL, die ohnehin da ist. Das schlanke Image spart Platz, braucht aber externe Embeddings und Extraktion. Ab zwei Instanzen kommen Redis, gemeinsamer Speicher und ein gemeinsamer Secret Key dazu.

13:35 Und ein Gateway vor dem externen Modell bündelt Budgets und Routing. Die Fußzeile ist ein Hinweis für die Langfristigkeit: Nur zwei Vektordatenbanken pflegt das Kernteam selbst. Gehen Sie von außen nach innen vor. Skizzieren Sie zuerst die Schichten und Zonen, dann zeichnen Sie die Datenflüsse aus der Governance-Matrix ein, mit dem externen Weg nur bis intern.

13:58 Danach halten Sie die Ressourcenannahmen für Pilot und Ausbau fest. Jede Entscheidung bekommt eine kurze, feste Form: Kontext, Entscheidung, verworfene Alternative und Folge. So entsteht nebenbei ein kleines Entscheidungsprotokoll. Zum Schluss tragen Sie RTO, RPO und Kostenblöcke ein. Und dann wird es praktisch. Im nächsten Modul dient dieser Entwurf als Vorlage für die Installation im Labor, und dort zeigt sich, ob er trägt.