История за два автоскейлъра: Как Netflix преминава към отворения код на Apache Flink
Изображение: Svetni.me / ИИ генерирано изображение
В официална публикация в технологичния си блог [1] инженерният екип на Netflix разкрива детайли за архитектурната трансформация на своята инфраструктура за поточна обработка на данни (stream processing). Към днешна дата компанията поддържа паралелно два различни механизма за автоматично мащабиране (autoscalers) на стрийминг задачи – вътрешно разработено решение от 2019 г. и новия компонент с отворен код от общността на Apache Flink. Инженерите обаче признават, че това е с точно един автоскейлър повече, отколкото биха искали да поддържат.
Мащабът на платформата прави прецизното оразмеряване критично за оперативната надеждност на стрийминг гиганта. В разпределената облачна инфраструктура на AWS компанията изпълнява над 30 000 активни Flink процеса. Повечето от тях се генерират напълно автоматизирано от платформата Data Mesh, но бързо растяща група от персонализирани задачи обслужва препоръчителните алгоритми, рекламната мрежа и преките предавания в реално време, където натоварването варира драматично в рамките на денонощието.
Изображение: Svetni.me / ИИ генерирана инфографика
Цената на мащабирането и ограниченията на външната телеметрия
При поточна обработка с натрупване на състояние (stateful processing) всяко действие по мащабиране е свързано със съществен оперативен разход [1]. За да промени изчислителния капацитет, системата по подразбиране трябва да създаде контролна точка (savepoint), да спре процеса контролирано и да го рестартира в нова конфигурация. При сложни работни потоци с терабайти вътрешно състояние тази процедура отнема минути, през които обработката спира.
Първото решение на Netflix, внедрено около 2019 г., работи като отделен стрийминг процес върху вътрешната система Mantis. То събира обобщени клъстерни метрики от мониторинг платформата Atlas, включително натоварване на процесора, мрежов трафик, изоставане (lag) в опашките на Apache Kafka и входящ дебит. Системата успешно намалява използваните изчислителни ресурси с между 25% и 45% за хиляди сравнително прости еднокомпонентни потоци.
Фундаменталното ограничение на този ранен модел се корени в неговата единица на мащабиране. Системата управлява клъстера като монолитно цяло чрез броя на виртуалните процеси (TaskManagers), принуждавайки всички оператори в насочения ацикличен граф (DAG) да се мащабират заедно. Това се оказва неефективно за съвременни топологии с множество клонове и обединения (joins), където отделните възли имат коренно различни изчислителни изисквания. Освен това външните метрики за процесорна заетост понякога пропускат реални затруднения, оставяйки претоварени оператори неотчетени [1].
Отвореният Flink Autoscaler: Оценка на истинския темп на обработка
Когато общността на Apache Flink разработва специализиран модул за автоскейлинг (FLIP-271), базиран на академичните изследвания по проекта DS2, парадигмата се променя радикално. Вместо да наблюдава виртуалните контейнери отвън, новият инструмент анализира работния процес директно отвътре.
В основата на алгоритъма стои изчисляването на истинския темп на обработка (True Processing Rate или TPR). По време на изпълнение Flink отчита точно каква част от всяка секунда отделният подзадачен процес е реално зает с работа, разграничавайки това време от периодите на изчакване (idle) или обратно налягане (backpressure). Чрез разделяне на наблюдавания дебит на коефициента на заетост алгоритъмът екстраполира максималния теоретичен капацитет на оператора при пълно натоварване:
| Параметър | Вътрешен автоскейлър (2019 г.) | Отворен Flink Autoscaler (OSS) |
|---|---|---|
| Единица за мащабиране | Цял Flink клъстер | Индивидуални върхове (vertices) в графа |
| Граници на контрол | Минимален/максимален брой TaskManagers | Минимален/максимален паралелизъм на възел |
| Източник на данни | Push поток от метрики през Atlas | Директен Pull през Flink JobManager REST API |
| Водещ сигнал | Процесор, мрежа, прогнозен входящ дебит | Време на заетост на възел / TPR алгоритъм |
| Приложимост | Прости потоци без състояние (stateless) | Сложни графи с множество оператори и състояние |
| Конфигурация | Глобална на ниво платформа | Индивидуални профили за всяка отделна задача |
Започвайки от входните източници на данни, автоскейлърът обхожда графа и изчислява необходимия паралелизъм за всеки отделен възел. По този начин се гарантира, че нито един оператор не се превръща в пречка, без да се налага ненужно увеличаване на ресурсите за останалата част от конвейера [1].
Инженерни предизвикателства при внедряването в мащаб
Оригиналната архитектура на отворения инструмент е проектирана за директно вграждане в оператора за Kubernetes. В Netflix обаче изпълнението на Flink се контролира от собствена разпределена контролна равнина. За да интегрира решението, екипът използва обособената самостоятелна библиотека на Flink Autoscaler и я вгражда в специализирано Spring Boot микроприложение.
Оркестрацията на процеса е поверена на платформата за устойчиви работни процеси Temporal. Докато първоначалният опит за пакетна оценка на всички задачи в един цикъл води до забавяния и взаимно блокиране, преминаването към модел с отделен дълготраен Temporal работен процес за всяка задача изолира рисковете от грешки (blast radius).
За да функционира стабилно при производствените обеми на Netflix, екипът внедрява и три ключови подобрения:
Оптимизация на метриките при висок паралелизъм: Извличането на телеметрия за големи топологии натоварваше контролера JobManager. Чрез кеширане на имената на метриките и филтриране на данните от страната на сървъра (принос, дарен на общността в FLINK-36172), системата вече управлява процеси с до 3000 подзадачи.
Защита на директните връзки (Forward Chaining): В Flink върховете, свързани чрез директна връзка в паметта, трябва да поддържат еднакъв паралелизъм. Промяната на паралелизма само за единия оператор тихо преобразува връзката в скъпо мрежово преразпределение (shuffle). Netflix модифицира алгоритъма, така че да открива тези подсвързани графи и да ги мащабира като единна неделима група.
Съобразяване с капацитета на приемниците (Sinks): Добавено е откриване на асинхронно обратно налягане от крайните хранилища, предотвратявайки опити за изкуствено увеличаване на изчислителната мощност, когато записващата система отдолу е изчерпала пропускателния си капацитет.
Преди прилагане на решенията за промяна модулът за изпълнение преминава през редица проверки за надеждност на ниво SRE, включително забрана за свиване на ресурсите в региони, към които се пренасочва трафик при аварии [1].
Резултати от експлоатацията и пътят към Flink 2
Внедряването на новия автоскейлър вече дава измерими икономически и технологични резултати. Екипът, отговарящ за телеметрията и логовете на клиентските приложения в Netflix, отчита 58% спад в годишните разходи за Flink изчисления, спестявайки около 1,1 милиона долара годишно [1, 2].
Инженерите подчертават, че при мащабиране надолу прекалената агресивност крие капани. Твърде рязкото свиване на капацитета води до незабавно претоварване на процесорите и скок в забавянето на данните. Поради това Netflix съзнателно конфигурира целева заетост от 0,45 – значително под препоръчаната от общността стойност от 0,70. Този компромис осигурява плавност и устойчивост, избягвайки скъпоструващи чести рестартирания.
Основното предизвикателство пред бързото мащабиране остава времето за възстановяване на състоянието от дисковите масиви. За да преодолее това тясно място, Netflix вече експериментира с Flink 2.2 и неговата архитектура с разделено състояние (disaggregated state), при която данните се съхраняват директно в отдалечени облачни хранилища. Опитът на инженерите показва три универсални поуки: изборът на правилния измерителен сигнал е по-важен от сложността на алгоритъма, разумните стандарти по подразбиране трябва винаги да позволяват фина настройка, а успешната стратегия изисква първо внедряване на утвърден отворен код и последващо активно участие в неговото развитие.
Източници:
[1]: A Tale of Two Flink Autoscalers - Netflix Technology Blog
[2]: Netflix Moves Toward Open Source Flink Autoscaler for 30,000+ Streaming Jobs - InfoQ