회사에서 머신 러닝을 위해 우선적으로 고려했던 방법이 AWS Sagemaker였는데, 효율성이 좋지 않아 물리 서버에서 직접 모델을 돌리게 됐습니다. (Sagemaker가 너무 비쌉니다..너무…)

그래서 s3 -> 물리 서버로 데이터를 이관하는 작업을 진행했고 그 과정을 기록합니다.

1. 아키텍처

사실 아키텍처는 대단할게 없습니다. 제약사항이 많지 않은 ETL이라 AWS glue를 쓰느냐, 아니면 sdk를 사용해 직접 구성하느냐였거든요.

glue는 사용하지 않기로 했습니다. 서버에서 s3에 접근해 데이터를 당겨오는 게 더 합리적이니까요. 그래서 물리 서버에서 docker로 airflow 컨테이너를 띄워서 ETL을 관리하기로 했습니다.

2. docker

물리 서버는 ubuntu 환경입니다. ubuntu 도커 사용기나 팁은 조금만 구글링해보면 좋은 블로그 / 문서가 많기 때문에 굳이 따로 적지는 않겠습니다.

도커 이미지는 이미 많은 분들이 사용하고 계신 purkel docker-airflow를 사용했습니다. Github 링크는 여기

git clone 받은 뒤 이미지 빌드하고 컨테이너만 올리면 바로 airflow를 사용할 수 있습니다. webserver / db 등 airflow에 필요한 설정들이 이미 잘 되어 있습니다. worker나 scheduler, 그 외 필요한 사항들은 환경에 맞게 설정해주면 되겠습니다.

3. airflow

여기서부터 조금 헤맸습니다. 예를 들면 이런겁니다.

No module named 오류입니다. python에서 폴더를 패키지로 인식하지 못해서 생기는 오류인데, pycharm을 사용하는 경우에는 바라보고 있는 폴더를 source root로 바꿔주는 방법도 있고, PYTHONPATH 환경 변수에 해당 폴더의 경로를 넣어주면 보통은 해결되는 문제입니다. python 3.3 이전 버전을 사용하고 있다면 해당 폴더에 __init__.py 파일이 없는게 오류의 원인일수도 있습니다.

그런데 위와 같이 일반적으로 알고 있거나 구글링을 했을 때 나오는 해결방법들이 먹히지 않을 때가 문제가 됩니다.이게 airflow 문제인지, docker 문제인지, 서버 문제인지조차 파악하는 데 너무 오래 걸렸거든요(뭐 하나라도 제대로 아는게 없네요..).

환경 변수에 PYTHONPATH를 추가하자!
그런데, 환경 변수를 물리 서버 .~rc 파일에다가 추가해줘도 읽을 수 있는건가? -> 도커를 잘 모름
그럼 airflow 컨테이너에서 바로 환경 변수를 읽을 수 있도록 해야겠구나!
그런데 webserver, worker, scheduler 다 따로 뭐가 있던데-> 도커도 잘 모르는데 airflow도 잘 모름
아 컨테이너라는 거에 개별적으로 올라가는거구나. 그럼 한 번에 환경변수를 추가하는 방법이 있나?
이미지를 빌드할 때 넣어주면 되겠구나. 그런데 이미지를 빌드할 때는 무슨 파일에서 어떻게 설정해줘야 하는거지?

도커의 간단 사용법 정도만 알고 바로 깔아서 사용하기 시작했기 때문에 정말 많은 삽질을 했습니다. 물론 저는 경력자 팀원분께서 차려놓은 밥상에 숟가락만 얹은 신입이지만.. 그 분도 도커나 airflow에 대해 거의 처음 접하셨기 때문에 함께 만들어갔다고 생각하려 합니다(그래도 역시 짬밥이 무섭더군요).

결론은, Dockerfile에서 환경 변수를 추가해서 문제를 해결했습니다. 문제의 해결방법은 코드 한 줄이었지만, 그 한 줄을 위해 하루의 절반 이상을 날렸었네요.

다음 글에서는 airflow 설정에 대해 조금 더 자세히 적어보고 테스트 실행과정까지 적어보겠습니다.