Time series storage на highload требует не только throughput, но и контроля деградации. Разбор системы, которая обрабатывает 50M samples/sec и 2.5PB данных.
В момент, когда метрики перестают быть «наблюдаемостью» и превращаются в поток, который трудно удержать, система генерировала около 1.3 млрд активных time series и принимала до 50 млн сэмплов в секунду. Переход с внешнего провайдера на собственный backend обнажил базовое ограничение: хранить и отдавать такие объёмы данных стабильно. Без жёстких ограничений (guardrails) любая ошибка в одном сервисе могла перегрузить ingestion или query слой. На этом масштабе деградация начинается локально, но быстро распространяется по всей системе.
Ключевое решение — multi-tenant архитектура с изоляцией и контролем нагрузки. В качестве единицы tenant выбрали сервис, а не команду. Это уменьшает churn в конфигурации и даёт точную атрибуцию роста метрик. Поверх этого добавили shuffle sharding — каждый tenant пишет и читает только из подмножества узлов. Это компромисс: ресурсы используются не максимально эффективно, но система получает предсказуемую изоляцию и устойчивость к сбоям. Дополнительно ввели ограничения на уровне tenant: rate limiting, число series, параметры запросов.
Реализация потребовала централизованного control plane. Он автоматически онбордит новые сервисы и применяет конфигурации без ручных операций. Часть лимитов задаётся явно, часть вычисляется. Например, ingestion rate выводится из лимита на количество series. Это снижает риск неконсистентных настроек. Для writes провели бенчмаркинг и задали per-replica лимиты, чтобы управлять нагрузкой и масштабированием. Для reads ситуация сложнее из-за вариативности запросов, поэтому применили query sharding и отдельные лимиты на выборки. Критичные запросы (evaluation) изолировали от ad-hoc нагрузки.
Отдельное внимание — отказоустойчивость. Stateful-компоненты сделали zone-aware и разнесли по трём зонам. Это снижает влияние отказов уровня зоны и операций вроде rolling deploy. Для крупных tenants compaction шардируется, чтобы избежать задержек чтения. Autoscaling добавили только на read path, где нагрузка более вариативна.
После стабилизации single-cluster архитектуры система упёрлась в blast radius. Решение — переход к multi-cluster. Tenants распределяются между кластерами, а специализированные нагрузки (например, инфраструктурные) изолируются отдельно. Это уменьшает зону поражения и даёт гибкость по регионам. Однако появляется новая сложность: управление размещением tenants и консистентность конфигураций.
Эту проблему закрыли через tooling, который хранит mapping tenant → cluster и служит источником истины. Деплой stateful-сервисов автоматизировали через Kubernetes-операторы, что убрало ручные rollout-процессы и снизило конфигурационный дрейф. Для кросс-кластерных запросов использовали Promxy с доработками: fanout-оптимизация и поддержка дополнительных типов данных. Это позволило сохранить единый слой запросов поверх распределённой архитектуры.
Результат — система, которая масштабируется через изоляцию, а не только через горизонтальное расширение. Удалось снизить влияние «шумных» tenants, улучшить предсказуемость нагрузки и повысить отказоустойчивость. Точных метрик улучшений не приводится, но архитектурные изменения явно направлены на контроль blast radius и стабильность при highload.
В итоге ключевые принципы остаются инженерно простыми: изоляция, автоматизация, контроль лимитов и разделение критичных путей. На этом масштабе observability — это уже не про сбор метрик, а про управление системой, которая сама легко становится источником инцидентов.