Автор: Абдуррахман Дж. Аллавала
Введение
Когда случается инцидент, команды обращаются к системам наблюдаемости (observability), чтобы получить ответы на единственные вопросы, которые в тот момент имеют значение: что сломалось и почему? Системы мониторинга для этого и созданы — и как правило справляются со своей задачей.
Но что происходит, когда стек наблюдаемости зависит от тех же систем, которые выходят из строя? В такой момент дашборды гаснут, алерты перестают срабатывать, а инструменты, призванные помочь в восстановлении, сами становятся частью аварии.
Это всё более распространённая проблема по мере того, как организации консолидируются на общих платформах — Kubernetes, сервисных сетках (service mesh) и другой общей инфраструктуре. В Airbnb тысячи сервисов опираются на совместную инфраструктуру, обеспечивая надёжный опыт для гостей и хозяев. Анализируя ключевые риски надёжности, мы выявили циклическую зависимость: наш конвейер метрик был построен на тех же системах, которые он должен был наблюдать.
Надёжность — основа того, как мы выстраиваем доверие и обеспечиваем выдающийся опыт для нашего глобального сообщества. Среди ключевых ценностей Airbnb — быть ответственным и надёжным хозяином для миллионов гостей и хозяев по всему миру. Разрыв цепочки зависимостей стал необходимым условием ответственной работы в масштабе и поддержания этого доверия.
В этой статье мы расскажем, как выявили и устранили зависимости в метрической платформе Airbnb. Начнём с того, почему циклические зависимости настолько опасны для наблюдаемости, затем подробно разберём конкретные архитектурные решения, которые позволили нам разорвать их на уровнях вычислений, сети и мета-мониторинга. Итогом стал набор практических подходов, которые можно применить, чтобы ваш стек наблюдаемости был надёжнее систем, за которыми он следит.
Скрытый риск: циклические зависимости в наблюдаемости
Надёжная наблюдаемость — это не только сбор данных, но и уверенность в том, что сам стек наблюдаемости работает стабильнее, чем системы, которые он мониторит.
В Airbnb платформенные команды предоставляют общую инфраструктуру, позволяющую разработчикам разворачивать сервисы и управлять ими с минимальными усилиями. Наша команда в значительной мере опиралась на эту инфраструктуру — и именно здесь мы столкнулись с неочевидной проблемой: стек наблюдаемости зависел от тех самых систем, которые был призван мониторить. Иными словами, у нас возникли циклические зависимости.
Оставить это без решения было нельзя. Нерешённая проблема подрывала ключевую цель наблюдаемости: давать инженерам возможность диагностировать первопричины, когда что-то идёт не так. Если система обнаружения сбоев зависит от той же инфраструктуры, которая отказывает, — видимость исчезает именно тогда, когда она нужна больше всего.
Решение было простым по замыслу: обеспечить каждому внутреннему клиенту резервный, высокодоступный путь сбора метрик. Не менее важно было чётко очертить границы ответственности: мы не пытались гарантировать доступность метрик для систем, которые не являются нашими внутренними клиентами, и не проектировали избыточность для внешних доменов сбоев.
Изоляция вычислений: выделенные кластеры без лишних затрат
Среди множества потребителей нашей метрической платформы команда Airbnb Cloud была одной из наиболее критичных. Airbnb управляет кластерами Kubernetes для самых разных задач — от персональных сред разработки до производственных нагрузок, обслуживающих Airbnb.com, — и наша система должна была соответствовать требованиям команды Cloud по доступности метрик.
Рассматривая, где разместить компоненты наблюдаемости, мы фактически столкнулись с двумя крайностями:
-
Запустить наблюдаемость на общих производственных кластерах. Это снижало операционную нагрузку, но тесно связывало нас с теми самыми приложениями, за которыми нам нужно было следить.
-
Управлять собственными кластерами Kubernetes. Это давало полную изоляцию, но требовало глубокой операционной экспертизы и постоянного обслуживания — работы, за которую небольшая, но сильная команда Observability бралась без энтузиазма.
Ни одна из крайностей не подходила. Первый вариант создавал циклические зависимости и ставил под угрозу целевые показатели доступности; второй накладывал чрезмерную операционную нагрузку.
Оптимальным решением оказалось размещение наших рабочих нагрузок на выделенных кластерах Kubernetes. Эти кластеры не используются совместно с продуктовыми или инфраструктурными приложениями, но при этом по-прежнему администрируются и обслуживаются командой Cloud. Это позволило сохранить Kubernetes как управляемую основу, одновременно сократив общие домены сбоев.
Чтобы поддерживать надёжность такой схемы, мы координируем изменения с командой Cloud: в один момент времени применяется только одно крупное изменение, и каждое изменение сначала проверяется на кластерах с более низким приоритетом, прежде чем попасть в операционные. Это позволило найти нужный баланс: высокая доступность для внутренних клиентов при минимальной операционной нагрузке на нашу команду.
Переосмысление сетевого уровня: отказ от сервисной сети
Данные наблюдаемости отличаются исключительно высоким объёмом трафика. В масштабах Airbnb трафик наблюдаемости превышает бизнес-трафик на порядки, что делает сетевой уровень ключевым фундаментом нашего стека.
Airbnb использует Istio в качестве сервисной сети (service mesh). Несмотря на очевидные преимущества Istio, он не подходил для нагрузок наблюдаемости. Непосредственная проблема была ясна: нельзя использовать один и тот же уровень данных (data plane) и для мониторинга продуктовых и инфраструктурных приложений, и для бизнес-трафика. Это создало бы циклическую зависимость: метрики уровня данных зависели бы от того же уровня данных для своей доставки.
Вторая проблема была менее очевидной: трафик наблюдаемости ведёт себя совсем иначе, чем обычный бизнес-трафик. Его объём значительно больше, и он — что, пожалуй, справедливо — требует более высокой доступности и приоритетности. Наша сервисная сеть изначально проектировалась под бизнес-нагрузки, а не под мир, где каждый сервис непрерывно отправляет телеметрию в центральное хранилище. Использование общего транспортного канала означало, что с ростом нагрузки перегрузка могла сделать метрики недоступными, снижая возможности отладки как для платформенных инженеров, так и для разработчиков продуктов. Хуже того, всплески телеметрии могли поглощать общую пропускную способность и деградировать или нарушать работу прикладного трафика, напрямую влияя на доступность Airbnb.com.
Первым крупным шагом стал полный пересмотр сетевого пути. Чтобы выйти из зависимости от сервисной сети, мы создали собственный уровень сетевого ввода (network ingress) уровня L7 на основе Envoy, который балансирует трафик и маршрутизирует запросы чтения и записи к нужным бэкендам. Запуск этого прокси независимо от общего уровня вычислений добавил отказоустойчивость и защитил путь приёма данных от сбоев в сервисной сети.
Возможно, возникнет вопрос: почему мы решили управлять собственным сетевым уровнем, но не собственным уровнем вычислений? С вычислениями Kubernetes уже был зрелой управляемой платформой под руководством команды Cloud, и добавление выделенных кластеров для наблюдаемости было относительно небольшим приращением к уже существующему парку. Сетевой уровень — другое дело: наша сервисная сеть не могла в нашем масштабе чисто изолировать и приоритизировать трафик наблюдаемости от бизнес-трафика, а нужные нам возможности — строгая приоритизация, изоляция и настраиваемая маршрутизация для телеметрии — как раз находились в зоне ответственности нашей команды. Управление этим уровнем давало нам необходимый контроль, а по сравнению с самостоятельным управлением Kubernetes это была значительно более простая поверхность для эксплуатации.
Отказ от сервисной сети открыл и важные новые возможности. Airbnb управляет более чем 1000 сервисами, каждый из которых соответствует своему тенанту в едином глобальном пространстве пользователей. Наш собственный уровень балансировки нагрузки делает это практичным: мы сопоставляем каждое имя сервиса с конкретным кластерным бэкендом, и каждый запрос должен содержать заголовок тенанта (tenant header), определяющий маршрутизацию. Маршрутизация на основе заголовков стала ключевым мотивом: она снимает с клиентов бремя сложной конфигурации и обеспечивает равномерное, предсказуемое распределение нагрузки.
Наконец, управление собственным сетевым уровнем даёт нам гибкость для реализации мощных нестандартных возможностей. Например, мы можем зеркалировать метрики в альтернативные места назначения для тестирования или применять детализированный контроль доступа — что критически важно при работе с внешними поставщиками или в специализированных сценариях. Эта расширяемость продолжает приносить дивиденды по мере развития платформы.
Мониторинг мониторинга
Выстроив устойчивость на ключевых уровнях инфраструктуры метрик, мы закономерно задались следующим вопросом: как узнать, когда проблемы возникают в самом движке метрик? Чтобы ответить на него, мы добавили ещё один уровень, задача которого — следить за мониторингом. Эта концепция называется мета-мониторинг.
В Airbnb мы запускаем отдельный набор инстансов Prometheus, целиком посвящённых мониторингу нашего стека наблюдаемости. Эти серверы Prometheus оповещают нас, когда какой-либо компонент начинает вести себя некорректно. Чтобы избежать коррелированных сбоев, они работают на узлах Kubernetes, изолированных от стека наблюдаемости и расположенных в разных зонах доступности. Каждый инстанс Prometheus является частью набора высокой доступности (high availability set), как и соответствующие инстансы Alertmanager. Мы следим за тем, чтобы ни одна пара Prometheus–Alertmanager не оказалась на одной общей инфраструктуре, что дополнительно сокращает общие домены сбоев.
Это порождает следующий вопрос: как узнать, что сам уровень мета-мониторинга недоступен? Запуск ещё одного стека мониторинга привёл бы к бесконечной рекурсии.
Вместо этого мы используем Dead Man’s Switch (переключатель мёртвой руки) — механизм, посылающий непрерывный сигнал. Получатель сигнала может считать, что что-то пошло не так, когда сигнал исчезает. В нашей реализации мы поддерживаем правило алертинга, которое постоянно срабатывает до тех пор, пока Prometheus корректно собирает метрики. Alertmanager непрерывно отправляет эти алерты во внешний топик AWS SNS, а CloudWatch alarm отслеживает частоту поступающих сообщений. Если они прекращаются — потому что Prometheus упал, сбор метрик завис, Alertmanager не может отправить сообщения или что-то ещё деградировало — срабатывает CloudWatch alarm и дежурный инженер получает вызов.
Все эти компоненты вместе образуют надёжную сигнальную цепочку, которая выявляет проблемы в самом уровне мета-мониторинга и помогает защитить «мониторинг мониторинга» от незаметных сбоев.
Заключение
Надёжный мониторинг требует проектирования с расчётом на неудобные ситуации: частичные аварии, деградацию сети, отказ зависимостей — именно те условия, при которых традиционные архитектуры наблюдаемости нередко «слепнут». В этой статье мы рассказали о том, как повысили надёжность, устранив циклические зависимости: запустив рабочие нагрузки наблюдаемости на выделенных (но управляемых) кластерах Kubernetes, отделив транспорт телеметрии от сервисной сети с помощью специализированного уровня прокси, а также добавив мета-мониторинг с поддержкой Dead Man’s Switch для защиты от незаметных сбоев.
Эти подходы применимы далеко за пределами Airbnb. Любая организация может повысить надёжность мониторинга, составив карту критических зависимостей, целенаправленно изолировав домены сбоев и обеспечив наличие независимого пути для сигналов, управляющих вызовами дежурных и реагированием на инциденты. Конкретные технологии будут различаться, но принцип неизменен: относитесь к мониторингу как к производственной системе, чья доступность должна превышать доступность того, за чем он наблюдает. Только так можно сохранить видимость во время инцидентов, ускорить восстановление и дать командам уверенность, которая нужна пользователям — и бизнесу.
Если такая работа вас интересует, ознакомьтесь с нашими открытыми вакансиями.
Благодарности
Благодарим команду Observability — Callum Jones, Eugene Ma, Natasha Aleksandrova, Rishabh Kumar, Rong Hu, Wei Song и Yann Ramin — а также наших партнёров по всей компании, без которых это было бы невозможным.
Отдельная благодарность Suman Karumuri и Xuan Lu за помощь в написании этой статьи в период их работы в Airbnb.
Все названия продуктов, логотипы и торговые марки являются собственностью соответствующих правообладателей. Все названия компаний, продуктов и сервисов, упомянутые на этом сайте, используются исключительно в идентификационных целях. Их упоминание не подразумевает чьего-либо одобрения.