✏️ 오늘 학습한 내용
1. 프로덕션 사용을 위한 Airflow 환경 설정
2. Airflow 로그 파일 삭제
3. Airflow 메타데이터 백업
4. Airflow 대안
🔎 프로덕션 사용을 위한 Airflow 환경 설정
먼저, 어떤 내용을 주의해야할 지 살펴보겠습니다.
airflow.cfg
/var/lib/airflow/airflow.cfg의 관리가 매우 중요합니다.
docker-compose.yaml에서 실행을 할 때는 기본이 되는 airflow.cfg는 Base Image에서 받아오고 그 위에 override하는 형태입니다.
이 airflow.cfg 내에는 굉장히 중요한 section들이 있기 때문에 관리를 잘해주어야합니다.
예를 들어,
[core] 섹션 밑에 dags_folder의 경우 이곳에 지정한 경로에서 DAG가 있는지 확인합니다.
/var/lib/ariflow/dags
Airflow Database upgrade
Airflow의 Database는 기본으로 Sqlite가 설치되어있기 때문에 프로덕션을 위해 다른 DB로 변경을 해줄 필요가 있습니다.
( Sqlite -> Postgres or MySQL )
또한, 이 DB의 정보를 주기적으로 백업해주는 것이 매우 중요합니다.
( 사고가 터졌을 때, variable, connection 등을 빠르게 복구하기 위함 )
이렇게 DB를 변경하는 경우에는
airflow.cfg 내의 [core] 섹션에 있는
sql_alchemy_conn을 변경해주어야합니다.
Enable Authentication
민감한 정보를 많이 가지고 있기 때문에 Airflow Web UI가 밖으로 노출이 되면 해킹의 위험성이 존재합니다.
따라서 가능하면 authentication을 기본으로 켜두는 것이 좋습니다.
( Airflow 2.0부터는 기본으로 ON )
또한, Strong한 password를 사용해야하고
가능하면 VPN 뒤에 위치시켜 외부에서 Access를 하지 못하게 해야합니다.
Airflow를 네트워크에 연결 후 아무 것도 변경하지 않으면 발생할 수 있는 일
->
해커들이 AWS의 모든 EC2 IP를 돌아보면서 8080포트에 ID/PW : airflow/airflow를 입력하기 때문에 중요한 정보가 넘어갈 가능성이 높음
Log 폴더의 용량
DAG의 수가 늘어나고 Task의 수가 늘어나면 지정해둔 Log 폴더가 금방 가득차게 됩니다.
가득차면 Airflow가 Logging을 하지못해 에러가 계속 발생하기 때문에 주기적으로 Log 폴더를 cleanup을 해주는 것이 중요합니다.
- Log 폴더를 지정하는 곳
[core] 섹션 of airflow.cfgbase_log_folderchild_process_log_directory
Scale Up to Scale Out
초기에는 Scale Up으로 버티다가
도저히 안되면 Scale Out으로 Worker 수를 증설
그러나 이 Scalue Out 시점에는 Cloud 도입을 고민하는 것이 좋습니다.
( Airflow의 Cloud option )
- GCP : Cloud Composer
- AWS : MWAA
- Microsoft Azure : Data Factory
or Docker/K8s
쿠버네티스를 사용하는 것이 가장 고도화된 방법이지만 운영 난이도가 높기 때문에 경력이 있는 인력이 없으면 힘들 수 있습니다.
Metadata DB 백업
Airflow의 metadata database를 주기적으로 Backup해줘야합니다.
그 중에서도 가장 중요한 정보들은 variables와 connections
그리고 Fernet key (DB를 암호화한 경우 복호화할 수 있는 Key)
Health-check monitoring
Airflow 서비스가 제대로 돌고 있는지 확인하기 위해서 health-check를 사용합니다.
그 대상은
1. web server
2. scheduler
3. metadata database
이를 사용하기 위해서 API를 먼저 활성화한 후,
Health Check Endpoint API를 모니터링 툴과 연동하는 것이 가장 좋습니다.
https://airflow.apache.org/docs/apache-airflow/stable/logging-monitoring/check-health.html
어느 정도 규모가 된다면 DataDog, Grafana 등을 사용하는 것이 일반적입니다.
( DevOps팀과 협업 )
🔎 Airflow 로그 파일 삭제
Airflow 로그 위치
Airflow는 Log를 두 군데에 기록을 합니다.
airflow.cfg에 등록되어있는
[logging]
base_log_folder = /var/lib/airflow/logs[scheduler]
child_process_log_directory = /var/lib/airflow/logs/schedulerDocker compose
docker compose를 통해 Airflow를 실행하는 경우 logs 폴더가 host volume의 형태로 세팅되어 있습니다.
Container 내의 /opt/airflow/logs에 로그가 저장이 됩니다.
volumes:
- ${AIRFLOW_PROJ_DIR:-.}/dags:/opt/airflow/dags
- ${AIRFLOW_PROJ_DIR:-.}/logs:/opt/airflow/logs🔎 Airflow 메타데이터 백업
메타 데이터의 주기적인 백업
가장 좋은 방법은 Airflow 메타 데이터 DB를 Airflow 밖에서 실행시키는 방법입니다.
RDS와 연동을 하여 RDS에 데이터가 기록이 되게하고 RDS 데이터 자체를 백업하는 프로세스를 만듦으로써 더 안전하게 운영할 수 있습니다.
Docker Container를 통해 Airflow를 돌리는 경우
메타 데이터들이 named_volume으로 persistent하게 유지가 됩니다.
그 폴더 자체를 백업을 하던지,
DAG 자체를 하나 만들어서 메타데이터 DB의 내용을 받아서 Cloud Storage에 저장을 하게끔 주기적으로 백업을 실행하도록 만드는 방법이 있습니다.
🔎 Airflow 대안
Airflow 이외의 다른 데이터 파이프라인 프레임워크
Prefect (Open Source)
Airflow와 상당히 흡사하며 좀 더 경량화된 버전입니다.
강점으로는 데이터 파이프라인을 동적으로 생성하는 것이 쉽다는 것과 가볍다는 점입니다.
Dagster (Open Source)
특징은 단순히 데이터 파이프라인만 관리하는 게아니라 데이터도 관리하는 툴입니다.
상당히 무겁습니다.
Airbyte (Open Source)
코딩을 최소화하는 Low-Code ETL 툴에 가깝습니다.
