Routing ruchu wideo w regionie Azji i Pacyfiku za pomocą etcd

Platforma streamingowa obsługująca osiem rynków w regionie Azji i Pacyfiku wyeliminowała powtarzający się błąd routingu, przenosząc konfigurację specyficzną dla regionów do etcd. Czas propagacji zmian routingu spadł do około sekundy. Redaktorzy mogą teraz promować pulę muzyczną przez kilka godzin bez ingerencji w kod, a platforma przestała przesyłać widzom z Korei Południowej sygnał z Tokio.

Dlaczego stary model zawiódł

Każdy router odczytywał trzy wartości dla każdego żądania: pulę trendów, tokenizer specyficzny dla języka oraz łańcuch awaryjny (fallback chain). To decyzje biznesowe — promowanie nowego artysty, reagowanie na awarię regionalną czy testowanie algorytmu rekomendacji — sterowały tymi wartościami, a nie zmiany w kodzie.

Początkowo każda wdrożona wersja zawierała plik JSON z tabelą routingu. Podczas incydentu inżynier dyżurny edytował plik na jednym węźle, aby przekierować ruch do puli zapasowej, ale nie zaktualizował pozostałych siedmiu węzłów. Doszło do rozbieżności konfiguracji (config drift): osiem krajów korzystało z różnych tabel, a żadne pojedyncze źródło nie weryfikowało „prawdy”. Błąd, który kierował widzów z Seulu do Tokio, utrzymywał się, ponieważ kod pozostał bez zmian; różniła się jedynie ukryta konfiguracja.

Wybór etcd jako jedynego źródła prawdy

Zespół porównał trzy opcje:

  • SQLite/MySQL – wymuszałoby odpytywanie bazy danych przez każdy router, co zwiększałoby opóźnienia lub powodowało zalew zapytań.
  • Consul – solidne narzędzie do discovery usług, ale platforma nie potrzebowała jego pełnych funkcji mesh.
  • etcd – silnie spójny magazyn klucz-wartość z prymitywem watch, który powiadamia klientów w momencie zmiany klucza.

Funkcja watch przeważyła szalę. Zamiast aby każdy router wielokrotnie pytał: „czy coś się zmieniło?”, routery pozostawały w uśpieniu, dopóki etcd nie przesłało aktualizacji. Niepotrzebny ruch sieciowy zniknął, a każda instancja dowiadywała się o zmianie jednocześnie.

Wzorce zapewniające bezpieczeństwo systemu

Samo etcd nie rozwiązało wszystkich ryzyk. Inżynierowie dodali trzy uzupełniające wzorce:

  1. Leases (dzierżawy) – redaktor może ustawić tymczasowe wzmocnienie (np. zwiększyć wagę puli K-pop na sześć godzin). Dzierżawa wygasa automatycznie, więc wzmocnienie znika bez konieczności ręcznego wycofania zmian.
  2. Compare-and-swap (CAS) – gdy dwie osoby jednocześnie edytują tę samą ustawienie, CAS zgłasza błąd jednej z nich, zapobiegając cichemu nadpisywaniu danych.
  3. Proces sidecar – PHP ma trudności z długotrwałymi połączeniami. Mały proces sidecar napisany w Go na każdej maszynie monitoruje etcd i zapisuje migawkę (snapshot) tabeli routingu do pliku w pamięci współdzielonej (/dev/shm). PHP odczytuje ten lokalny plik, unikając jakichkolwiek cykli sieciowych (round-trip) podczas obsługi żądania.

Odporność wbudowana w architekturę

Nowy projekt wprowadza kilka zabezpieczeń:

  • Odczyty z zerowym opóźnieniem – ścieżka krytyczna (hot path) PHP odczytuje dane z lokalnej pamięci, dzięki czemu żądania nigdy nie blokują się w oczekiwaniu na zdalny magazyn.
  • Łagodne pogarszanie jakości (graceful degradation) – jeśli etcd ulegnie awarii, routery nadal serwują ostatnią znaną poprawną konfigurację, co zapobiega nagłej przerwie w działaniu.
  • Niezawodne aktualizacje – proces sidecar obsługuje logikę ponownego łączenia i gwarantuje, że żadna zmiana nie zostanie pominięta, nawet jeśli połączenie z etcd zostanie tymczasowo przerwane.

Co zmieniło się w praktyce

Po migracji zespół odnotował gwałtowny spadek liczby incydentów spowodowanych nieaktualnymi lub niespójnymi danymi routingu. Pojedyncza konsola pokazuje obecnie aktualną konfigurację, a każda edycja propaguje się do wszystkich ośmiu regionów w ciągu sekundy. Tymczasowe wzmocnienia wygasają same po upływie czasu dzierżawy, co eliminuje konieczność ręcznego czyszczenia, które wcześniej prowadziło do błędów ludzkich.

Kontrargument: koszt sidecara

Dodanie sidecara oznacza drugi proces na każdy serwer i środowisko uruchomieniowe Go w stosie opartym na PHP. Niektórzy operatorzy obawiają się dodatkowego zużycia pamięci i konieczności monitorowania kolejnego pliku binarnego. W praktyce ślad pamięciowy sidecara pozostaje niewielki, a zyski w zakresie niezawodności — zwłaszcza gwarancja, że PHP nigdy nie zablokuje się na wywołaniu sieciowym — przewyższają narzut operacyjny.

Na co zwrócić uwagę w przyszłości

Zespoły zarządzające usługami wieloregionalnymi powinny monitorować:

  • metryki stanu etcd – warstwa routingu zależy od jednego magazynu; należy monitorować status kworum i opóźnienia.
  • obsługę wygasania dzierżaw – należy dopasować czasy dzierżawy do okien biznesowych; zbyt długie dzierżawy pozostawiają nieaktualne wzmocnienia.
  • skalowanie obciążenia watch – wraz ze wzrostem liczby routerów rośnie liczba połączeń watch; należy odpowiednio zaplanować wydajność serwerów etcd.

Podsumowanie

Dla każdego serwisu wymagającego szybkich, skoordynowanych zmian konfiguracji w wielu regionach, prymitywy watch, lease i transaction systemu etcd oferują lekką, silnie spójną alternatywę dla konfiguracji opartych na plikach lub rozbudowanych struktur typu mesh. Przekształcenie konfiguracji w samoczyszczący się magazyn sterowany modelem push wyeliminowało całą klasę incydentów i zapewniło platformie kontrolę nad logiką routingu w czasie rzeczywistym.