Brian hat ein Dev Diary über die kritische 13-tägige Neuschreibung der Ingress-Backend-Architektur nach schweren Serverausfällen während der Orion Anomalien am 16. Mai veröffentlicht. Die Überarbeitung der Datenbank priorisierte die Schreibleistung und die Speicherverwaltung, um der extremen Belastung durch Anomaly-Events standzuhalten.
Das Entwicklungsteam ist im März 2026 auf eine neue Datenbank umgestiegen. Während sich die alltägliche Latenz bei frühen Events wie +Gamma Hyderabad und der Orion Global Op verbesserte, versagte die Architektur unter der Spitzenbelastung während der Anomalien in Sydney und Prag. Die Aktivität der Agenten überlastete die Auto-Scaler, was zu Staus und einem Systemkollaps führte. Als Reaktion darauf löste Niantic einen Notfall-Code Red aus und beauftragte das Team damit, die Infrastruktur vor den Orion Kure und Jersey City Anomalien zu überarbeiten.
"Vorwärmen" von Anomaly-Standorten
Obwohl das Team bereits freitags vor einer Anomalie manuell zusätzliche Serverkapazitäten hochfährt, brauchte das System insbesondere während der Prag Anomalies noch fast 40 Minuten, um den Datenverkehr zu analysieren und festzustellen, welche Daten verschoben werden mussten, um sofort verfügbar zu sein.
Das System lädt nun vor den ersten Messfenstern bestimmte, stark nachgefragte Daten vorab, zusätzlich zur üblichen Erhöhung der Rechenleistung.
Beseitigung von Aktionsstaus
Aktionen von Agenten wurden zuvor in einer einzigen Tabelle aufgezeichnet, die nach Zeitstempel indiziert war, jedoch verursachten gleichzeitige Schreibvorgänge auf denselben Endpunkt während Anomalien schwere Verzögerungen.
Dieser Index wurde entfernt. Die Geschwindigkeit administrativer Abfragen durch das Team ist leicht gesunken, aber die Live-Schreibleistung hat sich deutlich verbessert.
Eliminierung von Geistereinträgen
Der Portal-Index, der zuvor nach physischem Standort und der Zeit der letzten Aktualisierung sortiert war, erzeugte bei jeder Statusänderung veraltete "Geistereinträge". Der Anomalie-Datenverkehr erzeugte ein Verhältnis von 100:1 von Geistereinträgen zu tatsächlichen Aktualisierungen, was das System verstopfte.
Die Sortierung nach der "Zeit der letzten Aktualisierung" wurde entfernt. Die Datenbank scannt und sortiert nahegelegene Portale nun on-the-fly, was dem alltäglichen Spiel eine geringe Latenz (unter 1,0 Millisekunde) hinzufügt, aber den Anomalie-Rückstand auflöst.
In-Memory Batching
Die bedeutendste strukturelle Änderung bestand darin, Portal-Aktualisierungen von sofortigen Datenbankschreibvorgängen in ein In-Memory-Batching-System zu verschieben. Spielaktionen werden nun im temporären Serverspeicher verarbeitet, bevor sie in Stapeln in die Datenbank geschrieben werden.
Leistungsdaten und Ergebnisse
Die Überarbeitung der Codebasis erforderte die Aktualisierung von über 200 Dateien, das Hinzufügen von 22.000 Codezeilen und das Entfernen von 5.000 Zeilen. Die neue Infrastruktur wurde am 30. Mai für Orion Kure und Jersey City bereitgestellt und lief ohne Scanner-Instabilität oder globale Login-Probleme.
Derzeit ist die In-Memory-Architektur nur an Anomalie-Wochenenden aktiv und wird am darauffolgenden Montag deaktiviert, um Daten zu sammeln und Fehler zu isolieren. Kürzlich durchgeführte Patches haben nachfolgende Probleme behoben, wie eingefrorene Portale, die eine Foto-Interaktion erforderten, um eine Statusaktualisierung zu erzwingen, und spezifische Blocker beim Abschluss von Missionen. Das Entwicklungsteam beabsichtigt, das System weiter zu verfeinern, bis die In-Memory-Portalarchitektur kontinuierlich und während des alltäglichen Spiels laufen kann, was dem XM-Netzwerk langfristige Stabilität bietet.
Quelle: https://ingress.com/news/rewiring-xm-network
@IUGER
Häufig: 2 Punkte
Selten: 4 Punkte
Sehr selten: 8 Punkte
