Gridmix

Gridmix

GridMix는 Hadoop 클러스터용 벤치마크예요. 프로덕션 부하에서 채굴된 프로파일을 모델링한 합성 작업(synthetic jobs)의 혼합을 제출해요. 이 도구 버전은 프로덕션 작업의 리소스 프로파일을 모델링해 병목을 식별하고 개발을 안내하려 시도해요.

출처: 문서

본문

개요 (Overview)

GridMix는 Hadoop 클러스터용 벤치마크예요. 프로덕션 부하에서 채굴된 프로파일을 모델링한 합성 작업의 혼합을 제출해요. 이 버전의 도구는 프로덕션 작업의 리소스 프로파일을 모델링해 병목을 식별하고 개발을 안내하려 시도해요.

GridMix를 실행하려면 주어진 클러스터의 작업 혼합을 설명하는 MapReduce 작업 트레이스가 필요해요. 이런 트레이스는 보통 Rumen 이 생성해요. GridMix는 또한 합성 작업이 읽을 바이트를 제공할 입력 데이터가 필요해요. 합성 작업이 현재 바이너리 리더이므로 입력 데이터는 특별한 형식일 필요가 없어요. 새 클러스터에서 실행한다면 입력 데이터를 생성하는 선택적 단계가 실행에 앞설 수 있어요.

주어진 클러스터의 프로덕션 작업 부하를 같은 또는 다른 클러스터에서 에뮬레이션하려면 다음 단계를 따라요:

  1. 프로덕션 클러스터에서 작업 히스토리 파일을 찾아요. 이 위치는 클러스터의 mapreduce.jobhistory.done-dir 또는 mapreduce.jobhistory.intermediate-done-dir 구성 속성으로 지정돼요. (MapReduce historyserver는 작업 히스토리 파일을 mapreduce.jobhistory.done-dir에서 mapreduce.jobhistory.intermediate-done-dir로 이동해요.)
  2. Rumen을 실행해 전체 또는 선택 작업에 대한 JSON 형식의 작업 트레이스를 만들어요.
  3. 벤치마크 클러스터에서 작업 트레이스와 함께 GridMix를 사용해요.

GridMix가 제출한 작업은 "GRIDMIXnnnnnn" 형태의 이름을 가지며, 여기서 "nnnnnn"은 앞에 0이 채워진 시퀀스 번호예요.

사용법 (Usage)

Gridmix는 hadoop 하위 명령으로 제공돼요.

구성 파라미터 없는 기본 명령줄 사용법:

$ hadoop gridmix [-generate <size>] [-users <users-list>] <iopath> <trace>

구성 파라미터를 가진 기본 명령줄 사용법:

$ hadoop gridmix \
  -Dgridmix.client.submit.threads=10 -Dgridmix.output.directory=foo \
  [-generate <size>] [-users <users-list>] <iopath> <trace>

-Dgridmix.client.submit.threads=10과 -Dgridmix.output.directory=foo 같은 구성 파라미터는 다른 GridMix 파라미터보다 앞에 사용해야 해요.

<iopath> 파라미터는 GridMix의 작업 디렉터리예요. 이것은 로컬 파일시스템이나 HDFS에 있을 수 있지만, GridMix가 로컬 파일시스템과 HDFS에 각각 같은 부하를 주도록 원래 작업 혼합과 같게 하는 것을 강력히 권장해요.

-generate 옵션은 합성 작업용 입력 데이터와 Distributed Cache 파일을 생성하는 데 사용돼요. 표준 크기 접미사 단위를 받아들여요. 예를 들어 100g는 100 * 2^30 바이트의 입력 데이터를 생성해요. 압축 형식의 입력 데이터 최소 크기(기본 128MB)는 gridmix.min.file.size로 정의돼요.

<iopath>/input은 생성된 입력 데이터의 대상 디렉터리이자/또는 입력 데이터가 읽힐 디렉터리예요. HDFS 기반 Distributed Cache 파일은 분산 캐시 디렉터리 <iopath>/distributedCache 아래에 생성돼요. 일부 필요한 Distributed Cache 파일이 분산 캐시 디렉터리에 이미 존재한다면, -generate 옵션이 지정될 때 나머지 존재하지 않는 Distributed Cache 파일만 생성돼요.

-users 옵션은 users-list 파일을 가리키는 데 사용돼요 (Emulating Users and Queues 참고).

<trace> 파라미터는 Rumen이 생성한 작업 트레이스의 경로예요. 이 트레이스는 압축(클러스터가 지원하는 압축 코덱 중 하나로 읽을 수 있어야 함)되거나 압축되지 않을 수 있어요. GridMix의 표준 입력 스트림을 통해 압축되지 않은 트레이스를 전달하고 싶다면 이 파라미터의 값으로 "-"를 사용해요.

지원되는 구성 파라미터는 다음 섹션에서 설명해요.

일반 구성 파라미터 (General Configuration Parameters)

Parameter Description
gridmix.output.directory 출력이 기록될 디렉터리. 지정하면 iopath는 이 파라미터에 상대적이 돼요. 제출 사용자는 이 디렉터리에 읽기/쓰기 접근이 있어야 해요. 또한 사용자는 실행 중 발생할 수 있는 할당량(quota) 문제를 염두에 둬야 해요. 기본값은 "gridmix".
gridmix.client.submit.threads 클러스터에 작업을 제출하는 스레드 수. 이것은 또한 주어진 시점에 트레이스의 제출 시간을 기다리며 메모리에 로드될 split 수를 제어해요. Split은 제출 기한을 맞추기 위해 사전 생성되므로 특히 빽빽한 트레이스는 더 많은 제출 스레드가 필요할 수 있어요. 하지만 split을 메모리에 저장하는 것은 합리적으로 비싸므로 신중히 올려야 해요. SERIAL 작업-제출 정책(Job Submission Policies 참고)의 기본값은 1이고, 다른 정책에서는 클라이언트 머신의 프로세서 수보다 하나 더 많아요.
gridmix.submit.multiplier 작업 제출을 가속화하거나 감속하는 승수. 두 작업을 분리하는 시간에 이 계수가 곱해져요. 기본값은 1.0. 이것은 작업 트레이스를 클러스터에 맞게 크기 조정하는 조잡한 메커니즘이에요.
gridmix.client.pending.queue.depth split 생성 대기 중인 작업 설명 큐의 깊이. 트레이스에서 읽은 작업은 제출 스레드가 처리하기 전에 이 깊이의 큐를 차지해요. 이것은 보통 구성하지 않아요. 기본값은 5.
gridmix.gen.blocksize 생성된 데이터의 블록 크기. 기본값은 256 MiB.
gridmix.gen.bytes.per.file 파일당 최대 쓰기 바이트. 기본값은 1 GiB.
gridmix.min.file.size 입력 파일의 최소 크기. 기본 제한은 128 MiB. 상대적으로 작은 입력 데이터셋으로 GridMix를 테스트하는 동안 "Found no satisfactory file" 같은 오류 메시지가 보이면 이 파라미터를 조정해요.
gridmix.max.total.scan 입력 파일의 최대 크기. 기본 제한은 100 TiB.
gridmix.task.jvm-options.enable Gridmix가 원래 작업(즉 트레이스를 통해)에서 얻은 값을 사용해 시뮬레이션된 태스크의 최대 heap 옵션을 구성하게 해줌.

작업 유형 (Job Types)

GridMix는 작업 트레이스, 본질적으로 JSON 인코딩된 작업 설명의 스트림을 입력으로 받아요. 각 작업 설명에 대해 제출 클라이언트는 원래 작업 제출 시간을 얻고, 그 작업의 각 태스크에 대해 읽고 쓴 바이트·레코드 수를 얻어요. 이 데이터가 주어지면 트레이스에 기록된 것과 같은 바이트·레코드 패턴의 합성 작업을 구성해요. 두 가지 유형의 작업을 구성해요:

Job Type Description
LOADJOB Rumen 트레이스에 언급된 작업 부하를 에뮬레이션하는 합성 작업. 현재 버전에서 I/O를 지원해요. 벤치마크 클러스터에서 I/O 작업 부하를 재현해요. 각 map·reduce 태스크의 상세 I/O 정보(읽고 쓴 바이트·레코드 수)를 각 작업의 입력 split에 임베드해 그렇게 해요. map 태스크는 중간 map 출력 데이터를 통해 reduce 태스크의 I/O 패턴을 더 전달해요.
SLEEPJOB 각 태스크가 프로덕션 트레이스에서 관찰된 특정 시간 동안 아무것도 하지 않고 sleep만 하는 합성 작업. ResourceManager의 확장성은 종종 매초 처리할 수 있는 하트비트 수에 의해 제한돼요. (하트비트는 NodeManager가 상태를 갱신하고 ResourceManager에서 새 작업을 가져오기 위해 보내는 주기적 메시지예요.) 벤치마크 클러스터는 보통 프로덕션 클러스터 크기의 일부이므로 슬레이브 노드가 생성하는 하트비트 트래픽은 프로덕션 클러스터 수준보다 훨씬 낮아요. 한 가지 가능한 해결책은 각 슬레이브 노드에서 여러 NodeManager를 실행하는 것이에요. 이것은 합성 작업이 생성하는 I/O 작업 부하가 슬레이브 노드를 망칠 것이라는 명백한 문제로 이어져요. 그래서 그런 작업이 필요한 거예요.

작업 유형에 영향을 주는 구성 파라미터:

Parameter Description
gridmix.job.type 이 키의 값은 LOADJOB 또는 SLEEPJOB 중 하나. 기본값은 LOADJOB.
gridmix.key.fraction LOADJOB 유형 작업에서 키 데이터에 사용되는 레코드의 비율. 기본값은 0.1.
gridmix.sleep.maptask-only SLEEPJOB 유형 작업에서 작업의 reduce 태스크를 무시할지 여부. 기본값은 false.
gridmix.sleep.fake-locations SLEEPJOB 유형 작업에서 map 태스크용 가짜(fake) 위치 수. 기본값은 0.
gridmix.sleep.max-map-time SLEEPJOB 유형 작업에서 map 태스크의 최대 실행 시간 (밀리초). 기본값은 무제한.
gridmix.sleep.max-reduce-time SLEEPJOB 유형 작업에서 reduce 태스크의 최대 실행 시간 (밀리초). 기본값은 무제한.

작업 제출 정책 (Job Submission Policies)

GridMix는 작업 제출 속도를 제어해요. 이 제어는 트레이스 정보에 기반하거나 ResourceManager에서 수집한 통계에 기반할 수 있어요. 사용자가 정의한 제출 정책에 따라 GridMix는 각각의 알고리즘을 사용해 작업 제출을 제어해요. 현재 세 가지 유형의 정책이 있어요:

Job Submission Policy Description
STRESS 클러스터가 스트레스 상태로 유지되도록 작업을 계속 제출. 이 모드에서 클러스터의 실시간 부하를 모니터링해 작업 제출 속도를 제어해서 클러스터에 안정된 스트레스 수준의 작업 부하를 유지해요. 수집한 통계에 기반해 클러스터가 underloaded인지 overloaded인지 정의해요. 다음 세 가지 조건이 모두 참일 때만 클러스터를 underloaded로 간주해요: 대기·실행 중 작업 수가 임계값 TJ 아래, 대기·실행 중 map 수가 임계값 TM 아래, 대기·실행 중 reduce 수가 임계값 TR 아래. 임계값 TJ, TM, TR은 각각 클러스터 크기와 map, reduce 슬롯 용량에 비례해요. 클러스터가 overloaded인 경우 작업 제출을 조절해요. 실제 계산에서는 각 실행 작업을 남은 작업으로 가중하며, 즉 90% 완료된 작업은 계산에서 0.1로만 계산돼요. 마지막으로 매우 큰 작업이 다른 작업을 막지 않도록 각 작업이 기여할 수 있는 대기/대기 중 태스크 수를 제한해요.
REPLAY 이 모드에서 작업 트레이스를 충실히 재생해요. 실제 작업 트레이스에 주어진 시간 간격을 정확히 따르는 모드예요.
SERIAL 이 모드에서 이전에 제출된 작업이 완료된 후에만 다음 작업을 제출해요.

작업 제출 정책에 영향을 주는 구성 파라미터:

Parameter Description
gridmix.job-submission.policy 이 키의 값은 세 가지 중 하나: STRESS, REPLAY 또는 SERIAL. 대부분의 경우 키의 값은 STRESS 또는 REPLAY. 기본값은 STRESS.
gridmix.throttle.jobs-to-tracker-ratio STRESS 모드에서 클러스터가 overloaded로 간주되기 위한 실행 작업과 NodeManager의 최소 비율. 이것은 앞서 언급한 임계값 TJ. 기본값은 1.0.
gridmix.throttle.maps.task-to-slot-ratio STRESS 모드에서 클러스터가 overloaded로 간주되기 위한 대기·실행 중 map 태스크(즉 미완료 map 태스크)와 map 슬롯의 최소 비율. 이것은 앞서 언급한 임계값 TM. 실행 중 map 태스크는 부분적으로 계산돼요. 예를 들어 40% 완료된 map 태스크는 0.6 map 태스크로 계산돼요. 기본값은 2.0.
gridmix.throttle.reduces.task-to-slot-ratio STRESS 모드에서 클러스터가 overloaded로 간주되기 위한 대기·실행 중 reduce 태스크(즉 미완료 reduce 태스크)와 reduce 슬롯의 최소 비율. 이것은 앞서 언급한 임계값 TR. 실행 중 reduce 태스크는 부분적으로 계산돼요. 예를 들어 30% 완료된 reduce 태스크는 0.7 reduce 태스크로 계산돼요. 기본값은 2.5.
gridmix.throttle.maps.max-slot-share-per-job STRESS 모드에서 overload 계산에서 작업의 미완료 map 태스크에 카운트될 수 있는 클러스터 map-슬롯 용량의 최대 비율. 기본값은 0.1.
gridmix.throttle.reducess.max-slot-share-per-job STRESS 모드에서 overload 계산에서 작업의 미완료 reduce 태스크에 카운트될 수 있는 클러스터 reduce-슬롯 용량의 최대 비율. 기본값은 0.1.

사용자와 큐 에뮬레이션 (Emulating Users and Queues)

전형적인 프로덕션 클러스터는 종종 서로 다른 사용자들과 공유되며, 클러스터 용량은 작업 큐를 통해 서로 다른 부서로 나뉘어요. 모든 사용자의 작업 간 공정성을 보장하고, 큐 용량 할당 정책을 존중하며, 잘못된 동작의 작업이 클러스터를 장악하는 것을 피하는 것은 Hadoop 소프트웨어에 상당한 복잡성을 더해요. 이 영역의 충돌을 충분히 테스트하고 버그를 발견하려면 GridMix는 서로 다른 사용자 및/또는 서로 다른 큐에 제출된 작업의 경합을 에뮬레이션해야 해요.

여러 큐를 에뮬레이션하는 것은 쉽다 — 벤치마크 클러스터를 프로덕션 클러스터와 같은 큐 구성으로 설정하고 합성 작업이 트레이스에 기록된 것과 같은 큐에 제출되도록 구성하면 돼요. 하지만 트레이스에 나타난 모든 사용자가 벤치마크 클러스터에 계정을 가진 것은 아니에요. 대신 여러 개의 테스트 사용자 계정을 설정하고 트레이스의 각 고유 사용자를 라운드-로빈 방식으로 테스트 사용자와 연결해요.

사용자와 큐의 에뮬레이션에 영향을 주는 구성 파라미터:

Parameter Description
gridmix.job-submission.use-queue-in-trace true로 설정하면 트레이스에 언급된 것과 정확히 같은 큐 집합을 사용해요. 기본값은 false.
gridmix.job-submission.default-queue 모든 작업이 제출될 기본 큐를 지정. 이 파라미터가 지정되지 않으면 GridMix는 클러스터에서 제출 사용자에 대해 정의된 기본 큐를 사용해요.
gridmix.user.resolve.class 사용할 UserResolver 구현을 지정. 현재 세 가지 구현이 있어요: org.apache.hadoop.mapred.gridmix.EchoUserResolver - 원래 작업을 제출한 사용자로 작업을 제출. 이 경우 작업 트레이스에서 식별된 프로덕션 클러스터의 모든 사용자가 벤치마크 클러스터에도 계정을 가져야 해요. org.apache.hadoop.mapred.gridmix.SubmitterUserResolver - 모든 작업을 현재 GridMix 사용자로 제출. 이 경우 트레이스의 모든 사용자를 현재 GridMix 사용자에 매핑하고 작업을 제출해요. org.apache.hadoop.mapred.gridmix.RoundRobinUserResolver - 트레이스 사용자를 라운드-로빈 방식으로 테스트 사용자에 매핑. 이 경우 여러 테스트 사용자 계정을 설정하고 트레이스의 각 고유 사용자를 라운드-로빈 방식으로 테스트 사용자와 연결해요. 기본값은 org.apache.hadoop.mapred.gridmix.SubmitterUserResolver.

gridmix.user.resolve.class가 org.apache.hadoop.mapred.gridmix.RoundRobinUserResolver로 설정되면 테스트 사용자 목록이 있는 users-list 파일을 정의해야 해요. 이것은 GridMix에 -users 옵션으로 지정돼요. 라운드-로빈 user-resolver를 사용할 때 -users 옵션으로 users-list 파일을 지정하는 것은 필수예요. 다른 user-resolver는 이 옵션을 무시해요.

users-list 파일은 한 줄에 한 사용자이며, 각 줄은 다음 형식이에요:

<username>

예:

user1
user2
user3

위 예제에서 user1, user2, user3 세 사용자를 정의했어요. 이제 트레이스의 각 고유 사용자를 위 사용자에게 라운드-로빈 방식으로 연결해요. 예를 들어 트레이스 사용자가 tuser1, tuser2, tuser3, tuser4, tuser5라면 매핑은 다음과 같아요:

tuser1 -> user1
tuser2 -> user2
tuser3 -> user3
tuser4 -> user1
tuser5 -> user2

하위 호환성 때문에 users-list 파일의 각 줄은 username[,group]* 형태의 사용자 이름 뒤에 그룹 이름을 포함할 수 있어요. 그룹 이름은 Gridmix가 무시해요.

분산 캐시 부하 에뮬레이션 (Emulating Distributed Cache Load)

Gridmix는 LOADJOB 유형의 작업에 대해 기본적으로 Distributed Cache 부하를 에뮬레이션해요. 이것은 별도의 MapReduce 작업의 일부로 모든 시뮬레이션 작업에 필요한 Distributed Cache 파일을 사전 생성해 수행해요. gridmix 시뮬레이션 작업에서 Distributed Cache 부하 에뮬레이션은 gridmix.distributed-cache-emulation.enable 속성을 false로 구성해 비활성화할 수 있어요. 하지만 gridmix의 Distributed Cache 데이터 생성은 -generate 옵션에 의해 구동되며 이 구성 속성과는 독립적이에요. Distributed Cache 파일 생성과 Distributed Cache 부하 에뮬레이션 모두 다음 경우에 비활성화돼요: 입력 트레이스가 파일 대신 표준 입력 스트림에서 오거나, 지정된 <iopath>가 로컬 파일시스템에 있거나, 분산 캐시 디렉터리(즉 <iopath>/distributedCache)의 상위 디렉터리 중 하나(분산 캐시 디렉터리 포함)에 others에 대한 실행 권한이 없을 때.

시뮬레이션 작업의 구성 (Configuration of Simulated Jobs)

Gridmix3는 시뮬레이션 작업에서 일부 구성 속성을 설정해 입력 Job trace의 해당 Job에 다시 매핑할 수 있게 해요. 이 구성 파라미터에는 다음이 포함돼요:

Parameter Description
gridmix.job.original-job-id 이 시뮬레이션 작업에 해당하는 원래 클러스터 작업의 job id
gridmix.job.original-job-name 이 시뮬레이션 작업에 해당하는 원래 클러스터 작업의 job name

압축/압축해제 에뮬레이션 (Emulating Compression/Decompression)

MapReduce는 데이터 압축과 압축해제를 지원해요. MapReduce 작업에 대한 입력은 압축될 수 있어요. 마찬가지로 Map과 Reduce 태스크의 출력도 압축될 수 있어요. GridMix의 압축/압축해제 에뮬레이션은 중요해요. 압축/압축해제를 에뮬레이션하면 태스크의 CPU와 메모리 사용에 영향을 미치기 때문이에요. 압축/압축해제를 에뮬레이션하는 태스크는 같은 노드에서 실행되는 다른 태스크와 데몬에 영향을 미칠 거예요.

gridmix.compression-emulation.enable이 true로 설정되면 압축 에뮬레이션이 활성화돼요. 기본적으로 압축 에뮬레이션은 LOADJOB 유형의 작업에 활성화돼요.

압축 에뮬레이션이 활성화되면 GridMix는 일정한 압축 비율의 압축된 텍스트 데이터를 생성해요. 따라서 시뮬레이션된 GridMix 작업은 실제 작업에서 관찰된 압축 비율과 무관하게 압축 가능한 텍스트 데이터(일정한 압축 비율)를 사용해 압축/압축해제를 에뮬레이션해요.

전형적인 MapReduce 작업은 다음 단계에서 데이터 압축/압축해제를 다뤄요:

  • 작업 입력 데이터 압축해제 (Job input data decompression): GridMix는 압축 에뮬레이션이 활성화되면 압축 가능한 입력 데이터를 생성해요. 원래 작업의 구성에 기반해 시뮬레이션된 GridMix 작업은 압축된 입력 데이터를 읽는 데 압축해제기를 사용할 거예요. 현재 GridMix는 mapreduce.input.fileinputformat.inputdir을 사용해 원래 작업이 압축된 입력 데이터를 사용했는지 여부를 결정해요. 원래 작업의 입력 파일이 압축되지 않았다면 시뮬레이션된 작업은 압축해제기를 사용하지 않고 압축된 입력 파일을 읽을 거예요.
  • 중간 데이터 압축/압축해제 (Intermediate data compression and decompression): 원래 작업이 map 출력 압축을 활성화했다면 GridMix도 시뮬레이션된 작업의 map 출력 압축을 활성화해요. 그에 따라 reducer는 압축해제기를 사용해 map 출력 데이터를 읽을 거예요.
  • 작업 출력 데이터 압축 (Job output data compression): 원래 작업의 출력이 압축됐다면 GridMix도 시뮬레이션된 작업의 작업 출력 압축을 활성화해요.

압축 에뮬레이션에 영향을 주는 구성 파라미터: 기본값은 true. 압축 에뮬레이션이 켜진 상태에서 GridMix는 압축된 입력 데이터를 생성할 거예요. 따라서 입력 데이터의 총 크기는 예상 크기보다 작을 거예요. GridMix가 압축을 올바르게 에뮬레이션할 수 있게 하려면 gridmix.min.file.size를 더 작은 값(대략 gridmix.gen.bytes.per.file의 10%)으로 설정해요.

High-Ram 작업 에뮬레이션 (Emulating High-Ram jobs)

MapReduce는 사용자가 작업을 High-Ram 작업으로 정의할 수 있게 해줘요. High-Ram 작업의 태스크는 태스크 프로세스에서 더 큰 비율의 메모리를 차지할 수 있어요. 이 동작을 에뮬레이션하는 것은 다음 이유로 중요해요:

  • 스케줄러에 대한 영향 (Impact on scheduler): High-Ram 작업의 태스크 스케줄링은 리소스 예약과 활용을 초래할 수 있으므로 스케줄링 동작에 영향을 미쳐요.
  • 노드에 대한 영향 (Impact on the node): High-Ram 태스크는 더 큰 메모리를 차지하므로 NodeManager는 이 태스크에 추가 리소스를 할당하기 위해 일부 부기(bookkeeping)를 수행해요. 따라서 이것은 높은 메모리 요구를 가진 태스크를 High-Ram 태스크로 간주해야 하는 메모리 에뮬레이션의 선구자가 돼요.

High-Ram 기능 에뮬레이션은 gridmix.highram-emulation.enable을 false로 설정해 비활성화할 수 있어요.

리소스 사용 에뮬레이션 (Emulating resource usages)

CPU, 물리 메모리, 가상 메모리, JVM heap 같은 리소스의 사용은 MapReduce가 태스크 카운터로 기록해요. 이 정보는 GridMix가 시뮬레이션된 태스크의 리소스 사용을 에뮬레이션하는 데 사용해요. 리소스 사용 에뮬레이션은 GridMix가 실제 클러스터에서 보인 것과 유사한 부하를 테스트 클러스터에 가하는 데 도움을 줘요. MapReduce 태스크는 전체 수명 동안 리소스를 사용해요. GridMix는 또한 리소스 사용 에뮬레이션을 시뮬레이션된 태스크의 전체 수명에 걸쳐 펼쳐 이 동작을 모방하려 해요.

각 에뮬레이션할 리소스에는 연관된 에뮬레이터가 있어야 해요. 각 에뮬레이터는 org.apache.hadoop.mapred.gridmix.emulators.resourceusage.ResourceUsageEmulatorPlugin 인터페이스를 구현해야 해요.

GridMix의 리소스 에뮬레이터는 매 실행 전에 구성(플러그 인/아웃)할 수 있는 플러그인들이에요. GridMix 사용자는 gridmix.emulators.resource-usage.plugins 파라미터의 값으로 에뮬레이터의 쉼표로 구분된 목록을 전달해 여러 에뮬레이터 플러그인을 구성할 수 있어요. GridMix와 함께 제공되는 에뮬레이터 목록:

  • 누적 CPU 사용 에뮬레이터 (Cumulative CPU usage emulator): GridMix는 Rumen이 발행한 누적 CPU 사용 값을 사용해 시뮬레이션된 태스크의 총 누적 CPU 사용이 Rumen이 발행한 값에 가깝도록 해요. gridmix.emulators.resource-usage.plugins 파라미터에 대해 구성된 에뮬레이터 플러그인 목록에 org.apache.hadoop.mapred.gridmix.emulators.resourceusage.CumulativeCpuUsageEmulatorPlugin을 추가해 GridMix가 누적 CPU 사용을 에뮬레이션하도록 구성할 수 있어요. CPU 사용 에뮬레이터는 태스크의 특정 진행 경계에서만 에뮬레이션하도록 설계됐어요. 이 간격은 gridmix.emulators.resource-usage.cpu.emulation-interval로 구성할 수 있어요. 이 파라미터의 기본값은 0.1, 즉 10%예요.
  • 총 heap 사용 에뮬레이터 (Total heap usage emulator): GridMix는 Rumen이 발행한 총 heap 사용 값을 사용해 시뮬레이션된 태스크의 총 heap 사용이 Rumen이 발행한 값에 가깝도록 해요.

단순화 가정 (Simplifying Assumptions)

GridMix는 커뮤니티의 피드백과 패치를 통합하며 단계적으로 개발될 거예요. 현재 그 의도는 MapReduce와 HDFS 성능을 평가하는 것이며 그 위의 계층(즉 광범위한 lib 및 하위 프로젝트 공간)은 아니에요. 이 두 가지 제한을 고려할 때, 작업 부하의 다음 특성은 현재 작업 트레이스에 포착되지 않으며 GridMix에서 정확히 재현될 수 없어요:

  • 파일시스템 속성 (Filesystem Properties): 블록 크기, 네임스페이스 계층, 또는 주어진 태스크에서 소비·방출된 바이트/레코드 외의 입력·중간·출력 데이터의 어떤 속성도 일치시키려 시도하지 않아요. 이것은 시스템의 가장 많이 사용되는 부분 중 일부 — 텍스트 처리, 스트리밍 등 — 이 현재 구현으로 의미 있게 테스트될 수 없음을 의미해요.
  • I/O 속도 (I/O Rates): 레코드가 소비/방출되는 속도는 reader/writer의 속도에 의해서만 제한되고 태스크 동안 일정하다고 가정돼요.
  • 메모리 프로파일 (Memory Profile): 태스크의 시간에 따른 메모리 사용에 대한 데이터는 없지만, 최대 heap 크기는 유지돼요.
  • 편향 (Skew): 주어진 태스크에서 소비·방출되는 레코드는 관찰된 평균을 따른다고 가정돼요. 즉 레코드는 실제 세계에서 보일 수 있는 것보다 더 규칙적일 거예요. 각 map은 각 reduce에 대해 비례적인 비율의 데이터를 생성하므로, 불균형 입력의 작업은 평탄화될 거예요.
  • 작업 실패 (Job Failure): 사용자 코드는 올바르다고 가정돼요.
  • 작업 독립성 (Job Independence): 한 작업의 출력이나 결과는 후속 작업이 언제 또는 실행되는지에 영향을 주지 않아요.

부록 (Appendix)

더 오래된 버전의 GridMix 도구가 존재해요. GridMix1, GridMix2, GridMix3의 원래 구현을 추적하는 이슈는 Apache Hadoop MapReduce JIRA에서 찾을 수 있어요. GridMix의 현재 개발을 추적하는 다른 이슈는 Apache Hadoop MapReduce JIRA를 검색해 찾을 수 있어요.

더 알아보기 (Learn more)