AWS MWAA에서 시작된 Managed Service에 대한 단상

Amazon Managed Workflow for Apache Airflow (MWAA)

 

Amazon Managed Workflow for Apache Airflow (MWAA) 때문에 일주일 넘게 고생했다. 여러 가지 문제가 있었는데 여기 정리하고 매니지 서비스에 대해 다시 생각해보고자 한다

우선 MWAA를 개발/운영 환경에서 쓰고 있었다. 인프라는 전부 테라폼으로 구축됐고 DAG은 GitHub Actions에 의해 배포된다. 즉, 사람의 실수로 뭔가 갑자기 이상 증세를 보이는 게 쉬운 구조는 아니다. 

1.
개발 쪽 MWAA에 자원이 부족해서 워커 인스턴스 개수를 늘리기 위해 다시 배포했는데 업데이트가 실패했다. environment를 배포한 건 꽤 오랜만이지만 특별히 문제가 될 건 없어 보였다. 단순히 인스턴스 개수 숫자만 바꾼 거니까. 

2.
원인을 알 수 없었기에 Case를 열고(cloud vendor에 공식으로 문의 보내는 프로세스를 의미) 몇 번 메시지를 주고받아보니 requirements.txt에 --constraint를 명시해 주란다. 놀랍게도 그렇게 하니 문제가 해결 됐다. 일단 좀 찜찜하긴 했지만 그냥 넘어갔다. 찜찜했던 이유는 어찌 되었든 불필요한 library까지 몽땅 다 설치하는 게 되기 때문이다. 스케줄러가 그걸 설치하는 시간도 무시하지 못하고. 아무튼, 각설하고 운영 환경에도 requirements.txt를 통일해 주기 위해 반영했다. 아시는 분은 아시겠지만 requirements.txt를 적용하려면 environment를 업데이트해야 한다. 

3.
운영 업데이트를 하고 나니 S3에 있는 DAG이 최신 버전으로 당겨와지지 않았다. 이것 때문에 다시 Case를 열었다. 다시 몇 번의 메시지를 또 주고받았다. 요청하는 정보를 모두 제공했지만 뚜렷한 문제를 발견하지 못했다. 꽤 시간을 허비했기 때문에 케이스를 응대하는 담당자에게 인터널 팀으로 에스컬레이션을 요청했다. 

4.
긴 시간이 지나서 최종 답변을 받았는데 airflow 데이터베이스 버전이 꼬였단다. 해결책은 environment를 삭제하고 다시 생성하란다. 즉, MWAA를 재생성하라는 것. 재생성이야 테라폼으로 그냥 삭제/생성해 주면 되긴 하지만 사실 이것도 각각 20분 이상씩 걸리는 작업이다. 더욱이 airflow에 connection 정보는 export도 안 돼서 다시 한 땀 한 땀 세팅해줘야 하고. ( 다운타임에 민감한 DAG이 돌고 있었다면 새로운 환경을 띄우고 스무스하게 넘기는 노고도 필요했을 거다 )

5.
짜증은 조금 났지만 재생성을 끝내고 평화가 찾아왔다. 하지만 이제 시작이다. airflow를 매니지드로 사용하는 게 맞을지 계속 고민이 된다. 그전에는 Airflow를 EC2에서 운영했고, Kubernetes로 운영을 위해 테스트도 꽤 진행했었다. 결론적으로는 이것저것 신경 쓰고 싶지 않아서 선택한 매니지드였는데 막상 문제가 생기니 유저가 할 수 있는 게 아무것도 없다. Kubernetes 환경이었다면 디비를 직접 재배포하던지 뭔가 대응했겠는데 말이다. 하물며 EC2였다면 docker-compose로 airflow를 다시 세팅하는데 5분도 안 걸리는 작업이다. 

6.
폭풍 같은 일주일이 지나갔고 남은 건 매니지드에 대한 불신과 아주 고생하며 얻은 경험치. 좋은 경험 했다. 이제 남은 건 airflow 환경을 어디서 운영할지 결정하는 일이다. 기회가 되면 각 환경별로 비교하는 글을 써볼 수도 있겠다.