0. INTRO
회사에서는 현재 ETL 작업을 위해 EMR 클러스터 두 개를 사용하고 있다. 하나는 개발 클러스터로 직원들이 spark 환경이 갖춰진 jupyter lab에 붙어 주로 작업을 하며 다른 하나는 운영 클러스터로 일단위, 월단위의 spark job이 airflow에서 수시로 던져저 작업이 도는 환경이다.
개발 클러스터는 매일매일 특정 시간에 구축되었다가 종료되는 스케쥴링이 되는 클러스터라 매일 출근하여 작업할때 새로 구축된 신선한 환경에서 깔끔하게 작업이 가능하다. 반면 운영 클러스터의 경우는 낮시간엔 물론이고 새벽에도 돌아가는 작업이 있기 때문에 종료되지 않고 24시간 계속 가동이 되고 있다.
문제는 이렇게 24시간동안 계속 운영되면서 작업이 돌아간지 약 1년 6개월이 지났다는 것이었다. 특별한 관리 없이 그 정도의 시간이 지나자 무한 pending되는 작업들이 1주일에도 몇번씩 나오는 상황이 발생하였다. 정확한 이유는 모르지만 클러스터 내부의 리소스나 캐시 등에 대한 관리가 되질 않아 서버가 자원을 제대로 할당받지 못하는 등의 이유가 아닐까 싶었다. 이유가 어찌되었든 종종 작업이 진행되지 않거나 auto scaling이 잘 되지 않는 문제 등의 이유로 우리는 운영 EMR 환경을 새로 만들어나 아니면 EKS 환경에 구축하여야하는 상황이 되었다.
현재는 임시적으로 새로운 운영 EMR을 구축하여 기존 작업들을 해당 클러스터로 모두 이사를 하였지만 궁극적으로는 'EMR on EKS' 모델로 가는 것이 이상적인 상황이라고 생각한다. 이번 시리즈에서는 'EMR on EKS' 환경 구축을 위해 개인적으로 실습해보았던 내용들을 순서대로 정리해보려한다.
1. EMR on EKS의 장점
1. 컨테이너화와 확장성
🔷EMR on EKS -> EKS에서 EMR을 실행하면 Kubernetes를 사용하여 데이터 ETL 작업을 컨테이너화 시킬 수 있습니다. 이렇게 하면 Kubernetes의 컨테이너 오케스트레이션 기능을 활용하여 EMR 작업을 더 효율적으로 확장할 수 있으며 EKS 노드의 ASG(Auto Scaling Group)를 활용하여 Kubernetes 노드들에 대한 확장도 가능합니다. 따라서 자원을 과다하게 할당하지 않고도 원하는 작업을 수행할 수 있게됩니다.
🔻 독립 EMR 클러스터 -> 전통적인 EMR 클러스터는 EKS만큼의 유연성과 확장성을 제공하지 않습니다. 클러스터 생성 시 인스턴스 유형을 선택하고 클러스터 크기를 수동으로 조절해야 하며, 변동하는 워크로드에 대한 효율적인 관리가 어려울 수 있습니다.
2. 자원 분리와 활용
🔷 EMR on EKS -> Kubernetes환경 위에서 작업이 이뤄지므로 Namespace 및 자원 할당량을 통한 강력한 자원 분리를 구현할 수 있습니다. 이로써 한 작업이 다른 작업과 간섭하지 않도록하며, 리소스 활용률을 향상시킬 수 있습니다.
🔻 독립 EMR 클러스터 -> 독립 EMR 클러스터에서는 자원 분리가 세세하게 이루어지지 않습니다. 클러스터 수준에서 리소스를 할당하므로 리소스 미사용 또는 리소스 간의 경합이 발생할 수 있습니다.
3. 유연성과 호환성
🔷 EMR on EKS -> EKS는 다양한 컨테이너화된 응용 프로그램과 서비스를 지원합니다. 이러한 유연성을 통해 EMR 환경을 다른 컨테이너화된 응용 프로그램과 원활하게 통합하여 호환성을 강화하고 데이터 처리 워크플로를 용이하게할 수 있습니다.
🔻 독립 EMR 클러스터 -> EMR은 다양한 빅 데이터 프레임워크 및 도구와 호환되지만 추가적인 노력 없이 다른 컨테이너화된 응용 프로그램 또는 마이크로 서비스와 쉽게 통합되지 않을 수 있습니다.
4. 비용 효율성
🔷 EMR on EKS -> Kubernetes 기반의 자동 스케일링과 자원 최적화를 통해 언제나 필요한 리소스만 지불하므로 비용을 절약할 수 있습니다. 또한 Worker 노드에 spot 인스턴스를 사용하여 비용을 더 줄일 수도 있습니다.
🔻 독립 EMR 클러스터 -> 클러스터의 크기와 리소스를 수동으로 관리하면 자원 활용이 최적화되지 않고 피크 기간 동안 높은 비용이 발생할 수 있습니다.
5. 생태계 통합
🔷 EMR on EKS -> EKS는 Amazon RDS, Amazon Redshift, AWS Glue와 같은 데이터 처리 및 분석에 일반적으로 사용되는 서비스들과 원활하게 통합되어 향후 더 나은 데이터 분석 생태계를 구축할 수 있습니다.
6. DevOps 및 CI/CD
🔷 EMR on EKS -> Kubernetes와 EKS를 사용하면 Docker-Kubernetes 환경에서 운영되는 현대적인 DevOps 관행을 채택하고 빅데이터 작업에 대한 지속적인 통합 및 지속적인 배포 (CI/CD) 파이프라인을 설정하여 데이터 처리 워크플로의 민첩성과 신뢰성을 향상시킬 수 있습니다.
2. EMR on EKS의 단점
1. 복잡성 및 Learning Curve
🔷 EMR on EKS -> EMR on EKS를 설정하고 관리하는 것은 독립 EMR 클러스터를 시작하는 것보다 훨씬 더 복잡할 수 있습니다. 사용자와 관리자는 EMR 및 Kubernetes/EKS를 모두 능숙하게 사용해야 하며 Kubernetes와 EKS는 컨테이너 오케스트레이션에 대한 더 깊은 이해를 필요로합니다. 이러한 지식은 사용하는 모든 사람에게는 필요하지 않을 수 있어 EMR on EKS 환경에 새로운 사용자가 와서 함께 사용하기에는 진입장벅이 높을 수 있습니다.
🔻 독립 EMR 클러스터 -> AWS의 EMR 클러스터는 초기 구성 및 운영을 간단하게 할 수 있도록 설계되어 있어 기존 데이터 처리 프레임워크에 익숙한 사용자들이 더 쉽게 접근이 가능하고 사용함에 있어 복잡성이 크지 않아 더 쉽게 배우고 사용할 수 있습니다.
2. 자원 오버헤드
🔷 EMR on EKS -> Kubernetes 위에서 EMR을 실행하면 Kubernetes Control Plane과 추가 컨테이너 레이어로 인해 자원 오버헤드가 발생할 수 있습니다. 이로 인해 독립 EMR 클러스터보다 약간 더 높은 자원 소비가 발생할 수 있습니다.
🔻 독립 EMR 클러스터 -> EMR 클러스터는 EC2 인스턴스에서 직접 워크로드를 실행하기 위한 것으로 최적화되어 있어 추가 Kubernetes 레이어 없이 자원 활용이 더 효율적으로 이루어질 수 있습니다.
3. 초기 설정 시간
🔷 EMR on EKS -> EKS 클러스터를 설정하고 작업을 위한 IAM 설정, Node Group 추가 및 ASG 설정 등 운영에 필요한 환경을 모두 구성한 다음 EMR을 배포하는 것은 독립 EMR 클러스터를 시작하는 것보다 더 많은 시간이 소요될 수 있습니다.
🔻 독립 EMR 클러스터 -> EMR 클러스터는 콘솔창에서 몇 번의 클릭 혹은 CLI 명령을 통해 상대적으로 빠르게 생성할 수 있으므로 데이터 처리 환경을 신속하게 배포하기에 적합합니다.
4. 비용 복잡성
🔷 EMR on EKS -> Kubernetes 환경에서 비용 관리는 자원에 대한 세부적인 제어 때문에 더 복잡할 수 있습니다. 사용자는 예상치 못한 비용을 피하기 위해 자원 할당을 철저히 관리해야 합니다.
🔻 독립 EMR 클러스터 -> EMR은 인스턴스 유형 및 클러스터 내 인스턴스 수를 기반으로 한 더 간단한 가격 모델을 제공하여 빌링을 간소화합니다.
3. OUTRO
- 이번 글에서는 EMR on EKS의 도입 배경 및 독립 EMR 클러스터와 비교했을 때 장단점에 대해서 서술해보았습니다. 다음 글에서부터는 본격적인 세팅 및 구성에 관한 이야기를 해보도록 하겠습니다.
