systemd로 Airflow 실행하기

systemd로 Airflow 실행하기 (Running Airflow with systemd)

systemd 기반 시스템과 Airflow를 통합해 데몬을 관리하는 방법을 설명하는 문서예요. systemd가 실패 시 데몬을 재시작해 주므로 감시가 쉬워져요. Airflow 3.0 이후 분리된 서비스들의 unit 파일과 필수 서비스에 대해 살펴볼게요.

출처: 문서

본문

Airflow는 systemd 기반 시스템과 통합할 수 있어요. systemd가 실패 시 데몬을 재시작해 주므로 데몬 감시가 쉬워져요.

scripts/systemd 디렉토리에는 Redhat 기반 시스템에서 테스트된 unit 파일이 있어요. 이 파일들은 /usr/lib/systemd/system으로 복사해 그대로 사용할 수 있어요.

최신 systemd unit 파일은 GitHub에서 찾을 수 있어요: https://github.com/apache/airflow/tree/main/scripts/systemd

가정 (Assumptions)

이 unit 파일들을 만들 때 다음 가정을 했어요:

Airflow가 user:group airflow:airflow로 실행된다.
Airflow가 Redhat 기반 시스템에서 실행된다.

이 경우가 아니라면 적절한 변경이 필요해요.

환경 구성 (Environment Configuration)

환경 구성은 /etc/sysconfig/airflow에서 가져온다는 점을 참고하세요.

scripts/systemd 안에 예시 파일이 제공돼요. AIRFLOW_HOME이나 AIRFLOW_CONFIG에서도 구성을 정의할 수 있어요.

가상 환경 사용하기 (Using Virtual Environments)

참고 (Note)

Airflow가 가상 환경(예: venv 또는 conda)에 설치되어 있다면, 각 systemd unit 파일의 ExecStart 줄을 업데이트해 먼저 virtualenv를 활성화해야 해요.

예시:

ExecStart=/bin/bash -c 'source /home/airflow/airflow_venv/bin/activate && airflow scheduler'

/home/airflow/airflow_venv/ 부분을 자신의 가상 환경 경로로 바꾸세요.

Airflow 3.0의 새로운 서비스들 (New Airflow 3.0 Services)

Apache Airflow 3.0부터 추가 컴포넌트들이 별도 서비스로 분리됐어요. 다음 새 unit 파일을 사용할 수 있어요:

airflow-dag-processor.service: Dag 파일 파싱용
airflow-triggerer.service: deferrable 태스크 트리거링용
airflow-api.service: 독립 REST API 서버용

필수 서비스 (Required services)

최소한 scheduler와 dag-processor와 api-server를 실행해야 해요:

airflow-scheduler.service
airflow-dag-processor.service
airflow-api.service

Dag processor가 실행되지 않으면 Dag 파일이 파싱되지 않아요.

airflow-triggerer.service는 deferrable 태스크나 이벤트 기반 triggers를 사용하지 않는다면 선택 사항이에요.

dag_processor와 triggerer 둘 다, 해당 job 레코드가 존재하지 않으면 /api/v2/monitor/health 엔드포인트는 status와 latest heartbeat에 null을 반환해요. job 레코드가 존재하지만 job이 더 이상 살아있지 않으면 status는 unhealthy예요. 배포가 의도적으로 triggerer를 사용하지 않는 경우에만 triggerer health 상태를 무시할 수 있어요.

각 컴포넌트가 health를 어떻게 보고하는지에 대한 자세한 내용은 Checking Airflow Health Status를 참고하세요.

systemd로 Airflow 실행하기