Мы уже писали, как можно развернуть контейнерные приложения Apache Flink для обработки больших объемов данных в реальном времени. В продолжение этой темы сегодня сравним развертывание Flink-заданий в Kubernetes и в кластере AWS EMR.
Flink-приложение в Kubernetes: преимущества и недостатки
Apache Flink — это мощный фреймворк с открытым исходным кодом для распределенной обработки данных. Он предназначен для создания приложений потоковой передачи данных в режиме реального времени и предоставляет простую, но мощную модель программирования для обработки крупномасштабных потоков данных. Архитектура Flink построена вокруг механизма распределенного потока данных, который может обрабатывать большие объемы данных почти в режиме реального времени. Также Flink поддерживает пакетную обработку, объединяя ее с потоковой передачей в рамках универсального API, о чем мы писали здесь и здесь.
Развертывание Apache Flink в Kubernetes дает гибкое и легкое использование потоковых приложений без необходимости управления инфраструктурой, т.к. Kubernetes представляет собой систему оркестрации контейнеров с открытым исходным кодом. Этот DevOps-инструмент автоматизирует развертывание, масштабирование и управление контейнерными приложениями за счет предоставления унифицированной платформы для развертывания приложений и управления ими в различных средах, а также обеспечения высокой доступности, отказоустойчивости и масштабируемости. Настройка кластера Kubernetes довольно проста благодаря возможности использовать операторы Kubernetes в различных облачных платформах: Amazon EKS, Google GKE, Azure и пр., о чем мы писали здесь. Также можно настроить кластер Kubernetes на голом железе (bare metal).
Чтобы развернуть Flink в Kubernetes, необходимо создать YAML-файл конфигурации, в котором указано количество реплик и другие сведения о развертывании контейнерного приложения, например, это может выглядеть так:
apiVersion: apps/v1
kind: Deployment
metadata:
name: flink
spec:
replicas: 3
selector:
matchLabels:
app: flink
template:
metadata:
labels:
app: flink
spec:
containers:
- name: flink
image: flink:latest
ports:
- containerPort: 6123
- containerPort: 8081
Далее можно создать само развертывание, воспользовавшись CLI-инструментом kubectl, чтобы запустить YAML-файл ранее определенной конфигурации:
kubectl apply -f flink-deployment.yaml
Запуск Flink-приложений в Kubernetes дает множество преимуществ, от масштабируемости и отказоустойчивости до простоты развертывания и мониторинга. В частности, можно использовать встроенную поддержку Flink для времени события и водяных знаков, чтобы создавать конвейеры потоковой передачи, которые могут обрабатывать события из нескольких источников и генерировать информацию в реальном времени. Также Flink предоставляет API для создания stateful-приложений, которые могут обрабатывать большие объемы данных и выполнять сложные преобразования над ними.
С практической точки зрения стоит помнить и про обратную сторону этих достоинств. В частности, при развертывании приложений Apache Flink в Kubernetes могут возникать такие проблемы, как нехватка памяти из-за некорректной настройки подов или особенностей самих заданий потоковой обработки данных. Также может возрасти время инициализации заданий, что чревато их зависанием и отказами. Подробнее об этом мы писали здесь.
Впрочем, любое техническое решение имеет какие-то ограничения. Поэтому важно рассмотреть Kubernetes как среду развертывания, оценив ее масштабируемость, отказоустойчивость, изоляцию, производительность, удобство мониторинга и стоимость эксплуатации. Именно эти критерии возьмем для сравнения с Amazon EMR, разобрав это далее.
Сравнение с Amazon EMR
Amazon EMR (Elastic MapReduce) – это облачный сервис обработки больших данных от AWS. Он предоставляет полностью управляемую среду для запуска инфраструктуры Big Data, включая экосистемы Apache Hadoop, Spark и Flink. EMR упрощает развертывание кластеров для обработки больших данных и управление ими практически без знания базовой инфраструктуры. Он также имеет бесшовную интеграцию с другими сервисами AWS, такими как S3, Redshift и Glue, что упрощает настройку сквозных конвейеров обработки данных. В Amazon EMR есть несколько разных типов инстансов, но не все инстансы AWS совместимы с решением EMR.
Для запуска платформы контейнерной виртуализации Kubernetes в AWS есть Amazon EKS (Elastic Kubernetes Service) — управляемый сервис для запуска Kubernetes в облаке AWS и локальных центрах обработки данных. EKS поддерживает большинство инстансов AWS, если они работают в среде Amazon. Однако, это отдельный сервис, который отличается от рассматриваемого нами EMR.
Чтобы получить объективное представление об эксплуатации Flink-приложений в кластерах Kubernetes и AWS EMR, сравним их по следующим критериям:
- Масштабируемость;
- Отказоустойчивость;
- Изоляция;
- Производительность;
- Мониторинг;
- Стоимость.
Начнем с масштабирования: масштабирование EMR занимает много времени по сравнению с Kubernetes. В плане отказоустойчивости EMR также проигрывает Kubernetes. В EMR может возникнуть сбой, отключив весь кластер. Kubernetes намного надежнее и с несколькими узлами гарантирует, что кластер не выключится, а, благодаря изоляции контейнеров в случае сбоя одного задания другие рабочие нагрузки не пострадают.
Еще одним серьезным недостатком EMR является то, что после настройки кластера EMR с определенной версией Hadoop или Flink, его нельзя обновить без перезапуска кластера. Это влияет на все запущенные задания. В EMR невозможно запустить два задания Flink с разными версиями, а в Kubernetes это очень просто, поскольку каждое задание контейнеризовано и не зависит от остальных заданий.
Что касается мониторинга, в EMR это очень просто и наглядно, если включено облачное наблюдение и ведение журнала S3. В Kubernetes ведение журнала необходимо настраивать вручную, например, извлекая метрики с помощью Prometheus и отображая их в Grafana. Если вся инфраструктура находится в AWS, то на логирование и генерацию оповещений в кластере Kubernetes DevOps-инженеру потратить дополнительное время и усилия.
Производительность существенно повышается при переходе с EMR на Kubernetes и обеспечивает лучшее соотношение цены и качества. Особенно это заметно, если есть и другие конвейеры данных, работающие в Kubernetes. Кроме того, Kubernetes может использовать контейнеризацию и архитектуры на основе микросервисов, чтобы обеспечить высокопараллелизированные и масштабируемые конвейеры обработки данных. Практика показывает, что при переходе с EMR на Flink в Kubernetes производительность приложения потоковой обработки данных может улучшиться на 15-20%.
Наконец, сравним варианты по стоимости. EMR предполагает оплату за каждый узел и тип его экземпляра, и эта сумма выше, чем в EKS. Плата за EKS распределяется между всеми рабочими нагрузками, выполняющимися в кластере.
Чтобы визуализировать достоинства и недостатки развертывания Flink-приложений в кластере Kubernetes по сравнению с AWS EMR, составим таблицу.
|
Критерий |
Kubernetes |
AWS EMR |
|
Масштабируемость |
лучше |
хуже |
|
Отказоустойчивость |
лучше |
хуже |
|
Изоляция |
лучше |
хуже |
|
Производительность |
лучше |
хуже |
|
Мониторинг |
хуже |
лучше |
|
Стоимость |
лучше |
хуже |
Сравнительная таблица показывает, что кластер Kubernetes для развертывания Flink-приложений лидирует по сравнению со средой AWS EMR. Поэтому при наличии настроенного кластера Kubernetes, где работают какие-то другие заданий, приложения Apache Flink целесообразно также развернуть в этой среде.
Узнайте больше про применение Apache Flink для потоковой обработки событий в распределенных приложениях аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
