HA reference architecture для Airflow 2.10/2.11 LTS

Production-grade Airflow 2.10/2.11 — это не один контейнер, а ~12-15 рабочих процессов, распределённых по 5-7 уровням инфраструктуры. Этот урок — полная reference-архитектура, которую вы можете взять как чертёж и адаптировать под свой scale: от small (50 DAGs) до large (5000+ DAGs).

В Airflow 2.x четыре главных компонента имеют HA-семантику: scheduler (HA через row-level locks в slot_pool — модуль 04), triggerer (HA через task_instance.next_method assignment), webserver (stateless — масштабируется горизонтально), DAG processor (опционально standalone в 2.x, mandatory в 3.x — AIP-66). Метаданные живут в одной PostgreSQL — она и есть основная точка отказа, потому её защищаем через Multi-AZ и read-only replica.

Полная reference-схема

Sizing per deployment scale

Конкретные числа для трёх типичных scale categories. Эти значения проверены на реальных deployments и могут служить starting point.

Multi-AZ deployment topology

Распределение компонентов по zones для отказоустойчивости:

AZ-1 (us-east-1a)              AZ-2 (us-east-1b)              AZ-3 (us-east-1c)
├── Webserver-1                 ├── Webserver-2                 ├── Webserver-3 (optional)
├── Scheduler-1                 ├── Scheduler-2                 ├── DAG Processor-2 (optional)
├── DAG Processor-1             ├── Triggerer-2                 ├── Celery worker pool C
├── Triggerer-1                 ├── Celery worker pool B
├── Celery worker pool A        ├── Redis replica 2
├── PgBouncer-1                 ├── PgBouncer-2
├── Redis primary               ├── RDS Postgres standby (sync)
└── RDS Postgres primary        └── Redis replica 1

Rule of thumb: каждый critical component (scheduler, triggerer, webserver) должен иметь хотя бы одну replica в другой AZ. DAG processor можно держать в одной AZ — при его краткой недоступности DAGs продолжают работать на уже serialized state.

Что именно даёт HA каждый компонент

Network policies и subnet segmentation

Production setup разделяет компоненты по subnets:

Worker-subnet отделён, потому что workers выполняют user code — это самый уязвимый компонент. Если worker compromise — у него нет direct access к DB, только через app-subnet или через REST API.

Production gotchas

Сloudflare/CDN перед webserver — анти-паттерн. Airflow Web UI делает heavy WebSocket polling для realtime graph view. CDN добавляет latency и проявляется в зависании UI. Используйте plain ALB/NLB с TLS termination.

Не запускайте scheduler и webserver в одном Pod. Они конкурируют за CPU и память. При spike нагрузки на UI webserver-у нужны ресурсы, но scheduler важнее — он определяет throughput всего кластера.

PgBouncer transaction mode ломает SET LOCAL и prepared statements. Airflow поддерживает это с 2.7+ (SQLAlchemy hint), но если используете custom plugins с raw psycopg2 — проверьте. Альтернатива: session mode pool (но эффективность ниже).

Health check для scheduler — не просто process alive. Используйте airflow jobs check --job-type SchedulerJob --hostname $HOSTNAME --limit 5 — он смотрит на latest_heartbeat в job table. Просто kill -0 показывает живой процесс, но не работающий scheduler.

Triggerer всегда нужен, даже если deferrable не используются. В 2.6+ некоторые built-in sensors переписаны deferrable (DateTimeSensorAsync, TimeDeltaSensorAsync) — без triggerer они падают. Min 1 triggerer mandatory.

Что мы рассмотрим дальше