ℹ️ 이 강의 자료는 AWS 매뉴얼 을 한글 번역으로 그대로 불러온 강의자료이다. EMR 클러스터 설정시 필요한 개념이나 용어를 설명하기위해서 복사해온 것으로, 강의 시점의 snapshot 유지의 목적이 있다. 정확한 정보는 언제나 공식 매뉴얼에서 확인하는 것이 가장 정확하다.

3 클러스터 인스턴스 구성 지침

매뉴얼

3.1 어떤 인스턴스 유형을 사용해야 할까요?

클러스터에 Amazon EC2 인스턴스를 추가하는 방법은 여러 가지가 있으며, 이는 클러스터의 인스턴스 그룹 구성을 사용하는지 아니면 인스턴스 플릿 구성을 사용하는지에 따라 달라집니다.

3.1.1 인스턴스 그룹

• 동일한 유형의 인스턴스는 수동으로 코어 및 작업 인스턴스 그룹에 추가합니다.
• 다른 인스턴스 유형을 사용할 수 있는 작업 인스턴스 그룹을 수동으로 추가합니다.
• Amazon EMR에서 인스턴스 그룹에 대한 자동 조정을 설정하여 지정한 Amazon CloudWatch 지표 값에 따라 인스턴스를 자동으로 추가 및 제거합니다. 자세한 내용은 Scaling을 참조하세요.

EMR 클러스터는 인스턴스를 그룹 단위로 관리할 수 있으며, 각 그룹은 특정 역할과 EC2 인스턴스 타입으로 구성된다. 예를 들어 프라이머리 노드는 특정 EC2 타입으로 지정해 두고 이후 필요에 따라 인스턴스 수만 조정하여 확장할 수 있다. 코어 노드의 경우에도 특정 타입(E 타입, B 타입 등)을 선택하고 원하는 개수를 설정한 뒤, 상황에 맞게 각 타입별 인스턴스 수를 늘리거나 줄일 수 있다. 이처럼 EMR은 EC2 리소스 타입별로 역할 그룹을 구분하여 클러스터를 관리할 수 있도록 지원하며, 사용자는 요구되는 워크로드 특성에 맞게 유연하게 인스턴스를 조정할 수 있다.

3.1.2 인스턴스 플릿

• 단일 작업 인스턴스 집합을 추가합니다.
• 기존 코어 및 작업 인스턴스 플릿에 대한 온디맨드 및 스팟 인스턴스의 대상 용량을 변경합니다. 자세한 내용은 인스턴스 플릿 구성을 참조하세요.

인스턴스 플릿은 하둡 클러스터를 구성할 때 각 노드별로 사용할 인스턴스 타입과 역할을 세부적으로 직접 지정할 수 있는 방식이다. 즉, 어떤 노드는 특정 인스턴스 타입으로, 다른 노드는 또 다른 인스턴스 타입으로 설정하는 등 다양한 구성을 유연하게 조합할 수 있다. 그러나 멀티 마스터 구성을 사용할 경우 인스턴스 플릿은 지원되지 않기 때문에 우리의 고려 대상은 아니다. 다만 필요에 따라 선택적으로 활용할 수 있는 옵션으로 존재한다는 점은 알아둘 필요가 있다.

3.1.3 인스턴스 유형과 용량 계획 방법

클러스터의 인스턴스를 계획하는 한 가지 방법은 대표 샘플 데이터 세트를 사용하여 테스트 클러스터를 실행하고 클러스터 내 노드의 사용률을 모니터링하는 것입니다. 자세한 내용은 클러스터 보기 및 모니터링을 참조하세요. 또 한 가지 방법은 고려 중인 인스턴스의 용량을 계산하여 이 값을 데이터의 크기와 비교하는 것입니다.

일반적으로 작업을 할당하는 마스터 노드 유형에는 처리 능력이 뛰어난 EC2 인스턴스가 필요하지 않습니다. 작업을 처리하고 데이터를 HDFS에 저장하는 코어 노드 유형용 Amazon EC2 인스턴스에는 처리 능력과 스토리지 용량이 모두 필요하며, 작업 노드 유형용 Amazon EC2 인스턴스는 필요하지 않습니다.데이터를 저장하고 처리 능력만 필요합니다. 사용 가능한 Amazon EC2 인스턴스 및 해당 구성에 대한 지침은 을 참조하십시오Amazon EC2.

3.1.4 대부분의 Amazon EMR 클러스터에 적용가능한 지침

• AWS계정당 실행하는 온디맨드 Amazon EC2 인스턴스의 총 수에는 vCPU 제한이AWS 리전 있습니다. vCPU 한도 및 계정에 대한 한도 증가를 요청하는 방법에 대한 자세한 내용은 Linux 인스턴스용 Amazon EC2 사용 설명서의 온디맨드 인스턴스를 참조하십시오.
• 마스터 노드에는 일반적으로 계산 요구 사항이 많지 않습니다. 노드 수가 많은 클러스터나 마스터 노드 (JupyterHub, Hue 등) 에 특별히 배포된 응용 프로그램이 있는 클러스터의 경우 더 큰 마스터 노드가 필요할 수 있으며 이는 클러스터 성능을 개선하는 데 도움이 될 수 있습니다. 예를 들어 소규모 클러스터 (노드 50개 이하) 에는 m5.xlarge 인스턴스를 사용하고 대규모 클러스터에는 더 큰 인스턴스 유형으로 늘리는 것을 고려해 보십시오.
• 코어 및 작업 노드의 컴퓨팅 요구는 애플리케이션에서 수행하는 처리 유형에 따라 달라집니다. CPU, 디스크 공간 및 입력/출력 측면에서 균형 잡힌 성능을 제공하는 범용 인스턴스 유형에서 많은 작업을 실행할 수 있습니다. 컴퓨팅 집약적인 클러스터는 RAM보다 비례적으로 더 많은 CPU를 사용할 수 있는 고성능 CPU 인스턴스의 실행에서 이점을 얻을 수 있습니다. 데이터베이스 및 메모리 캐싱 애플리케이션은 고용량 메모리 인스턴스의 실행에서 이점을 얻을 수 있습니다. 파싱, NLP 및 머신 러닝과 같은 네트워크 집약적 및 CPU 집약적 애플리케이션을 클러스터 컴퓨팅 인스턴스에서 실행하면 그에 비례하여 높은 CPU 리소스와 향상된 네트워크 성능을 제공하는 이점이 있을 수 있습니다.
• 클러스터의 각 단계마다 필요한 용량이 다른 경우 적은 코어 노드 수로 시작하여 작업 흐름의 가변 용량 요구 사항에 맞춰 작업 노드 수를 늘리거나 줄일 수 있습니다.
• 처리할 수 있는 데이터 양은 입력 및 출력되거나 처리 중인 데이터의 크기와 코어 노드의 용량에 따라 달라집니다. 입력, 중간 및 출력 데이터 세트는 모두 처리 중에 클러스터에 상주합니다.

AWS에서는 계정당 실행할 수 있는 온디맨드 EC2 인스턴스 수에 대해 리전별 vCPU 제한을 두고 있다. 이는 특정 사용자가 과도한 비용을 발생시키거나 특정 리전에서 리소스를 과도하게 점유하여 다른 사용자들의 서비스 운영에 영향을 주는 상황을 방지하기 위한 장치이다. 마스터 노드(프라이머리 노드)는 일반적으로 네임노드 역할을 하며 CPU 사용량이 많지 않지만, 실제 클러스터 환경에서는 Hive, Hue 등 다양한 패키지의 마스터 서버가 함께 배포되므로 더 큰 인스턴스가 필요할 수 있다. 따라서 노드 수가 50개 이하인 소규모 클러스터에는 m5.xlarge 인스턴스를 권장하며, 노드 수가 많거나 추가적인 패키지를 함께 실행하는 경우에는 더 큰 인스턴스를 사용하는 것이 성능 향상에 도움이 된다.
코어 및 작업 노드의 경우에는 워크로드 성격에 따라 인스턴스 유형을 선택해야 한다. CPU, 메모리, 디스크 I/O가 균형 잡힌 범용 인스턴스는 일반적인 워크로드에 적합하고, CPU 집약적 애플리케이션에는 고성능 CPU 인스턴스가, 메모리 기반 애플리케이션에는 메모리 최적화 인스턴스가 적합하다. 또한 NLP, 머신러닝 등 네트워크 및 CPU 집약적 작업의 경우 클러스터 컴퓨팅 인스턴스를 활용하면 높은 CPU와 네트워크 성능을 동시에 얻을 수 있다. 클러스터 운영에서는 작업 단계별로 요구되는 용량이 다르므로 초기에는 적은 코어 노드로 시작해 필요에 따라 작업 노드를 증감시키는 방식이 권장된다. 다만, 실제 실습 환경에서는 m5.xlarge조차도 비용 부담이 크기 때문에 최소한의 규모에서 시작하는 것이 현실적이다.

3.2 스팟 인스턴스는 언제 사용해야 합니까?

스팟 인스턴스는 온디맨드 인스턴스 대비 최대 90%까지 저렴하게 사용할 수 있는 옵션이다. AWS에서 상대적으로 활용되지 않거나 유휴 상태에 있는 자원을 비용 절감을 위해 제공하는 방식으로, 실제로는 AWS의 스팟 인스턴스 풀에 요청을 보내어 할당받는 구조이다. 온디맨드 인스턴스는 요청 시 즉시 발급이 보장되지만, 스팟 인스턴스는 수요와 입찰 상황에 따라 할당이 거부될 수 있으며 가격도 변동된다. 사용자가 설정한 입찰 한도를 초과하면 인스턴스를 확보하지 못할 수도 있다. 또한 이미 발급받은 스팟 인스턴스라 하더라도 AWS가 자원을 회수해야 하는 경우 예고 후 강제로 종료될 수 있다. 일반적인 EC2 인스턴스는 물리적 장애가 발생하지 않는 한 중도 종료되지 않지만, 스팟 인스턴스는 이러한 특성 때문에 예기치 않게 중단될 위험이 존재한다. 따라서 비용은 크게 절감할 수 있지만 안정성과 운영의 복잡성이 증가하므로, Amazon EMR에서 스팟 인스턴스를 활용할 때는 클러스터 설정에서 이러한 특성을 충분히 고려해야 한다.

Amazon EMR에서 클러스터를 시작할 때 스팟 인스턴스에서 마스터, 코어 또는 태스크 인스턴스를 시작하도록 선택할 수 있습니다. 각 인스턴스 그룹 유형이 클러스터에서 서로 다른 역할을 수행하므로 스팟 인스턴스에서 각 노드 유형이 시작됩니다. 클러스터 실행 도중에는 인스턴스 구매 옵션을 변경할 수 없습니다. 마스터 및 코어 노드의 경우 온디맨드에서 스팟 인스턴스로 변경하거나 그 반대로 변경하려면 클러스터를 종료하고 새 클러스터를 시작해야 합니다. 작업 노드의 경우 새 작업 인스턴스 그룹 또는 인스턴스 플릿을 시작하고 이전 그룹이나 플릿을 제거할 수 있습니다.

주제

• 작업 노드 스팟 인스턴스 종료로 인한 작업 실패를 방지하기 위한 Amazon EMR 설정
• 스팟 인스턴스의 마스터 노드
• 스팟 인스턴스의 코어 노드
• 스팟 인스턴스의 작업 노드
• 애플리케이션 시나리오를 위한 인스턴스 구성

작업 노드 스팟 인스턴스 종료로 인한 작업 실패를 방지하기 위한 Amazon EMR 설정

스팟 인스턴스는 작업 노드를 실행하는 데 자주 사용되므로 Amazon EMR에는 스팟 인스턴스에서 실행 중인 작업 노드가 종료될 때 실행 중인 작업이 실패하지 않도록 YARN 작업을 예약하는 기본 기능이 있습니다. Amazon EMR은 애플리케이션 마스터 프로세스가 코어 노드에서만 실행되게 함으로써 이를 지원합니다. 애플리케이션 마스터 프로세스는 실행 중인 작업을 제어하며, 작업 수명 동안 유지되어야 합니다.

Amazon EMR 릴리스 버전 5.19.0 이상에서는 기본 제공되는 YARN 노드 레이블 기능을 사용하여 이를 지원합니다. (이전 버전에서는 코드 패치를 사용했습니다.) yarn-site및capacity-scheduler 구성 분류의 속성은 기본적으로 YARN 용량 스케줄러와 공정 스케줄러가 노드 레이블을 활용하도록 구성됩니다. Amazon EMR은 레이블로 코어 노드에 자동으로CORE 레이블을 지정하고 속성을 설정하여 애플리케이션 마스터가 CORE 레이블이 있는 노드에서만 예약되도록 합니다. yarn-site 및 capacity-scheduler 구성 분류에서 해당 속성을 수동으로 수정하거나, 연결된 XML 파일에서 직접 수정하면 이 기능이 작동하지 않거나 변경됩니다.

Amazon EMR은 기본적으로 다음과 같은 속성과 값을 구성합니다. 이러한 속성을 구성할 때 각별히 주의하십시오.

• 모든 노드에 대한 yarn-site(yarn-site.xml)
  • yarn.node-labels.enabled: true
  • yarn.node-labels.am.default-node-label-expression: 'CORE'
  • yarn.node-labels.fs-store.root-dir: '/apps/yarn/nodelabels'
  • yarn.node-labels.configuration-type: 'distributed'
• 마스터 및 코어 노드에 대한 yarn-site(yarn-site.xml)
  • yarn.nodemanager.node-labels.provider: 'config'
  • yarn.nodemanager.node-labels.provider.configured-node-partition: 'CORE'
• 모든 노드에 대한 capacity-scheduler(capacity-scheduler.xml)
  • yarn.scheduler.capacity.root.accessible-node-labels: '*'
  • yarn.scheduler.capacity.root.accessible-node-labels.CORE.capacity: 100
  • yarn.scheduler.capacity.root.default.accessible-node-labels: '*'
  • yarn.scheduler.capacity.root.default.accessible-node-labels.CORE.capacity: 100

참고

Amazon EMR 6.x 릴리스 시리즈부터 YARN 노드 레이블 기능은 기본적으로 비활성화되어 있습니다. 애플리케이션 마스터 프로세스는 기본적으로 코어 및 작업 노드 모두에서 실행할 수 있습니다. 다음과 같은 속성을 구성하여 YARN 노드 레이블 기능을 활성화할 수 있습니다.

• yarn.node-labels.enabled: true
• yarn.node-labels.am.default-node-label-expression: 'CORE'

스팟 인스턴스의 마스터 노드

마스터 노드는 클러스터를 제어하고 지시합니다. 마스터 노드가 종료되면 클러스터가 종료되므로 갑작스런 종료를 허용할 수 있는 클러스터를 실행 중인 경우에만 마스터 노드를 스팟 인스턴스로 시작해야 합니다. 새 애플리케이션을 테스트하거나, Amazon S3와 같은 외부 스토어에 정기적으로 데이터를 보관하는 클러스터를 보유하고 있거나, 클러스터 완료를 보장하는 것보다 비용이 더 중요한 클러스터를 실행하는 경우에 해당될 수 있습니다.

마스터 인스턴스 그룹을 스팟 인스턴스로 시작할 경우 스팟 인스턴스 요청이 충족될 때까지 클러스터가 시작되지 않습니다. 최대 스팟 가격을 선택할 때 이 점을 고려해야 합니다.

클러스터를 시작할 때 스팟 인스턴스 마스터 노드만 추가할 수 있습니다. 실행 중인 클러스터에서 마스터 노드를 추가하거나 제거할 수는 없습니다.

일반적으로 전체 클러스터(모든 인스턴스 그룹)를 스팟 인스턴스로 실행 중이면 마스터 노드가 스팟 인스턴스로만 실행됩니다.

스팟 인스턴스의 코어 노드

코어 노드는 HDFS를 사용하여 데이터를 처리하고 정보를 저장합니다. 코어 인스턴스를 종료하면 데이터 손실의 위험이 있습니다. 따라서 일부 HDFS 데이터 손실이 허용되는 경우에만 스팟 인스턴스에서 코어 노드를 실행하십시오.

코어 인스턴스 그룹을 스팟 인스턴스로 시작하면 Amazon EMR은 요청된 코어 인스턴스를 모두 프로비저닝할 수 있을 때까지 기다린 후 인스턴스 그룹을 시작합니다. 즉, Amazon EC2 인스턴스 6개를 요청했는데 최대 스팟 가격 이하로 사용할 수 있는 인스턴스가 5개만 있는 경우 해당 인스턴스 그룹은 시작되지 않습니다. Amazon EMR은 6개의 Amazon EC2 인스턴스를 모두 사용할 수 있을 때까지 또는 클러스터를 종료할 때까지 계속 대기합니다. 실행 중인 클러스터에 용량을 추가하기 위해 코어 인스턴스 그룹의 스팟 인스턴스 수를 변경할 수 있습니다. 인스턴스 그룹 작업 및 인스턴스 플릿에서의 스팟 인스턴스를 통한 작업 방법에 대한 자세한 내용은 인스턴스 플릿 또는 유니폼 인스턴스 그룹으로 클러스터를 생성합니다. 단원을 참조하십시오.

스팟 인스턴스의 작업 노드

작업 노드는 데이터를 처리하지만 HDFS에 영구 데이터를 보관하지 않습니다. 스팟 가격이 최대 스팟 가격보다 높아져서 작업 노드가 종료되는 경우 데이터가 손실되지 않으며 클러스터에 미치는 영향이 최소 수준입니다.

하나 이상의 작업 인스턴스 그룹을 스팟 인스턴스로 시작하면 Amazon EMR은 최고 스팟 가격을 사용하여 가능한 한 많은 작업 노드를 프로비저닝합니다. 즉, 노드 6개로 구성된 작업 인스턴스 그룹을 요청했는데 스팟 최고 가격 이하로 사용할 수 있는 스팟 인스턴스가 5개만 있는 경우 Amazon EMR은 5개 노드로 인스턴스 그룹을 시작하고 가능한 경우 6번째 노드를 추가합니다.

작업 인스턴스 그룹을 스팟 인스턴스로 시작하는 방법은 비용을 최소화하면서 클러스터의 용량을 확장하는 전략적인 방법입니다. 온디맨드 인스턴스로 마스터 및 코어 인스턴스 그룹을 시작하는 경우에는 클러스터 실행 시 용량이 보장됩니다. 작업 인스턴스 그룹에 필요한 만큼 작업 인스턴스를 추가하여 피크 트래픽을 처리하거나 데이터 처리를 가속화할 수 있습니다.

콘솔, AWS CLI 또는 API를 사용하여 작업 노드를 추가 또는 제거할 수 있습니다. 또한 다른 작업 그룹을 추가할 수도 있지만, 작업 그룹은 일단 생성되고 나면 제거가 불가능합니다.

3.3 애플리케이션 시나리오를 위한 인스턴스 구성

3.3.1 시나리오별 권장사항

다음 표에는 일반적으로 다양한 애플리케이션 시나리오에 적합한 노드 유형 구매 옵션 및 구성에 대한 빠른 참조가 나와 있습니다. 각 시나리오 유형에 대한 추가 정보를 보려면 링크를 선택하십시오.

()	Master Node	코어 노드 구매 옵션	태스크 노드 구매 옵션
장기 실행 클러스터 및 데이터 웨어하우스	온디맨드	온디맨드 또는 인스턴스 집합 조합	스팟 도는 인스턴스 집합 조합
비용 기반 워크로드	스팟	스팟	스팟
데이터 크리티컬 워크로드	온디맨드	온디맨드	스팟 도는 인스턴스 집합 조합
애플리케이션 테스트	스팟	스팟	스팟

스팟 인스턴스가 Amazon EMR 클러스터를 실행하는 데 유용한 몇 가지 시나리오가 있습니다.

3.3.2 장기 실행 클러스터 및 데이터 웨어하우스

데이터 웨어하우스와 같이 예측 가능한 컴퓨팅 용량 변동이 있는 영구 Amazon EMR 클러스터를 실행하는 경우 스팟 인스턴스를 사용하여 더 낮은 비용으로 최대 수요를 처리할 수 있습니다. 마스터 및 코어 인스턴스 그룹을 온디맨드 인스턴스로 시작하여 일반 용량을 처리하고 작업 인스턴스 그룹을 스팟 인스턴스로 시작하여 피크 로드 요구 사항을 처리할 수 있습니다.

3.3.3 비용 기반 워크로드

완료 시간보다 비용을 낮추는 것이 더 중요한 일시적 클러스터를 실행 중이며 부분 작업 손실을 허용할 수 있는 경우, 전체 클러스터(마스터, 코어 및 작업 인스턴스 그룹)을 스팟 인스턴스로 실행하면 최대 비용 절감의 혜택을 얻을 수 있습니다.

3.3.4 데이터 크리티컬 워크로드

완료 시간보다 비용이 적게 드는 것이 더 중요하지만 일부 작업을 놓치는 것은 용납되지 않는 클러스터를 실행 중인 경우 마스터 및 코어 인스턴스 그룹을 온디맨드 인스턴스로 시작하고 하나 이상의 스팟 인스턴스 작업 인스턴스 그룹으로 보완하십시오. 마스터 및 코어 인스턴스 그룹을 온디맨드 인스턴스로 실행하면 데이터가 HDFS에 유지되고 스팟 시장 변동으로 인한 클러스터가 종료되지 않도록 보호되는 동시에 작업 인스턴스 그룹을 스팟 인스턴스로 실행함으로써 발생하는 비용을 절감할 수 있습니다.

3.3.5 애플리케이션 테스트

프로덕션 환경 내 시작을 준비하기 위해 새 애플리케이션을 테스트하려는 경우 전체 클러스터(마스터, 코어 및 작업 인스턴스 그룹)를 스팟 인스턴스로 실행하면 테스트 비용을 낮출 수 있습니다.

3.4 클러스터에 필요한 HDFS 용량 계산

클러스터에서 사용할 수 있는 HDFS.

• Amazon EC2.
• Amazon EC2. Linux Amazon EC2 Amazon EC2.
• 코어 노드에 연결된 Amazon EBS 볼륨의 수와 크기
• RAID형 중복성을 제공하기 위해 각 데이터 블록이 HDFS에 저장되는 방식을 의미하는 복제 인수. 기본적으로 복제 인수는 10개 이상의 코어 노드로 이루어진 클러스터의 경우 3이고, 4-9개 코어 노드로 구성된 클러스터의 경우 2이며, 3개 이하 노드로 구성된 클러스터의 경우 1입니다.

클러스터의 HDFS 용량을 계산하려면 각 코어 노드에 대해 인스턴스 스토어 볼륨 용량을 Amazon EBS 스토리지 용량 (사용하는 경우) 에 추가합니다. 이 결과에 코어 노드 수를 곱한 합계를 코어 노드 수에 따른 복제 인수로 나눕니다. 예를 들어 i2.xlarge 유형의 코어 노드가 10개 있고 Amazon EBS 볼륨이 연결되지 않은 800GB의 인스턴스 스토리지가 있는 클러스터의 경우 HDFS에 사용할 수 있는 총 약 2,666GB가 있습니다 (10노드 x 800GB ÷ 3 복제 요소).

계산된 HDFS 용량 값이 데이터보다 작으면 다음 방법으로 HDFS 스토리지의 양을 늘릴 수 있습니다.

• 추가 Amazon EBS 볼륨으로 클러스터를 생성하거나 Amazon EBS 볼륨이 연결된 인스턴스 그룹을 기존 클러스터에 추가
• 다른 코어 노드 추가
• Amazon EC2
• 데이터 압축 사용
• 하둡 구성 설정을 변경하여 복제 인수 낮추기

복제 인수를 낮추면 HDFS 데이터의 중복성과 손실/손상된 HDFS 블록으로부터의 클러스터 복구 기능이 감소되므로 이 기능은 각별히 주의해서 사용해야 합니다.

클러스터의 HDFS 용량을 정확히 계산하기는 어렵지만, 일반적으로는 프로젝트나 회사에서 예상되는 평균 사용량보다는 최대 수요(capacity)를 기준으로 계산한 뒤 이에 맞추어 데이터 노드 스펙을 결정하는 것이 바람직하다. 이후 데이터가 더 늘어나는 경우에는 점진적으로 확장하는 방식이 효율적이다. 다만, 한 번에 지나치게 많은 노드를 추가하면 리밸런싱에 따른 부담이 커질 수 있으므로, 데이터 사용량의 변동 폭이 큰 경우에는 최대값을 기준으로 설정해 두는 것이 안정적이다. 반대로 서비스 초기처럼 데이터 성장 패턴을 예측하기 어려운 상황에서는 큰 규모로 시작하기보다는 작게 구성한 뒤 필요할 때 확장하는 것이 더 유리하다.


HDFS 스토리지를 늘리는 방법은 단순히 노드를 추가하는 것 외에도 여러 가지가 있다. Amazon 환경에서는 EC2에 새로운 EBS 볼륨을 연결하여 기존 데이터 노드의 디스크 용량을 확장할 수 있다. 이는 데이터 노드의 스펙을 바꾸지 않고도 디스크 용량을 유연하게 늘릴 수 있는 방법이다. 또한 코어 노드를 추가하는 것은 곧 데이터 노드를 추가하는 것이므로, 디스크 용량뿐 아니라 CPU와 메모리 같은 컴퓨팅 자원이 지속적으로 부족할 때 선택할 수 있는 옵션이다.


만약 디스크 용량 부족이 주요 문제라면 데이터를 압축하는 것이 효과적인 해결책이 될 수 있다. 일반적으로 압축을 적용하면 최소 1/3에서 최대 1/5 수준까지 데이터 용량을 줄일 수 있으므로, CPU나 메모리보다 디스크 리소스가 병목이 되는 상황에서는 압축을 우선 적용하는 것이 권장된다. 마지막으로, 하둡 복제 인수를 줄이는 방법도 있지만 이는 데이터 중복성과 장애 복구 능력을 크게 저하시킬 수 있으므로 3 이하로 낮추는 것은 권장하지 않는다.


따라서 HDFS 용량 확장은 ① EBS 볼륨 추가, ② 코어 노드(=데이터 노드) 확장, ③ 데이터 압축 적용, ④ 복제 인수 조정이라는 네 가지 방법을 조합하여 상황에 맞게 선택할 수 있다.