Einheit 7.3: Leistungsengineering

Einführung

Die Leistung auf IONOS Cloud wird bereits bei der Auslegung konzipiert und nicht erst nachträglich optimiert. Die Plattform bietet eine kleine Anzahl von Entscheidungen, die die gesamte Latenz und Durchsatzrate bestimmen: auf welcher Speicherebene ein Volume sitzt und wie groß es ist, ob eine Datenbank-Ebene von einem Pooler und einem Cache vorgerendert wird und wo jede Ebene auf dem schichtweise aufgebauten Netzwerkpfad landet, den Sie in Einheit 1.2 eingerichtet haben. Wenn Sie diese Entscheidungen richtig treffen, funktioniert die Architektur unter Last vorhersehbar; wenn Sie sie falsch treffen, kann keine spätere Optimierung den verlorenen Spielraum wiederherstellen.

Diese Einheit kombiniert Entscheidungen, die in früheren Modulen getroffen wurden, zu einem einzigen Leistungsüberblick. Sie geht von den Rechenklassen aus Einheit 4.1, den Block Storage-Ebenen aus den Einheiten 4.2 und 5.1, dem no-read-replica-Muster aus Einheit 5.3, der Cache-Ebene aus Einheit 5.5 und den Lastbalancern aus den Einheiten 3.3 und 3.4 aus. Die regulierte Transaktionsplattform von FinCorp dient als Grundlage für die getroffenen Entscheidungen.

1. Speicherleistungsböden und Auswahl der Ebene

Block Storage auf IONOS 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 Ebenen das gleiche Maximum von 4 TB pro Volume erreichen. Das Kriterium ist das Leistungsprofil, und die beiden SSD-Ebenen verhalten sich sehr unterschiedlich von HDD.

Die Leistung von HDD ist statisch und unabhängig von der Größe des Volume: Jedes HDD-Volume liefert die gleiche sequenzielle Lese-/Schreibgeschwindigkeit von 200 MB/s bei einer Blockgröße von 1 MB und 1.100 IOPS bei 4 KB (mit höheren Spitzenwerten). Ein 50-GB-HDD-Volume und ein 2-TB-HDD-Volume haben die gleiche Leistung. Dies macht HDD vorhersehbar, aber flach, und eignet sich für sequenziellen Bulk- und Archivzugriff rather als für transaktionale Datenbanken.

Die Leistung von SSD ist das Gegenteil: Sie skaliert mit der Größe des Volume bis zu einem Maximum. Die folgende Tabelle zeigt das dokumentierte Leistungsprofil von SSD der Plattform.

Da die Durchsatzrate und die IOPS-Anzahl pro Gigabyte anfallen, wird ein kleiner SSD-Volume ein anspruchsvolles Workload behindern. Die Plattform empfiehlt, SSD-Volumen von mindestens 100 GB zu buchen, um den vollen Nutzen der Hochgeschwindigkeits-SSD zu erzielen; kleinere Volumen sind erlaubt, aber sie haben eine suboptimale Leistung. Für Datenbank-Workloads ist diese 100-GB-Grenze die tragende Regel: Ein SSD-Volume unter etwa 100 GB wird eine Datenbank-Ebene beeinträchtigen, auch wenn die Datenmenge winzig ist. Die Leistung, die das Data Center Designer für ein Volume vorhersagt, wird aus seiner Größe abgeleitet, und für SSD ist sie einmalig, wenn das Volume 600 GB überschreitet, bei den pro-VM-Obergrenzen von 45.000 Lese-IOPS und 600 MB/s sequenzieller Durchsatzrate für SSD-Premium.

Die Konsequenz für das Design ist direkt. Sie dimensionieren ein Datenbank-SSD-Volume zuerst nach der Leistung und zweitens nach der Kapazität. Die Transaktionsdatenbank von FinCorp enthält nur einige Zehner Gigabyte an Live-Daten, aber die Bereitstellung auf einem 40-GB-SSD-Volume würde unter der Leistungsgrenze liegen und die Ebene behindern, die das regulierte Workload des Unternehmens trägt. Das Volume wird daher auf oder über 100 GB dimensioniert, unabhängig von der Datenmenge, und auf SSD-Premium, damit die pro-GB-IOPS-Zuweisung im Vergleich zu SSD-Standard verdoppelt wird. Das Bulk-Audit-Archiv hingegen ist sequenziell und kostensensibel, daher landet es auf HDD, wo die Größe die Leistung nicht beeinflusst, oder auf Object Storage ganz.

2. Durchsatzhebel: Pooling, Caching und Node-Obergrenzen

Sobald der Speicher korrekt gestuft ist, ist die nächste Leistungsfrage die Konkurrenz, und hier formen die ehrlichen Grenzen der Plattform das Design. Managed PostgreSQL und MariaDB haben keine Lese-Replikate (Einheit 5.3). Sie können die Lesevorgänge nicht durch Hinzufügen von Replikat-Endpunkten skalieren, sodass die Durchsatzhebel Connection-Pooling und Caching sind.

Die Verbindungsobergrenze ist kein Einstellknopf. PostgreSQL's max_connections wird aus Cluster RAM berechnet und ist nicht benutzerkonfigurierbar, reicht von 384 Verbindungen bei 4 GB RAM bis hin zu einer harten Obergrenze von 1.000 Verbindungen über 8 GB, wobei 11 Verbindungen für interne Superuser- und Replikationszwecke reserviert sind. Eine Anwendungsebene, die pro Anfrage eine neue Verbindung öffnet, wird diese Obergrenze lange vor dem Erreichen von CPU ausgeschöpft. Die native Antwort ist der gemanagte pgbouncer-Connection-Pooler: DBaaS poolt standardmäßig nicht, aber Sie können den gemanagten pgbouncer aktivieren und den Transaktionsmodus (Standard, der die Verbindung nach jeder Transaktion freigibt) oder den Sitzungsmodus wählen. Wenn Pooling aktiviert ist, verbinden sich Anwendungen auf Port 6432 anstelle des nativen Ports 5432 der Datenbank. Transaktionsmodus-Pooling ermöglicht es, dass eine kleine Anzahl von echten Hintergrundverbindungen eine große Anzahl von Anwendungsklienten bedient, was dazu beiträgt, dass eine beschäftigte Zustandslose-Ebene innerhalb der RAM-abgeleiteten Obergrenze bleibt.

Caching ist der zweite Hebel und der, der die Lese-Replikate ersetzt. Die In-Memory DB-Ebene (Einheit 5.5) absorbiert leseschwere Datenverkehr vor der relationalen Datenbank mit submillisekundiger Abrufzeit, sodass wiederholte Lesevorgänge die PostgreSQL überhaupt nicht erreichen. Ein einzelnes In-Memory DB Cluster kann weit mehr gleichzeitige Verbindungen absorbieren als die relationale Ebene (der zugrunde liegende Valkey-Motor standardmäßig mit einer Obergrenze von 10.000 Client-Verbindungen), was genau der Grund ist, warum der Cache und nicht die Datenbank die Ebene ist, die dem bursty Lese-Pfad gegenübersteht. Cache-aside- oder Write-through-Platzierung (Einheit 5.5) bestimmt die Konsistenz; auf jeden Fall ist der Cache der Durchsatzmultiplikator, der die Plattform ohne Lese-Replikate skalieren lässt.

Der dritte Hebel ist die horizontale Rechenleistung. Ein einzelnes Node hat eine endliche Obergrenze, unabhängig von Speicher und Pooling, sodass wirklich hochleistungsfähige Zustandslose-Ebenen hinter einem Load Balancer skaliert werden, anstatt einen einzelnen Server unendlich zu skalieren. Hierbei kommen zwei Lastverteilungsrealitäten zum Tragen. Erstens ist ein Kubernetes-Lastverteilungsdienst ein einzelnes Node-statisches IP und kein gemanagter verteilter Lastverteilungsdienst (Einheit 6.1), sodass es selbst eine einzelne Node-Obergrenze ist, es sei denn, Sie platzieren ein separates Managed Application Load Balancer vor dem Cluster. Zweitens verteilen die gemanagten Lastverteilungsdienste, aber beschleunigen sie nicht: sowohl Managed Network Load Balancer als auch Managed Application Load Balancer bieten Round-Robin-, Least-Connections-, Random- und Source-IP-Algorithmen, und die Algorithmuswahl bestimmt, wie gleichmäßig die Last auf gesunde Ziele verteilt wird, und nicht, wie schnell ein einzelnes Ziel läuft. Least Connections glättet ungleichmäßige Anfragekosten; Source IP bewahrt die Sitzungsaffinität auf Kosten einer gleichmäßigen Verteilung. Die Lastverteilung erhöht die Gesamtdurchsatzleistung nur durch Hinzufügen von gesunden Hintergrundsystemen, sodass die Kapazitätsplanung letztendlich die Hintergrundplanung ist.

3. Rechtzeitiges Anpassen versus Überdimensionierung

Rechtzeitiges Anpassen entspricht die Ressourcen dem beobachteten Bedarf und ist der Standard für Kosteneffizienz. Zwei Plattformmechaniken machen es weniger schmerzhaft, als es klingt. CPU, RAM, Netzwerk-Schnittstellen und Speicher können auf Dedicated Core-Servern (Einheit 4.3) live skaliert werden, sodass Sie klein beginnen und wachsen können, ohne neu aufzubauen; nur CPU und RAM können herunterskaliert werden und ein RAM-Hotplug über 240 GB erfordert einen Neustart. Und die Speicherleistung von SSD wächst mit dem Volume, sodass das Wachsen eines Volume für die Kapazität auch seine Durchsatzleistung erhöht, was das Rechtzeitige Anpassen von Speicher und Leistung im Einklang hält, anstatt sie in Spannung zu bringen.

Bewusste Überdimensionierung ist die gerechtfertigte Ausnahme, und Einheit 2.4 hat sie als Kontrollkosten und nicht als Verschwendung dargestellt. Der klarste Fall ist die Datenbank-SSD-Basis aus Abschnitt 1: Sie überdimensionieren die Kapazität, um Leistung zu kaufen, da die beiden auf SSD gekoppelt sind. Ein zweiter Fall ist die Reserve auf einer Ebene, die keinen Neustart während der Spitzenstunden elegant absorbieren kann, wo der Aufwand für die Mitnahme von Ersatz-CPU und RAM günstiger ist als eine restart-induzierende Downsizing-Erholung. Die Disziplin besteht darin, nur dort zu überdimensionieren, wo ein gemessener Leistungs-Boden oder eine betriebliche Einschränkung es rechtfertigt, und überall sonst rechtzeitig anzupassen.

Die folgende Tabelle fasst zusammen, wo jede Haltung anwendbar ist.

4. Wo die Latenz im geschichteten Architektur-Design gewonnen oder verloren geht

Die geschichtete Form aus Einheit 1.2 (öffentlicher Layer-7-Lastenausgleich zu stateless-Rechenzentrum zu privatem Layer-4-Lastenausgleich zu privatem Daten-Tier) ist auch eine Latenzkarte. Jeder Hop addiert Rundreisen, und das Designziel ist es, den heißen Pfad kurz zu halten und die langsamen Komponenten davon fernzuhalten.

Der öffentliche Managed Application Load Balancer beendet TLS einmal am Rand und leitet es an die stateless-Ebene weiter, sodass die Back-end-Hops im Klartext auf dem privaten LAN laufen und wiederholte Handshakes vermeiden können. Die stateless-Ebene sollte keinen Sitzungsstatus enthalten, sowohl weil Auto-Scaling und Lastenausgleich-Failover dies erfordern (Einheiten 4.3 und 7.1), als auch weil die Externalisierung des Sitzungsstatus in die In-Memory DB-Ebene eine langsame pro-Anfrage-Datenbankabfrage in einen sub-Millisekunden-Cache-Treffer verwandelt. Der private Layer-4-Lastenausgleich vor dem Daten-Tier addiert einen TCP-Pass-through-Hop, aber keine TLS-Arbeit. Die langsamste Komponente, die relationale Datenbank, sitzt am unteren Ende des Pfades und wird durch den Pooler (der es innerhalb seines Verbindungslimits hält) und den Cache (der die meisten Lesevorgänge davon abhält, es überhaupt zu erreichen) geschützt. Die Latenz wird daher durch die Beendigung von TLS einmal, die stateless-Anwendungsebene und den Cache gewonnen; sie geht durch pro-Anfrage-Verbindungen, zu kleine SSD unter der Datenbank und Lesevorgänge, die anstelle des Caches auf die relationale Ebene fallen, verloren.

Eine Hardware-Feinheit ist auf dieser Höhe wichtig. Sehr hohe Host-Netzwerkbandbreite bei IONOS ist eine Eigenschaft spezifischer dedizierter Hardware und nicht des allgemeinen Block Storage-Stoffes. Premium-Host-Netzwerke erscheinen auf dedizierter Hardware wie den VMware Private Cloud-Hosts und der GPU/HPC-AI-Plattform, während NVLink-Klassen-Interconnect spezifisch für die Cloud-GPU-Plattform (Compute Engine GPU-VMs) ist, deren GPU-Server zwei NVLink-Cluster von jeweils vier GPUs ausstellen, die separat adressiert werden. Nehmen Sie nicht an, dass InfiniBand oder RDMA-Klassen-Leistung für allgemeine Block Storage oder Standard-Rechenzentrum-LANs verfügbar sind; diese verwenden das iSCSI-Block-Stoff und das Standard-Virtuelle-Netzwerk. Für FinCorp ist die praktische Lesart, dass die regulierte Transaktionsebene auf Standard-Rechenzentrum durch korrekte SSD-Ebene, Pooling und Caching konzipiert ist, während jede zukünftige Low-Latency-HPC- oder AI-Training-Workload ein separates Hardware-Gespräch auf der dedizierten GPU-Plattform ist und kein Attribut, das das allgemeine Stoff bietet.

Entscheidungszusammenfassung

Zusammenfassung

Leistungsengineering bei IONOS ist eine Reihe von Design-Time-Platzierungen und nicht eine nachträgliche Feinabstimmung: Tier- und Größenspeicherung auf das Leistungsminimum, Pooling und Caching der Datenbank, um innerhalb fester Verbindungsobergrenzen und der no-read-replica-Grenze zu arbeiten, Skalieren von stateless-Tiers hinter Balancern, die verteilen anstelle von beschleunigen, und Halten des Hot-Pfad-Kurzwegs über die geschichtete Architektur. Überprovisionierung ist nur gerechtfertigt, wo ein gemessenes Minimum oder eine betriebliche Einschränkung es erfordert; überall sonst ist Right-Sizing mit Live-Wachstum sowohl billiger als auch ausreichend.

Wichtige Punkte:

• Die Leistung von SSD skaliert pro Gigabyte und verschlechtert sich unter ~100 GB, sodass Datenbankvolumen zuerst für die Leistung dimensioniert werden; die Leistung von HDD ist flach und unabhängig von der Größe von Volume.
• Es gibt keine Read-Replicas; Pooling (gemanagter pgbouncer, Transaktionsmodus, Port 6432) und der In-Memory DB-Cache sind die Lesedurchsatzhebel, und die PostgreSQL-Verbindungsobergrenze ist RAM-abgeleitet bis zu 1.000.
• Gemanagte Lastenbalancer verteilen den Datenverkehr auf gesunde Backends, beschleunigen jedoch kein einzelnes Backend; ein Kubernetes-LoadBalancer-Service ist ein einzelner Node-statischer IP.
• Right-Size und Live-Wachstum standardmäßig; Überprovisionierung nur absichtlich am Datenbank-SSD-Minimum oder auf Spitzen-Tiers, die keinen Neustart absorbieren können.
• Premium-Host-Netzwerk ist eine Eigenschaft von 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 den allgemeinen Block Storage-Stoff.

Wichtige Begriffe:

• Verbindungspooler (pgbouncer): Ein gemanagter Zwischenhandler, der viele Anwendungsclients auf eine kleine Anzahl von realen Datenbankverbindungen multiplexiert; explizit aktiviert, auf Port 6432 erreichbar, standardmäßig im Transaktionsmodus.
• Leistungsminimum: Das Mindest-Volume-Größe, unter dem SSD-Speicherung eine verringerte Durchsatzleistung und IOPS (~100 GB für Datenbank-Workloads) liefert.
• Einzel-Node-Obergrenze: Die endliche Durchsatzleistung eines Servers oder eines einzelnen Node-Endpunkts, über die hinaus die einzige Abhilfe das Skalieren über zusätzliche gesunde Backends ist.

Weitere Lektüre

• Einheit 4.2: Bilder, Datenträger und Cloud-Init (Block Storage-Stufen und die SSD-Etage im Kontext)
• Einheit 5.3: Relationale Datenbanken (das no-read-replica-Muster und Replikationsmodi)
• Einheit 5.5: In-Memory-Datenbank (die Cache-Ebene, die den Leseaufwand absorbiert)
• Einheit 1.2: Die kanonische geschichtete Architektur (die Latenzkarte, die diese Einheit nachzeichnet)