AWS 기술 블로그
우아한형제들의 Data on EKS 중심의 데이터 플랫폼 구축 사례
우아한형제들은 ‘문 앞으로 배달되는 일상의 행복’ 이라는 비전을 실현하기 위해 데이터와 AI를 기반으로 ‘배달의 민족’ 서비스의 사용자 경험을 지속적으로 개선하고 있습니다. 팬데믹 이후 배달시장은 폭발적으로 성장하였고 데이터의 크기 또한 이전과 비교할 수 없을 정도로 증가하였습니다. 기존 데이터 플랫폼은 EC2를 기반으로 하는 EMR과 쿼리 엔진, 데이터 파이프라인 그리고 분석 도구들로 운영되고 있었습니다. EC2 기반의 데이터 플랫폼은 급격하게 늘어나는 데이터와 다양한 데이터 포맷 그리고 분석/AI 등의 새롭게 추가되는 요구사항들을 처리하는 데 비용 증가, 민첩성 부족, 유지 보수의 복잡성 등의 문제를 안고 있었습니다.
치열한 경쟁속에 빠르게 변화하는 시장에 대응할 수 있도록 데이터 플랫폼의 성능과 확장성을 높이고 지속적인 통합/배포(CI/CD) 가 수월한 컨테이너 기반 환경으로의 전환을 고려해야만 했습니다. 우아한형제들은 Amazon EKS 기반의 Data on EKS로 데이터 플랫폼을 재구축하며 확장성과 자원 최적화를 이루고, 데이터 처리, 분석, AI 워크로드를 유연하게 지원할 수 있는 환경을 마련했습니다.
전체 아키텍처 개요
우아한형제들의 Data on EKS 기반 데이터 플랫폼은 구성은 다음과 같습니다.
- Amazon EKS: 데이터 플랫폼의 코어 역할을 수행하며, 다양한 에코 시스템(Karpenter, KEDA, ArgoCD 등)들을 활용하여 강력한 확장성과 운영 편의성을 제공합니다. 다양한 워크로드를 하나의 EKS 클러스터에서 관리할 수 있기 때문에 운영의 이점을 얻을 수 있습니다.
- Amazon EKS Anywhere: : EKS를 온프레미스 환경에 설치하기 위한 배포판입니다. 오픈소스이며 제공되는 운영도구에서 손쉽게 쿠버네티스 클러스터를 구축 및 운영할 수 있습니다. 특히 AWS의 IAM Role을 연동할 수 있어 클라우드/온프레미스 모두 일관된 권한 정책을 사용할 수 있습니다. IDC내 GPU 서버들에 컨테이너 워크로드들을 제출하기 위해 EKS Anywhere 클러스터를 구축하였습니다.
- Amazon EMR on EKS: Amazon EMR 워크로드를 EKS 클러스터에서 처리함으로써 Spark 및 Flink와 같은 데이터 처리 작업을 유연하게 운영할 수 있도록 지원합니다. EMR on EKS는 EMR on EC2 대비 더욱더 민첩한 스케일 인/아웃을 제공하며, YARN보다 더 강력한 워크로드 격리가 가능합니다. 또한 Apache Yunikorn과 같은 데이터 워크로드에 최적화된 스케줄러와 결합하여 더욱 효과적으로 자원을 활용할 수 있습니다. 이는 비용 개선에도 큰 효과가 있습니다.
- 그 외 플랫폼 구성 요소: 데이터 파이프라인을 빌드하기 위한 Airflow, 쿼리 기반의 데이터 조회 및 처리를 위한 Trino 와 Trino의 권한 관리를 위한 Ranger, 그리고 데이터를 활용하고자 하는 누구나 데이터에 접근할 수 있도록 다양한 분석/BI 도구와 데이터 API 등을 모두 EKS 환경으로 이관하였습니다.
Data on EKS로의 여정
1. Data on EKS를 선택한 이유
기존 EC2 기반의 데이터 플랫폼이 성능적 한계를 보이자, 주요 워크로드를 컨테이너 기반으로 옮기기로 결정하였습니다. 특히 다음과 같은 이점들을 기대하였습니다.
- 유연한 컴퓨팅 자원 활용: EKS에서는 Karpenter를 활용하여 빠르고 유연하게 컴퓨팅 자원을 할당하고 이용할 수 있습니다. Karpenter를 활용하면 다양한 크기와 세대, On-demand/Spot, x86/ARM 인스턴스를 손쉽게 혼용하여 구성할 수 있으며, 이러한 유연성을 통해서 비용 절감 효과도 얻을 수 있습니다. 모든 워크로드가 컨테이너 안에서 동작하는 Data on EKS에서도 Karpenter의 유연한 컴퓨팅 자원 확보 기능을 그대로 활용할 수 있습니다.
- 다양한 워크로드 통합: EKS에서 제공하는 강력한 자원 격리 기능을 사용해 하나의 EKS 클러스터에 다양한 Data on EKS 워크로드를 구성할 수 있습니다. 각각의 워크로드를 위한 별도의 EKS 클러스터를 구성할 필요가 없기 때문에 일관된 인프라 운영이 가능합니다.
2. Data on EKS의 첫 걸음
EKS를 도입하기로 결정하였지만 당시 팀 내 쿠버네티스 운영 경험이 전무하였기 때문에 데이터플랫폼 전체를 이관하기보다는 특정 서비스를 이관하고 거기서 쌓인 역량을 바탕으로 나머지 서비스들도 이관하는 접근 방식을 채택하였습니다.
당시 배달의민족 서비스는 빠른 성장과 사업 확장이 맞물려 데이터가 흘러 넘쳐 들어올 뿐만 아니라 활용에 대한 요구사항 또한 급증하였습니다. 이에 따라서 EC2에서 운영되던 Apache Airflow에 등록된 DAG의 개수가 급증하였고, 기존에 겪지 못했던 운영상의 여러 문제점들이 나타나 Airflow를 EKS 위로 가장 먼저 이전하였습니다.
Airflow의 Worker는 실행되는 DAG의 수에 따라 탄력적으로 운영할 필요가 있습니다. 정기적인 작업이 집중적으로 실행되는 자정 이후 새벽 시간대에는 Worker 수가 Scale-out 되어야 하고, 간헐적인 Ad-hoc 작업이 발생하는 업무시간대에는 Scale-in 되어야 합니다. 이러한 Worker의 요구사항은 Karpenter와 KEDA를 도입하여 충족시켰으며, 이는 비용 개선으로도 이어졌습니다.
Airflow를 위한 Helm Operator도 개발하여 개발 환경도 고도화할 수 있었습니다. Airflow에 등록하기 위한 DAG를 테스트 하기 위해서는 개발환경이 필요하고, Airflow 서비스는 1개의 Git 브랜치를 연동하여 DAG를 등록할 수 있습니다. 이는 여러 사용자들이 DAG를 개발하고 이를 동일한 개발환경의 브랜치에 머지했을 경우 개발환경에서 테스트 중인 다른 DAG에 영향을 줄 수 있게 되고, 사용자들의 문의 증가로 인해 운영 비용이 크게 증가하였습니다.
우아한형제들에서는 이러한 부분들을 쿠버네티스의 패키지 매니저와 Operator가 결합된 Helm Operator사용해 해결할 수 있었습니다. 각 사용자의 개발 브랜치와 연동된 사용자별 Airflow 환경을 배포할 수 있게 하였습니다. 각자의 Airflow 환경이 생김으로써 하나의 개발 환경에서 발생하였던 병합 충돌이 완전 사라졌을 뿐만 아니라 환경을 격리해 패키지 충돌 등의 문제도 해결되며 운영 비용과 편의성이 크게 향상되었습니다.
3. Amazon EMR on EKS의 도입
Airflow를 도입해 EKS 경험을 쌓고 난 후에 본격적으로 데이터 플랫폼을 EKS로 이관하기 시작하였습니다. 특히 EMR의 경우 데이터 플랫폼의 중심으로 전사 서비스의 DB 연동 뿐만 아니라, 분석 마트 생성까지 거의 모든 데이터파이프라인에 사용되는 데이터 처리 엔진입니다. Amazon EMR on EKS 를 도입해 기존의 단점을 보완하고, 데이터 처리 환경의 유연성을 크게 높였습니다. 다음과 같은 이점을 얻을 수 있었습니다.
- 비용 절감: 기존 EC2 인스턴스 기반 운영에서는 워크로드가 없는 경우에도 상시 운영 중인 인스턴스들이 필요하였으며, 고정 비용이 높고 리소스를 과도하게 할당해야 하는 비효율이 발생했습니다. 이를 상시 운영 인스턴스가 불필요한 Amazon EMR on EKS로 전환하여 비용을 절감하였습니다. 또한 Karpenter가 제공하는 빠른 인스턴스 할당 및 유연한 Spot 인스턴스 할당 기능을 통해서도 많은 비용을 절감했습니다.
- 운영 편의성 향상 : EMR on EC2에서는 의존 패키지 구성이 다른 경우 별도의 환경을 구축하거나 별도 클러스터를 워크로드 목적에 따라 추가 생성이 필요하였습니다. EMR on EKS에서는 각기 다른 작업을 제출하기 위해 별도 클러스터를 생성하거나 바이너리 설치가 필요하지 않습니다. Data on EKS 워크로드별로 컨테이너 이미지만 생성해두면 하나의 EKS 클러스터에 다수의 EMR on EKS 워크로드를 동시에 처리할 수 있습니다.
4. 데이터 플랫폼의 완성
Amazon EMR on EKS를 도입한 이후에는 데이터 조회 및 처리를 위한 Trino를 적용하였고, 데이터의 활용성을 높이기 위해서 다양한 분석/BI 도구와 데이터 API 등을 모두 EKS 환경으로 이관하여 데이터 플랫폼을 완성하였습니다.
Data on EKS 개선하기
1. 고급 스케줄링 활용
데이터 워크로드를 위한 Pod의 스케줄링을 최적화하기 위해서 Apache Yunikorn 쿠버네티스 스케줄러를 이용하고 있습니다. Yunikorn에서 제공하는 Bin Packing 수행을 통해서 데이터 로컬리티를 향상시키고, 과도한 인스턴스 프로비저닝을 방지하고 있습니다. 또한 Gang 스케줄링을 통해 연관 작업을 효율적으로 묶어서 실행시켜 안전성을 더욱 향상시켰습니다.
2. CI/CD 기반 컨테이너 이미지 관리
EMR 워크로드용 컨테이너 이미지를 CI/CD 파이프라인으로 관리하고 있습니다. 표준 이미지를 기반으로 각 데이터 애플리케이션 개발자가 필요한 이미지를 CI/CD 파이프 라인을 통해서 활용할 수 있도록, 셀프 서비스 형태로 구성되어 있습니다. 컨테이너 이미지를 통해서 다양한 패키지 의존성을 해결하고, 지속적인 버전 업그레이드를 수행할 수 있게 되었습니다.
3. 통합 모니터링 시스템
Spark 작업 로그 및 메트릭을 프로메테우스로 통합하여 클러스터 모니터링을 간소화하였습니다. 또한 Spark History 서버에서 클러스터의 작업 이력을 관리해, 각 작업에 대한 인사이트를 효율적으로 제공하고 있습니다. Airflow의 태스크 상세화면 UI를 커스텀하여 Spark 작업의 메트릭과 작업 이력 페이지로 이동할 수 있는 링크를 제공하여 사용자들이 손쉽게 작업 상태를 확인할 수 있도록 편의성을 향상시켰습니다.
향후 개선 방향
1. 보안 및 권한 관리 강화
데이터 보안 수준을 높이기 위해 Trino 에 Apache Ranger와 같은 접근 제어 도구를 도입하여 데이터 접근 권한을 세부적으로 관리하고 있습니다. 이와 함께 EMR on EKS는 AWS Lake Formation의 권한 제어 기능을 통해 한층 강화된 데이터 보안을 적용할 예정입니다.
2. 하이브리드 클라우드 도입
IDC에 구축된 Amazon EKS Anywhere와의 더욱 적극적인 연계를 통해 온프레미스 자원과 클라우드 자원을 효율적으로 활용하는 하이브리드 클라우드 환경을 구성하여, 고성능이 요구되는 GPU 작업이나 네트워크를 많이 사용하지 않는 작업들을 온프레미스에서 유연하게 처리할 계획입니다.
결론
우아한형제들은 Data on EKS를 활용하여 기존 데이터 플랫폼의 한계를 극복하고, 비즈니스 민첩성과 운영 효율성을 대폭 향상시켰습니다. 데이터파이프라인 구축, 분석, MLOps 작업이 셀프 서비스화되면서 조직 전반의 데이터 기반 의사결정이 더욱 활성화되었습니다. 앞으로도 컨테이너 기반 플랫폼의 확장을 통해 지속적인 성능 개선과 보안 강화를 추구할 것입니다.