Airbnb разработала внутреннюю систему хранения для обработки 50 миллионов образцов в секунду и 2,5 петабайт временных рядов данных. Этот переход был необходим из-за огромного объема данных, генерируемых обширной инструментовкой кода по всей эволюционирующей продукции и инфраструктуре. Основной инженерной задачей было сохранение и обслуживание этого огромного набора данных с высокой производительностью.Для управления таким масштабом Airbnb приняла многоарендную архитектуру, изолируя арендаторов по сервису или процессу для стабильной группировки и атрибуции. Они реализовали шардирование shuffle для изоляции рабочих нагрузок арендаторов, повышая отказоустойчивость за счет обеспечения того, чтобы арендаторы записывали и запрашивали только подмножество узлов. Операционную сложность, особенно настройку арендаторов и управление конфигурацией, решала консолидированная плоскость управления, автоматизирующая настройку и упрощающая обновления конфигурации.Ключевыми требованиями для системы были обработка более 50 миллионов образцов в секунду, поддержка многочисленных панелей управления и оповещений, а также поддержание низких времен выполнения запросов. Первоначальная проверка с помощью тень-clusетров показала проблемы с надежностью, задержки уплотнения и медленную производительность запросов, особенно с большими данными. Решение этих проблем началось с обеспечения надежности одного кластера, сосредоточившись на стабилизации записей, чтений и уплотнения через бенчмаркинг, ограничители и изоляцию путей запросов.Система была сделана отказоустойчивой с помощью компонентов, осведомленных о зонах, развернутых по три зоны. Были реализованы ограничения на реплику и контроли на уровне арендатора для эффективного управления флотом и защиты системы. Затем была принята много-кластерная архитектура для уменьшения радиуса действия сбоев и повышения гибкости.Этот много-кластерный подход, однако, ввел сложности в открытие метрик, запросы и операционные накладные расходы. Эти сложности были смягчены с помощью инструментов для сопоставления арендатор-кластер и автоматизированных стратегий развертывания с помощью операторов Kubernetes. Введение Promxy с пользовательскими улучшениями облегчило меж-кластерные запросы и оповещения.Ключевые выводы из этого пути включают значительную стоимость меж-кластерных запросов и важность согласованности развертывания, достигаемой за счет автоматизации и стандартизированных развертываний. Философия эволюционировала в сторону рассмотрения кластеров как одноразовых ресурсов, подобных "скоту", а не критических, уникальных "домашних животных", что позволяет легче масштабировать и обслуживать. В конечном итоге, создание этой платформы требовало сочетания архитектурных инноваций, операционной строгости и культурного сдвига в управлении ожиданиями.