KubernetesPodOperator으로 로컬 k8s에서 airflow 배치작업 만들기

로컬에서 mwaa airflow를 띄워보고 >> https://pearlluck.tistory.com/791

AWS MWAA local runner로 로컬에서 airflow 2.2 사용해보기

로컬에서 쿠버네티스 환경을 구축해봤다.  >> https://pearlluck.tistory.com/794

로컬 환경에서 쿠버네티스 구축하기 (kind, docker-desktop)

 

쿠버네티스 환경에서 동작하는 배치를 로컬 mwaa airflow에서 띄워볼 준비가 된 것이다.

드디어 최종목표(?)였던 KubernetesPodOperator로 배치작업을 만들어볼 것이다.

 

지난글에서도 언급했던 세가지 질문이다. 

 

• 어떻게 쿠버네티스 환경을 만들지? 로컬에서? 
• 어떻게 로컬에서 띄운 mwaa와 쿠버네티스를 연결하지?
• 어떻게 로그와 진행결과를 확인하지? 대시보드가 있으려나? 

이번엔 두번째 질문에 대한 답을 찾아볼 예정이다. 

 

 

결론부터 질문에 대한 답을 말하자면, KubernetesPodOperator를 사용했다. 

기존에는 airflow가 PythonOperator를 사용해서 모델 이미지를 AWS sagemaker로 주

기적으로 학습하게 했다.

이젠 KubernetesPodOperator를 사용해서 모델 이미지를 가지고 직접 쿠버네티스 환경에서 학습하게 해준다. 

KubernetesPodOperator를 통해 직접 정의한 이미지를 사용할 수 있는데, 특히 AWS ECR에 존재하는 이미지를 사용했다. 

---

Airflow 배치작업 : 모델훈련용

airflow는 주로 딥러닝이나 머신러닝을 사용해서 만든 모델을 AWS sagemaker가 주기적으로 훈련시키는 작업을 한다.

요런 배치작업들을 PythonOperator를 사용해서 진행했다. 

어떤 sagemaker 인스턴스를 사용할지, 어떤 작업을 train 시킬지 등 sagmaker관련 config를 직접 (거의 하드코딩) 넣었다.. 

 

그리고 요즘엔 GPU환경에서 모델을 훈련시켜야하는 상황까지 생겼다. 

요런 GPU접속이 별도로 필요한 배치작업들은 SShOperator를 사용해서 진행했다. 

GPU서버로 터널링해서 coda 가상환경으로 접속해 개발한 모델 코드를 실행시키도록 하는것이다. 

 

컨테이너 환경 기반 학습

하지만 쿠버네티스 환경에서 airflow를 사용하기로 했다. 

관련 상황과 내용이 아주 유사해서

작년에 우아한형제들 추천시스템 팀에서 발표햔 우아콘 영상을 참고했다. >> 추천시스템 성장일지 : 데이터엔지니어편

 

영상에서 나왔던것처럼 학습안정성과 실행환경의 문제로 인해 

SShOperator를 사용한 가상환경 기반의 학습환경에서

KubernetesPodOperator를 사용한 컨테이너기반 학습환경으로 개선했다고 한다.

 

아마 기존에 동작하던 배치작업들을 KubernetesPodOperator로 동작할수 있도록 변경할수 있을 것 같다. 

KubernetesPodOperator

사실 쿠버네티스 환경에서 airflow를 사용하는 방법은 여러가지였다.

1.쿠버네티스 위에 직접 Airflow를 구성하거나

2.Kubernetes Executor를 사용하는 방법이다.

2-1. 일반 Operator로 구현해서 KubernetesExecutor를 사용하거나

2-2. KubernetesPodOperator로 구현해서 KubernetesExecutor를 사용할 수 있다.

 

잘 정리 되어있던 라인 엔지니어링 글을 빌리면 위 방법들의 차이점은 아래와 같다. 

 

첫번째 쿠버네티스 위에 직접 Airflow를 구성하는 방법의 경우,

Airflow webserver, scheduler 등 airflow 리소스들이 쿠버네티스 환경에서 단지 그대로 올라간 것 뿐이다.

쿠버네티스가 오케스트레이션을 해주기 때문에 유지보수 및 관리는 수월하지만, 컨테이너 확장성 면에선 단점이 있다. 

 

두번째 Kubernetes Executor를 사용하는 방법의 경우,

그 중에서 일반적인 Operator로 동작할 경우, 
수행해야할 시점에 스케쥴러가 테스크를 찾고, executor가 동적으로 airflow 워커를 Pod 형태로 실행시킨다. 
해당 워커 pod에서 각각 operator가 수행하도록 DAG 코드에 정의한 '테스크'를 수행한다.

반면에 KubernetesPodOperator로 동작할 경우, 
일반적인 Operator처럼 스케쥴러가 테스크를 찾고, executor가 동적으로 airflow 워커를 pod형태로 실행시키는것은 같다.
다만 해당 워커 pod에서 직접 정의한 이미지를 pod 형태로 또 다시 실행하는 것이다. 

그래서 일반적인 Operator로 동작할 경우에는

워커 pod의 정보가 airflow.cfg Kubernetes에 컨테이너 정보와 DAG 볼륨, 로그볼룸 등 지정되어 있다. 

하지만 KubernetesPodOperator로 동작할 경우에는

워커 pod의 정보를 직접 정의한 컨테이너 이미지, namespace, resource, affinity 등 원하는 조건의 Pod를 만들수 있다.

 

KubernetesPodOperator로 만든 배치작업

이제 드디어 KubernetesPodOperator로 배치작업을 하나 만들어보자.

우리는 개발환경으로 구축한 로컬 mwaa airflow환경에서 구성할 것이다.

 

가장 심플하고 간단하게 airflow 공식문서의 example job을 올려보자. 

local mwaa를 사용하는 방법에서 언급한것처럼 example코드를 바탕으로 DAG를 작성하면 된다. 

 

다만 KubernetesPodOperator을 사용하기 위해 apache-airflow[cncf.kubernetes] 패키지를 추가해야한다.

 

그리고 로컬환경에서 띄운 airflow 웹(localhost:8080)으로 접속해서

example_kubernetes_pod DAG를 활성화시킨다.

 

그럼 이렇게 airflow에서 hello-world 이미지가 pod로 띄워진 로그를 확인할 수 있다.

 

그럼 간단하게 KubernetesPodOperator으로 로컬 k8s에서 airflow 배치작업 만들기 완료! 

---

 

실제로 적용하기 위해서는 컨테이너 이미지를 수정하면 된다. 테스트용 이미지가 아니라 모델 훈련용 이미지로 말이다. 

즉 KubernetesPodOperator에 사용하게 될 컨테이너 이미지는

현재 sagemaker에서 모델을 훈련시키기 위해 사용했던 traingImage가 된다. 

 

다만 이 이미지들을 AWS ECR에 저장되어 있다. 

그래서 쿠버네티스 환경에서 pod를 띄울때 추가적으로 private registry인 ECR에서 이미지를 Pull하는 작업이 필요했다..

<< 사실 요걸 깨닫기 위해 무수한 삽질의 연속..이였다.... >> 

 

다음 글에서는 KubernetesPodOperator의 각 파라미터들에 대해서 조금더 파헤쳐볼 예정이다..!