Где лучше запустить Flink-приложение: Kubernetes vs AWS EMR

развертывание Flink Kubernetes AWS EMR, Apache Flink Kubernetes Amazon, Apache Flink DevOps Kubernetes, Flink Kubernetes, Apache Flink для разработчиков и дата-инженеров примеры курсы обучение, потоковая обработка данных Flink, обучение дата-инженеров и разработчиков курсы примеры, Школа Больших Данных Учебный Центр Коммерсант

Мы уже писали, как можно развернуть контейнерные приложения 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 в Москве:

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Источники

  1. https://medium.com/@zhnemati/flink-kubernetes-operator-vs-amazon-emr-de611075ba89
  2. https://blog.acethecloud.com/apache-flink-and-kubernetes-a-perfect-match-for-cloud-native-data-processing-10-recipes-6b15a132b186
Контакты авторизированного учебного центра
«Школа Больших Данных»
Адрес:
127576, г. Москва, м. Алтуфьево, Илимская ул. 5 корпус 2, офис 319, БЦ «Бизнес-Депо»
Часы работы:
Понедельник - Пятница: 09.00 – 18.00
Остались вопросы?
Звоните нам +7 (495) 414-11-21 или отправьте сообщение через контактную форму. Также вы можете найти ответы на ваши вопросы в нашем сборнике часто задаваемых вопросов.
Оставьте сообщение, и мы перезвоним вам в течение рабочего дня
Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.
Или напишите нам в соц.сетях
Поиск по сайту