[AWS][EMR] EMR ( Master/Core/Task/AutoScaling/SpotInstance )

EMR은 기존 Hadoop에서의 Computing 부분을 그대로 구현해 놓은 플랫폼이라고 이해하면 된다. (Storage는 HDFS를 사용할수도 있지만, 주로 Object Strorage인 S3과 함께 사용한다.)

Cloud 특성에 맞게 Auto Scaling 도 지원하여 처리량에 따라 Instance를 유동적으로 Scale In/Out을 할 수 있으나, 흔히 떠올리는 Auto Scaling 처럼 바로바로 인스턴스가 할당되고 회수되진 않는다. 회수는 바로 해가지만 할당하는데는 8~20분 정도 걸리는 것 같다. 

 

EMR 내에는 Hadoop, JupyterHub, Hive, Zeppelin, Flink, Spark, Hue 등 다양한 분산처리 및 노트북 환경들을 제공한다. 아래와 같이 내가 필요한 서비스의 버전을 확인하고 EMR 버전을 선택하면 되며, Cloudera에서 제공하듯 체크하는 것으로 서비스들의 설치를 진행할 수 있다. EMR의 지속적인 Version up을 통해 각 컴포넌트들의 업데이트를 지원해주고 있다. 

EMR 설정 화면

 

또한, EKS 기반 EMR  / EC2 기반 EMR을 선택할 수 있으며 현재 글에선 EC2 기반 EMR에 대해서 다룰 예정이다. 

 

 

Structure

Hadoop은 Master - Worker 의 구조라면, EMR은 Master - Core - Task Node 로 구성되어 있다. 

• Master Node : 전반적인 Master성 Application 이 실행되는 노드이다 ( ex.NameNode , ResourceManager, 그외 Hive Server 등 설치하려는 서비스의 Master Process들) 다른 노드들 간의 작업 트래킹 및 리소스 분배를 진행하며 전반적인 클러스터의 상태를 모니터링하고 관리한다. 1개 이상의 노드가 필요하며 여러개의 Master Node를 실행시켜 HA를 지원하기도 한다.
• Core Node : 클러스터의 HDFS(Hadoop Distributed File System)에 작업을 실행하고 데이터를 저장할 수 있는 노드이다. DataNode, NodeManager 가 실행된다고 이해하면 된다. Master 노드에서 관리되며, 1개 이상의 노드가 필요하다. 
• Task Node :  HDFS에 데이터를 저장하지 않고 작업들만 처리하는 노드이다. Nodemanager가 실행된다고 이해하면 된다. 선택사항이며, 꼭 필요한 노드는 아니다.

클러스터를 구성할 때 작업의 성격에 따라 각 Node들에 해당하는 리소스를 적절히 설정하여야 하며 NameNode, ResourceManager를 포함하고 있는 Master Node, Datanode를 포함하고 있는 Core Node는 On-demand로 설정해야 한다. (기술적으로 필수인 것은 아니지만 데이터 유실의 위험성 존재 및 클러스터 안정성을 위함)

 

 

Core / Task Node가 분리되어 있는 이유

기존 하둡의 경우 Master 에 Resource Manager / Namenode가, Worker에 Node Manager / Datanode가 설치되어 있었다.

하지만 EMR에서는 Worker를 Datanode가 있는 Node(Core), 없는 Node(Task)를 분리하여 제공한다. 

때문에 Task 노드를 활용하면 HDFS에 저장을 하지 않는 Spark나 기타 Map Reduce를 사용하는 병렬 프레임워크들을 사용할 때 조금 더 유연하게 사용할 수 있다. DataNode에 대한 부담이 없으므로 정말 Job들을 처리하는 Worker로써 쉽고 빠르게 늘리고 줄일 수 있는 것이다. 기존 하둡과 다르게 데이터 저장을 S3에 하기 때문에 가능한 것이라 보여진다.

 

 

S3를 기존 HDFS를 대체하는 Storage로 쓰는데 여전히  HDFS가 필요한 이유

우선 Hive 처럼 Metastore를 사용하거나 Hue, Oozie 등 여전히 datanode를 필요로 하는 서비스들이 존재한다. 기존과 다르게 HDFS 가 휘발성이지만 (EMR종료시 다 날아가게됨) S3보다 빠른 I/O를 제공하므로, 목적에 따라 영구 저장이 필요 없는대신 빠른 접근이 필요한 경우 HDFS를 임시 저장소로 활용할 수도 있다. 

 

 

Cluster Composition

인스턴스 타입의 구성을 설정할 수 있다.

• Uniform Instance Group : 단일 인스턴스 타입을 사용하여 EMR 구성
• Instance Fleets : 여러 개의 인스턴스 타입을 활용하여 EMR 구성
  - 최대 5개의 타입을 지정할 수 있으며, 이 때 인스턴스 구성은 CPU / Memory  비율이 맞는 타입들 + Spot Instance 사용 시 인스턴스 타입별 회수율을 고려하여 선택한다.

Instance Fleets은 특히나 Spot Instance를 사용할 때 고려하게 되는데, 인스턴스 획득 및 회수에 대한 전략을 위해서도 필요하고 혹시나해당 인스턴스 타입의 장애가 생겼을 시 다른 타입의 인스턴스로 빠르게 획득할 수 있다는 특징이 있다. 

 

이렇게 각 노드 별로 각각의 Instance Fleets 집합을 구성할 수 있으며, 각 Node 당 최대 5개의 타입으로 구성할 수 있다. 각각의 Instance 타입마다 Bidding 가격과 최대 사용 용량 (Unit)을 지정하며, Unit별 On-Deamnd 와 Spot 의 비율도 설정할 수 있다. 

 

 

이 때 보이는 Instance Type의 사양에서 vCore는 EC2의 vCore 가 아니라 Yarn의 vCore개수를 의미하며,  링크 에서 각 인스턴스 타입에 해당하는 Yarn Memory 등 Hadoop Default 설정을 확인할 수 있다. 

 

 

Auto Scailing

Core / Task Node에만 적용할 수 있다.

• Minimum : Core+Task Unit Minimum. 
• Maximum : Core+Task Unit Maximum.
• On-demand Limit (Optional) : Core+Task 의 On-demand Maximum
  : On-demand 와 Spot Instance의 용량 분리에 사용하는 Configuration
• Maximum Core Node (Optional) : Core Unit Maximum 
  : Core 와 Task의 용량 분리에 사용하는 Configuration

Auto Scaling 시 영향을 주는 Yarn / Hdfs metric 들 ( ex. yarn.resourcemanager.nodemanager-graceful-decommission-timeout-secs ) 등은 추후에 따로 정리해보도록 하겠다.

 

 

 

Instance 구입 옵션

다른 AWS 서비스들과 비슷하게 EMR에서도 시간당 EMR 사용 비용 + 시간당 각 Node로 사용하는 EC2의 Instance Type에 따른 비용을 지불한다. 이 때, Purchasing Option이라 하여 On-demand 와 Spot Instance를 선택할 수 있고, Saving Plan(SP) 나 Reserved Instance(RI) 를 통해 비용을 절감할 수 있다.

 

 

 

Purchasing Option

 

1) On-Demand

On-Demand는 시간당 사용한 Computing 용량에 대한 비용을 지불한다. 즉 시간당 사용하는 EC2 비용 그대로를 할인 없이 지불하는 대신 그 누구에게도 뺏기지 않고 안전하게 사용할 수 있다. 때문에 Master나 HDFS를 사용하는 Core Node, 그리고 안정성을 요하는 작업일 때 On-Demand Instance 비율을 높여 Cluster를 구성하게 된다. 

 

2) Spot Instance

Spot instance란 On-demand 요금보다 70~90% 절감된 비용으로 사용할 수 있는 Instance들이다.

 

Bidding 시스템 (절대적인 가격을 입력할수도, On-demand의 몇 %를 Max Bidding 으로 가져갈 것인지 설정할 수 있다.) 이라 유휴 Pool 내에서 내가 Bidding을 높게 했을 때 Spot Instance를 사용할 수 있으며, 반대로 누군가가 나보다 Spot instance를 사용하기 위한 Bidding을 높게 했다면 뺏길 수 있는 시스템이다. 이외에도 Spot Instance를 받아 왔는데 해당 리소스를 충분히 사용하고 있지 않다면 내부 알고리즘에 의해 뺏길 수 있다. 때문에 사람들이 많이 사용하지 않는 시간대에 많이 사용하지 않는 인스턴스 타입을 스팟으로 가져갈 경우 확실히 비용을 절감할 수 있다.

 

다시 정리하면, Spot Instance가 시작되는 경우는 내가 설정한 최고 가격이 Spot Instance 가격보다 높을 때 이다. Spot Instance 가격은 늘 변하기에 언제 어떤 가격일지 알 수 없다. 반대로 내가 설정한 최고 가격보다 Spot Instance 가격이 높으면 Spot Instance는 종료되며 나보다 최고 가격을 더 높게 설정한 누군가에게 뺏기게 된다. 

 

EC2 Spot instance 공식 홈페이지에선 중단 빈도가 5% 미만, Spot Instance Advisor 에서는 모든 리전 및 인스턴스 유형의 평균 중단 빈도는 10% 미만 이라고 하지만 사실 사람들이 많이 사용하는 인스턴스들에 대해서는 중단률이 20% 이상이다.  [링크]

 

 

때문에 Uniform Instance Group 보단, Instance Fleets을 사용하여 인스턴스 타입을 잘 구성해야 하고, 언제든 받고 뺏길 수 잇는 시스템이다 보니 Task 노드 구성에 포함하기엔 좋은 옵션인건 분명하다. (하지만 안정성을 요하는 Master / Core 에는 적합하지 않다)

 

 

Reserved Instance (RI)

1년 혹은 3년 약정을 걸고 특정 Zone에서 사용할 인스턴스들과 사용량을 미리 선결제 함으로서 "예약"을 할 수 잇는 기능을 제공한다.

최대 72% 절약할 수 있다고 안내하는데 찾아보니 확인해보니 3년 전체 선결제 기준, 자주 사용하는 m5인스턴스 기준으로 62%정도의 할인율 가져갈 수 있는 것으로 보인다. 하지만 동일 인스턴스 타입을 변경하거나 Zone을 변경하거나 하는 등의 변경은 불가하며, 동일 인스턴스 타입 패밀리( ex. m5.large -> m5.2xlarge ) 내에서만 변경할 수 있고, 변경 과정도 Saving Plan보다는 조금 귀찮은 편이라 공식 문서에서도 Saving Plan 사용을 추천하고 있다. 장점이라하면, 만약 구매한 예약 인스턴스를 다 팔지 못했을 때 MarketPlace를 통한 재판매를 할 수 있다는 부분이 있다.

 

Saving Plan (SP)

RI 처럼 미리 사용할 사용량에 대해 결제 및 예약하는 방식이 아니라 시간 당 사용금액을 미리 1년 혹은 3년 약정을 걸어 할인을 받는 방식이다. 

 

현재 총 두가지 플랜을 제공하고 있다. 

• EC2 instance plan - Computing saving plan보단 옵션이 적으며 최대 72% 할인 가능
  : 지정한 Region 내에서만 Instance를 변경할 수 있고 EC2 Instance에 대해서만 적용할 수 있다
  : 같은 Instance Family 에만 적용할 수 있다. 
  -> RI 와 약정 방식만 다르지 거의 동일한 제약과 할인율을 가지고 있다. 

 

• AWS Compute Savings Plan - 조금 더 유연한 Plan 이며 최대 66% 까지 할인 가능
  : 여러 Region에 걸쳐 적용할 수 있고 EC2와 Fargate에 적용할 수 있다
  : EC2 Instance Family 와 OS 변경에 대한 제한이 없다  
  
  

 

보면, 같은 인스턴스 타입 / 같은 조건 ( 선결제 옵션 , Region 등) 적용 시 RI 와 Saving Plan은 같은 요금 할인율을 보여주고 있다.

때문에 사용량에 대해 미리 선결제 하는 RI보단 시간 당 사용금액을 약정을 거는 방식인 SP를 조금 더 많이 사용하는 것 같으며 실제 공식문서 에서도 SP 사용을 권장한다.

 

 

 

Conclusion

EMR의 관건은 비용 효율적이면서 안정성있는 클러스터를 구성하는 것이다. 적절한 Instance Type 설정 및 On-demand 와 Spot Instance의 적절한 구성과 목적에 맞는 Auto Scaling 등 다양한 옵션을 고려해야 한다.

비용 절약을 위하여 M5계열 인스턴스 타입들을 모두 Spot Instance로 활용하여Task Node를 구성했었는데, Worst case로 모든 Task Node를 다 잃는 경우도 생기고(On-demand 100% Bidding 시 Task Node 를 뺏기는 일이 생각보다 빈번해서 놀랐다..) 클러스터를 Resizing 하는 과정에서의 대기시간들, 부족한 Resource로 인해 실행되던 Job들이 죽는 등 운영성 클러스터로 사용하기에는 어려운 상황을 마주하게 된다. 그렇다고 모든 Instance를 다 On-Demand로 구성하자니 비용 차이가 두배 가까이 나게 되니 그 중간의 타협점을 찾아나가야 하는 것이 엔지니어의 일인 듯 하다.

 

 

 

Reference
https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-overview.html
https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-master-core-task-nodes.html
https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-file-systems.html
https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-instance-purchasing-options.html
https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-instance-fleet.html
https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-scaling.html