Зачем и как Apache Flink использует удаленный вызов процедур, с помощью каких технологий реализуется это RPC-взаимодействие и почему в 2023 году Akka заменен на Pekko.
Удаленный вызов процедур в Apache Flink
Мы уже рассказывали, как RPC-вызовы используются для коммуникации между компонентами Spark. Удаленный вызов процедур используется и в Apache Flink, который тоже является распределенной системой, компоненты которой располагаются на разных узлах кластера. RPC обеспечивает механизм для обмена сообщениями и вызова методов между этими распределёнными компонентами, позволяя им взаимодействовать так, как будто они находятся в одной среде. В частности, RPC применяется для взаимодействия между менеджерами заданий и задач (JobManager и TaskManager), обеспечивая координацию распределённых вычислений и обмен данными в режиме реального времени. Например, JobManager использует RPC-вызовы, передавая команды менеджерам задач для их запуска или остановки. Это позволяет централизованно контролировать выполнение заданий и управлять ресурсами в кластере. В ответ менеджеры задач отправляют информацию о состоянии задач, метрики производительности и другую диагностическую информацию через RPC. Благодаря этому менеджер заданий может принимать обоснованные решения о распределении ресурсов и обработке отказов.
В случае сбоя одного из компонентов, RPC помогает быстро перенаправить задачи на другие доступные узлы, обеспечивая надёжность и отказоустойчивость системы.
При защите сетевых соединений между процессами машин с помощью аутентификации и шифрования Apache Flink различает внутреннее и внешнее соединение. Внутреннее соединение относится ко всем соединениям, установленным между процессами Flink. Эти соединения запускают пользовательские протоколы Flink. Пользователи никогда не подключаются напрямую к внутренним конечным точкам соединения.
Внешние конечные точки соединения (REST API) относятся ко всем соединениям, установленным извне к процессам Flink: команды веб-интерфейса и HTTP-вызовы для запуска и управления работающими заданиями/приложениями, включая связь CLI с JobManager/Dispatcher. Для большей гибкости безопасность внутренних и внешних подключений можно включить и настроить отдельно.
Внутренняя связь включает в себя:
- управляющие сообщения, т.е. RPC-вызовы между менеджерами задач, заданий, ресурсов и диспетчером (JobManager, TaskManager, ResourceManager, Dispatcher);
- передача данных — соединения между диспетчерами задач для обмена данными во время их перемешивания, трансляции, перераспределения и пр.
- Blob-службы для распространения библиотек и других артефактов.
Все внутренние соединения используют взаимную аутентификацию (mTLS) и зашифрованы с помощью SSL. Все внешние подключения осуществляются через конечную точку REST без аутентификации клиента. При желании можно настроить SSL-аутентификацию подключений к конечной точке REST, включив в конфигурацию Flink простую взаимную аутентификацию или запустить прокси-сервер, который будет аутентифицировать и пересылать клиентские запросы в Flink, например, Envoy Proxy или NGINX с MOD_AUTH. Впрочем, вернемся к использованию RPC-вызовов между компонентами Flink и разберем, как это реализуется.
От Akka к Pekko: эволюция RPC-реализаций
Изначально RPC в Flink был реализован поверх Akka – довольно распространенного фреймворка для создания распределённых и параллельных JVM-приложений, написанных на Scala и Java. Он основан на модели акторов, которая упрощает разработку многопоточных и распределённых систем. Это парадигма программирования для построения высоко-конкурентных и распределённых систем. Акторы взаимодействуют друг с другом посредством асинхронных сообщений. Это упрощает управление состоянием и потоками выполнения. Каждый актор имеет своё собственное состояние и обработка сообщения — единственный способ изменить это состояние. Так акторы избегают проблем, связанных с общим состоянием и синхронизацией. Асинхронное взаимодействие позволяет избежать проблем, вызванных блокировками.
Модель акторов позволяет легко реализовать масштабируемые решения, поскольку добавление новых узлов в систему не требует изменений в логике взаимодействия акторов. А изолированность состояния акторов способствует более высокой надёжности системы, так как сбои в одном акторе не влияют на состояние других акторов. Это парадигма программирования включает в себя механизм супервизора, чтобы управлять ошибками и восстанавливать акторов после сбоев. Все это обеспечивает асинхронность и отсутствие блокировок, что идеально подходит для RPC, позволяя обрабатывать множество параллельных запросов без блокировки потоков.
До версии 1.11 Apache Flink активно использовал Akka для управления распределёнными компонентами и координации задач в своей архитектуре для реализации следующих возможностей:
- обмен сообщениями о состоянии между процессами/компонентами, например, JobManager и TaskManager;
- обеспечение гарантии многопоточности, т.е. только один поток может вносить изменения во внутреннее состояние компонента;
- наблюдение за компонентами на предмет неожиданных сбоев, т. е. обнаружение и обработка сбоев потока TaskManager.
Однако, начиная с июня 2020 года, Flink начал искать альтернативный RPC-фреймворка, чтобы повысить степень контроля разработчиков над обменом сообщениями между распределенными компонентами. Кроме того, 7 сентября 2020 компания-разработчик Akka объявила об изменении лицензии для этого проекта с версии 2.7, требуя коммерческой лицензии при превышении определенного порога.
Поэтому начиная с версии 1.18 Akka во Flink заменен на Apache Pekko — ответвление Akka 2.6.x, созданное до принятия проектом Akka лицензии Business Source. Pekko тоже использует модель акторов для предоставления высокоуровневых абстракций реализации параллелизма. Также Pekko предоставляет библиотеки для сохранения данных, потоков, HTTP, API Java и Scala. Как и Flink, Apache Pekko предназначен для работы в JVM.
Произведенная в 2023 году замена Akka на Pekko во Flink включала, в т.ч., переименование некоторых классов. Например, все пакеты, которые раньше начинались с org.apache.flink.runtime.akka, стали начинаться с org.apache.flink.runtime.pekko. А классы, которые содержали в названии Akka, теперь содержат Pekko. В частности, класс AkkaRpcService был переименован в PekkoRpcService. Все классы и интерфейсы, связанные с Akka, были аналогично обновлены, чтобы отразить изменения в используемой технологии. Переход на Pekko позволил Flink избежать ограничений, связанных с новой коммерческой лицензией Akka, и продолжить использовать открытые технологии для обработки потоков данных. Pekko управляется сообществом, что делает его развитие более гибким и открытым для участия внешних разработчиков. Наконец, Pekko сохраняет совместимость с предыдущими версиями, что облегчает миграцию для проектов, уже использующих Akka.
Таким образом, переход на Pekko позволил Flink оставаться свободным и открытым проектом, не сталкиваясь с ограничениями на использование ключевых технологий для реализации RPC-взаимодействий между компонентами этого распределенного фреймворка.
Освойте возможности Apache Flink для пакетной и потоковой аналитики больших данных и машинного обучения на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
