Маршрутизация видеотрафика в Азиатско-Тихоокеанском регионе с помощью etcd
Видеостриминговая платформа, обслуживающая восемь рынков Азиатско-Тихоокеанского региона, устранила повторяющуюся ошибку маршрутизации, перенеся региональные конфигурации в etcd. Время распространения изменений маршрутизации сократилось примерно до одной секунды. Редакторы теперь могут временно повышать приоритет музыкального пула на несколько часов, не меняя код, а платформа перестала направлять южнокорейских зрителей на поток из Токио.
Почему старый подход перестал работать
Каждый роутер считывал три значения для каждого запроса: пул трендов, языковой токенизатор и цепочку резервных вариантов (fallback chain). Эти значения определялись бизнес-решениями — продвижением нового артиста, реагированием на региональный сбой или тестированием алгоритма рекомендаций, — а не изменениями в коде.
Изначально при каждом развертывании вместе с приложением поставлялся JSON-файл с таблицей маршрутизации. Во время инцидента дежурный инженер отредактировал файл на одном узле, чтобы перенаправить трафик на резервный пул, но не обновил остальные семь узлов. Возник рассинхрон конфигураций (config drift): в восьми странах использовались разные таблицы, и не было единого источника, подтверждающего «истинные» данные. Баг, из-за которого зрители из Сеула попадали на поток из Токио, сохранялся, потому что код оставался прежним — различались только скрытые конфигурации.
Выбор etcd в качестве единого источника истины
Команда сравнила три варианта:
- SQLite/MySQL — заставили бы каждый роутер постоянно опрашивать базу данных, что увеличило бы задержки или привело к лавине запросов.
- Consul — надежный инструмент для обнаружения сервисов (service discovery), но платформе не требовались все его возможности mesh-сети.
- etcd — хранилище «ключ-значение» с сильной согласованностью и примитивом watch, который уведомляет клиентов в момент изменения ключа.
Именно функция watch перевесила чашу весов. Вместо того чтобы каждый роутер постоянно спрашивал «изменилось ли что-нибудь?», роутеры находились в режиме ожидания, пока etcd не присылал обновление. Лишний сетевой трафик исчез, и каждый экземпляр узнавал об изменениях одновременно.
Паттерны для обеспечения безопасности системы
Сам по себе etcd не решал все риски. Инженеры добавили три дополняющих его паттерна:
- Leases (аренды) — редактор может установить временное повышение приоритета (например, увеличить вес пула K-pop на шесть часов). Срок аренды истекает автоматически, поэтому повышение исчезает без необходимости ручного отката.
- Compare-and-swap (CAS) — если два человека одновременно редактируют одну и ту же настройку, CAS выдает ошибку одному из них, предотвращая скрытую перезапись данных.
- Sidecar-процесс — PHP плохо справляется с длительными соединениями. Крошечный sidecar на Go на каждом узле отслеживает etcd и записывает снимок таблицы маршрутизации в файл в разделяемой памяти (
/dev/shm). PHP считывает этот локальный файл, избегая сетевых задержек при обработке запроса.
Отказоустойчивость, заложенная в архитектуру
Новая архитектура включает несколько страховочных механизмов:
- Чтение с нулевой задержкой — основной путь выполнения (hot path) в PHP считывает данные из локальной памяти, поэтому запросы никогда не зависают в ожидании удаленного хранилища.
- Плавная деградация — если etcd выйдет из строя, роутеры продолжат использовать последнюю известную рабочую конфигурацию, что предотвратит внезапный сбой.
- Надежные обновления — sidecar берет на себя логику переподключения и гарантирует, что ни одно изменение не будет пропущено, даже если соединение с etcd временно прервется.
Что изменилось на практике
После миграции команда зафиксировала резкое снижение количества инцидентов, вызванных устаревшими или неверными данными маршрутизации. Теперь единая консоль отображает текущую конфигурацию, а любое изменение распространяется на все восемь регионов в течение секунды. Временные повышения приоритета аннулируются автоматически по истечении срока аренды, что избавляет от необходимости ручной очистки, которая раньше приводила к человеческим ошибкам.
Контраргумент: цена использования sidecar
Использование sidecar означает наличие второго процесса на каждом сервере и среды выполнения Go в стеке, ориентированном на PHP. Некоторые операторы беспокоятся о дополнительном потреблении памяти и необходимости мониторинга еще одного бинарного файла. На практике потребление ресурсов sidecar остается скромным, а выигрыш в надежности — особенно гарантия того, что PHP никогда не будет блокироваться на сетевом вызове — перевешивает эксплуатационные расходы.
На что обратить внимание в дальнейшем
Командам, управляющим мультирегиональными сервисами, следует отслеживать:
- Метрики состояния etcd — уровень маршрутизации зависит от единого хранилища; следите за состоянием кворума и задержками.
- Обработка истечения срока аренды — подбирайте время аренды в соответствии с бизнес-задачами; слишком длительные аренды оставляют устаревшие повышения приоритета в силе.
- Масштабирование нагрузки watch — с ростом числа роутеров увеличивается количество соединений watch; планируйте емкость серверов etcd соответствующим образом.
Итог
Для любого сервиса, которому требуются быстрые и скоординированные изменения конфигурации в множестве регионов, примитивы watch, lease и transaction в etcd предлагают легковесную и строго согласованную альтернативу конфигурациям на основе файлов или тяжеловесным mesh-системам. Превращение конфигурации в push-ориентированное хранилище с механизмом самоочистки устранило целый класс инцидентов и обеспечило платформе контроль над логикой маршрутизации в режиме реального времени.