Архитектура сервиса^Beta

Сервис Cloud Airflow может быть развернут в следующих конфигурациях:

• Single: экземпляр сервиса, развернутый на одном сервере. Решение подходит для разработки и тестирования, снижает расходы на развертывание тестовой инфраструктуры. Не обеспечивает отказоустойчивость: сбой узла приводит к остановке всей работы.
• Кластер: отказоустойчивая конфигурация из нескольких узлов (сбой одного узла не приводит к остановке инстанса Cloud Airflow). Решение обеспечивает высокую производительность и подходит для хранения баз данных, в том числе для высоконагруженных проектов со строгими требованиями к сохранности данных.

Cloud Airflow представляет рабочие процессы (workflow) в виде направленных ациклических графов (DAG — Directed Acyclic Graph). Графы представляют собой DAG-файлы со скриптами на языке Python и размещаются в хранилище DAG-файлов. Для корректного выполнения рабочих процессов имена DAG-файлов должны быть уникальными. Хранилище DAG-файлов является центральным звеном архитектуры сервиса и обеспечивает взаимосвязь всех остальных компонентов.

Компоненты архитектуры сервиса Cloud Airflow:

• Веб-сервер (Web Server) — веб-приложение для управления и визуализации рабочих процессов.
• База метаданных (Metadata DB) — служебная база данных, которая хранит историю выполнения задач, сами задачи и системные настройки, что обеспечивает согласованность рабочих процессов. В Cloud Airflow используется база данных PostgreSQL.
• Планировщик (Scheduler) — отвечает за запуск задач в соответствии с DAG. Он регулярно проверяет, какие задачи готовы к выполнению (по умолчанию — каждую минуту), и отправляет их на исполнение указанному Executor через очередь задач (Redis).
• Триггерер (Triggerer) — компонент архитектуры, который ожидает внешние события от планировщика для возобновления отложенных задач.
• Очередь задач (Redis) — очередь для асинхронного обмена между планировщиком и исполнителями.
• Исполнитель (Executor) — отвечает за выполнение задач из DAG на worker-узлах. Исполнитель забирает задачи из очереди и определяет, где и как они будут запускаться. Исполнители бывают различных типов. В сервисе Cloud Airflow используется исполнитель с типом CeleryExecutor, распределенный исполнитель задач на основе библиотеки Celery (Python).
• Хранилище DAG-файлов (DAG Directory) — каталог с Python-файлами, в которых описаны рабочие процессы.
• Внешний сервис (External Service) — внешние сервисы, с которыми взаимодействуют задачи (например, PostgreSQL, AWS S3, HTTP API).

Схема взаимодействия компонентов Cloud Airflow приведена на рисунке 1.

Рисунок 1 — Схема взаимодействия компонентов Cloud Airflow

Общий принцип работы с сервисом:

1. Пользователь загружает DAG-файл в хранилище (DAG Directory).
2. Планировщик (Scheduler) обнаруживает новый DAG-файл и начинает планировать его запуски.
3. Когда приходит время выполнения, планировщик ставит задачи в очередь (Redis).
4. Исполнитель (Executor) забирает задачу из очереди и выполняет ее.
5. Результат (успех или ошибка) записывается в базу метаданных (Metadata DB).
6. Веб-сервер (Web Server) отображает статус выполнения в UI.