Batch Serving
일정 기간 데이터 수집 후 일괄 학습 및 결과 제공하는 특성이 있음
대량의 데이터 처리할 때 효율적인 방식이다.
Batch Serving은 예측 코드를 주기적으로 실행해서 예측 결과를 제공
Job Scheduler는 Apache Airflow를 주로 사용
Batch Processing과 Batch Serving의 차이
Batch Processing : 일정 기간 동안 일괄적으로 작업을 수행
Batch Serving : 일정 기간동안 일괄적으로 머신러닝 예측 작업을 수행
Batch Processing이 더 큰 개념이며, Batch로 진행하는 작업에 Airflow를 사용할 수 있음
Crontab
airflow 등장전 사용하던 시스템이다.
(서버에서) crontab -e 입력
실행된 에디터에서 0 * * * predict.py 입력(0 * * * 은 매 시 0분을 의미)
OS에 의해 매 시 0분에 predict.py가 실행한다.
Linux는 일반적인 서버 환경이고, Crontab도 기본적으로 설치되어 있기 때문에 매우 간편하다.
Apache Airflow이란?
- Linux Crontab의 문제 존재
재실행 및 알림을 하지 못한다.
과거 실행 이력 및 실행 로그를 보기 어려움
여러 파일을 실행하거나, 복잡한 파이프라인을 만들기 힘들다는 단점이 있다.
airflow는 좀 더 정교한 스케줄링 및 워크플로우 도구이다!!
Airflow 등장 후, 스케줄링 및 워크플로우 도구의 표준이 되었다.
주요 기능
- 파이썬을 사용해 스케줄링 및 파이프라인 작성
- 스케줄링 및 파이프라인 목록을 볼 수 있는 웹 UI 제공
- 특정 조건에 따라 작업을 분기할 수도 있음(Branch 사용)
Airflow의 핵심 기능들
-
DAGs (Directed Acyclic Graphs)
Airflow에서 작업을 정의하는 방법, 작업의 흐름과 순서 정의
DAG은 이름 그대로, 순환하지 않는 방향이 존재하는 그래프를 의미
DAG Directory
DAG 파일들을 저장하는 곳
-
Operator
Airflow의 작업 유형을 나타내는 클래스
Batch Scheduling을 위한 DAG 생성한다.
BashOperator, PythonOperator, SQLOperator 등 다양한 Operator 존재Airflow는 Crontab처럼 단순히 하나의 파일을 실행하는 것이 아닌, 여러 작업의 조합도 가능함
DAG 1개 : 1개의 파이프라인
Task : DAG 내에서 실행할 작업
하나의 DAG에 여러 Task의 조합으로 구성
-
Scheduler
Airflow의 핵심 구성 요소 중 하나. DAGs를 보며 현재 실행해야 하는지 스케줄을 확인
DAGs의 실행을 관리하고 스케줄링 -
Executor
작업이 실행되는 환경
LocalExecutor, CeleryExecutor 등 다양한 Executor가 존재
실습
설치
window 환경에서는 리눅스를 써야할 때 wsl을 사용한다.
(도커나 다른 방법을 사용해도 되지만 기본적인 것부터 배워보자)
- 가상환경 설정
python -m venv .venv
source .venv/bin/activate-
airflow설치(파이썬 버전에 맞게 설치한다.)
-
Airflow에서 사용할 DB 초기화
export AIRFLOW_HOME=`pwd`
echo $AIRFLOW_HOME
airflow db init- airflow 어드민 계정 생성 및 web server, scheduler 실행
# airflow webserver 실행
airflow webserver --port 8080
# airflow scheduler 실행
airflow scheduler- directory 생성 및 DAGs 작성
Airflow DAG 파일은 크게 3가지 파트로 나뉨
- DAG 정의
- Task 정의
- Task에서 사용할 함수가 있다면 정의 (PythonOperator)
- Task 순서 정의(연결)
- py 저장후 webserver로 확인하면 끝!!
실무에서 사용할 때 중요한 인자
catchup
- 과거에 지나간 일자의 DAG을 실행할지를 결정하는 옵션(따라잡다)
True : DAG에서 정의한 start_date부터 현재까지 미실행된 모든 스케줄에 대해 DAG을 실행
과거 데이터를 처리할 필요 있을 때 유용
False : DAG에서 정의한 start_date와 상관없이 앞으로 실행될 DAG을 실행
depends_on_past
- 특정 Task가 이전 DAG 실행 결과에 의존할지 여부 결정
- 이전 Task와 상관없이 작업을 수행하고 싶은지 고민
- 하루 단위의 작업들이 의존성이 있다면 True를 주고 순차적으로 실행
Airflow architecture
Scheduler
Scheduler는 각종 메타 정보의 기록을 담당
Scheduler - Executor
Executor는 스케줄링 기간이 된 DAG을
실행하는 객체. 크게 2종류로 나뉨
- Local Executor
DAG Run을 프로세스 단위로 실행 - Remote Executor
DAG Run을 외부 프로세스로 실행
Workers
DAG의 작업을 수행
Metadata Database
메타 정보를 저장
Webserver
WEB UI를 담당
실무에서 Airflow 구축하는 방법
Airflow를 구축하는 방법으로 보통 3가지 방법을 사용
1) Managed Airflow (GCP Composer, AWS MWAA)
클라우드 서비스 형태로 Airflow를 사용하는 방법
장점
- 설치와 구축을 클릭 몇번으로 클라우드 서비스가 다 진행
- 유저는 DAG 파일을 스토리지(파일 업로드) 형태로 관리
단점
- 높은 비용과 적은 자유도, 클라우드에서 기능을 제공하지 않으면 불가능한 제약이 많음
2) VM + Docker compose
직접 VM 위에서 Docker compose로 Airflow를 배포하는 방법
장점
1. Managed Service 보다는 살짝 복잡하지만, 어려운 난이도는 아님
2. (Docker와 Docker compose에 익숙한 사람이라면 금방 익힐 수 있음)
3. 하나의 VM만을 사용하기 때문에 단순
단점
1. 각 도커 컨테이너 별로 환경이 다르므로, 관리 포인트가 늘어남
2. 특정 컨테이너가 갑자기 죽을 수도 있고, 특정 컨테이너에 라이브러리를 설치했다면, 나머지 컨테이너에도 하나씩 설치해야 함
3) Kubernetes + Helm
Kubernetes 환경에서 Helm 차트로 Airflow를 배포하는 방법
Kubernetes는 여러 개의 VM을 동적으로 운영하는 일종의 분산환경으로, 리소스 사용이 매우 유연한게 대표적인 특징(필요에 따라 VM 수를 알아서 늘려주고 줄여줌)
장점
- 특정 시간에 배치 프로세스를 실행시키는 Airflow와 궁합이 매우 잘 맞음
- Airflow DAG 수가 몇 백개로 늘어나도 노드 오토 스케일링으로 모든 프로세스를 잘 처리할 수 있음
단점
- 하지만 쿠버네티스 자체가 난이도가 있는만큼 구축과 운영이 어려움
보통 데이터 팀에 엔지니어링 팀이 존재하고, 쿠버네티스 환경인 경우에 적극 사용
