- OpenAI hat seine PostgreSQL-Infrastruktur massiv ausgebaut, um auf den starken Anstieg bei ChatGPT- und API-Traffic zu reagieren, und verarbeitet mit einem einzelnen Azure PostgreSQL Flexible Server und rund 50 Read Replicas mehrere Millionen QPS
- Bei Beibehaltung einer auf leselastige Workloads optimierten Architektur wurden zur Entlastung der Schreiblast einige Workloads nach Azure Cosmos DB migriert
- Mit verschiedenen Optimierungen wie PgBouncer Connection Pooling, Cache Locking, Rate Limiting und Workload-Isolierung wurden Stabilität und Latenz verbessert
- Um die Grenzen einer Single-Primary-Architektur zu überwinden, wurden parallel Hochverfügbarkeitskonfigurationen (HA), Hot Standby und Tests mit Cascading Replication durchgeführt
- Mit diesem Ansatz wurden 99,999 % Verfügbarkeit und p99-Latenzen im zweistelligen Millisekundenbereich erreicht; zugleich wurde die Grundlage für eine künftige Skalierung mit sharded PostgreSQL oder verteilten Systemen geschaffen
Überblick über die PostgreSQL-Skalierung
- PostgreSQL ist das zentrale Datensystem für ChatGPT und die OpenAI API; in den vergangenen 12 Monaten ist die Last um mehr als das Zehnfache gestiegen
- Mit einer einzelnen Primary-Instanz und weltweit verteilten rund 50 Read Replicas werden die Anfragen von 800 Millionen Nutzern verarbeitet
- Bei Beibehaltung der leselastigen Struktur wurden einige Workloads zur Entlastung der Schreiblast nach Azure Cosmos DB verlagert
- Das Hinzufügen neuer Tabellen ist untersagt, und neue Workloads werden standardmäßig in einem Sharding-System platziert
Herausforderungen und Gegenmaßnahmen bei einer Single-Primary-Architektur
- Eine Single-Writer-Architektur hat Grenzen bei der Schreibskalierung und ein Single Point of Failure (SPOF)
- Lesetraffic wird auf Replicas verteilt, Schreibtraffic für shardbare Workloads wurde nach Cosmos DB verlagert
- Eine Hochverfügbarkeitskonfiguration mit Hot Standby unterstützt im Fehlerfall eine schnelle Promotion (Failover)
- Bei sprunghaft ansteigender Leselast kam es durch eine Welle von Cache Misses zu CPU-Sättigung
- Durch Einführung eines Cache-Locking-Mechanismus werden doppelte Abfragen für denselben Schlüssel verhindert
Abfrage- und Ressourcenoptimierung
- Komplexe Multi-Join-Abfragen belegten übermäßig viel CPU und verursachten Service-Latenzen
- Ineffizientes, vom ORM erzeugtes SQL wurde überprüft, und komplexe Join-Logik wurde in die Anwendungsschicht verlagert
- Mit der Einstellung idle_in_transaction_session_timeout werden lang andauernde inaktive Abfragen verhindert
- Zur Lösung des „Noisy Neighbor“-Problems wurde Traffic auf Instanzen nach Priorität getrennt
- Niedrig priorisierte Anfragen werden isoliert, damit sie hoch priorisierte Services nicht beeinträchtigen
Verbindungsmanagement und Laststeuerung
- Um das Limit von 5.000 Verbindungen bei Azure PostgreSQL zu überwinden, wurde PgBouncer als Proxy-Schicht eingeführt
- Durch Wiederverwendung von Verbindungen wurde die durchschnittliche Verbindungszeit von 50 ms auf 5 ms reduziert
- Um regionenübergreifende Netzwerklatenzen zu verringern, wurden Proxy, Client und Replica in derselben Region platziert
- Rate Limiting wurde auf Anwendungs-, Proxy- und Abfrageebene angewendet, um plötzliche Traffic-Spitzen zu verhindern
- Auch die ORM-Schicht wurde so verbessert, dass bestimmte Query Digests blockiert werden können
Replikation und Management von Schemaänderungen
- Da die Primary WAL-Logs an alle Replicas streamen muss, steigt bei wachsender Zahl von Replicas die Netzwerklast
- Cascading Replication wird in Zusammenarbeit mit dem Azure-Team getestet
- Zwischen-Replikas leiten WAL an nachgelagerte Replicas weiter und schaffen damit die Grundlage für eine Skalierung auf mehr als 100 Replicas
- Schemaänderungen, die ein full table rewrite auslösen, sind untersagt
- Innerhalb eines 5-Sekunden-Timeouts sind nur leichte Änderungen erlaubt; das Erstellen und Löschen von Indizes kann gleichzeitig erfolgen
- Auch beim Backfill gelten strenge Geschwindigkeitsbegrenzungen
Ergebnisse und weitere Pläne
- PostgreSQL verarbeitet mehrere Millionen QPS und erreicht Latenzen im Bereich von einigen Dutzend Millisekunden (p99) sowie eine Verfügbarkeit von 99,999 %
- In den vergangenen 12 Monaten gab es nur einen einzigen SEV-0-Vorfall, der beim Launch von ChatGPT ImageGen auftrat
- Die verbleibenden schreiblastigen Workloads werden schrittweise ebenfalls nach Cosmos DB migriert
- Nach Abschluss von Cascading Replication sollen Skalierbarkeit und Stabilität der Replicas weiter verbessert werden
- Künftig wird die Einführung von sharded PostgreSQL oder alternativen verteilten Systemen geprüft
Noch keine Kommentare.