[Re2020] AWS Analytics 주요 업데이트 – EMR on EKS 신규 기능 출시
안녕하세요. 김범환입니다.
AWS는 매년 리인벤트 행사쯤에 맞추어 업데이트를 쏟아닙니다. 이번에도 여지없이 많은 업데이트를 쏟아냈는데 전체적으로 살펴보니 IoT, 머신러닝 분야에 해당하는 내용의 업데이트가 많네요. 제 생각엔 아무래도 신생(?)분야여서 새로운 기술들도 많이 나오고 수요도 많다보니 그런것 같습니다.
Analytics 분야에도 업데이트가 꽤 있었습니다만 다른 분야에 비해서는 적은 편입니다. 분야를 Analytics로 한정지으면 어떻게 보면 업데이트가 거의 없어보이지만, computing쪽에서의 대거 업데이트, 그리고 스토리지에서의 대거 업데이트가 있었으니 Analytics쪽은 기초체력?이 좋아졌다고 봐도 될 것 같습니다. 예를들어 EBS의 GP3 타입이 나오면서 전반적으로 스토리지 성능이 좋아지고 가격이 저렴해졌습니다. 또한 S3가 ‘강력한 쓰기 후 읽기 일관성’을 지원하면서 EMRFS에서 Consistent View를 위해 추가적인 비용을 지불하지 않아도 됩니다. EC2의 신규 인스턴스 또한 analytics 분야에 활용할 수 있죠.
그런 기초체력을 바탕으로 Analytics분야에서는 새로운 서비스보다는 현재 있는 서비스의 활용성을 높일 수 있는 기능들을 많이 내놓은 것 같습니다. EMR과 Redshift에 업데이트가 좀 있었는데 Redshift는 소규모 기능 업데이트들이 주를 이뤘고 EMR은 (이번 포스팅에 다룰 내용인) 이제 EKS 클러스터에서 EMR을 돌릴 수 있게 되었습니다.
EMR은 지금까지 Hadoop, Spark 등 대규모 분석을 위한 클러스터를 관리하기 위해 EC2 인스턴스를 직접 활용했습니다. EMR에 클러스터 생성을 요청하면 EMR이 EC2 인스턴스들을 띄우고 거기에 HDFS, Spark 클러스터, Yarn Resource Manager 등 클러스터 관리에 필요한것을 설치하여 제공하는 형식이었죠.
그런데 요즘에는 컨테이너 기술이 주목을 받으면서 Spark, Hadoop 등의 대규모 오픈소스 프로젝트에서도 컨테이너 환경을 도입할 수 있게 지원해주고 있습니다. 클러스터 구성에서 지원하는 리소스매니저에 Kubernetes(k8s)를 지원하여 의존성 관리, 개발–배포 환경의 통일 등 컨테이너 환경의 장점을 빅데이터 분석에도 적용하려는 모습입니다.
이번에 소개드리는 “EMR on EKS”는 이러한 트렌드에 맞추어서 EKS 클러스터에 EMR 클러스터를 배포하여 Spark 엔진 등을 사용하는 Job을 제출할 수 있도록 해주는 기능입니다.
EMR on EKS 를 소개시켜드리기 전에 먼저 Spark on k8s를 살짝 소개해 드리자면… 위의 그림이 spark on k8s의 작동방식을 잘 설명하고 있습니다. spark-submit을 yarn 에다가 하는 것이 아닌 k8s api server에 요청하게 됩니다. 그러면 k8s 클러스터 내에 Spark driver와 executor들이 생성되어 작업을 수행합니다. 기존에 Yarn이 하던 일을 k8s가 수행한다고 생각하면 쉽습니다. k8s의 내장 스케쥴러를 이용할 수 있게 spark에서 업데이트를 해놨습니다.
이렇게 클러스터의 리소스매니저를 k8s로 통일하게 되면 우선 spark 클러스터만을 위해 yarn을 굳이 구성하지 않아도 되어서 클러스터 관리를 일원화 할 수 있습니다. 빅데이터 워크로드 뿐만 아니라 웹서버, 관리용 서버 들도 k8s 상에서 관리하는 상황에서는 관리 포인트를 줄이는 효과가 있겠죠. 또한 컨테이너의 기본적인 장점인 의존성관리 등이 편해질 수 있겠네요.
EMR on EKS 는 위에서 설명드린 spark on k8s 를 기본 컨셉으로 EMR과 EKS가 제공하는 장점을 활용할 수 있게끔 만들어놓은 기능입니다. k8s관리는 EKS에 맡기고, spark의 성능최적화, 모니터링 등은 EMR에 맡겨서 편의성을 제공합니다.
조금 더 자세히 얘기해보겠습니다. EKS는 Control plane을 세 가용영역에 걸쳐 운영하기 때문에 높은 가용성을 보장합니다. 이에 따른 비용은 상대적으로 저렴한 편입니다. 반면 EMR on EC2에서 Multi-Master를 구현하려고 하면 무려 마스터 노드를 세개의 비용을 부담해야합니다. 또한 Fargate를 이용하면 조금 더 유연하게 클러스터를 운영할 수도 있습니다. 기존 EMR에서도 오토스케일링을 지원하지만 태생적으로 VM은 띄우고 클러스터에 조인시키는데에 적지 않은 시간이 필요합니다. Fargate는 VM이 아닌 컨테이너를 띄우는 형식이기 때문에 더 부드러운 스케일링이 가능할 것 같습니다.
또한 EMR은 자체적으로 spark의 성능튜닝(https://aws.amazon.com/ko/blogs/big-data/amazon-emr-introduces-emr-runtime-for-apache-spark/)을 해놓았다고 합니다. 그냥 Spark를 EKS에서 사용하는것에 비해 3배정도의 성능향상이 있다고 하는데 물론 spark의 설정, 워크로드의 특성에 따라 많은 차이가 있을 수 있습니다. 그래도 자체적으로 성능튜닝을 할 여유가 없다면 AWS에서 해놓은 튜닝을 이용해보는 것도 괜찮을 것 같습니다.
그리고 위와 같이 여러 Spark 버전을 사용하는 경우에도 클러스터를 효율적으로 사용 할 수 있습니다. 왼쪽 그림처럼 여러 EMR 버전이나 Spark 버전을 사용하는 경우 각각 클러스터를 따로 생성해야하고 클러스터 마다 각각의 마스터노드들이 생겨나는 오버헤드가 있습니다. EMR on EKS에서는 가상 클러스터를 만들 때 EMR의 버전을 지정하지 않습니다. EMR의 버전을 Job을 제출할때 명시하게 되어있는데 이러한 구조 덕분에 하나의 가상 클러스터에서도 여러가지 버전의 Spark 작업을 제출할 수 있습니다.
EMR on EKS의 장점을 정리해보자면
- EKS가 갖는 장점을 그대로 EMR에 적용이 가능하고 (fargate, 관리형 control plane)
- AWS가 해놓은 성능튜닝
- 여러버전의 Spark를 큰 오버헤드 없이 사용
정도가 될 것 같습니다.
너무 장점만 늘어놓은 것 같은데, 사실 관리적인 측면에서 EMR on EKS 가 제공하는 기능은 아직은 좀 제한적인 것 같습니다. 우선 서울리전에서 사용이 불가능하고, 거의 모든 작업을 CLI를 통해서 해야합니다. Spark History 서버도 자체적으로 제공하는 Persistent UI 가 있지만 아무래도 EMR on EC2 에서 설치되어 제공되던거에 비해서는 반응성이 느립니다. Yarn 을 사용하지 않으니 Resource Manager에서 보던 정보들을 사용하지 못하고 k8s 관리도구를 통해 봐야합니다. k8s 사용에 익숙한 분들에게는 괜찮겠지만 EMR 플랫폼에 익숙한 유저들에게는 불편할 수도 있을것 같습니다.
이만 마치겠습니다.
감사합니다.
최신 댓글