Topik ini menguraikan arsitektur Apache Airflow 3.x beserta alur informasi antar komponennya. Pembahasan mencakup scheduler, dag processor, executor, worker, triggerer, basis data metadata, serta API server yang menyajikan antarmuka web. Setelah membacanya, peran setiap komponen dan perjalanan sebuah task dari berkas DAG sampai log dapat dijelaskan secara berurutan.
Gambaran komponen#
Airflow tersusun atas beberapa proses yang saling melengkapi dan bertukar informasi melalui satu basis data. Pada pemasangan paling kecil, sebagian komponen berjalan di dalam proses yang sama, sedangkan pemasangan besar memisahkannya ke banyak mesin. Diagram berikut memperlihatkan komponen Airflow 3.x beserta arah alurnya.
Secara garis besar, alur informasinya bergerak seperti berikut. Dag processor membaca berkas DAG lalu menuliskan definisinya ke basis data metadata. Scheduler membaca definisi dan status tersebut, memicu dag run sesuai jadwal, lalu menyerahkan task yang dependensinya sudah lengkap kepada executor, yaitu komponen yang mengatur cara task dijalankan. Worker, yaitu proses yang mengeksekusi task, kemudian menulis log dan melaporkan status kembali melalui API server.
Sementara itu, peramban web berkomunikasi dengan API server untuk mengakses antarmuka web (UI) dan REST API. Setiap kotak pada diagram dibahas pada bagian berikutnya.
Scheduler dan dag processor#
Scheduler adalah proses jangka panjang yang mengatur kapan sebuah task dieksekusi. Komponen ini membaca definisi DAG dan status dag run dari basis data metadata, memeriksa jadwal, membuat dag run baru ketika waktunya tiba, lalu menyerahkan task yang dependensinya sudah lengkap kepada executor. Dalam arsitektur 3.x, executor merupakan properti konfigurasi dari scheduler, sehingga berjalan di dalam proses scheduler dan bukan sebagai proses terpisah.
Dag processor adalah proses yang membaca berkas DAG dari sumber yang disebut dag bundle dan menuliskan definisi hasil serialisasi ke basis data metadata. Hasil serialisasi adalah definisi DAG yang sudah dikonversi menjadi bentuk yang dapat disimpan. Pada pemasangan lokal, dag bundle tersebut adalah folder dags di disk. Pemisahan ini membuat proses membaca dan memvalidasi berkas DAG tidak lagi menjadi beban scheduler, sehingga parsing dan penjadwalan dapat diskalakan secara terpisah.
Basis data metadata#
Basis data metadata adalah sumber kebenaran tunggal bagi seluruh komponen. Isinya mencakup definisi DAG hasil serialisasi, status dag run dan task instance, jadwal, konfigurasi kunci-nilai bernama Variables, serta kredensial koneksi bernama Connections. Komponen tidak saling memanggil langsung, melainkan bertukar informasi melalui basis data ini.
Dag processor menulis definisi ke basis data, scheduler membaca definisi dan menulis status melalui basis data yang sama, sedangkan API server membaca dan menulis isinya atas permintaan UI maupun task SDK. Task SDK adalah pustaka yang digunakan task untuk berkomunikasi dengan Airflow. Dengan pola ini, komponen dapat dijalankan pada mesin yang berbeda selama semuanya mengakses basis data yang sama. Untuk pemasangan lokal, SQLite digunakan karena tidak membutuhkan layanan tambahan, sedangkan pemasangan produksi umumnya menggunakan PostgreSQL atau MySQL.
Executor dan worker#
Executor menentukan bagaimana dan di mana task benar-benar dijalankan, dan Airflow menyediakan beberapa pilihan executor bawaan. LocalExecutor menjalankan task pada mesin yang sama dengan scheduler, sehingga cocok untuk pemasangan satu mesin. CeleryExecutor menyerahkan task ke antrean pesan (message queue) seperti Redis atau RabbitMQ agar dapat dikerjakan worker di banyak mesin sekaligus. KubernetesExecutor menjalankan setiap task dalam pod Kubernetes yang dibuat sesuai permintaan. Pod adalah unit terkecil yang dapat dijalankan pada Kubernetes.
Worker adalah proses yang mengeksekusi task yang diterimanya. Setelah task selesai, worker menulis log task sebagai berkas di disk dan melaporkan status akhir task, misalnya success atau failed, melalui API server sesuai mekanisme task SDK. Pada pemasangan paling minimal, pekerjaan task dapat berjalan di dalam proses yang sama dengan scheduler tanpa worker terpisah. Pemisahan worker menjadi penting ketika jumlah DAG dan beban task meningkat, karena kapasitas eksekusi dapat ditingkatkan hanya dengan menambah worker.
Triggerer#
Triggerer adalah proses opsional yang menjalankan task dalam keadaan deferrable, yaitu task yang menunggu peristiwa luar sebelum melanjutkan eksekusinya. Contohnya adalah sensor, yakni task yang menunggu suatu kondisi terpenuhi, misalnya menunggu sebuah berkas muncul di folder arsip atau berlalunya jeda waktu tertentu. Alih-alih membiarkan task menunggu sambil menempati worker, Airflow memindahkan penungguan tersebut ke triggerer. Penungguan itu dijalankan di dalam event loop asyncio, yaitu mekanisme untuk menangani banyak tugas dalam satu proses, sehingga satu triggerer dapat menampung ribuan penungguan sekaligus. Manfaat utama mekanisme ini adalah slot worker tetap bebas untuk task yang benar-benar dieksekusi.
Proses ini dijalankan dengan perintah airflow triggerer sebagaimana komponen lain, dan dapat berbagi mesin dengan scheduler pada pemasangan menengah. Triggerer hanya wajib dijalankan apabila pipeline menggunakan operator deferrable, yaitu komponen siap pakai Airflow yang mendukung cara kerja deferrable. Pada pemasangan kecil yang belum memerlukan sensor deferrable, triggerer dapat dilewati tanpa memengaruhi komponen lain.
API server, UI, dan log#
API server adalah pintu masuk Airflow bagi manusia maupun program. Komponen ini menyajikan REST API dan UI untuk memeriksa, memicu, dan mendebug DAG serta task-nya. Ketika task berjalan, task tersebut melaporkan statusnya kembali melalui API server dengan bantuan task SDK, tanpa perlu akses langsung ke basis data metadata. Pola ini memusatkan akses tulis pada satu komponen dan memudahkan pengamanan basis data.
Di sisi pengguna, peramban web membuka UI yang menampilkan daftar DAG, status dag run, graf dependensi task, dan log task. Log setiap task ditulis oleh worker sebagai berkas pada disk, kemudian ditampilkan kembali di UI ketika sebuah task diklik. Karena semua status tersimpan di basis data metadata, tampilan yang terlihat di UI selalu mencerminkan keadaan terkini yang diketahui Airflow.
Ringkasan#
- Scheduler memicu dag run sesuai jadwal dan menyerahkan task yang siap kepada executor yang berjalan di dalam proses scheduler.
- Dag processor memisahkan parsing berkas DAG dari scheduler dan menulis definisi hasil serialisasi ke basis data metadata.
- Basis data metadata menjadi sumber kebenaran tunggal sehingga komponen dapat dijalankan terpisah, sedangkan worker menjalankan task dan menulis lognya.
- Triggerer menangani task deferrable agar slot worker tidak terkunci oleh penungguan, sedangkan API server menyajikan UI dan REST API sekaligus menerima status task dari task SDK.
Referensi#
- Architecture Overview — Dokumentasi Apache Airflow — Mendaftar komponen wajib dan opsional Airflow beserta peran masing-masing.
- Scheduler — Dokumentasi Apache Airflow — Menjelaskan perilaku scheduler dalam memicu dag run dan task.
- Executor — Dokumentasi Apache Airflow — Mengenalkan pilihan executor bawaan dan perannya dalam menjalankan task.
- UI Overview — Dokumentasi Apache Airflow — Memetakan halaman-halaman antarmuka web Airflow 3.x.