BLOG
Amazon EMR에서 제공하는 동적 스케일링 기능을 활용하여 비용 절감 효과를 높일 수 있습니다. 클러스터에서 노드 수를 빠르게 늘리거나 줄이는 기능은 Amazon EMR을 탄성 있게 만드는 주요 특징들입니다. 워크로드가 거의 없거나 없을 때 클러스터의 크기를 조정하여 EMR의 스케일링을 활용할 수 있습니다. 작업이 너무 느려질 경우 처리 성능을 추가하기 위해 클러스터를 확장할 수도 있습니다. 이를 통해 적은 비용으로 작업 비용을 충당할 수 있습니다.
이 기능의 복잡한 논리를 알면 이를 활용하여 클러스터 비용을 절감할 수 있습니다. 이 글에서는 EMR 클러스터의 크기 조정 방법을 자세히 설명하고, 이 기능을 통해 클러스터의 이점을 극대화하고 비용을 절감하는 몇 가지 모범 사례를 소개합니다.
EMR 스케일링은 단순히 클러스터에서 노드를 추가하거나 제거하는 것보다 더 복잡합니다. 한가지 일반적인 오해는 Amazon EMR의 스케일링이 Amazon EC2 스케일링과 똑같이 작동한다는 것입니다. EC2 스케일링을 사용하면 노드를 거의 즉각적으로 추가/제거할 수 있지만, EMR은 특히 클러스터를 축소할 때 더 복잡합니다. 이는 중요한 데이터 또는 작업이 노드에서 실행되고 있을 수 있기 때문입니다.
데이터 손실을 방지하기 위해 Amazon EMR 스케일링을 사용하면 노드를 제거하기 전에 손실될 수 있는 Apache Hadoop 작업이나 고유한 데이터가 실행되지 않습니다. EMR 클러스터의 크기를 조정할 때 이 해제 지연을 고려하는 것이 좋습니다. 이 프로세스의 작동 방식을 이해하고 설명하면 느린 클러스터 크기 조정 및 비효율적인 자동 스케일링 정책과 같은 다른 문제를 해결할 수 있습니다.
EMR 스케일 클러스터가 축소되면 종료될 노드에서 두개의 서로 다른 해제 프로세스가 트리거됩니다. 첫번째 프로세스는 Hadoop 리소스 관리자인 Hadoop YARN의 해제입니다. Amazon EMR에 제출된 Hadoop 작업은 일반적으로 YARN을 통해 실행되므로, EMR은 노드를 제거하기 전에 모든 실행 중인 YARN 작업이 완료되었는지 확인해야 합니다. 어떤 이유로 인해 YARN 작업이 중단된 경우에도 해제 작업이 여전히 완료되도록 구성 가능한 시간 초과가 발생합니다. 이 시간 초과가 발생하면 YARN작업은 종료되고 대신 다른 노드로 다시 예약되어 작업을 완료할 수 있습니다.
두번째 해제 과정은 Hadoop 분산 파일 시스템 또는 HDFS입니다. HDFS는 HDFS를 실행 중인 모든 노드의 EMR 클러스터를 통해 분산되는 블록에 데이터를 저장합니다. HDFS 노드는 폐기할 때 해당 데이터 블록을 다른 HDFS 노드로 복제하여 노드가 종료될 때 손실되지 않도록 해야 합니다.
그러면 여러분은 Amazon EMR에서 이 지식을 어떻게 사용할 수 있을까요?
클러스터 크기 조정 팁
다음은 클러스터의 크기를 조정할 때 고려해야 할 몇 가지 문제입니다.
EMR 클러스터는 Hadoop 작업에 두가지 유형의 노드, 즉 핵심 노드와 작업 노드를 사용할 수 있습니다. 핵심 노드는 HDFS 데이터노드 프로세스를 실행하여 영구 데이터를 호스트하고 YARN의 리소스 관리자를 통해 Hadoop 작업을 실행합니다. 작업 노드는 YARN을 통해서만 Hadoop 작업을 실행하고 HDFS에 데이터를 저장하지 않습니다.
실행 중인 클러스터에서 작업 노드를 축소하는 경우 클러스터에서 실행 중인 Hadoop 작업이 해제될 때까지 약간의 지연이 예상됩니다. 이렇게 하면 중단을 통해 작업 진행률이 저하되지 않으므로 작업 노드를 최대한 활용할 수 있습니다. 그러나 작업에서 이러한 중단을 허용하는 경우에는 yarn-site.xml에서 yarn.resourcemanager.nodemanager-graceful-decommission-timeout-secs 속성(EMR 5.14)를 조정하여 크기 조정에 대한 1시간 기본 시간제한을 조정할 수 있습니다. 이 프로세스가 시간 초과되면 실행 중인 작업에 관계 없이 작업 노드가 종료됩니다. 이 프로세스는 일반적으로 비교적 빠르기 때문에 작업 노드를 빠르게 축소할 수 있습니다.
핵심 노드를 축소할 때에는 Amazon EMR도 데이터를 보호하기 위해 해제할 때까지 HDFS를기다려야 합니다. HDFS는 해제하는 데 비교적 오랜 시간이 걸릴 수 있습니다. HDFS 블록 복제가 hdfs-site.xml에 있는 구성을 통해 설계에 의해 조정되기 때문입니다. 이는 다시 HDFS의 해제가 제한됨을 의미합니다. 이렇게 하면 노드가 중단되는 경우에도 클러스터가 급증하는 워크로드로부터 보호되지만 해제 속도가 느려집니다. 많은 수의 핵심 노드를 축소할 때는 더 빠르게 축소할 수 있도록 미리 이러한 구성을 조정하는 것이 좋습니다.
예를 들어, HDFS를 사용하고 속도를 조정할 때 이 연습을 고려합니다.
hdfs-site.xml에 있는 HDFS 구성은 조정 블록 복제에 가장 큰 영향을 미칩니다.
- balance.bandwidthPerSec: 각 노드의 복제에 대한 대역 폭
- replication.max-streams: 블록 복제를 위해 실행되는 최대 스트림
- replication.max-streams-hard-limit: 최대 스트림에 대한 엄격한 제한
- balance.max.concurrent.moves: 블록 밸런서가 대기 이동에 사용하는 스레드 수
- replication.work.multiplier.per.iteration: 각 복제 간격 동안 즉시 전송을 시작할 블록 수를 결정하는 데 사용됨
(수정 시 주의: 특히 로드가 많은 클러스터에서 이러한 구성을 잘못 변경하면 클러스터 성능이 심각하게 저하될 수 있습니다.)
클러스터 크기 조정 속도 연습
이러한 구성을 수정하면 해제 시간을 크게 단축할 수 있습니다. 이 차이를 알기 위해서는 다음 연습을 해 보세요.
- 다음 하드웨어 구성을 사용하여 EMR 클러스터를 생성합니다.
- 마스터: 노드 1개– xlarge
- 코어: 6개 노드– m3.xlarge
- SSH(Secure Shell)를 사용하여 클러스터의 마스터 노드에 연결합니다.
자세한 내용은 Amazon EMR 문서의 SSH를 사용하여 마스터 노드에 연결하기를 참조하십시오.
- 다음 작업을 사용하여 HDFS로 데이터 로드:
$ hadoop jar /usr/lib/hadoop-mapreduce/hadoop-mapreduce-examples.jar teragen 1000000000 /user/hadoop/data1/
$ s3-dist-cp –src s3://aws-bigdata-blog/artifacts/ClusterResize/smallfiles25k/ –dest hdfs:///user/hadoop/data2/
- hdfs-site.xml 구성을 편집합니다.
$ sudo vim /etc/hadoop/conf/hdfs-site.xml
그런 다음 hdfs-site 속성에 다음 구성 설정을 붙여 넣습니다.
고지사항: 이러한 값은 예를 들어 상대적으로 높은 값이며 반드시 프로덕션에 사용해서는 안 됩니다. 로드 중인 프로덕션 클러스터를 수정하기 전에 이에 대한 구성 값을 테스트해야 합니다.
<property>
<name>dfs.datanode.balance.bandwidthPerSec</name>
<value>100m</value>
</property>
<property>
<name>dfs.namenode.replication.max-streams</name>
<value>100</value>
</property>
<property>
<name>dfs.namenode.replication.max-streams-hard-limit</name>
<value>200</value>
</property>
<property>
<name>dfs.datanode.balance.max.concurrent.moves</name>
<value>500</value>
</property>
<property>
<name>dfs.namenode.replication.work.multiplier.per.iteration</name>
<value>30</value>
</property>
- 6개에서 5개의 핵심 노드로 EMR 클러스터의 크기를 조정하고, EMR 이벤트 탭에서 크기 조정에 걸린 시간을 확인합니다.
- 구성을 수정하지 않고 이전 단계를 반복하고 크기 조정 시간의 차이를 확인합니다.
이 연습을 수행하는 동안 크기 조정 시간이 45분 이상(구성 변경 없음)에서 약 6분으로 단축되었습니다(수정된 hdfs-site 구성 사용). 이 연습은 HDFS가 기본 구성에서 얼마나 제한되는지 보여 줍니다. 이러한 제한을 제거하는 것이 위험하고 이러한 제한을 사용하는 성능을 먼저 테스트해야 하지만, 이러한 제한은 해제 시간을 크게 단축시켜 크기를 조정할 수 있습니다.
다음은 클러스터 크기를 조정하기 위한 몇가지 추가 팁입니다.
- 크기 조정 시간 제한을 줄입니다. EMR 노드는 인스턴스 그룹 또는 인스턴스 fleet의 두가지 방법으로 구성할 수 있습니다. 자세한 내용은 인스턴스 fleet 또는 균등 인스턴스 그룹이 있는 클러스터 생성을 참조하십시오. EMR은 인스턴스 fleet에 노드가 구성된 경우 축소 크기 조정 시간 제한을 구현했습니다. 이 시간 초과는 크기 조정 중에 문제가 발생할 경우 인스턴스 fleet이 영구적으로 크기를 조정하지 못하도록 합니다. 현재 기본 값은 1일이므로 인스턴스 fleet 크기를 축소할 때는 주의하십시오.
한 인스턴스 fleet 축소 요청이 하루 이상 걸리면, 현재 많은 인스턴스가 실행 중인 경우에 완료되고 일시 중지됩니다. 반면, 인스턴스 그룹에는 기본 축소 크기 조정 시간 제한이 없습니다. 그러나 두 유형 모두 앞의 yarn-site.xml에서 yarn.resourcemanager.nodemanager-graceful-decommission-timeout-secs 속성(EMR 5.14 내에서)에서 설명한 1시간 YARN 시간 초과를 가집니다.
- 핵심 노드의 크기를 조정할 때는 HDFS 작성의 높은 빈도에 주의하십시오. HDFS가 많은 쓰기 작업을 받고 있는 경우 복제가 필요한 많은 블록을 수정합니다. 이 복제는 모든 해제 핵심 노드에서 블록 복제를 방해할 수 있으며 크기 조정 프로세스를 상당히 지연시킬 수 있습니다.
자동 스케일링을 위한 정책 설정
수동 스케일링이 유용하지만 대부분의 시간 클러스터 크기 조정은 Amazon EMR 자동 스케일링을 통해 동적으로 실행됩니다. 일반적으로 자동 스케일링 정책의 세부 정보는 특정 Hadoop 작업에 맞게 조정되어야 하므로 자세한 내용은 설명하지 않겠습니다. 대신 클러스터의 자동 스케일링 정책을 설정하기 위한 일반적인 지침을 제공합니다.
다음은 자동 스케일링 정책을 설정할 때 고려해야 할 몇가지 사항입니다.
스케일링을 위한 메트릭
스케일링을 트리거 할 노드 유형에 적합한 메트릭을 선택합니다. 예를 들어, YARNMemoryAvailablePercentage 메트릭에서만 핵심 노드를 확장하는 것은 적합하지 않습니다. 이는 더 많은 처리 능력이 필요할 때 HDFS의 전체 크기를 증가/감소시키기 때문입니다. 또한 작업 노드와 함께 제공되지 않는 HDFS 스토리지 공간을 늘리려고 하기 때문에 HDFSUtilization에서 작업 노드를 스케일링하는 것도 의미가 없습니다. 핵심 노드에 대한 일반적인 자동 스케일링 메트릭은 HDFSUtilization입니다. 작업 노드에 대한 일반적인 자동 스케일링 메트릭에는 ContainerPending-Out 및 YarnMemoryAvailablePercentage가 포함됩니다.
참고: Amazon EMR에는 현재 HDFS가 필요하므로 클러스터에 하나 이상의 핵심 노드가 있어야 합니다. 핵심 노드는 CPU 및 메모리 리소스도 제공할 수 있습니다. 그러나 HDFS를 확장할 필요가 없고 작업에 더 많은 CPU 또는 메모리 리소스만 필요한 경우에는 해당 용도로 작업 노드를 사용하는 것이 좋습니다.
핵심 노드 스케일링
앞에서 설명한 것처럼 클러스터에서 두가지 EMR 노드 유형 중 하나가 핵심 노드입니다. 핵심 노드는 HDFS를 실행하므로 해제 지연 시간이 길어집니다. 즉, 확장 속도가 느리므로 적극적으로 확장해서는 안 됩니다. 한번에 몇 개의 핵심 노드만 추가하고 제거하면 스케일링 문제를 방지할 수 있습니다. HDFS 스토리지가 필요하지 않는 한 일반적으로 작업 노드의 크기를 조정하는 것이 더 좋습니다. 많은 수의 핵심 노드를 스케일링해야 하는 경우에는 해제 시간을 단축하고 축소를 가속화하기 위해 hdfs-site.xml 구성을 변경하는 것이 좋습니다.
작업 노드 스케일링
작업 노드는 HDFS를 실행하지 않으므로 동적 작업을 통해 적극적으로 스케일링할 수 있습니다. Hadoop 작업에 다운타임기간 동안 급증하는 작업이 있는 경우 원하는 노드 유형을 사용합니다.
매우 적극적인 자동 스케일링 정책을 사용하여 작업 노드를 설정할 수 있으며 작업 노드를 쉽게 확장하거나 축소할 수 있습니다. HDFS 공간이 필요 없는 경우 클러스터의 작업 노드를 사용할 수 있습니다.
스팟 인스턴스 사용하기
자동 스케일링은 EMR 스팟 인스턴스 유형을 사용하기에 완벽한 시간입니다. 스팟 인스턴스가 사라지고 다시 나타나는 경향이 있으므로 작업 노드에 적합합니다. 이러한 작업 노드는 공격적으로 확장하거나 축소하는 데 이미 사용되고 있기 때문에 여기서는 스팟 인스턴스의 단점이 거의 없을 수 있습니다. 그러나 시간에 민감한 Hadoop 작업의 경우에는 가용성 보장을 위해 온디맨드 인스턴스의 우선 순위가 지정될 수 있습니다.
핵심 노드에 대한 스케일 인 VS 스케일 아웃 정책 비교
스케일 인 정책과 정반대인 스케일 아웃 정책을 만들어 핵심 노드에 적용하지 마십시오. 대부분의 경우, 규모를 확장하면 해제 작업이 추가로 지연됩니다. 이를 고려하여 스케일 인 정책이 스케일 아웃 정책보다 더 관대하도록 하십시오. 즉, 크기 조정을 트리거하기 위한 더 긴 축소 시간과 더 높은 메트릭 요구 사항이 필요합니다.
스케일 아웃 정책이 낮은 축소 시간과 적은 노드 증가량으로 인해 쉽게 트리거된다고 생각할 수 있습니다. 축소 및 노드 증가량으로 스케일 인 정책을 트리거하기는 어렵습니다.
핵심 노드 자동 스케일링을 위한 최소 노드
핵심 노드의 크기를 조정할 때 고려해야 할 마지막 한가지 사항은 yarn-site.xml에 있는 yarn.app.mapreduce.am.labels 속성입니다. Amazon EMR에서 yarn.app.mapreduce.am.labels는 기본적으로 응용 프로그램 마스터가 항상 작업 노드가 아닌 핵심 노드에서 실행됨을 의미하는 “Core”로 설정됩니다. 이는 작업 노드에 스팟 인스턴스가 사용되는 시나리오에서 응용프로그램 오류를 방지하는 데 도움이 됩니다.
즉, 최소 핵심 노드 수를 설정할 때 클러스터에서 실행할 동시 애플리케이션 마스터 수보다 크거나 같은 숫자를 선택해야 합니다. 응용 프로그램 마스터가 작업 노드에서도 실행되도록 하려면 이 속성을 “TASK”가 포함하도록 수정해야 합니다. 하지만 모범사례로서, 작업 노드에 스팟 인스턴스를 사용하는 경우 TASK에 yarn.app.mapreduce.am.labels 속성이 설정되지 않도록 해야합니다.
S3DistCp를 사용하여 데이터 통합하기
이 게시물을 마치기 전에 클러스터 크기 조정에 대해 공유할 마지막 정보가 있습니다. 핵심 노드의 크기를 조정할 때 HDFS를 해제하는 데 시간이 오래 걸릴 수 있습니다. 종종 이는 클러스터의 HDFS에 여러개의 작은 파일을 저장한 결과입니다. HDFS 내에 작은 파일(128MB인 HDFS 블록 크기보다 작은 파일)이 많으면 메타데이터 오버헤드가 많이 발생하고 해제 및 Hadoop 작업이 느려질 수 있습니다.
데이터를 집계하여 작은 파일을 최소화하면 클러스터와 작업을 보다 원활하게 실행할 수 있습니다. 파일을 집계하는 방법에 대한 자세한 내용은 Amazon EMR에서 S3DistCp를 사용하여 HDFS와 Amazon S3간에 데이터를 효율적으로 이동하기 위한 7가지 팁을 참조하십시오.
요약
이 게시물에서는 Amazon EMR 크기 조정 로직이 데이터 및 Hadoop 작업을 보호하기 위해 어떻게 작동하는지에 대해 읽어 보았습니다. 또한 EMR 크기 조정 및 자동 스케일링에 대한 몇가지 추가 고려 사항을 제공했습니다. 이러한 작업 방식을 염두에 두면 필요한 클러스터 리소스만 사용할 수 있으므로 클러스터 절감 효과를 극대화할 수 있습니다.
원문 URL: https://aws.amazon.com/ko/blogs/big-data/best-practices-for-resizing-and-automatic-scaling-in-amazon-emr/
** 메가존 TechBlog는 AWS BLOG 영문 게재글중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.