Konfiguracja Celery Kubernetes Executor dla Airflow 2.0
Masz dylemat, który Executor wybrać do swojego kolejnego projektu Airflow? Celery Executor i Kubernetes Executor to ciekawe połączenie – Celery Kubernetes Executor daje użytkownikom korzyści obu rozwiązań. Chcesz dowiedzieć się, jak go skonfigurować? Przeczytaj nasz artykuł.
Airflow Kubernetes Executor vs Celery Executor – pierwsze spojrzenie
Airflow oferuje dwa executory, które umożliwiają równoległe wykonywanie wielu zadań. Pierwszy to Celery Executor, który pozwala rozdzielać zadania na wielu workerów. Liczbę workerów i ich zasoby można zdefiniować z góry. Zadania mogą być wykonywane równolegle na każdym workerze, a maksymalną liczbę zadań na workerze określa zmienna worker_concurrency. Ograniczeniem jest to, że liczba workerów i ich zasoby muszą być zdefiniowane z góry i są uruchomione cały czas – nawet jeśli żadne zadanie nie jest wykonywane, zasoby są wykorzystywane, a koszty naliczane. Aby Celery Executor działał poprawnie, konieczne jest wdrożenie message brokera (RabbitMQ / Redis), co komplikuje konfigurację.
Drugim Executorem obsługującym dużą liczbę zadań jest Kubernetes Executor, który uruchamia każdą instancję zadania w osobnym podzie Kubernetes. Zaletą jest to, że każde zadanie ma własną, dedykowaną przestrzeń zasobów. Błąd w jednym zadaniu nie wpływa na inne. Konfigurując Airflow Kubernetes Executor, należy użyć „template”, który służy do tworzenia nowych podów dla kolejnych zadań.
Oba te rozwiązania mają swoje zalety i wady, ale w większych projektach wybór odpowiedniego rozwiązania może być problematyczny. Tu z pomocą przychodzi nowe rozwiązanie w Airflow 2.0 – Celery Kubernetes Executor.
W tym ćwiczeniu wykorzystaliśmy elementy naszego najnowszego produktu opartego na Airflow 2.0, który jest aktywnie rozwijany przez DS Stream (dlatego nie możemy udostępnić pełnego kodu). Jeśli jesteś zainteresowany szczegółami, skontaktuj się z działem sprzedaży. Wkrótce więcej informacji o tym projekcie pojawi się na naszej stronie.
Celery Kubernetes Executor – konfiguracja
To połączenie dwóch powyższych rozwiązań. Pozwala korzystać jednocześnie z Celery i Kubernetes Executor. Daje to większe możliwości, ale wymaga również więcej pracy, ponieważ trzeba skonfigurować oba executory. To połączenie jest idealne do procesów, w których jest wiele niewymagających zadań (do Celery), ale także zadania wymagające dużych zasobów lub izolacji runtime (do Kubernetes).
Konfiguracja Celery Kubernetes Executor
Aby skonfigurować Airflow do użycia Celery Kubernetes Executor, potrzebujesz:
- Zewnętrznej bazy danych
- Message brokera (RabbitMQ/Redis)
- pod-template.yaml – szablonu poda potrzebnego dla Kubernetes Executor do tworzenia nowych podów
W pliku konfiguracyjnym airflow.cfg należy ustawić executor=CeleryKubernetesExecutor oraz kubernetes_queue = kubernetes. W tym przypadku Celery Executor staje się domyślnym executorem. Chęć użycia Kubernetes Executor należy wyrazić w pliku DAG, ustawiając w operatorze parametr queue=’kubernetes’:
System uruchamiamy na Kubernetes Service w Microsoft Azure. W tym celu należy skonfigurować Docker Image, który będzie używany w Airflow. Tworząc go, korzystam z obrazu Apache Airflow w wersji 2.1.4 dostępnego na https://hub.docker.com. Przykładowy Dockerfile poniżej:
Ważne jest utworzenie pliku pod-template.yaml, którego Kubernetes Executor użyje do tworzenia nowych podów. Tam można zdefiniować wymagane zasoby i limity dla każdego poda. Pamiętaj, aby załadować ten plik do obrazu, który będzie używany w konfiguracji Airflow, do ścieżki ${AIRFLOW_HOME}/.
Ścieżkę do tego pliku należy zapisać w pod_template_file w airflow.cfg (pod_template_file = /opt/airflow/pod-template.yaml).
Konfiguracja Celery z message brokerem jest identyczna jak dla Celery Executor. Opisaliśmy to w innym artykule.
Testowanie
Tak skonfigurowany Airflow pozwala korzystać z obu executorów w zależności od potrzeb projektu. Aby to przetestować, skonfigurowałem Airflow jak powyżej i sprawdziłem, czy oba executory działają. Utworzyłem dwa DAGi:
- test_10_task_celery – Celery Executor (10 zadań równolegle)
- test_10_task_kubernetes – do testowania Kubernetes Executor (10 zadań równolegle)
Jedyną różnicą jest parametr queue=”kubernetes” w test_10_task_kubernetes.
Dla Celery Executor działa 10 workerów (worker-deployment-%), a dla Kubernetes Executor powstaje 10 tymczasowych workerów (test10taskkubernetestask#.%):
Po zakończeniu test_10_task_kubernetes tymczasowe workery są usuwane, ale workery Celery nadal działają.
Celery Kubernetes Executor skonfigurowany w ten sposób pozwala uruchomić nawet 1000 zadań równolegle, zarówno przez Celery Executor, jak i Kubernetes Executor. W tym celu ustawiono parametry:
- scheduler_heartbeat_sec = 1
- worker_pods_creation_batch_size = 16
- worker_pods_pending_timeout = 600
- worker_pods_queued_check_interval = 10
Zaletą Kubernetes Executor jest to, że zasoby nie są wykorzystywane cały czas. Celery zużywa zasoby stale, bo workery działają non-stop, a Kubernetes tylko wtedy, gdy trzeba wykonać zadania. Pytanie brzmi – które rozwiązanie jest bardziej opłacalne finansowo? Zrobiliśmy małe porównanie przy użyciu Azure Pricing calculator. Założyliśmy, że Kubernetes Executor działa 1 godzinę dziennie (13 węzłów); dodatkowo potrzebne są 2 węzły dla webservera i scheduler’a.
Dla Celery Executor przez cały miesiąc potrzeba 6 węzłów. Wyniki porównania poniżej:
Różnica to ponad 1000 USD na korzyść Kubernetes Executor! Koszty mogą się znacznie różnić, ale każdy przypadek należy analizować indywidualnie. Jeśli zasoby byłyby potrzebne nie przez 1, a przez 5 godzin dziennie, koszty obu rozwiązań byłyby równe.
Wnioski
Zarówno Celery, jak i Kubernetes Executor mają swoje zalety i wady. Żaden nie jest idealny do każdego zadania. Celery Executor to idealne rozwiązanie dla dużej liczby zadań niewymagających dużych zasobów. Kubernetes Executor pozwala tworzyć osobne środowisko dla każdego zadania, co umożliwia realizację bardziej wymagających zadań. Dodatkowo Kubernetes Executor nie utrzymuje niepotrzebnych podów, gdy nie ma zadań, podczas gdy Celery Executor ma stałą liczbę workerów – niezależnie od obciążenia. Ich połączenie, możliwe w Airflow 2.0 – Celery Kubernetes Executor – pozwala na jeszcze lepszą i efektywniejszą pracę bez kompromisów koniecznych przy wyborze jednego z dwóch executorów.
Jak Airflow może pomóc Twojej firmie? Odwiedź naszą stronę Data Pipeline Automation i znajdź rozwiązanie dopasowane do Twoich potrzeb. Cały proces uruchamiania Airflow zostanie zautomatyzowany przez naszą aplikację, co pozwoli skonfigurować całą infrastrukturę jednym kliknięciem. Podczas budowy wykorzystane zostaną nowoczesne koncepcje i technologie, takie jak CI/CD, Terraform czy Kubernetes. Po więcej szczegółów – skontaktuj się z działem sprzedaży.
Data warehouse vs data lake vs lakehouse: porównanie.
