Dynamometer 가이드

Dynamometer는 Hadoop의 HDFS NameNode를 성능 테스트하는 도구예요. 목표는 프로덕션 파일시스템 이미지에 대해 NameNode를 초기화하고 NameNode의 감사(audit) 로그 등을 통해 수집된 프로덕션 워크로드를 재생해 실제 환경을 제공하는 것이에요.

출처: 문서

본문

개요 (Overview)

Dynamometer는 Hadoop의 HDFS NameNode를 성능 테스트하는 도구예요. 목표는 프로덕션 파일시스템 이미지에 대해 NameNode를 초기화하고 NameNode의 감사 로그 등을 통해 수집된 프로덕션 워크로드를 재생해 실제 환경을 제공하는 것이에요. 이것은 특성이 프로덕션에서 겪는 것과 유사할 뿐만 아니라 실제로 동일한 워크로드를 재생할 수 있게 해줘요.

Dynamometer는 단일 NameNode와 구성 가능한 수의 DataNode를 시작하는 YARN 애플리케이션을 실행해, 전체 HDFS 클러스터를 단일 애플리케이션으로 시뮬레이션해요. 추가로 MapReduce 작업으로 실행되는 워크로드 작업이 있는데, 감사 로그를 입력으로 받아 그 안에 포함된 정보를 사용해 NameNode에 일치하는 요청을 제출해 서비스에 부하를 유발해요.

Dynamometer는 이 같은 워크로드를 서로 다른 Hadoop 버전이나 다른 구성으로 실행할 수 있어서, 실제 대규모 클러스터에 배포할 필요 없이 구성 조정과 코드 변경을 규모에 맞게 테스트할 수 있게 해줘요.

이 문서 전반에서 "Dyno-HDFS", "Dyno-NN", "Dyno-DN"은 Dynamometer 애플리케이션 안에서 시작되는 HDFS 클러스터, NameNode, DataNode(각각)를 가리켜요. 한정어 없이 쓰인 HDFS, YARN, NameNode 같은 용어는 Dynamometer가 실행되는 기존 인프라를 가리켜요. Dynamometer가 어떻게 동작하는지(사용법이 아닌)에 대한 자세한 내용은 이 페이지 끝의 Architecture 섹션을 참고하세요.

요구사항 (Requirements)

Dynamometer는 YARN 애플리케이션을 기반으로 하므로 실행에는 기존 YARN 클러스터가 필요해요. 또한 통신용 임시 파일을 저장할 수반하는 HDFS 인스턴스도 필요해요.

빌드 (Building)

Dynamometer는 세 개의 주요 컴포넌트로 구성되며 각각 고유한 모듈에 있어요:

Infrastructure (dynamometer-infra): Dyno-HDFS 클러스터를 시작하는 YARN 애플리케이션.
Workload (dynamometer-workload): 감사 로그를 재생하는 MapReduce 작업.
Block Generator (dynamometer-blockgen): 각 Dyno-DN의 입력 파일을 생성하는 MapReduce 작업. 그 실행은 infrastructure 애플리케이션을 실행하기 위한 전제 단계예요.

이 모든 컴포넌트의 컴파일된 버전은 표준 Hadoop 배포판에 포함돼요. 패키지된 배포판의 share/hadoop/tools/dynamometer에서 찾을 수 있어요.

설정 단계 (Setup Steps)

Dynamometer 애플리케이션을 시작하기 전에 완료해야 하는 여러 설정 단계가 있어요. Dynamometer에 어떤 구성을 사용할지, 어떤 버전을 사용할지, 로드할 때 어떤 fsimage를 사용할지 등을 지시해요. 이 단계들은 한 번 수행해 모든 것을 배치한 다음, 그에 대해 약간의 수정으로 여러 Dynamometer 실행을 수행해 변동을 측정할 수 있어요.

아래에서 논의하는 스크립트는 배포판의 share/hadoop/tools/dynamometer/dynamometer-{infra,workload,blockgen}/bin 디렉터리에서 찾을 수 있어요. 해당 Java JAR 파일은 share/hadoop/tools/lib/ 디렉터리에서 찾을 수 있어요. 아래의 bin 파일 참조는 현재 작업 디렉터리가 share/hadoop/tools/dynamometer라고 가정해요.

1단계: 필수 파일 준비 (Step 1: Preparing Requisite Files)

첫 Dyno-HDFS 클러스터를 시작하기 전에 여러 단계가 필요해요.

2단계: FsImage 파일 준비 (Step 2: Prepare FsImage Files)

NameNode에서 fsimage와 관련 파일을 수집해요. 여기에는 NameNode가 checkpointing의 일부로 만드는 fsimage_TXID 파일, 이미지의 md5 해시를 담은 fsimage_TXID.md5, 일부 메타데이터를 담은 VERSION 파일, 그리고 오프라인 이미지 뷰어를 사용해 fsimage로부터 생성할 수 있는 fsimage_TXID.xml 파일이 포함돼요:

hdfs oiv -i fsimage_TXID -o fsimage_TXID.xml -p XML

Secondary/Standby NameNode가 있다면 그곳에서 이 파일들을 수집하는 것을 권장해요. Active NameNode에 추가 부하를 주지 않기 위해서요. 이 모든 파일은 각 작업들이 접근할 수 있는 HDFS의 어딘가에 배치해야 해요. 모두 같은 폴더에 있어야 해요. 예: hdfs:///dyno/fsimage.

이 모든 단계는 upload-fsimage.sh 스크립트로 자동화할 수 있어요. 예:

./dynamometer-infra/bin/upload-fsimage.sh 0001 hdfs:///dyno/fsimage

여기서 0001은 원하는 fsimage의 트랜잭션 ID예요. 스크립트의 사용 정보에서 자세한 내용을 확인하세요.

3단계: Hadoop 바이너리 준비 (Step 3: Prepare a Hadoop Binary)

Dyno-NN과 -DN을 시작하는 데 사용할 Hadoop 배포 tarball을 수집해요.

4단계: 구성 준비 (Step 4: Prepare Configurations)

Dyno-HDFS 클러스터에 사용할 Hadoop 구성을 준비하고, Dynamometer가 Dyno-NN·Dyno-DN 실행과 관련해 어떤 설정을 사용할지 지정해요.

5단계: 블록 생성 작업 실행 (Step 5: Execute the Block Generation Job)

위에 업로드된 XML 파일을 사용해 블록 목록을 생성해요:

-fsimage_input_path hdfs:///dyno/fsimage/fsimage_TXID.xml
-block_image_output_dir hdfs:///dyno/blocks
-num_reducers R
-num_datanodes D

이 예제에서 위에 업로드된 XML 파일은 hdfs:///dyno/blocks에 블록 목록을 생성하는 데 사용돼요. R개의 reducer가 작업에 사용되고, D개의 블록 목록이 생성돼요 — 이것은 Dyno-HDFS 클러스터에서 몇 개의 Dyno-DN이 시작되는지 결정해요.

6단계: 감사 트레이스 준비 (선택) (Step 6: Prepare Audit Traces (Optional))

이 단계는 Dynamometer의 감사 트레이스 재생 기능을 사용하려는 경우에만 필요해요. 단지 Dyno-HDFS 클러스터를 시작하려는 경우 다음 섹션으로 건너뛰어도 돼요.

감사 트레이스 재생은 매퍼당 하나의 입력 파일을 받으며, 현재 auditreplay.command-parser.class 구성으로 구성 가능한 두 가지 입력 형식을 지원해요. 시작 시 지정된 감사 로그 디렉터리 안의 모든 감사 로그 파일에 대해 하나의 매퍼가 자동으로 생성돼요.

기본은 직접 형식인 org.apache.hadoop.tools.dynamometer.workloadgenerator.audit.AuditLogDirectParser예요. 이것은 표준 구성 감사 로거가 생성하는 형식의 파일을 받아들여요. 예를 들어 다음과 같은 줄:

1970-01-01 00:00:42,000 INFO FSNamesystem.audit: allowed=true	ugi=hdfs	ip=/127.0.0.1	cmd=open	src=/tmp/foo	dst=null	perm=null	proto=rpc

이 형식을 사용할 때는 auditreplay.log-start-time.ms도 지정해야 해요. 이것은 (Unix epoch 이후 밀리초로) 감사 트레이스의 시작 시간이어야 해요. 모든 매퍼가 단일 시작 시간에 동의하도록 필요해요. 예를 들어 위 줄이 첫 감사 이벤트라면 auditreplay.log-start-time.ms=42000을 지정해요. 파일 내에서 감사 로그는 오름차순 타임스탬프 순서여야 해요.

다른 지원 형식은 org.apache.hadoop.tools.dynamometer.workloadgenerator.audit.AuditLogHiveTableParser예요. 이것은 출력 필드가 있는 Hive 쿼리가 생성하는 형식의 파일을 받아들이는데, 순서대로:

relativeTimestamp: 트레이스 시작부터의 이벤트 시간 오프셋 (밀리초)
ugi: 제출 사용자의 사용자 정보
command: 명령 이름, 예: 'open'
source: 소스 경로
dest: 대상 경로
sourceIP: 소스 IP

예시 쿼리:

SELECT (timestamp - ${startTimestamp} AS relativeTimestamp, ugi, command, source, dest, sourceIP
FROM '${auditLogTableLocation}'
WHERE timestamp >= ${startTimestamp} AND timestamp < ${endTimestamp}
DISTRIBUTE BY src
SORT BY relativeTimestamp ASC;

감사 로그 파티셔닝 (Partitioning the Audit Logs)

위에 표시된 Hive 쿼리에 호출자의 소스 IP로 출력 파일을 파티셔닝해야 함을 나타내는 DISTRIBUTE BY src 절이 있음을 알 수 있어요. 이것은 단일 클라이언트에서 시작된 요청의 더 가까운 순서를 유지하려는 목적이에요. Dynamometer는 파티션 내에서도 연산의 엄격한 순서를 보장하지 않지만, 순서는 일반적으로 파티션 간보다 파티션 내에서 더 가깝게 유지돼요.

Hive를 사용하든 원시 감사 로그를 사용하든, 워크로드 재생을 수행하는 데 필요한 동시 클라이언트 수에 따라 감사 로그를 파티셔닝해야 해요. 파티션 키로 소스 IP를 사용하는 것은 위에서 논의한 잠재적 이점이 있는 한 가지 접근 방식이지만, 어떤 파티션 스킴도 합리적으로 잘 동작해야 해요.

Dynamometer 실행 (Running Dynamometer)

위 설정 단계를 완료하면 Dyno-HDFS 클러스터를 시작하고 그에 대해 워크로드를 재생할 준비가 된 거예요! Dyno-HDFS YARN 애플리케이션을 실행하는 클라이언트는 Dyno-HDFS 클러스터가 완전히 시작된 후 워크로드 재생 작업을 선택적으로 실행할 수 있어요. 이것은 각 재생을 클라이언트의 단일 실행으로 만들어 다양한 구성 테스트를 쉽게 해줘요. 두 가지를 별도로 실행해 더 많은 제어를 할 수도 있어요. 마찬가지로 Dynamometer/YARN이 제어하지 않는 외부 NameNode에 대한 Dyno-DN을 실행하는 것도 가능해요. 이것은 아직 지원되지 않는 NameNode 구성(예: HA NameNodes)을 테스트하는 데 유용할 수 있어요. 외부 NameNode의 service RPC 주소를 가리키는 값으로 -namenode_servicerpc_addr 인수를 infrastructure 애플리케이션에 전달해 할 수 있어요.

수동 워크로드 실행 (Manual Workload Launch)

먼저 infrastructure 애플리케이션을 실행해 내부 HDFS 클러스터의 시작을 개시해요. 예:

./dynamometer-infra/bin/start-dynamometer-cluster.sh
    -hadoop_binary_path hadoop-3.0.2.tar.gz
    -conf_path my-hadoop-conf
    -fs_image_dir hdfs:///fsimage
    -block_list_path hdfs:///dyno/blocks

이것은 필수 인수를 보여줘요. 추가 사용법 정보는 -help 플래그로 실행하면 돼요. 클라이언트는 Dyno-NN의 시작 진행 상황과 몇 개의 Dyno-DN이 live로 간주하는지 추적해요. Dyno-NN이 safemode를 벗어나 사용할 준비가 될 때 로깅으로 알려줘요. 이 시점에 워크로드 작업(map-only MapReduce 작업)을 실행할 수 있어요. 예:

./dynamometer-workload/bin/start-workload.sh
    -Dauditreplay.input-path=hdfs:///dyno/audit_logs/
    -Dauditreplay.output-path=hdfs:///dyno/results/
    -Dauditreplay.num-threads=50
    -nn_uri hdfs://namenode_address:port/
    -start_time_offset 5m
    -mapper_class_name AuditReplayMapper

워크로드 생성 유형은 구성 가능해요. AuditReplayMapper는 앞서 논의한 대로 감사 로그 트레이스를 재생해요. AuditReplayMapper는 구성으로 구성돼요. auditreplay.input-path, auditreplay.output-path, auditreplay.num-threads는 감사 로그 파일의 입력 경로, 결과의 출력 경로, map 태스크당 스레드 수를 지정하는 데 필요해요. input-path의 파일 수와 같은 수의 map 태스크가 실행돼요. 각 태스크는 이 입력 파일 중 하나를 읽고 num-threads 스레드를 사용해 그 파일에 포함된 이벤트를 재생해요. 감사 로그 이벤트를 원래 발생했던 것과 같은 속도로 충실히 재생하기 위해 최선의 노력을 해요 (선택적으로 auditreplay.rate-factor를 지정해 조정할 수 있는데, 이것은 재생 속도에 대한 곱셈 계수로 예를 들어 2.0을 사용하면 원래 속도의 2배로 이벤트를 재생해요).

AuditReplayMapper는 벤치마크 결과를 출력 디렉터리의 part-r-00000 파일에 CSV 형식으로 출력해요. 각 줄은 user,type,operation,numops,cumulativelatency 형식이며, 예를 들어 hdfs,WRITE,MKDIRS,2,150이에요.

통합 워크로드 실행 (Integrated Workload Launch)

infrastructure 애플리케이션 클라이언트가 워크로드를 자동으로 실행하게 하려면 워크로드 작업의 파라미터를 infrastructure 스크립트에 전달해요. 현재 이 방식에서는 AuditReplayMapper만 지원돼요. 위와 같은 파라미터로 통합 애플리케이션을 실행하려면 다음을 사용할 수 있어요:

./dynamometer-infra/bin/start-dynamometer-cluster.sh
    -hadoop_binary hadoop-3.0.2.tar.gz
    -conf_path my-hadoop-conf
    -fs_image_dir hdfs:///fsimage
    -block_list_path hdfs:///dyno/blocks
    -workload_replay_enable
    -workload_input_path hdfs:///dyno/audit_logs/
    -workload_output_path hdfs:///dyno/results/
    -workload_threads_per_mapper 50
    -workload_start_delay 5m

이 방식으로 실행하면 클라이언트는 워크로드가 완료되면 Dyno-HDFS 클러스터의 종료를 자동으로 처리해요. 지원되는 파라미터의 전체 목록은 -help 플래그로 실행해 확인하세요.

아키텍처 (Architecture)

Dynamometer는 YARN 위의 애플리케이션으로 구현돼요. Dynamometer 애플리케이션에는 세 개의 주요 행위자가 있어요:

Infrastructure는 시뮬레이션된 HDFS 클러스터예요.
Workload는 시뮬레이션된 NameNode에 부하를 생성하기 위해 HDFS 클라이언트를 시뮬레이션해요.
driver는 다른 두 컴포넌트를 조정해요.

driver에 캡슐화된 로직은 사용자가 단일 명령으로 Dynamometer의 전체 테스트 실행을 수행할 수 있게 해주며, 최적 구성을 찾기 위해 서로 다른 파라미터를 훑는 것 같은 일을 가능하게 해요.

infrastructure 애플리케이션은 네이티브 YARN 애플리케이션으로 작성되며, 단일 NameNode와 수많은 DataNode가 실행되고 함께 연결돼 완전히 시뮬레이션된 HDFS 클러스터를 만들어요.

Dynamometer가 매우 사실적인 시나리오를 제공하려면 NameNode의 관점에서 프로덕션 클러스터와 같은 정보를 포함하는 클러스터가 필요해요. 이것이 위에서 설명한 설정 단계가 먼저 프로덕션 NameNode에서 FsImage 파일을 수집해 호스트 HDFS 클러스터에 배치하는 것과 관련된 이유예요.

전체 클러스터만큼의 블록을 복사하지 않기 위해 Dynamometer는 블록에 실제로 저장된 데이터는 블록 메타데이터만 아는 NameNode에 무관하다는 사실을 활용해요. Dynamometer의 blockgen 작업은 먼저 Offline Image Viewer를 사용해 FsImage를 XML로 바꾼 다음, 이를 파싱해 각 블록의 메타데이터를 추출하고, 시뮬레이션된 DataNode가 소비하도록 이 정보를 HDFS에 배치하기 전에 파티셔닝해요. SimulatedFSDataset이 DataNode 스토리지 계층을 우회하고 이전 단계에서 추출한 정보에서 로드된 블록 메타데이터만 저장하는 데 사용돼요. 이 방식은 메타데이터의 크기가 데이터 자체보다 수 자릿수 작기 때문에 Dynamometer가 각 물리 노드에 많은 시뮬레이션된 DataNode를 담을 수 있게 해줘요.

프로덕션 환경과 일치하는 스트레스 테스트를 만들려면 Dynamometer는 프로덕션 워크로드에 대한 정보를 수집하는 방법이 필요해요. 이 정보는 NameNode 감사 로그에서 얻을 수 있으며, 앞서 설명한 workoutloader가 이를 재생해요.

외부 리소스 (External Resources)

Dynamometer에 대한 더 많은 정보는 초기 릴리스를 발표한 블로그 게시물이나 이 발표 를 볼 수 있어요.

더 알아보기 (Learn more)

원문: 문서