Time series storage bei Highload erfordert nicht nur Durchsatz, sondern auch Kontrolle der Degradation. Analyse eines Systems, das 50M Samples/Sekunde und 2.5PB Daten verarbeitet.
In dem Moment, in dem Metriken aufhören, „Observability“ zu sein und sich in einen schwer beherrschbaren Strom verwandeln, erzeugte das System etwa 1,3 Milliarden aktive Time Series und verarbeitete bis zu 50 Millionen Samples pro Sekunde. Der Übergang von einem externen Anbieter zu einem eigenen Backend offenbarte eine grundlegende Einschränkung: solch große Datenmengen stabil zu speichern und bereitzustellen. Ohne strenge Einschränkungen (Guardrails) konnte jeder Fehler in einem Dienst die Ingestion- oder Abfrageebene überlasten. Auf diesem Maßstab beginnt die Degradation lokal, breitet sich jedoch schnell im gesamten System aus.
Die Schlüsselentscheidung war eine Multi-Tenant-Architektur mit Isolation und Lastkontrolle. Als Einheit wurde der Dienst und nicht das Team gewählt. Dies reduziert den Churn in der Konfiguration und ermöglicht eine präzise Attribution des Wachstums der Metriken. Darüber hinaus wurde Shuffle Sharding hinzugefügt — jeder Tenant schreibt und liest nur aus einer Teilmenge von Knoten. Dies ist ein Kompromiss: Die Ressourcen werden nicht maximal effizient genutzt, aber das System erhält vorhersehbare Isolation und Fehlertoleranz. Zusätzlich wurden Einschränkungen auf der Ebene des Tenants eingeführt: Rate Limiting, Anzahl der Series, Abfrageparameter.
Die Implementierung erforderte einen zentralisierten Control Plane. Dieser onboardet automatisch neue Dienste und wendet Konfigurationen ohne manuelle Eingriffe an. Ein Teil der Limits wird explizit festgelegt, ein Teil wird berechnet. Zum Beispiel wird die Ingestion-Rate aus dem Limit für die Anzahl der Series abgeleitet. Dies verringert das Risiko inkonsistenter Einstellungen. Für Writes wurde ein Benchmarking durchgeführt und per-Replica-Limits festgelegt, um die Last und Skalierung zu steuern. Für Reads ist die Situation aufgrund der Variabilität der Anfragen komplexer, daher wurde Query Sharding und separate Limits für Abfragen angewendet. Kritische Anfragen (Evaluation) wurden von ad-hoc Lasten isoliert.
Besonderes Augenmerk gilt der Fehlertoleranz. Stateful-Komponenten wurden zone-aware gestaltet und auf drei Zonen verteilt. Dies verringert den Einfluss von Ausfällen auf Zonenebene und Operationen wie Rolling Deploys. Für große Tenants wird die Kompaktierung shardiert, um Verzögerungen beim Lesen zu vermeiden. Autoscaling wurde nur für den Read-Pfad hinzugefügt, wo die Last variabler ist.
Nach der Stabilisierung der Single-Cluster-Architektur stieß das System auf den Blast Radius. Die Lösung war der Übergang zu Multi-Cluster. Tenants werden zwischen Clustern verteilt, und spezialisierte Lasten (z. B. Infrastruktur) werden separat isoliert. Dies verringert die Schadenszone und bietet Flexibilität in den Regionen. Es entsteht jedoch eine neue Komplexität: das Management der Platzierung von Tenants und die Konsistenz der Konfigurationen.
Dieses Problem wurde durch ein Tooling gelöst, das das Mapping Tenant → Cluster speichert und als Quelle der Wahrheit dient. Das Deployment von Stateful-Services wurde durch Kubernetes-Operatoren automatisiert, was manuelle Rollout-Prozesse beseitigte und den Konfigurationsdrift reduzierte. Für Cross-Cluster-Abfragen wurde Promxy mit Anpassungen verwendet: Fanout-Optimierung und Unterstützung zusätzlicher Datentypen. Dies ermöglichte es, eine einheitliche Abfrageebene über der verteilten Architektur zu erhalten.
Das Ergebnis ist ein System, das sich durch Isolation und nicht nur durch horizontale Erweiterung skalieren lässt. Es gelang, den Einfluss „lauter“ Tenants zu verringern, die Vorhersagbarkeit der Last zu verbessern und die Fehlertoleranz zu erhöhen. Genaue Metriken der Verbesserungen werden nicht angegeben, aber die architektonischen Änderungen sind eindeutig auf die Kontrolle des Blast Radius und die Stabilität bei Highload ausgerichtet.
Letztendlich bleiben die Schlüsselprinzipien ingenieurtechnisch einfach: Isolation, Automatisierung, Kontrolle der Limits und Trennung kritischer Pfade. Auf diesem Maßstab ist Observability nicht mehr nur das Sammeln von Metriken, sondern das Management eines Systems, das selbst leicht zur Quelle von Vorfällen werden kann.