403 Forbidden
Your Airflow administrator chose not to expose the configuration, most likely for security reasons.
웹 화면의 Admin → Configuration 은 기본적으로 막혀 있다. airflow.cfg 에 접속 문자열이나 키가 들어 있어 그대로 노출하면 위험하기 때문이다. 열려면 설정을 바꾼다.
[webserver]
expose_config = True
non-sensitive-only 로 두면 민감한 값은 가린 채 나머지만 보여 준다. 운영 환경에서는 이쪽을 권한다.
환경변수로도 지정할 수 있다. 컨테이너 배포에서는 이 방식이 편하다.
AIRFLOW__WEBSERVER__EXPOSE_CONFIG=non-sensitive-only
Helm 차트라면 values.yaml 의 config 블록에 넣는다.
config:
webserver:
expose_config: 'non-sensitive-only'
설정을 바꿨는데도 그대로라면 적용 대상 컴포넌트를 확인한다. 화면을 그리는 프로세스(Airflow 2.x 의 webserver, 3.x 의 api-server)가 그 설정을 읽어야 하며, 파드를 다시 만들어야 반영된다.
설정 화면을 열지 않고도 실제 적용된 값을 확인하는 방법이 있다. 이쪽이 더 확실하다.
airflow config list
airflow config get-value core parallelism
Airflow 의 자원 문제는 대개 "동시에 얼마나 돌릴 것인가" 를 정하는 네 개의 값과 스케줄러의 DAG 파싱 부하에서 나온다.
| 설정 | 범위 | 의미 |
|---|---|---|
core.parallelism |
전체 | 한 Airflow 배포에서 동시에 실행할 태스크 인스턴스 총수 |
core.max_active_tasks_per_dag |
DAG | DAG 하나가 동시에 돌릴 태스크 수 |
core.max_active_runs_per_dag |
DAG | DAG 하나가 동시에 가질 수 있는 실행(run) 수 |
celery.worker_concurrency |
워커 | Celery 워커 하나가 동시에 처리할 태스크 수 |
core.dag_concurrency 는 옛 이름이며 max_active_tasks_per_dag 로 바뀌었다. 옛 이름을 그대로 쓰면 무시되거나 경고가 난다.
특정 자원을 두고 다투는 태스크는 Pool 로 묶어 상한을 둔다. 데이터베이스 접속이나 외부 API 호출처럼 동시 실행 수를 제한해야 하는 작업에 쓴다. 전체 값을 낮추는 것보다 영향 범위가 좁다.
태스크 간 우선순위는 priority_weight 로 정한다. 큐가 밀릴 때 어떤 것을 먼저 꺼낼지 정하는 값이다.
스케줄러는 DAG 파일을 주기적으로 다시 읽는다. DAG 수가 많거나 파일 안에서 무거운 작업을 하면 이 파싱이 스케줄러를 붙잡는다.
| 설정 | 기본값 성격 | 조정 방향 |
|---|---|---|
scheduler.min_file_process_interval |
파일 하나를 다시 파싱하는 최소 간격 | 늘리면 파싱 부하가 준다 |
scheduler.dag_dir_list_interval |
DAG 디렉터리 목록을 다시 훑는 간격 | 늘리면 새 DAG 인식이 늦어진다 |
scheduler.parsing_processes |
파싱에 쓰는 프로세스 수 | CPU 여유가 있으면 늘린다 |
DAG 파일 최상위(모듈 수준)에서 데이터베이스 조회나 API 호출을 하면 그것이 파싱마다 실행된다. 스케줄러가 느려지는 가장 흔한 원인이다. 그런 작업은 태스크 안으로 옮긴다.
| Executor | 성격 |
|---|---|
| LocalExecutor | 스케줄러 프로세스 안에서 실행. 단순하고 작은 규모에 적합 |
| CeleryExecutor | 워커 풀이 상시 대기. 태스크 시작이 빠르고, 워커가 놀아도 자원을 점유한다 |
| KubernetesExecutor | 태스크마다 파드를 만든다. 평소 자원 점유가 없고 작업별 자원 지정이 자유롭다. 파드 생성 지연이 있다 |
짧은 태스크가 자주 도는 워크로드에는 Celery 가, 무겁고 드물게 도는 작업에는 Kubernetes 가 유리하다. 둘을 함께 쓰는 구성도 가능하다.
메타데이터 데이터베이스는 외부의 PostgreSQL 을 쓰고, 접속 수가 많으면 PgBouncer 를 둔다. Helm 차트에는 PgBouncer 가 포함돼 있다. SQLite 는 시험용이며 동시 실행을 지원하지 않는다.
차트 값에서 조정하는 주요 항목은 다음과 같다. 항목 이름은 차트 버전에 따라 달라지므로 helm show values 로 실제 값을 확인한다.
helm repo add apache-airflow https://airflow.apache.org
helm show values apache-airflow/airflow > values-default.yaml
| 영역 | 확인할 것 |
|---|---|
executor |
위 선택에 따라 |
scheduler.replicas · 자원 요청/한계 |
스케줄러는 2 개까지 두어 가용성을 확보할 수 있다 |
workers.replicas · workers.persistence |
Celery 를 쓸 때 |
| 메타데이터 DB | 차트 내장 PostgreSQL 은 시험용. 운영은 외부 DB |
pgbouncer.enabled |
접속 수가 많으면 켠다 |
dags.gitSync |
DAG 전달 방식 |
| 로그 | 파드가 사라지면 로그도 사라진다. PVC 또는 원격 로깅을 둔다 |
config |
위의 parallelism 등 설정을 여기에 넣는다 |
Airflow 3.x 에서는 webserver 자리에 apiServer 가 온다. 2.x 기준 예제를 그대로 옮기면 값이 적용되지 않으므로 차트 버전을 먼저 확인한다.