Einheit 7.3: Performance Engineering

Einführung

Die Leistungsfähigkeit in IONOS CLOUD wird bereits im Entwurfsstadium konzipiert, nicht erst nachträglich optimiert. Die Plattform bietet eine kleine Anzahl von Entscheidungen, die die End-to-End-Latenz und den Durchsatz maßgeblich bestimmen: Welches Speicherstadium ein Volume nutzt und wie groß es ist, ob ein Datenbankstadium durch einen Pooler und einen Cache bedient wird und an welcher Stelle jedes Stadium auf dem in Einheit 1.2 definierten mehrstufigen Netzwerkpfad platziert wird. Werden diese Entscheidungen korrekt getroffen, verhält sich die Architektur unter Last vorhersehbar. Werden sie falsch getroffen, lässt sich der verlorene Spielraum durch nachträgliche Optimierungen nicht wiederherstellen.

Diese Einheit fasst die in früheren Modulen getroffenen Entscheidungen in einer einheitlichen Leistungsperspektive zusammen. Sie setzt die Compute-Klassen aus Einheit 4.1, die Block-Speicherstufen aus Einheit 4.2 und 5.1, das Muster ohne Lese-Replikate aus Einheit 5.3, das Cache-Stadium aus Einheit 5.5 sowie die Load Balancer aus Einheit 3.3 und 3.4 voraus. Die regulierte Transaktionsplattform von FinCorp bildet die Grundlage für die durchgerechneten Entscheidungen.

1. Leistungsgrenzen der Speicher und Auswahl der Leistungsklasse

Block Storage in IONOS CLOUD ist ein iSCSI-Blockgerät, das als HDD, SSD Standard und SSD Premium verfügbar ist. Das Auswahlkriterium ist selten die Kapazität, da alle drei Leistungsklassen dasselbe Maximum von 4 TB pro Volume erreichen. Das Kriterium ist das Leistungsprofil, und die beiden SSD-Leistungsklassen verhalten sich sehr unterschiedlich zu HDD.

Die HDD-Leistung ist statisch und unabhängig von der Volumengröße: Jedes HDD-Volumen liefert dieselbe sequenzielle Lese- und Schreibgeschwindigkeit von 200 MB/s bei einer Blockgröße von 1 MB sowie 1.100 IOPS bei 4 KB (mit Bursting auf höhere Werte). Ein 50-GB-HDD-Volumen und ein 2-TB-HDD-Volumen performen identisch. Dies macht HDD vorhersehbar, aber gleichbleibend, und eignet sich für sequenziellen Massen- und Archivzugriff, nicht jedoch für transaktionale Datenbanken.

Die SSD-Leistung ist das Gegenteil: Sie skaliert mit der Volumengröße bis zu einem Höchstwert. Die folgende Tabelle zeigt das dokumentierte SSD-Leistungsprofil der Plattform.

Da der SSD-Durchsatz und die IOPS pro Gigabyte berechnet werden, versagt ein kleines SSD-Volumen bei anspruchsvollen Workloads. Die Plattform empfiehlt, SSD-Volumes mit mindestens 100 GB zu buchen, um den vollen Nutzen der schnellen SSD zu erzielen; kleinere Volumes sind zulässig, performen jedoch suboptimal. Für Datenbank-Workloads ist diese 100-GB-Grenze die tragende Regel: Ein SSD-Volumen unter etwa 100 GB beeinträchtigt eine Datenbank-Ebene, selbst wenn der Datensatz winzig ist. Die vom Data Center Designer für ein Volume vorhergesagte Leistung leitet sich aus seiner Größe ab, und bei SSD wird sie begrenzt, sobald das Volume 600 GB überschreitet, bei den pro-VM-Höchstwerten von 45.000 Lese-IOPS und 600 MB/s sequenzieller Durchsatz für SSD Premium.

Die Auswirkung auf das Design ist direkt. Sie dimensionieren ein Datenbank-SSD-Volumen zuerst nach Leistung und zweitens nach Kapazität. Die Transaktionsdatenbank von FinCorp enthält nur wenige Dutzend Gigabyte an aktiven Daten, aber die Bereitstellung auf einem 40-GB-SSD-Volumen würde unter der Leistungsgrenze liegen und genau die Ebene drosseln, die den regulierten Workload des Unternehmens trägt. Das Volume wird daher unabhängig vom Datenabdruck mit 100 GB oder mehr bereitgestellt, und zwar auf SSD Premium, damit die IOPS-Zuweisung pro GB im Vergleich zu SSD Standard verdoppelt wird. Das Massen-Audit-Archiv ist demgegenüber sequenziell und kostensensibel, daher wird es auf HDD platziert, wo die Größe die Leistung nicht beeinflusst, oder ganz auf Object Storage.

2. Durchsatzhebel: Pooling, Caching und Node-Obergrenzen

Sobald die Speicherung korrekt gestaffelt ist, lautet die nächste Performance-Frage nach der Parallelität. Hier bestimmen die ehrlichen Grenzen der Plattform das Design. Managed PostgreSQL und MariaDB verfügen über keine Lese-Replikate (Einheit 5.3). Sie können Lesezugriffe nicht skalieren, indem Sie Replikat-Endpunkte hinzufügen. Daher sind die Durchsatzhebel das Verbindungspooling und das Caching.

Die Verbindungsobergrenze ist kein Einstellregler. Der Wert von max_connections in PostgreSQL wird aus dem RAM des Clusters berechnet und ist nicht durch den Benutzer konfigurierbar. Er reicht von 384 Verbindungen bei 4 GB RAM bis zu einer harten Obergrenze von 1.000 Verbindungen bei mehr als 8 GB RAM. Dabei sind 11 Verbindungen für interne Superuser- und Replikationszwecke reserviert. Eine Anwendungsschicht, die für jede Anfrage eine neue Verbindung öffnet, erreicht diese Obergrenze lange bevor die CPU ausgelastet ist. Die native Lösung ist der verwaltete pgbouncer-Verbindungspooler: DBaaS poolt standardmäßig nicht, aber Sie können den verwalteten pgbouncer aktivieren und den Transaktionsmodus (Standard, gibt die Verbindung nach jeder Transaktion frei) oder den Sitzungsmodus wählen. Wenn Pooling aktiviert ist, verbinden sich Anwendungen über Port 6432 statt über den nativen Port 5432 der Datenbank. Das Pooling im Transaktionsmodus ermöglicht es einer kleinen Anzahl echter Backend-Verbindungen, eine große Anzahl von Anwendungsclients zu bedienen. Dadurch bleibt eine ausgelastete stateless-Schicht innerhalb der aus dem RAM abgeleiteten Obergrenze.

Caching ist der zweite Hebel und derjenige, der Lese-Replikate ersetzt. Die In-Memory DB-Ebene (Einheit 5.5) fängt leseintensiven Traffic vor der relationalen Datenbank ab und ermöglicht Abrufe in unter Millisekunden, sodass wiederholte Lesezugriffe PostgreSQL gar nicht erst erreichen. Ein einzelner In-Memory DB-Cluster kann deutlich mehr gleichzeitige Verbindungen aufnehmen als die relationale Ebene (die zugrunde liegende Valkey-Engine hat standardmäßig eine Obergrenze von 10.000 Client-Verbindungen). Genau deshalb ist es der Cache und nicht die Datenbank, der die schubweise Leseanfrage bearbeitet. Die Platzierung als Cache-aside oder Write-through (Einheit 5.5) bestimmt die Konsistenz. In beiden Fällen ist der Cache der Durchsatzmultiplikator, der es der Plattform ohne Lese-Replikate ermöglicht, zu skalieren.

Der dritte Hebel ist horizontale Compute-Skalierung. Ein einzelner Node hat eine endliche Obergrenze, unabhängig von Speicherung und Pooling. Daher skalieren stateless-Schichten mit wirklich hohem Durchsatz horizontal hinter einem Load Balancer, anstatt einen einzelnen Server unendlich hochzuskalieren. Hier stoßen auch zwei Realitäten bei Load Balancern auf. Erstens ist ein Kubernetes LoadBalancer Service eine statische IP eines einzelnen Nodes und kein verwalteter, verteilter Balancer (Einheit 6.1). Er ist daher selbst eine Obergrenze auf Node-Ebene, es sei denn, Sie setzen einen separat bereitgestellten Managed Application Load Balancer vor den Cluster. Zweitens verteilen die verwalteten Balancer, beschleunigen aber nicht: Sowohl der Managed Network Load Balancer als auch der Managed Application Load Balancer bieten die Algorithmen Round Robin, Least Connections, Random und Source IP. Die Wahl des Algorithmus steuert, wie gleichmäßig die Last auf gesunde Ziele verteilt wird, nicht aber, wie schnell ein einzelnes Ziel arbeitet. Least Connections glättet ungleiche Anfragekosten; Source IP erhält die Sitzungsaffinität auf Kosten der gleichmäßigen Verteilung. Der Balancer erhöht den Gesamtdurchsatz nur durch das Hinzufügen gesunder Backends. Die Kapazitätsplanung ist daher letztlich eine Backend-Planung.

3. Right-Sizing im Vergleich zu Over-Provisioning

Right-Sizing passt Ressourcen an die beobachtete Nachfrage an und ist der Standardansatz für Kosteneffizienz. Zwei Plattformmechanismen machen es weniger aufwendig, als es klingt. CPU, RAM, NICs und Speicher können auf Dedicated Core Servern live hochskaliert werden (Einheit 4.3), sodass Sie klein anfangen und ohne Neuaufbau wachsen können; nur das Herunterskalieren von CPU und RAM sowie ein RAM-Hotplug über 240 GB erfordern einen Neustart. Und die SSD-Speicherleistung wächst mit dem Datenträger, sodass das Vergrößern eines Datenträgers für mehr Kapazität auch dessen Durchsatz erhöht. Dadurch bleiben Speicher-Right-Sizing und Leistung im Einklang, statt im Widerspruch zu stehen.

Bewusstes Over-Provisioning ist die gerechtfertigte Ausnahme, und Einheit 2.4 hat es als Kontrollkosten statt als Verschwendung gerahmt. Der klarste Fall ist der SSD-Grundwert für Datenbanken aus Abschnitt 1: Sie provisionieren Kapazität über, um Leistung zu kaufen, da beide auf SSD gekoppelt sind. Ein zweiter Fall ist Puffer auf einer Ebene, die während der Spitzenzeiten einen Neustart nicht sauber absorbieren kann, bei dem die Kosten für zusätzliche CPU- und RAM-Reserven günstiger sind als eine durch Herunterskalieren ausgelöste Neustart-Wiederherstellung. Die Disziplin besteht darin, nur dort überzuprovisionieren, wo ein gemessener Leistungsgrundwert oder eine operative Einschränkung es rechtfertigt, und überall else right-sizing anzuwenden.

Die folgende Tabelle fasst zusammen, wo jede Haltung Anwendung findet.

4. Wo Latenz in der geschichteten Architektur gewonnen oder verloren wird

Die geschichtete Struktur aus Einheit 1.2 (öffentlicher Layer-7-Load Balancer, zustandslose Rechenstufe, privater Layer-4-Load Balancer und nur privat zugängliche Datenstufe) ist zugleich eine Latenzkarte. Jeder Hop fügt Rundläufe hinzu, und das Designziel besteht darin, den kritischen Pfad kurz zu halten und langsame Komponenten von diesem Pfad fernzuhalten.

Der öffentliche Managed Application Load Balancer beendet TLS einmalig am Rand und leitet an die zustandslose Stufe weiter, sodass die Hops zu den Backends im privaten LAN im Klartext ablaufen können und wiederholte Handshakes vermieden werden. Die zustandslose Stufe sollte keinen Sitzungszustand halten, sowohl weil Auto Scaling und Load-Balancer-Failover dies erfordern (Einheiten 4.3 und 7.1), als auch weil die Externalisierung des Sitzungszustands auf die In-Memory DB-Stufe eine langsame Datenbanksuche pro Anfrage in einen Cache-Treffer unter einem Millisekunde verwandelt. Der private Layer-4-Load Balancer vor der Datenstufe fügt einen TCP-Pass-Through-Hop hinzu, aber keine TLS-Arbeit. Das langsamste Komponente, die relationale Datenbank, befindet sich am unteren Ende des Pfads und wird sowohl durch den Pooler (der sie innerhalb ihrer Verbindungsobergrenze hält) als auch durch den Cache (der die meisten Lesezugriffe davon fernhält) abgeschirmt. Latenz wird daher gewonnen, indem TLS einmalig beendet, die Anwendungsebene zustandslos und cache-vorgeschaltet gehalten und jede Datenbankverbindung gepoolt wird; sie wird verloren durch Verbindungen pro Anfrage, zu klein dimensionierte SSD unter der Datenbank und Lesezugriffe, die anstelle des Caches auf die relationale Stufe durchfallen.

Ein Hardware-Feintuning ist auf dieser Ebene relevant. Sehr hohe Host-Netzwerkbandbreite auf IONOS CLOUD ist eine Eigenschaft bestimmter dedizierter Hardware, nicht der allgemeinen Block Storage-Infrastruktur. Premium-Host-Netzwerke erscheinen auf dedizierter Hardware wie den VMware Private Cloud-Hosts und der GPU/HPC-AI-Plattform, während NVLink-Klasse-Interconnect spezifisch für die Cloud GPU-Plattform (Compute Engine GPU VMs) ist, deren GPU-Server zwei NVLink-Cluster mit jeweils vier GPUs bereitstellen, die separat adressiert werden. Man sollte nicht von InfiniBand- oder RDMA-Klasse-Leistung für allgemeine Block Storage oder Standard-Compute-LANs ausgehen; diese nutzen das iSCSI-Block-Fabric und das Standard-Netzwerk. Für FinCorp lautet die praktische Interpretation, dass die regulierte Transaktionsebene auf Standard-Compute durch korrekte SSD-Schichtung, Pooling und Caching ausgelegt wird, während ein zukünftiger Low-Latency-HPC- oder KI-Training-Workload ein separates Hardware-Thema auf der dedizierten GPU-Plattform ist und kein Attribut, das die allgemeine Infrastruktur bereitstellt.

Entscheidungszusammenfassung

Zusammenfassung

Performance Engineering auf IONOS CLOUD besteht aus einer Reihe von Designentscheidungen zur Platzierung, nicht aus nachträglicher Optimierung: Speicher nach Leistungsgrenze und Größe dimensionieren, die Datenbank durch Pooling und Caching so gestalten, dass sie innerhalb fester Verbindungsgrenzen und der Grenze ohne Lese-Replikaten arbeitet, zustandslose Ebenen hinter Load Balancern horizontal skalieren, die verteilend statt beschleunigend wirken, und den kritischen Pfad in der geschichteten Architektur kurz halten. Überdimensionierung ist nur dann gerechtfertigt, wenn eine gemessene Leistungsgrenze oder eine operative Einschränkung dies erfordert; überall else ist das Right-Sizing mit live Wachstum sowohl kostengünstiger als auch ausreichend.

Wichtige Punkte:

• Die SSD-Leistung skaliert pro Gigabyte und nimmt unter etwa 100 GB ab, daher werden Datenbankvolumes zunächst nach Leistung dimensioniert; die HDD-Leistung ist konstant und unabhängig von der Volumengröße.
• Es gibt keine Lese-Replikaten; Pooling (verwalteter pgbouncer, Transaktionsmodus, Port 6432) und der In-Memory DB-Cache sind die Hebel für die Lese-Leistung, und die PostgreSQL-Verbindungsgrenze ist RAM-abhängig und beträgt bis zu 1.000.
• Verwaltete Load Balancer verteilen den Traffic auf gesunde Backends, beschleunigen aber kein einzelnes Backend; ein Kubernetes LoadBalancer Service ist eine statische IP auf einem einzelnen Knoten.
• Standardmäßig Right-Sizing und live Wachstum anwenden; bewusst nur bei der SSD-Leistungsgrenze der Datenbank oder auf Spitzen-Ebenen überdimensionieren, die einen Neustart nicht absorbieren können.
• Premium-Host-Netzwerk ist eine Eigenschaft dedizierter Hardware (VMware Private Cloud und GPU/HPC-AI), und NVLink-Klasse-Interconnect ist spezifisch für die Cloud GPU-Plattform (Compute Engine GPU VMs), nicht für die allgemeine Block Storage-Infrastruktur.

Wichtige Begriffe:

• Connection Pooler (pgbouncer): Ein verwalteter Vermittler, der viele Anwendungsclients auf eine kleine Anzahl echter Datenbankverbindungen multiplexiert; wird explizit aktiviert, ist über Port 6432 erreichbar und verwendet standardmäßig den Transaktionsmodus.
• Leistungsgrenze: Die minimale Volumengröße, unterhalb derer SSD-Speicher einen verringerten Durchsatz und IOPS liefert (etwa 100 GB für Datenbank-Workloads).
• Einzelknoten-Grenze: Der endliche Durchsatz eines einzelnen Servers oder eines einzelnen Endpunkts, jenseits dessen das einzige Mittel die horizontale Skalierung über zusätzliche gesunde Backends ist.

Weitere Lektüre

• Einheit 4.2: Images, Disks und Cloud-Init (Block-Speicher-Ebenen und die SSD-Untergrenze im Kontext)
• Einheit 5.3: Relationale Datenbanken (das Muster ohne Lese-Replikate und Replikationsmodi)
• Einheit 5.5: In-Memory-Datenbank (die Cache-Ebene, die die Leseauslastung absorbiert)
• Einheit 1.2: Die kanonische geschichtete Architektur (die Latenzkarte, die diese Einheit nachverfolgt)