AWS MWAA 활용하기

요약

AWS MWAA 서비스는 빠르게 작업할 수 있지만 동시에 사용자가 개입할 수 있는 부분이 추상화되어 있어 세밀하게 작동시키기는 힘들다

 

AWS MWAA

AWS MWAA 는 AWS 의 Managed Workflow for Apache Airflow 를 줄인말이다. 한국어로 접한다면 관리형 Apache Airflow 로 볼 수 있다.

 

해당 서비스는 클릭 몇번으로 손쉽게 ETL Orchestration 도구인 에어플로우를 구축 및 작동시킬 수 있다는 큰 장점이 있다. DAG 코드나 플러그인 등록 등 여러 관련된 코드들도 S3 버킷에 저장을 하여 불러와 사용할 수 있는데 이 또한 쉽게 구축할 수 있는 이유 중 하나이기도 하다.

 

AWS 에서 제공하는 서비스이기 때문에 다른 서비스들과의 연계성도 매우 뛰어나다. 기본적으로 AWS 관련 Operator 들이 설치가 되어 있으며 다른 서비스를 사용할 때 인증을 별도의 AWS 정책을 활용해서 권한을 부여받는다. IAM 계정이나 실질 유저가 아니기 때문에 정책을 활용한 방식은 별도의 계정 관리 없이 진행할 수 있다는 의미이기도 하다.

 

MWAA Architecture

https://docs.aws.amazon.com/mwaa/latest/userguide/what-is-mwaa.html#architecture-mwaa

위 아키텍쳐를 보면 MWAA 는 사실상 2개의 VPC 상에서 돌아간다. 하나는 AWS 측에서 관리하는 서비스 VPC 이고 다른 하나는 실제 사용자가 관여하는 고객용 VPC 이다.

 

AWS 에서는 Elastic Container Service (ECS) 라는 서비스와 AWS Fargate 를 뒷단에서 활용한다. AWS ECS 는 간단히 말해서 EKS 와 비슷한 Container Orchestration 도구이며 실제로 AWS 가 많이 밀고 있는 서비스 중 하나이다. 이와 마찬가지로 AWS Fargate 는 AWS 의 EC2 와 비슷한 Compute Service 이다.

 

참고로 AWS EKS, AWS ECS, AWS Fargate 서비스를 비교 및 설명해주는 문서도 참고해보면 도움이 된다.

https://www.cloudzero.com/blog/ecs-vs-eks

AWS ECS Vs. EKS Vs. Fargate: Which One Should You Use?

 

 

S3 를 사용한 코드 관리

여기에서는 중요한 부분은 사실 S3 이다.

 

물론 나머지 부분도 다 이해하면 좋지만 애초에 해당 서비스는 '관리형' 이기 때문에 나머지는 신경 안 써도 크게 문제가 되지는 않는다.

 

에어플로우를 실행할 때 가장 핵심이 되는 것은 DAG 파일들이다. 그리고 더 나아가자면 DAG 를 도와주는 Operator, Plugin 등이 있다. MWAA 에서는 이러한 코드 부분들과 파이썬 패키지 등을 전부 S3 에 저장하고 여기에서부터 배포를 하게 된다.

 

이러한 방식은 S3 의 버전 관리와 연계해서 사용하면 더 편리하다. 그 이유는 MWAA 에서는 혹시나 배포가 실패할 경우 마지막 성공한 버전으로 다시 롤백을 하기 때문이다. 그렇기 때문에 버전이 관리가 되면 MWAA 에서도 버전을 통해서 관리가 될 수 있다.

 

S3 에 DAG, Plugin, requirement.txt 등등을 저장하게 되면 다음과 같은 구조로 변하게 된다.

 

배포된 MWAA S3 버킷

 

보면 총 5개의 폴더가 있다:

• scripts
• requirements
• plugins
• data
• dags

물론 MWAA 를 배포할 때 전부 필요한 것은 아니다. 기본적으로 dags 폴더만 만들어주고 여기에다가 파이썬 코드를 업로드하면 된다.

 

위에 나머지 폴더들은 상황에 따라서 달라지는 경우이다. 해당 버킷에 있는 파일 및 폴더들은 작업하는 MWAA 워커나 웹 서버의 '/usr/local/airflow/' 디렉토리로 옮겨진다. 그렇기 때문에 실제로 DAG 를 실행했을 때의 import 경로를 이를 고려해서 작성하면 된다.

 

더 넘어가기 전에 몇가지 참고할 사항을 적자면

• MWAA 는 뒷단에 Fargate 를 통해서 작동하기 때문에 설치되는 플러그인이나 파이썬 패키지가 설치 과정을 10분 넘기면 자동으로 종료가 된다.
• plugins 폴더에는 하나의 'zip' 형식의 파일을 'plugins.zip' 이름으로 압축해서 올려줘야 한다.
• requirements 폴더에는 파이썬의 패키지 요구사항을 정리한 'requirements.txt' 파일이 들어가 있으면 된다.

 

배포

MWAA 의 배포는 어떻게 하는걸까?

 

사실 배포가 가장 쉬우면서도 어려운 부분이다.

 

쉽다는 것은 구축된 MWAA 환경에서 배포에 적용할 plugins.zip, requirements.txt 등을 알맞게 지정해주면 자동으로 업데이트하면서 배포가 된다. DAG 는 S3 에 있는 dags 폴더 기준으로 10초마다 갱신을 하기 때문에 별도의 설정이 필요없다.

 

어려운 부분은 한번 관리를 잘못하거나 임의로 수정 및 배포를 하게 된다면 이를 되돌리거나 감지하는 것은 쉽지 않고 S3 로 바로 파일을 올려서 배포하는 경우 (별도의 SCM 없이) 이전 기록을 관리하기 쉽지 않다.

 

신경써야 하는 부분이 따라서 한 두개가 아닌데 이 때 별도의 깃 레포를 만들어서 배포할 MWAA 를 미리 MWAA Local Runner 를 사용해서 확인해보고 CI 툴이나 깃헙 파이프라인 같은 도구들을 써서 S3 에 넣어주도록 만드는 것도 하나의 방안이다.

 

이 때 AWS CLI 로도 MWAA 를 작동시킬 수 있으니 굳이 콘솔에서 매번 피곤하게 관리하지 않아도 되는 부분을 참고하면 좋다.

 

https://docs.aws.amazon.com/cli/latest/reference/mwaa/index.html

mwaa — AWS CLI 1.25.6 Command Reference

 

 

결론

이상 간단하게 MWAA 에 대해서 살펴봤는데 초기에는 편리할 수도 있는 도구이겠지만 사실 더 좋은 대안들은 많다. 이미 오래전부터 출시한 GCP 의 Airflow 서비스나 그냥 쿠버네티스를 직접 띄워 Airflow 를 실행 관리해서 더 세세한 부분을 관리할 수 있다.

 

물론 여전히 작은 규모의 데이터 엔지니어들이나 팀이 있거나 빠르게 관리 포인트를 우회하고자 한다면, DAG 가 그렇게 많지 않다면 고려해볼만한 서비스이다.