[airflow] ml pipeline 및 웹 서버 자동화에 대한 고민

전반적인 프로젝트 리뷰

우리는 ugatit 모델을 활용해서 개나 고양이 이미지를 이모티콘으로 바꾸는 웹 서비스를 진행했었다.

프로젝트에서 모델 학습부터 웹서버를 빌드하는 과정은 매우 길고 계속해서 지켜봐야 했는데(2~3일 학습 docker compose 통해 빌드 1시간) 여기서 여러가지 문제점이 발생했었다.

• 중간에 학습이 끊긴 경우 알기 힘들다.
• 학습이 언제 끊나는지 알 수가 없어서 끝나면 바로 빌드를 할 수가 없다.
• 빌드가 30분간 지속이 되는데, 해당 시간 동안 업무 공백이 발생한다.

위의 문제점을 보완하기 위해 학습 및 빌드 프로세스를 자동화하여 및 에러 발생시 슬렉에 로그를 날려주면 디버깅 및 효율적인 시간 분배를 할 수 있다고 판단했다. 때문에 airflow를 도입하여 해당 워크 플로우를 자동화 하려고 했다.

프로젝트는 아래 링크에서 확인이 가능하다.

https://github.com/kdt-programmers-b6/MeowBowWow2emoji

해결 방법 모색

하나의 싱글 머신에서 위의 프로세스를 해결하기 위해서는 2가지 방안이 존재한다.

1. docker compose 활용하여 컨테이너로 띄우기

2. local 환경에서 airflow 세팅하여 자동화

1번 방법 선택 이유와 구현 방법

선택이유

로컬에서 환경을 구축하는 것은 굉장히 비효율적이다. 구체적으로 우리는 다양한 환경이 존재하고 그 환경에 맞게 구축해야하는데 그러한 과정에서 발생하는 트러블 및 트러블 슈팅 비용은 정말 말도 안되게 비싸다. 우리는 시간 빌게이츠가 아니다.

도커를 통해 컨테이너를 이용하면 빠르게 위의 과정을 압축할 수 있다.

구현 방법

해당 방법으로 접근하기 위해 아래의 계획을 세웠다.

• 도커 컴포즈를 활용하여 airflow 환경을 세팅
• 도커 오퍼레이터를 활용해 tensorflow 1.14 image를 바탕으로 ugatit 모델 학습
• 백엔드 서버로 체크포인트 넘기기
• 도커 오퍼레이터로 각기 다른 이미지들을 바탕으로 웹 서버 구현

위의 프로세스는 이미 도커 파일들이 잘 구성되어 있고 해당 도커 컴포즈 파일을 기반으로 오퍼레이터를 페러렐하게 구현하면 된다고 생각했다.

1번 방법 실패 요인

• 메모리 부족
  airflow는 4~6의 메모리를 먹는 어플리케이션이다.
  모델 학습 및 다양한 컨테이너를 동시에 운용하기에 너무 많은 메모리 소모로 내 사정으로는 어려웠다.

• airflow 도커 컴포즈 불가
  해당 부분을 airflow에서 지원해주지 않는다. 이러한 상황으로 모두 dockeroperator를 활용해서 세팅해야 하는데 해당 부분에 대한 reference가 존재하지 않았다. 위의 레퍼런스가 없는 이유는 kubernetes 라는 녀석 강력한 녀석이 존재하기 때문에 굳이 사용할 필요가 없기 때문이다.

• 공간 복잡도 증가 및 다양한 컨테이너 통제의 어려움
  해당 워크플로우를 작동시키기 위해서는 적어도 10개의 컨테이너가 동시에 동작해야 한다. 실행시킨다고 하더라도 내부에서는 디버깅을 각기 진행시켜줘야 한다. 도커에서는 다양한 컨테이너 상태를 살피기에는 적절치않았다.

1번 방법의 해결 방법

1. 메모리 부족 문제: 그냥 진짜 렘을 늘리면 된다. 그러나 비용적 측면애서 기각

2. docker in docker 를 활용해서 소켓을 이어 붙여주거나 privilage 를 사용하면 된다.

https://shisho.dev/blog/posts/docker-in-docker/

3. k8s를 도입하면 된다.

위의 해결방법으로 해결하지 않는 이유

1번은 정말 비효율적이다. 해당 방법보다는 여러대의 컴퓨터를 이용하는 것이 비용적인 측면에서 저렴하다.

2번으로 진행하는 것은 현실적이다. 이미 다른 CI/CD 툴이 컨테이너에서 동작하는 경우(젠킨스 등) 도커 인 도커를 사용하여 다른 컨테이너를 제어한다.

그러나 보안상의 이슈와 쿠버네티스가 존재하며, 무엇보다 1번의 문제가 해결이 되지 않았다.

3번은 필자가 해당 기술 스택에 대해 무지하다.

결론 및 실패를 공유하며...

도커, airflow 모두 만능은 아니다. 항상 제약 조건이 붙으며 그러한 한계를 느끼며 다른 기술이 발전한다.

위의 실패경험 때문에 쿠버네티스에 대해 공부를 시작했다. 본격적으로 시간과 정신의 방에서 공부할 예정이다.

항상 느끼지만 부족함을 느끼거나, 실패를 경험할 때 그 순간은 무척이나 고통스럽다. 그러나 돌이켜 보면 이 부분은 나아가는 원동력이 된다.

구체적으로, 나도 위의 과정에서 그냥 되겠지 라는 생각으로 진행하는데 메모리가 터지거나, 끊임없는 트러블 슈팅, 기존 코드들에 대한 이해의 부족으로 workflow를 구성하지 못했다. (위의 과정을 한 1주일 박았는데 성과가 없다... 8월달까지 포폴 완성해야하는데... ㅠㅠㅠ)

그러나 위의 과정에서 발생한 트러블 및 기존 기술들에 대한 제약조건 등을 구체적으로 알 수 있었고 부족한 부분을 채우기 위한 양분이 되었다.

이러한 실패 경험을 통해 더욱 정교하게 프로젝트를 설계해야 겠다는 것을 느끼며 이만 총총!