От силози към сервизна топология: Защо Netflix изгради карта на зависимостите в реално време

Изображение: Svetni.me / Авторско изображение

В съвременните софтуерни архитектури мащабът и сложността на системите често надхвърлят капацитета на човешкото възприятие. Когато една платформа се състои от хиляди независими компоненти, разбирането на техните взаимовръзки по време на работа се превръща в критично предизвикателство. В официална публикация на своя инженерен блог [1], технологичният екип на Netflix сподели подробности за разработването на нова вътрешна система, наречена Service Topology (Сервизна топология) – динамична карта на разпределената инфраструктура в реално време, проектирана да преодолее традиционните ограничения на мониторинга.

Тази инициатива е директен отговор на предизвикателствата, породени от управлението на огромна екосистема от микроуслуги, работеща в контейнеризираната платформа Titus на компанията и управлявана от динамична прокси инфраструктура.

Проблемът на „силозната“ наблюдаемост

В рамките на Netflix функционират хиляди микроуслуги, чиито мрежови пътища и логически връзки непрекъснато се променят под влиянието на автоматично мащабиране, динамично маршрутизиране и чести внедрявания на нов код. Исторически погледнато, разработчиците и SRE инженерите (Site Reliability Engineers) са разчитали на три основни източника за наблюдаемост (observability): мрежови логове, приложни метрики и разпределено проследяване на заявките.

Всеки от тези източници обаче съществува в собствен технически и логически „силоз“:

• Мрежовите логове (например VPC Flow Logs) дават информация за физическите IP адреси, портове и TCP пакети. Те обаче не разполагат с приложен контекст и не знаят коя логическа микроуслуга или конкретен контейнер стои зад даден IP адрес в силно динамична облачна среда, където адресите се пренасочват за секунди.
• Приложните метрики (често събирани чрез IPC библиотеки) описват здравето на дадена услуга – например брой заявки в секунда, проценти на грешките или латентност на нишките. Те обаче не предоставят информация за това откъде идват заявките или накъде отиват след това.
• Разпределеното проследяване (distributed tracing) чертае жизнения цикъл и пътя на отделните заявки през системата. Тъй като обемът на трансакциите в Netflix е огромен, пълното записване на тези следи е невъзможно поради разходите за съхранение, което налага агресивно семплиране (например записване на по-малко от 1% от общия трафик). Това прави проследяването ненадеждно за установяване на пълни системни зависимости.

По време на мащабен инцидент, липсата на единна картина принуждаваше инженерите да сглобяват пъзела на зависимостите ръчно в реално време. Те трябваше да превключват между множество табла за визуализация, да анализират сурови логове и да разчитат на статична архитектурна документация, която бързо остарява [1]. Основни въпроси като „Кой е реалният обсег на въздействие (blast radius) при отказ на тази конкретна база данни?“ или „Настоящото забавяне локален проблем ли е, или е ефект от upstream зависимост?“ изискваха дълги софтуерни разследвания.

Трите стълба на единния графов модел

За да реши този проблем, Netflix изгражда Service Topology като разпределена графова база данни, която агрегира три допълващи се слоя телеметрия в общ логически модел [1]:

1. eBPF мрежови лог-файлове (Ядро на ОС): Чрез използването на eBPF (Extended Berkeley Packet Filter) технологията в ядрото на Linux, Netflix събира данни за мрежовия поток на най-ниско ниво. Софтуерът наблюдава промените в състоянието на TCP сокетите директно в ядрото, без да изисква промяна в кода на приложенията или инструментация. eBPF служи като източник на „абсолютната истина“ за мрежовата свързаност, тъй като регистрира всеки пакет, независимо от използвания език за програмиране или комуникационен протокол. Чрез картографиране на мрежовите сокети към метаданните от платформата Titus, системата превежда суровите IP адреси в трайни логически идентичности на микроуслуги.
2. IPC (Inter-Process Communication) метрики (Приложно ниво): Тези данни се излъчват от клиентските комуникационни библиотеки в приложенията. Те добавят важен приложен контекст, който липсва в мрежовите пакети на ядрото – например конкретните API ендпойнти (endpoints), използваните протоколи (като gRPC, GraphQL или HTTP/JSON) и специфични метаданни за трансакциите. Тази информация попълва графовия модел с бизнес логика, показвайки не просто че две услуги си говорят, а какви точно команди обменят.
3. Разпределено проследяване (Ниво заявка): Макар и ограничено от семплирането, проследяването на трансакциите предоставя критичен поглед върху сложните пътища на заявките. То позволява на Service Topology да разбере условните разклонения и последователността на повикванията (например услуга А вика услуга Б, само ако услуга В върне специфичен код).

Всеки от тези три потока се събира в собствен изолиран графов дял (partition). След това конвейерът за данни извършва съпоставка и слива тези дялове в единен, високопроизводителен граф на зависимостите.

Архитектура на обработка и междинно резолване

Преработката на терабайти телеметрия в реално време изисква стабилна разпределена архитектура. Netflix използва вътрешните си платформи за обработка на събития Keystone и Mantis за първоначално инжектиране и филтриране на потоците данни. Истинското инженерно предизвикателство в тази архитектура обаче е т.нар. „междинно резолване“ (Intermediary Resolution) [1].

В реалния свят софтуерният трафик рядко преминава директно от една услуга към друга. Той преминава през AWS балансьори на натоварването (Elastic Load Balancers), мрежови NAT шлюзове и Envoy проксита. Ако тези междинни хардуерни и софтуерни компоненти се оставят в графа, той става пренаситен с излишен шум и става неизползваем за инженерите.

Затова филтриращият алгоритъм на Service Topology автоматично анализира мрежовите и приложни връзки, за да „колапсира“ физическите транзитни хопове. Вместо верига от типа Услуга А -> Load Balancer -> Envoy Proxy -> Услуга Б, системата чертае директно логическо ребро Услуга А -> Услуга Б [1]. Това позволява чиста логическа визуализация на архитектурно ниво.

Оперативни ползи и контрол на производителността

Резултатът от тази разработка е високопроизводителен граф на зависимостите, който поддържа подсекундни заявки за обхождане в реално време. По време на авария SRE екипът може незабавно да види текущото състояние на мрежовия граф, да анализира кои upstream и downstream услуги са засегнати и да локализира аномалиите. Системата поддържа и заявки за „пътуване във времето“ (time travel), с които може да се извлече топологията от произволен минал момент и да се сравни с текущата – безценен инструмент за откриване на проблеми след нови софтуерни деплоймънти.

Важен аспект от внедряването на eBPF технологии в такива мащаби е контролът над системното натоварване. Тъй като eBPF програмите работят в ядрото, те могат да консумират ценни ресурси при интензивен трафик. За да се справят с това, Netflix разработват и споделят с отворен код инструмента bpftop [2]. Той позволява на инженерите да наблюдават производителността на самите eBPF процеси в реално време, предотвратявайки риска наблюдаемостта да застраши стабилността на доставката на видео стрийминг услугите.

Service Topology на Netflix е ярък пример за това как модерното софтуерно инженерство преминава от фрагментирани телеметрични силози към единни, интелигентни карти на разпределената инфраструктура. Чрез автоматизиране на мрежовия анализ и обединяване на ядрото с приложното ниво, стрийминг гигантът поставя нови стандарти за надеждност в ерата на облачните технологии.

Източници:

[1]: From Silos to Service Topology: Why Netflix Built a Real-Time Service Map - Netflix TechBlog
[2]: Introducing bpftop: Streamlining eBPF performance optimization - Netflix TechBlog