Amazon EMR 재구성을 통한 신속한 클러스터 수정

장기 실행 중인 Amazon EMR 클러스터를 사용하는 개발자 또는 데이터 과학자는 워크로드가 빠르게 변화하는 상황을 접하게 됩니다. 이러한 워크로드의 변화는 종종 클러스터에서 최적화된 실행을 위해 별도의 애플리케이션 구성을 필요로 합니다.

이제 재구성 기능을 사용해서 실행 중인 EMR 클러스터의 구성을 변경할 수 있습니다. EMR 릴리스 emr-5.21.0부터 이 기능을 사용해서 새 클러스터를 생성하거나 각 노드에 수동으로 SSH 접속하지 않더라도 구성을 수정할 수 있습니다.

이 게시물에서는 다음 내용을 다룹니다.

재구성 사용
인스턴스 그룹 상태, 구성 버전 및 이벤트
재구성 사용 사례 예시
재구성의 이점

재구성 사용

다음과 작업이 EMR release emr-5.21.0에서 업데이트되었습니다.

재구성 제출
구성 수정
구성 수준 정의

재구성 제출

EMR 콘솔, SDK 또는 AWS CLI를 사용하여 재구성을 제출할 수 있습니다. 자세한 내용은 재구성 제출 및 추가 정보를 참조하십시오.

구성 수정

재구성을 제출할 경우 클러스터에 적용하고자 하는 모든 구성을 포함해야 합니다. 이러한 항목에 대해서만 업데이트가 적용되며 그외 모든 항목은 제거됩니다. EMR 콘솔에서 구성을 수정할 경우에는 이전 클러스터 구성을 추적해서 반영됩니다.

구성 수준 정의

애플리케이션에 대해서 클러스터 수준 및 인스턴스 그룹 수준 구성을 정의 할 수 있습니다. 클러스터를 생성시에 클러스터 수준의 구성을 제공할 수 있습니다. 그러면 클러스터가 실행된 후에 추가된 인스턴스 그룹을 비롯한 모든 인스턴스 그룹에 이러한 구성이 자동으로 적용됩니다. 구성이 시작된 후에는 클러스터 수준 구성을 수정할 수 없습니다. 그러나 재구성 요청을 통해 인스턴스 그룹 수준에서 해당 구성을 보충하거나 재정의할 수 있습니다. 인스턴스 그룹에 대한 재구성 요청을 제출할 때마다 이러한 새 인스턴스 그룹 수준 구성에는 상속된 클러스터 수준 구성보다 높은 우선 순위로 설정됩니다.

클러스터 수준 및 인스턴스 그룹 수준 구성이 인스턴스 그룹에서 함께 작동하는 방식을 더 잘 이해하기 위해 EMR 콘솔에서 간단한 데모를 살펴보겠습니다.

[구성] 탭의 [필터] 드롭다운 목록에서 인스턴스 그룹을 선택합니다. 원하는 인스턴스 그룹의 구성 테이블로 이동합니다. 구성 테이블의 [소스] 열은 현재 구성 수준을 나타냅니다.

이 클러스터는 클러스터 수준 구성 세트로 시작합니다.

[
  {
    "Classification": "core-site",
    "Properties": {
      "Key-A": "Value-1",
      "Key-B": "Value-2"
    }
  }
]

콘솔에서 볼 수 있는 바와 같이 인스턴스 그룹 ig-Y4E3MN8C4YBP는 클러스터 수준 구성 세트를 자동으로 상속했습니다. 이제 다음과 같이 인스턴스 그룹을 재구성합니다.

[
  {
    "Classification": "core-site",
    "Properties": {
      "Key-A": "Value-a",
      "Key-C": "Value-3"
    }
  }
]

이 요청이 수신되면 구성 “Key-A”의 값이 인스턴스 그룹 수준 구성에 의해 재정의되고 “Value-1”에서 “Value-a”로 변경됩니다. 이와 대조적으로, 구성 “Key-B”의 값은 변경되지 않은 상태로 유지됩니다. 한편, 사용자의 요청은 새로운 보조 구성 “Key-C”를 도입합니다. 콘솔의 구성 테이블은 항상 이러한 유형의 미묘한 변경 사항을 표시합니다.

클러스터 수준 및 인스턴스 그룹 수준 구성을 사용자 정의하는 방법에 대한 자세한 내용은 클러스터를 생성할 때 구성 제공을 참조하십시오.

인스턴스 그룹 상태, 구성 버전 및 이벤트

재구성 요청의 상태는 인스턴스 그룹 상태 전환, 구성 버전 증가 및 CloudWatch 이벤트에 나타납니다. 각 항목이 재구성 요청에 대한 추적 상태를 유지하는 원리를 이해해야 합니다.

인스턴스 그룹 상태: 인스턴스 그룹은 재구성 요청을 수신한 후 RUNNING 상태에서 RECONFIGURING 상태로 전환합니다. RECONFIGURING 상태는 재구성 프로세스의 시작을 나타냅니다. 프로세스가 완료되고 구성이 적용된 후에는 인스턴스 그룹이 RUNNING 상태로 복귀합니다. 그런 다음에는 애플리케이션의 웹 UI 또는 애플리케이션 특정 명령을 통해 구성을 확인할 수 있습니다.
구성 버전: 사용자가 제출한 모든 재구성 요청은 새로운 버전 번호로 구분되는 새 구성 세트를 설정합니다. 구성 버전은 0에서부터 시작하며 사용자가 제출한 새 구성 세트마다 1이 증가합니다. 각 인스턴스 그룹은 해당 구성 버전 번호를 유지합니다. 버전 번호는 서로 다른 인스턴스 그룹을 재구성한 횟수에 따라 증가합니다.
이벤트: EMR은 각 재구성 요청의 상태를 Amazon CloudWatch 이벤트로 게시합니다. 이러한 이벤트는 요청이 제출되고, 재구성 작업이 시작 및 만료된 정확한 시기를 보여줍니다. 손쉬운 추적을 위해 각 요청은 관련 구성 버전과 함께 게시됩니다. 예를 들어, 다음 이벤트 플로는 EMR이 인스턴스 그룹에서 전형적인 재구성 요청을 실행하는 과정을 보여줍니다.

재구성 작업에 대한 EMR 이벤트 및 인스턴스 그룹 상태 전환의 전체 목록은 EMR Management Guide를 참조하십시오.

재구성 사용 사례 예시

다음은 재구성 작업의 몇 가지 사용 사례 예시입니다.

HDFS 블록 크기 재구성
용량 스케줄러 대기열 구성

HDFS 블록 크기 재구성

변동이 심한 워크로드를 처리해야 하는 경우가 있습니다. 이러한 변동은 클러스터의 수명 내내 새로운 애플리케이션 구성을 필요로 할 수 있습니다.

예를 들어, 장기 실행 중인 클러스터에서 워크로드와 파일 크기가 최근에 증가했다고 가정해 보겠습니다. 그리고 귀사는 현재 클러스터를 교체하지 않고 이 증가에 대응하고자 합니다.

더 나은 성능을 위해 HDFS 블록 크기를 증가 시키려면 새 재구성 기능을 활용할 수 있습니다. HDFS NameNode는 클러스터의 각 데이터 블록을 추적합니다. 이 블록 크기를 늘리면 NameNode에서 관찰해야 하는 블록의 수가 감소하므로 HDFS 성능이 향상될 수 있습니다. 그 뿐 아니라, 이 기능은 필요한 매퍼의 수를 줄임으로써 작업 성능을 개선해 줍니다.

HDFS 블록 크기를 기본값인 128GB에서 256GB로 늘리려면 동일한 노드를 실행하는 마스터 인스턴스 그룹에 재구성 요청을 제출합니다.

$ aws emr modify-instance-groups --cli-input-json file://reconfiguration.json

다음은 reconfiguration.json 파일의 예입니다.

reconfiguration.json:
{
  "ClusterId": "j-MyClusterID",
  "InstanceGroups": [
  {
    "InstanceGroupId": "ig-MyMasterId",
    "Configurations": [
    {
      "Classification": "hdfs-site",
      "Properties": {
        "dfs.blocksize": "256m"
      },
    "Configurations": []
    }]
  }]
}

그러면 EMR 재구성 프로세스에서 hdfs-size.xml 파일 내의 “dfs.blocksize” 파라미터를 제공된 “256m” 값으로 수정합니다. 또한 재구성 프로세스는 새 구성을 적용하기 위해 NameNode를 자동으로 재시작합니다. 클러스터에 추가된 모든 새 블록은 새 기본 블록 크기인 256MB를 자동으로 사용합니다. 기존 블록에 이 기본값이 적용되게 하려면 다음 단계를 따릅니다.

블록을 새 위치로 복사합니다.
원래 블록을 삭제합니다.
블록을 다시 원래 위치로 복사합니다.

복원된 블록에는 새 기본 블록 크기가 적용됩니다. 재시작되는 동안 잠시 NameNode가 비활성 상태가 됩니다.

용량 스케줄러 대기열 구성

서로 다른 Hadoop 작업 간에 전략을 공유하는 클러스터 리소스를 변경하려고 합니까? 실행 중인 클러스터의 YARN CapacityScheduler 구성을 수정하려고 합니까? 다른 조직과 함께 관리하는 대형 공유 클러스터에 새 대기열을 추가하려고 합니까? 변화하는 워크로드를 수용하기 위해 서로 다른 대기열 간의 용량 할당을 변경하려고 합니까?

EMR 재구성 기능을 사용하면 마스터 노드에 재구성 요청을 제출함으로써 변경을 수행할 수 있습니다. 새 구성은 수 분 내에 대기열에 적용됩니다. 마스터 노드에 로그인하여 구성 파일을 직접 업데이트 하거나 수동으로 대기열을 새로고침 하는 번거로운 작업이 필요 없습니다.

EMR 클러스터는 기본적으로 단일 대기열을 포함합니다. 두 개의 추가 대기열(알파 및 베타)를 생성하고 각 대기열에 총 리소스 가용량의 30%를 각각 할당할 수 있습니다. 다음은 이러한 변경을 수행하기 위해 재구성 요청을 제출하는 명령어 예시입니다.

$ aws emr modify-instance-groups --cli-input-json file://reconfiguration.json

다음은 reconfiguration.json 파일의 예입니다.

reconfiguration.json:
{
   "ClusterId":"j-MyClusterID",
   "InstanceGroups":[
      {
         "InstanceGroupId":"ig-MyMasterId",
         "Configurations":[
            {
               "Classification":"capacity-scheduler",
               "Properties":{
                  "yarn.scheduler.capacity.root.queues":"default,alpha,beta",
                  "yarn.scheduler.capacity.root.default.capacity":"40",
                  "yarn.scheduler.capacity.root.default.accessible-node-labels.CORE.capacity":"40",
                  "yarn.scheduler.capacity.root.alpha.capacity":"30",
                  "yarn.scheduler.capacity.root.alpha.accessible-node-labels":"*",
                  "yarn.scheduler.capacity.root.alpha.accessible-node-labels.CORE.capacity":"30",
                  "yarn.scheduler.capacity.root.beta.capacity":"30",
                  "yarn.scheduler.capacity.root.beta.accessible-node-labels":"*",
                  "yarn.scheduler.capacity.root.beta.accessible-node-labels.CORE.capacity":"30"
               },
               "Configurations":[]
            }
         ]
      }
   ]
}

“*” 레이블에 대한 액세스 권한은 두 대기열 모두에 제공되므로 각 대기열은 레이블이 지정된 코어 노드에 액세스할 수 있습니다. 또한 모든 대기열 가용량의 합계는 100이 되어야 합니다. 기본 대기열의 가용량은 40%로 줄어듭니다.

마지막으로, 코어 레이블에 대한 각 대기열의 액세스 가용량은 대기열 자체의 가용량과 일치합니다. 이는 대기열 간의 코어 파티션 분할이 클러스터의 나머지와 동일한 비율로 이루어짐을 의미합니다.

이 단계를 완료한 후에는 YARN ResourceManager 웹 UI로 이동하여 수정 내용이 적용되었는지 확인합니다.

EMR 재구성의 이점

EMR 재구성의 이점은 다음과 같습니다.

롤링 재구성 프로세스
재구성 실패 및 복귀

롤링 재구성 프로세스

EMR 재구성의 주요 이점 중 하나는 롤링 재구성 프로세스입니다. 문서에는 다음과 같이 설명되어 있습니다.

“Amazon EMR은 작업 및 코어 인스턴스 그룹의 인스턴스를 재구성할 때 ‘롤링’ 프로세스를 따릅니다. 한 번에 인스턴스 그룹 내의 인스턴스 중 10%만이 수정 및 재시작됩니다. 이 프로세스는 완료하는 데 시간이 더 걸리지만 실행 중인 클러스터에서 발생할 수 있는 애플리케이션 실패의 가능성을 줄여줍니다.”

롤링 재구성은 재구성 동안 코어 노드의 90%가 실행 상태를 유지하도록 함으로써 HDFS 다운타임이 발생하지 않도록 보호해 줍니다. 추가적으로, EMR 기반의 YARN에는 NodeManager 복구 기능이 활성화되어 있습니다. NodeManager는 재구성 재시작 후 실행 중인 컨테이너를 복구합니다.

컨테이너는 항상 활성 상태이므로 일부 MapReduce 작업은 재구성 프로세스 동안 계속 실행될 수 있습니다. 그러나 재시작 후 모든 애플리케이션을 복구할 수 있는 것은 아닙니다. 예를 들어, YARN 기반의 Spark(EMR 기본값)에서는 NodeManager 재시작 후 실행자 문제 및 작업 실패가 발생할 수 있습니다.

프로덕션 환경에서 재구성을 수행하기 전에 안전한 환경에서 수행하려는 유형의 재구성을 애플리케이션에서 테스트하십시오.

마지막으로, 롤링 재구성 프로세스는 인스턴스 그룹의 구성 상태에 대한 일시적인 불일치를 유발할 수 있습니다. 불일치된 동안, 일부 인스턴스는 이전 구성을 가지는 동시에 다른 인스턴스는 새로 요청된 구성을 가질 수 있습니다. 클러스터를 재구성할 때에는 이러한 상황으로 인해 발생할 수 있는 부작용을 고려해야 합니다.

재구성 실패 및 복귀

또한 EMR은 인스턴스 그룹을 재구성 실패로부터 복구할 수 있습니다.

새 구성을 적용하기 위해 EMR에서는 재구성된 애플리케이션을 재시작하고 해당 애플리케이션이 실행 중인지 확인한 후 재구성 작업의 완료를 선언합니다.

그러나 어떤 노드에서라도 애플리케이션이 재시작에 실패하는 경우 재구성 작업은 실패하고 인스턴스 그룹은 RECONFIGURING 상태로 유지됩니다. 이러한 실패는 문제가 있는 구성 값에 의해 발생할 수 있습니다. 예를 들어, `yarn.resourcemanager.scheduler.address`에 대한 잘못된 값은 YARN ResourceManager의 재시작 실패를 유발할 수 있습니다.

이러한 경우 EMR은 자동으로 구성 복귀를 트리거 합니다. 복귀는 인스턴스 그룹에서 이전에 작동 했던 구성 세트를 재적용합니다. 복귀는 복귀 작업이 완료되는 즉시 인스턴스 그룹 상태를 RUNNING 상태로 되돌립니다. 따라서 인스턴스 그룹은 작동 상태로 돌아가고 클러스터에서의 애플리케이션 가용성을 유지합니다. 롤링 재구성은 프로세스 내내 계속됩니다.

이전에 작동했던 구성을 재적용한 후에도 애플리케이션이 시작되지 않는 경우, EMR은 추가적으로 재구성을 시도하지 않고 인스턴스 그룹을 ARRESTED 상태에 배치합니다. 인스턴스 그룹을 ARRESTED 상태에서 해제하려면 새로운 재구성 요청을 제출합니다.

요약

이 게시물에서는 새 EMR 클러스터 재구성 기능을 사용하여 인스턴스 그룹을 구성하거나 클러스터를 실행하는 방법에 대한 기본적인 내용을 살펴보았습니다. 재구성 요청 제출의 추가적인 의미와 중요한 구성 수준 개념 및 재구성 추적을 위한 여러 방법을 단계별로 소개했습니다. 재구성의 실제 예시를 소개했으며 두 가지 유용한 재구성 기능을 다루었습니다.

새로운 클러스터 재구성 기능을 사용해 보고 아래의 댓글을 통해 여러분의 경험을 공유해 주시기 바랍니다!