Amazon Web Services 한국 블로그
Amazon EMR 클러스터 스토리지의 동적 스케일링
Amazon EMR과 같은 관리형 Apache 하둡 환경에서는 클러스터의 스토리지 용량이 가득 찬 경우 손쉽게 대응할 수 있는 솔루션이 없습니다. 이 상황은 고객이 클러스터를 시작할 때 Amazon Elastic Block Store(Amazon EBS) 볼륨을 설정하고 마운트 지점을 구성했기 때문에 발생합니다. 따라서 클러스터가 실행된 후에는 스토리지 용량을 수정하기 어렵습니다. 이를 위한 솔루션은 일반적으로 클러스터에 노드를 추가하고 데이터를 데이터 레이크로 백업한 다음 더 큰 스토리지 용량으로 새 클러스터를 시작하는 방식을 사용합니다. 또는 스토리지를 차지하는 데이터를 폐기 가능한 경우 과다한 데이터를 제거하는 것이 일반적인 방식입니다.
이에 대해 Amazon EMR에서 관리 가능한 방식으로 해결하는 데 도움이 될 수 있게 Amazon EBS의 탄력적 볼륨 기능을 사용하여 스토리지를 동적으로 확장하는 방안에 대해 알려 드리겠습니다. 이 기능을 통해 볼륨을 사용하는 중에도 볼륨 크기를 늘리거나, 성능을 조정하거나, 볼륨 유형을 변경할 수 있습니다. 변경이 적용되는 동안에는 EMR 클러스터를 계속 사용하여 빅 데이터 애플리케이션을 실행할 수 있습니다.
HDFS와 YARN이 Amazon EMR 클러스터의 디스크 공간을 사용하는 방식
Amazon EMR 클러스터를 생성하면 기본적으로 HDFS(Hadoop Distributed File System) 및 YARN(Yet Another Resource Negotiator)이 모든 코어/작업 노드에서 사용 가능한 로컬 디스크 스토리지를 사용하도록 구성됩니다. 이 구성은 yarn-site.xml 및 hdfs-site.xml 구성 파일 안에 설정됩니다.
구체적으로, HDFS의 경우 NameNode 데몬에 의해 유지되는 파일의 데이터 블록을 저장하는 로컬 스토리지를 사용하도록 dfs.datanode.data.dir 파라미터를 구성합니다. 그리고 YARN의 경우에는 NodeManager 데몬이 YARN 컨테이너를 실행하는 데 필요한 중간 파일을 저장하도록 yarn.nodemanager.local-dirs 파라미터를 구성합니다.
예를 들어, 클러스터가 MapReduce 작업을 실행할 때 매핑 작업은 yarn.nodemanager.local-dirs에 의해 정의된 디렉토리 내에 출력 파일을 저장합니다. 또한 yarn.nodemanager.log-dirs 파라미터는 YARN 애플리케이션이 종료된 후 코어 및 작업 노드에 컨테이너 로그를 저장하도록 구성됩니다.
스토리지 문제를 방지하기 위한 일반 모범 사례
Amazon EMR 클러스터에서의 작업 실행을 계획할 때에는 다음과 같은 유용한 팁을 활용하면 클러스터의 가용 스토리지를 초과하지 않는 데 도움이 됩니다.
미래의 스토리지 요구 사항 예측
해당 작업의 스토리지 요구 사항을 미리 계획합니다. 기본 스토리지 구성으로 클러스터를 시작하면 해당 워크로드를 위한 용량이 충분하지 않을 수 있으며 작업을 실행하는 데 문제가 발생할 수 있습니다. 작업을 위해 중간 스토리지가 얼마나 필요한지를 예측하는 것이 좋습니다. 그리하면 이를 기반으로 새 클러스터를 시작할 때 스토리지 구성을 사용자 지정할 수 있습니다.
데이터 레이크에 수동적 데이터 저장
Amazon Simple Storage Service(Amazon S3)와 같은 데이터 레이크에 모든 수동 데이터를 저장하는 방식으로 워크로드를 설계하도록 하십시오. 이 방식에서는 데이터를 프로세싱하고, 기타 계산 작업을 수행하고, 영구 저장을 위해 결과를 데이터 레이크에 다시 저장하는 데에만 클러스터를 사용할 수 있습니다. 이 접근 방식은 실행 중인 클러스터의 스토리지 요구 사항을 최소화합니다.
추가 용량 계획
사용 사례가 입력 또는 출력 데이터를 클러스터에 로컬로 저장할 것을 요구하는 경우(HDFS 또는 로컬 스토리지), 클러스터의 크기를 적절히 계획해야 합니다. 예를 들어, HDFS를 사용하는 경우 데이터를 저장하기에 충분하도록 더 많은 수의 코어 노드를 포함한 클러스터를 생성할 수 있습니다. 또는 기본 구성이 제공하는 것보다 더 많은 EBS 스토리지 용량을 가지도록 코어 인스턴스 그룹을 사용자 지정할 수 있습니다.
스토리지가 최대 용량에 도달하는 경우 발생할 수 있는 문제
EMR 클러스터를 사용하여 여러가지 데이터 프로세싱 애플리케이션을 실행하면 언젠가는 클러스터의 스토리지 용량이 가득 차게 될 수 있습니다. 이 경우 다음과 같은 문제가 클러스터에 영향을 미칠 수 있습니다.
YARN 관점에서의 문제
yarn.nodemanager.local-dirs 또는 yarn.nodemanager.log-dirs 파라미터에 의해 정의된 디렉토리가 적어도 전체 볼륨 스토리지의 90%까지 채워진 경우에는 NodeManager가 해당 디스크를 비정상 상태로 표시합니다. 이 동작은 NodeManager가 해당 디스크를 포함하는 노드도 비정상으로 표시하게 만듭니다. 따라서 노드가 비정상 상태이면 ResourceManager는 노드에 어떤 컨테이너도 지정하지 않습니다.
그 뿐 아니라, EMR 클러스터의 종료 보호 기능이 꺼져 있는 경우 EMR 서비스가 궁극적으로는 클러스터에서 노드를 종료시키게 됩니다.
HDFS 관점에서의 문제
클러스터상의 HDFS 사용량이 증가하는 경우 EBS 볼륨의 로컬 스토리지 사용량 또한 증가합니다. EMR에서는 HDFS 데이터 디렉토리가 YARN 로컬 및 로그 디렉토리와 같은 마운트 지점 아래에 구성됩니다. 따라서 마운트 지점의 사용량이 HDFS로 인해 스토리지 임계값(90%)을 초과하는 경우 YARN이 해당 디스크를 비정상으로 표시하게 되고 ResourceManager는 노드를 블랙리스트에 포함시킵니다.
코어 및 작업 노드의 스토리지 공간 크기를 동적으로 조정
클러스터에 있는 코어 및 작업 노드의 스토리지를 확대하기 위해서는 다음 부트스트랩 작업 스크립트를 활용합니다.
s3://aws-bigdata-blog/artifacts/resize_storage/resize_storage.sh
그 뿐 아니라, 클러스터의 EC2 인스턴스 프로파일은 ec2:ModifyVolume 권한이 있어야 볼륨 크기를 조정할 수 있습니다.
스크립트는 EMR 클러스터의 모든 노드에서 실행됩니다. 스크립트는 노드에 cron 작업을 구성하고 2분마다 디스크 사용률 검사를 수행합니다. 마스터 노드에서는 루트 볼륨과 다양한 마스터 데몬을 저장하는 볼륨에 대한 검사를 수행합니다. 코어 및 작업 노드에서는 스크립트에서 YARN과 HDFS가 사용하는 볼륨에 대한 검사를 수행하고 스토리지를 확대할 필요가 있는지 여부를 결정합니다.
볼륨이 사용량의 90%를 초과했다고 확인되면 볼륨 크기가 “--scaling-factor” 파라미터에서 지정한 비율만큼 확대됩니다. 크기 재지정 과정을 진행할 때에는 볼륨의 파티션이 확장되고 파일 시스템이 확대되어 업데이트된 용량을 반영합니다. 이 모든 동작은 클러스터에서 실행 중인 애플리케이션에 영향을 미치지 않고 수행됩니다.
이 솔루션을 사용하기 전에 다음과 같은 사항을 고려하십시오.
- EMR 클러스터에서는 클러스터가 스토리지 백엔드로 EBS 볼륨을 사용하는 경우에만 노드의 스토리지 용량을 확대할 수 있습니다. 일부 EC2 인스턴스 유형은 인스턴스 스토어 볼륨만 사용하거나 인스턴스 스토어와 EBS 볼륨을 모두 사용합니다. 이러한 EC2 인스턴스 유형을 사용하는 클러스터에서는 스토리지 용량의 크기를 재지정할 수 없습니다.
- 스크립트의 조정 인수 옵션을 결정하는 동안, 업데이트된 구성이 상당 시간 지속될 수 있도록 볼륨을 증가하는 계획을 사전에 수립하십시오. 동일한 볼륨에 추가 수정을 적용하려면 약 6시간을 기다린 후에 스토리지 조정을 수행해야 합니다.
결론
이 게시물에서는 Amazon EMR 클러스터 노드에서 HDFS와 YARN이 어떻게 로컬 스토리지를 사용하는지 설명해 드렸습니다. 또한 Amazon EBS의 탄력적 볼륨 기능을 사용하여 EMR에서 스토리지를 확장하는 방법을 다루었습니다. 이 기능을 사용하면 볼륨을 사용 중일 때에도 볼륨 크기를 증가시키거나, 성능을 조정하거나, 볼륨 유형을 변경할 수 있습니다. 그러면 변경이 적용되는 동안 계속해서 EMR 클러스터를 사용하여 빅 데이터 애플리케이션을 실행할 수 있습니다.
질문이나 제안이 있으면 아래에 의견을 남겨주시기 바랍니다.
Jigar Mistry는 Amazon Web Services의 하둡 시스템 엔지니어입니다. 그는 클라우드에서 오픈 소스 애플리케이션을 사용하여 대규모 데이터세트를 처리하기 위한 설계 지침과 기술 지원을 고객에게 제공합니다. 그는 여가 시간에 캠핑을 즐기며 시애틀 지역의 다양한 맛집을 탐색합니다.
이 글은 AWS BigData 블로그의 Dynamically scale up storage on Amazon EMR clusters의 한국어 번역입니다.