Маршрутизація відеотрафіку в Азійсько-Тихоокеанському регіоні за допомогою etcd

Відеострімінгова платформа, що обслуговує вісім ринків Азійсько-Тихоокеанського регіону, усунула повторювану помилку маршрутизації, перенісши специфічні для регіонів конфігурації в etcd. Час поширення змін маршрутизації скоротився приблизно до однієї секунди. Редактори тепер можуть підвищувати популярність музичного пулу на кілька годин без внесення змін у код, а платформа перестала надсилати південнокорейським глядачам потік із Токіо.

Чому старий підхід не працював

Кожен роутер зчитував три значення для кожного запиту: пул трендів, мовний токенізатор та ланцюжок резервних варіантів (fallback chain). Ці значення визначалися бізнес-рішеннями — просуванням нового артиста, реагуванням на регіональний збій або тестуванням алгоритму рекомендацій, — а не змінами в коді.

Спочатку кожен розгортання (deployment) містило JSON-файл із таблицею маршрутизації. Під час інциденту черговий інженер відредагував файл на одному вузлі, щоб спрямувати трафік на резервний пул, але не оновив інші сім вузлів. Виникло розходження конфігурацій (config drift): вісім країн працювали з різними таблицями, і не було єдиного джерела, яке б підтверджувало «істину». Помилка, через яку глядачі з Сеула потрапляли на потік із Токіо, зберігалася, оскільки код залишався незмінним; відрізнялася лише прихована конфігурація.

Вибір etcd як єдиного джерела істини

Команда порівняла три варіанти:

  • SQLite/MySQL — змушували б кожен роутер опитувати базу даних, що додавало б затримку або створювало надмірну кількість запитів.
  • Consul — надійний інструмент для виявлення сервісів (service discovery), але платформі не були потрібні всі його можливості mesh-мережі.
  • etcd — сховище «ключ-значення» з високим рівнем узгодженості (strong consistency) та примітивом watch, який сповіщає клієнтів у момент зміни ключа.

Функція watch стала вирішальною. Замість того, щоб кожен роутер постійно запитував «чи щось змінилося?», роутери залишалися в режимі очікування, поки etcd не надсилав оновлення. Зайвий мережевий трафік зник, і кожен екземпляр дізнавався про зміни одночасно.

Патерни для забезпечення безпеки системи

Один лише etcd не вирішував усіх ризиків. Інженери додали три взаємодоповнювальні патерни:

  1. Leases (оренди) — редактор може встановити тимчасове підвищення (наприклад, збільшити вагу пулу K-pop на шість годин). Термін оренди закінчується автоматично, тому підвищення зникає без необхідності ручного відкату.
  2. Compare-and-swap (CAS) — якщо двоє людей одночасно редагують одне й те саме налаштування, CAS видає помилку для одного з них, запобігаючи непомітному перезапису.
  3. Sidecar-процес — PHP має труднощі з тривалими з'єднаннями. Маленький Go-sidecar на кожному вузлі стежить за etcd і записує знімок (snapshot) таблиці маршрутизації у файл спільної пам'яті (/dev/shm). PHP зчитує цей локальний файл, уникаючи будь-яких мережевих запитів під час обробки запиту.

Стійкість, закладена в архітектуру

Нова архітектура додає кілька рівнів захисту:

  • Читання з нульовою затримкою — основний шлях виконання (hot path) у PHP зчитує дані з локальної пам'яті, тому запити ніколи не зависають в очікуванні віддаленого сховища.
  • Поступова деградація (graceful degradation) — якщо etcd виходить з ладу, роутери продовжують обслуговувати останню відому коректну конфігурацію, запобігаючи раптовому збою.
  • Надійні оновлення — sidecar-процес керує логікою повторного підключення та гарантує, що жодна зміна не буде пропущена, навіть якщо з'єднання з etcd тимчасово перерветься.

Що змінилося на практиці

Після міграції команда помітила різке скорочення інцидентів, спричинених застарілими або невідповідними даними маршрутизації. Тепер єдина консоль відображає поточну конфігурацію, а будь-яке редагування поширюється на всі вісім регіонів протягом секунди. Тимчасові підвищення анулюються автоматично після закінчення терміну оренди, що усуває необхідність ручного очищення, яке раніше призводило до людських помилок.

Контраргумент: ціна використання sidecar

Додавання sidecar означає наявність другого процесу на кожному сервері та середовища виконання Go у стеку, орієнтованому на PHP. Деякі оператори занепокоєні додатковим споживанням пам'яті та необхідністю моніторингу ще одного бінарного файлу. На практиці використання ресурсів sidecar залишається скромним, а переваги у надійності — особливо гарантія того, що PHP ніколи не блокуватиметься через мережевий виклик — переважають експлуатаційні витрати.

На що звернути увагу далі

Командам, які керують мультирегіональними сервісами, слід контролювати:

  • метрики стану etcd — рівень маршрутизації залежить від єдиного сховища; стежте за статусом кворуму та затримкою.
  • обробку закінчення терміну оренди — узгоджуйте час оренди з бізнес-циклами; занадто довгі терміни оренди залишають застарілі підвищення активними.
  • масштабування навантаження watch — зі збільшенням кількості роутерів зростає кількість з'єднань watch; відповідно плануйте потужність серверів etcd.

Висновок

Для будь-якого сервісу, якому потрібні швидкі та узгоджені зміни конфігурації в багатьох регіонах, примітиви watch, lease та transaction у etcd пропонують легку, суворо узгоджену альтернативу конфігураціям на основі файлів або важким mesh-мережам. Перетворення конфігурації на сховище, що працює за принципом push та має механізм самоочищення, усунуло цілий клас інцидентів і надало платформі можливість керувати логікою маршрутизації в режимі реального часу.