안녕하세요 오토피디아 데이터 엔지니어 김건우입니다.오토피디아에서는 여러 배치 작업에 Airflow를 사용하고 있습니다. 서비스가 많아지고 요구사항이 늘어나면서 Airflow의 DAG가 점차 늘어났는데요. 그러다보니 초반에 사용하던 방식 그대로 Airflow를 활용하면 불편한 부분이 생겨났고 이러한 변화에 따라 Airflow 사용 환경을 개선할 필요성이 굳어졌습니다.이번 글에서는 기존에 오토피디아에서 Airflow를 사용하던 방식과 이를 사용하면서 겪은 문제들을 어떻게 해결하였는지 공유드리려고 합니다.지금까지 Airflow를 운영하면서 겪은 여러 불편함이 있었는데요. 모든 문제를 한 번에 해결할 수는 없기 때문에 일단 가장 시급한 문제들부터 우선순위를 매겨 해결하려 하였습니다. 제가 정의한 문제는 총 4가지로 아래와 같습니다.• DAG의 로컬 테스트가 안됨• 수 많은 secret들이 github에 존재함• Airflow 사용에 대한 공통 사용 가이드가 없음• 다른 on-premise 리소스들은 대부분 ArgoCD로 관리되고 있는데 Airflow만 아닌 상황이번 글에서는 1, 2, 4번 문제에 대해 자세히 알아보고 어떤 식으로 해결하였는지를 공유드리려고 합니다.가장 해결이 필요하다고 생각한 것은 DAG 로컬 테스트입니다. 오토피디아에서는 Airflow를 dev, prod로 환경을 구분하여 사용하고 있습니다. 각 환경은 별도의 Airflow 깃허브 브랜치로 관리되고 있고, git-sync를 통해 해당 브랜치에 코드를 merge하면 10초 간격으로 Airflow와 싱크됩니다.지금까지는 새로운 DAG를 만들고 테스트를 하기 위해서는 dev 브랜치에 머지를 하고 dev 환경에서 추가한 DAG를 실행하며 테스트해야 했습니다. 이렇게 되면 2가지 큰 불편함이 존재했습니다.• DAG 테스트를 위해서는 테스트를 할 때마다 dev 환경에 코드를 머지하고 싱크되기까지(10초) 기다려야 한다.• 만약 dev에 테스트를 하고 있는데 다른 누군가가 dev의 자신의 코드를 prod로 merge 해야한다면 병목이 될 수 있다.따라서 이러한 문제들을 해결하기 위해서 로컬에서 prod, dev와 동일한 환경으로 DAG를 테스트할 수 있도록 하여 최대한 위와 같은 비효율을 줄이는 것이 필요했습니다.이제까지는 별도로 secret을 관리하는 방법이 없다보니 만약 필요하다면 secret 파일을 직접 넣거나 하드코딩 하였습니다. 그러다보니 모든 시크릿이 github에 올라가있어 보안적으로도 좋지 않았고, 만약 .gitignore로 secret을 제외하면 다른 누군가가 해당 DAG를 수정할 때 불편함을 겪기도 하였습니다.이전까지는 이러한 문제를 해결할 방안이 없었기 때문에 어려움을 겪었지만 사내에 Vault를 도입하면서 모든 중요 secret들을 중앙에서 관리할 수 있게되며 문제를 조금 더 쉽게 해결할 수 있게 되었습니다.오토피디아에서는 대부분의 쿠버네티스 서비스들을 ArgoCD를 통해 배포하고 있습니다. ArgoCD를 이용하면 굉장히 편리하게 쿠버네티스에 어플리케이션을 배포할 수