하둡 완벽 가이드 - 10. 하둡 클러스터 설정

사용자의 입장으로만 하둡을 바라보게 되어 깊이가 부족하다는 생각을 하게 되었다.
하둡 완벽 가이드를 읽고 이해한대로 정리한다.

---

하둡 클러스터는 직접 구축하는 방법과 클라우드 호스팅 방식으로 제공되는 하둡 서비스를 이용하는 방법 두가지로 크게 나뉘어진다.

10장에서는 하둡 클러스터를 자체적으로  구축하는 방법에 대해 소개한다.
하둡 클러스터를 자체적으로 구축하는 방법에도 다음과 같은 방법이 존재한다.
(1) 바이너리 형태로 아파치 하둡 프로젝트에서 직접 제공하는 아파치 타르볼
(2) 아파치 빅탑 프로젝트를 이용해 설치할 수 있는 RPM과 데비안 패키지
(3) 클라우데라 매니저와 아파치 암바리 같은 하둡 클러스터의 설치 및 관리 기능을 제공하는 하둡 클러스터 관리 도구

10.1 클러스터 명세

하둡은 범용 하드웨어에서 구동되도록 설계되었다. 범용 하드웨어는 저급의 하드웨어 보다는 다양한 벤더로부터 쉽게 구할 수 있는 표준화된 하드웨어를 의미한다.

저급의 하드웨어가 클러스터에 성능에 좋지 않지만, 대용량 데이터베이스급의 컴퓨터도 비용 대비 성능이 좋지 않다. 소수의 컴퓨터로 충분한 기능을 커버할 수 있지만 컴퓨터 한 대의 장애가 클러스터에 미치는 영향이 크기 때문이다.
RAID를 사용하는 것도 얻을 수 있는 이익이 없다. HDFS 자체에서 각 블록을 여러 대의 노드에 복재하는 기능을 제공하므로 RAID 장치가 지원하는 중복성은 필요하지 않다. RAID striping 방식(RAID 0)은 심지어 HDFS블록을 모든 디스크에 라운드 로빈으로 배열하는 HDFS의 JBOD 방식보다 더 느리다. RAID 0의 읽기와 쓰기 동작은 RAID 배열의 가장 느린 디스크의 속도에 의해 제한받기 때문이다. 그리고 JBOD 환경에서 디스크 하나가 고장나면 HDFS는 고장난 디스크 없이도 동작하지만 RAID는 하나의 디스크 고장이 전체 디스크 배열을 불능 상태로 만들 수 있다. 

2021년 기준 컴퓨터의 사양은 다음과 같다.

10.1.1 클러스터 규모 결정

클러스터는 점점 커지므로, 처음에 결정하기는 어렵다. 따라서 '얼마나 빨리 클러스터가 커질 것인가?' 그리고 '그렇다면 어떻게 추가할 것인가?'를 고민해야한다. 고민을 함께 해보자.

마스터 노드 시나리오

네임노드, 보조 네임노드, 리소스 매니저, 히스토리 서버와 같은 마스터 데몬을 어떤 노드에서 실행할지는 클러스터 규모에 따라 다르다.

• 10대 정도 수준의 작은 클러스터: 네임노드와 리소스 매니저를 단일 마스터 컴퓨터에서 동시에 구동해도 된다.
• 더 큰 클러스터: 네임노드가 전체 네임스페이스의 파일 및 블록에 대한 메타데이터를 모두 메모리에 보관해야 하므로 상당한 용량의 메모리가 필요해 클러스터 전체 노드 수가 계속 증가한다면 분리해야한다. 보조 네임노드 역시 동일하다. 

또한 HDFS와 YARN이 마스터 데몬을 활성-대기 쌍으로 실행할 수 있는 설정 (고가용성)을 지원하기 때문에도 분리하기도 한다.

10.1.2 네트워크 토폴로지

일반적으로 하둡 클러스터 아키텍처는 랙과 노드 두 단계의 네트워크 토폴로지로 구성된다. 

랙 인식 기능

전체 클러스터가 단일 랙에서만 구동되지 않는다면 하둡의 성능을 최대로 끌어내기 위해서 하둡에 네트워크 토폴로지를 설정해야 한다. 네트워크 토폴로지를 설정하면 하둡이 맵리듀스 태스크를 최대한 가까운 노드에 전송되도록 하고 (같은 랙의 노드에 우선적으로 태스크를 전달한다) HDFS는 성능과 장애 복구의 균형을 유지하면서 복제소의 배치 작업을 지능적으로 수행한다.

노드와 랙 같은 네트워크의 위치 정보는 트리 형태로 표현되며, 각 위치 사이의 네트워크 '거리'를 반영할 수 있다. 

매핑 정보는 자바 인터페이스인 DNSToSwitchMapping에 기술하며, 해당 인터페이스 자체를 구현하는 경우는 거의 없고, 매핑 정보를 기술한 사용자 정의 스크립트를 실행하는 기본 구현체인 ScriptBasedMapping에 매핑할 호스트명이나 IP주소와 같은 다수의 인자를 전달받아 표준출력으로 내보낸다. 네임노드와 리소스 매니저는 이를 이용하여 워커 노드의 네트워크 위치 정보를 파악한다. 해당 스크립트 위치를 설정하지 않으면 모든 노드를 단일 네트워크 위치인 /default-rack으로 간주한다.

10.2 클러스터 설치 및 설정

아파치 하둡 배포판을 사용하여 하둡 클러스터를 설치하고 설정하는 방법에 대해 알아보자.

10.2.1 자바 설치

하둡은 자바가 설치된 유닉스 및 윈도우 운영 체제에서 실행된다. 하둡 배포판의 벤더가 인증한 운영 체제, 자바, 하둡의 조합을 반드시 확인하고 설치해야한다.

10.2.2 유닉스 사용자 계정 생성

동일한 컴퓨터에서 수행되는 다른 서비스와 하둡 프로세스를 구분하려면 하둡 전용 사용자 계정을 생성하는 것이 좋다. HDFS, 맵리듀스, YARN 서비스는 일반적으로 동일한 hadoop 그룹에 속한 hdfs, mapred, yarn과 같은 별도의 사용자 계정으로 실행된다.

10.2.3 하둡 설치

1. 아파치 하둡의 배포 페이지에서 하둡을 내려받은 후 /usr/local (혹은 /opt)과 같은 위치에서 압축을 푼다. 홈 디렉토리는 NFS로 마운트된 경우가 많으므로 하둡을 거기 설치하지 말자!
2. 하둡 파일의 소유자를 hadoop 사용자와 hadoop 그룹으로 변경하자
3. HADOOP_HOME을 지정하고 PATH를 설정한다.

10.2.4 SSH 구성

하둡 제어 스크립트는 SSH를 이용하여 전체 클러스터를 대상으로 작업을 수행하도록 개발되었다. 예를 들면 클러스터의 모든 데몬을 시작하고 중지하는 스크립트이다. 제어 스크립트 대신 전체 클러스터를 대상으로 분산 쉘이나 하둡 전용 관리 애플리케이션과 같은 방법을 쓸 수도 있다. 

원활한 작업을 위해 클러스터에 있는 모든 머신에서 hdfs와 yarn 사용자 계정이 암호 없이 접속 가능한 SSH 로그인을 설정하는게 좋다. 공개키/개인키 쌍을 만들어 NFS에 배치하고 클러스터의 모든 머신이 이를 공유하면 쉽다.

10.2.5 하둡 구성

10.3절에서 설명한다.

10.2.6 HDFS 파일시스템 포맷

HDFS를 처음 설치했으면 사용하기 전에 반드시 파일시스템을 포맷해야 한다. 포맷 작업은 새로운 빈 파일시스템을 생성하는 것으로, 저장 디렉터리와 네임노드 초기 버전의 영속적인 데이터 구조를 만드는 것이다.

hdfs namenode -format

이때, 네임노드가 파일시스템의 모든 메타데이터를 직접 관리하기 때문에 데이터노드는 초기 포맷 과정에 관여하지 않는다. 동일한 이유로 파일 시스템의 크기도 나중에 고려하면 된다.

10.2.7 데몬의 시작과 중지

10.2.4에서 소개한 스크립트를 (sbin 디렉터리에 위치) 사용하기 위해 클러스터에 어떤 컴퓨터들이 있는지 관리해야 한다. 이를 위해 slaves라는 파일에 컴퓨터의 목록을 한 행당 하나씩 호스트명이나 IP 주소를 이 파일에 기록한다. 이 파일은 네임노드와 리소스 매니저에서 수행되는 제어 스크립트에서만 사용되므로 모든 워커 노드로 배포할 필요는 없다.

start-dfs.sh # hdfs 데몬 시작

해당 스크립트에서 수행하는 작업은 다음과 같다.

1. hdfs getconf -namenodes 로 출력된 네임노드 시작
2. slaves 파일의 목록에 있는 각 컴퓨터에서 데이터 노드 시작
3. hdfs getconf -secondarynamenodes 명령을 실행하여 반환되는 컴퓨터에서 보조 네임노드 시작

start-yarn.sh # yarn 데몬 시작

리소스 매니저는 start-yarn.sh 스크립트가 수행된 머신에서만 실행된다. 수행하는 작업은 다음과 같다.

1. 로컬 컴퓨터에서 리소스 매니저를 시작한다.
2. slaves 파일의 목록에 있는 각 컴퓨터에서 노드 매니저를 실행한다.

중지를 위해서는 stop-dfs.sh, stop-yarn.sh 스크립트를 제공한다.

각 스크립트는 내부적로 hadoop-deamon.sh, yarn-deamon.sh 스크립트를 이용하여 하둡 데몬, YARN을 시작하고 중지한다.

mapred 계정으로 구동하는 MapReduce 데몬(잡 히스토리 서버)의 실행 방법은 다음과 같다.
mr-jobhistory-daemon.sh start historyserver

10.2.8 사용자 디렉터리 생성

하둡 클러스터를 구동했다면 사용자별로 홈 디렉터리를 생성하고 해당 디렉토리에 대한 소유 권한을 부여하면 된다.
특정 사용자의 디렉터리 용량을 제한할 수도 있다.

10.3 하둡 환경 설정

하둡 환경 설정에는 아래와 같은 파일들이 사용된다. 이 파일들은 하둡 기본 디렉터리 아래의 etc/hadoop/ 디렉토리에 있다. --config 옵션으로 (HADOOP_CONF_DIR 환경변수 설정과 동일한 기능) 로컬 파일시스템의 특정 디렉터리를 지정하여 데몬을 실행하면 설정 디렉터리를 다른 곳으로 옮길 수 있다.  -> 업그레이드 할 때 쉬워진다!

파일명	형식	설명
hadoop-env.sh	Bash 스크립트	하둡을 구동하는 스크립트에서 사용되는 환경변수
mapred-env.sh	Bash 스크립트	맵리듀스를 구동하는 스크립트에서 사용되는 환경변수 (hadoop-env.sh을 재정의)
yarn-env.sh	Bash 스크립트	YARN을 구동하는 스크립트에서 사용되는 환경변수 (hadoop-env.sh을 재정의)
core-site.xml	하둡 설정 XML	HDFS, 맵리듀스, YARN에서 공통적으로 사용되는 I/O 설정과 같은 하둡 코어를 위한 환경 설정 구성
hdfs-site.xml	하둡 설정 XML	네임노드, 보조 네임노드, 데이터노드 등과 같은 HDFS 데몬을 위한 환경 설정 구성
mapred-site.xml	하둡 설정 XML	잡 히스토리 서버 같은 맵리듀스 데몬을 위한 환경 설정 구성
yarn-site.xml	하둡 설정 XML	리소스 매니저, 웹 애플리케이션 프록시 서버, 노드 매니저와 같은 YARN 데몬을 위한 환경 설정 구성
slaves	일반 텍스트	데이터노드와 노드 매니저를 구동할 컴퓨터의 목록(행당 하나)
hadoop-metrics2.properties	자바 속성	메트릭의 표시를 제어하기 위한 속성
log4j.properites	자바 속성	시스템 로그, 네임노드 audit 로그, JVM 프로세스의 태스크 로그
hadoop-policy.xml	하둡 설정 XML	하둡을 보안 모드로 구동할 때 사용되는 접근제어 목록에 대한 환경 설정 구성

10.3.1 환경 설정 관리

하둡에서는 환경 설정 정보를 클러스터에 있는 각 하둡 노드가 가지고 있고, 이 파일들은 전체 관리자가 dsh나 pdsh 같은 병렬 쉘 도구를 이용해 동기화한다. 모든 마스터와 워커 컴퓨터가 하나의 환경 설정 파일 집합을 사용할 수 있도록 설계되었다. 전체 클러스터에 변경 내역을 적용하는 것은 클라우데라 매니저나 아파치 암바리와 같은 하둡 클러스터 관리 도구의 가장 큰 장점이다. 

one-size-fits-all 환경 설정 모델이 적합하지 않은 클러스터(ex, 클러스터 확장을 위해 추가하려는 컴퓨터의 사양이 다른 경우)는 설정을 세분화할 수 있다. 컴퓨터의 "등급" 개념을 적용하여 등급별로 다른 환경 설정을 관리할 수 있따. 하둡 자체에서는 등급별 환경 설정 관리도구를 지원하지 않지만, 세프, 퍼펫, CFEngine, Bcfg2와 같은 도구를 쓸 수 있다.

클러스터 규모에 상관없이 모든 컴퓨터가 동기화되었다는 것을 보장하기 위해 하둡용 제어 스크립트 뿐만 아니라 클러스터 관리를 위한 설정 관리 도구를 사용하는 것이 좋다.

10.3.2 환경 설정

hadoop-env.sh 스크립트의 변수를 설정하는 방법을 다룬다. 맵리듀스와 YARN의 설정 파일은 각각 mapred-env.sh, yarn-env.sh이며, hadoop-env.sh에서 설정한 속성값을 재정의할 수 있다.

• JAVA_HOME: 자바 라이브러리 위치. 없다면 쉘 환경변수의 JAVA_HOME을 찾지만, 설정해주는 것이 전체 클러스터가 동일한 버전의 동일한 버전의 자바를 사용할 수 있도록 보장할 수 있다.
• HADOOP_HEAPSIZE: 하둡 데몬의 힙 크기. 하둡의 데몬당 기본 메모리의 크기는 1000MB(1G)이다. yarn-env.sh 스크립트에서 YARN_RESOURCE_HEAPSIZE를 설정하여 리소스 매니저의 힙 크기를 재정의할 수 있다. HDFS 데몬에 네임노드에 힙 메모리를 더 할당하는 환경변수가 없으므로, hadoop-env-sh의 HADOOP_NAMENODE_OPTS 속성에 JVM 옵션으로 메모리 용량을 설정해서 더 할당 해야한다. 보조 네임노드를 위해 반드시 HADOOP_SECONDARYNAMENODE_OPTS에도 동일하게 설정해야한다.
• HADOOP_LOG_DIR: 하둡이 생성하는 시스템 로그 파일이 저장되는 위치. 기본적으로 $HADOOP_HOME/logs에 저장되지만, 하둡 업그레이드 작업으로 설치 디렉토리가 변경된 후에도 로그 파일 위치를 동일하게 관리하기 위해 /var/log/hadoop 정도에 저장하는게 좋다.
  
  • .log : 애플리케이션의 log4j를 통해 출력되는 로그 메시지. 로그파일의 순환을 위해 일일 순환 파일 추가자를 사용한다. 하둡은 오래된 로그파일을 자동으로 삭제하지 않으므로, 보관 계획을 세워야한다.(그냥 하루에 하나씩 로그 파일을 만들어서 쌓는다는 뜻이다. https://jins-dev.tistory.com/entry/Log-Rotation-Roll-the-log-%EB%A1%9C%EA%B7%B8-%EB%A1%A4%EB%A7%81%EB%A1%9C%ED%85%8C%EC%9D%B4%EC%85%98%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC)
  • .out: 표준 출력과 표준 에러 로그가 함께 기록되는 로그파일. 보통 비어있거나 적은 양의 로그만 기록된다. 이 로그파일은 데몬이 재시작될 때만 순환되고 최근 다섯개의 로그만 보관한다. 파일명 끝에 1~5 번호가 붙으며 5가 가장 오래된 파일이다.
  • 파일명은 {데몬을 수행하는 사용자 이름}-{데몬 이름}-{머신의 호스트명}.{log|out}.{date_id} 이다. 실제로 모든 로그의 파일명은 유일하므로 클러스터에 속한 모든 머신의 로그를 모아서 하나의 디렉토리에 보관할 수도 있다. 
• HADOOP_INDENT_STRING: 데몬을 수행하는 사용자 이름 
• HADOOP_SSH_OPTS: SSH에 옵션을 설정. 타임아웃 시간을 정하는 ConnectTimeout, 알려진 호스트 파일에 새로운 호스트를 자동으로 추가하는 것을 제어할 수 있는 StrictHostKeyChecking 속성(기본은 ask, no로 설정하면 자동이다!) 등이 있다. 

10.3.3 중요한 하둡 데몬 속성

core-site.xml, hdfs-site.xml, yarn-site.xml에 설정한다.

The core-site.xml file informs Hadoop daemon where NameNode runs in the cluster. It contains the configuration settings for Hadoop Core such as I/O settings that are common to HDFS and MapReduce.

The hdfs-site.xml file contains the configuration settings for HDFS daemons; the NameNode, the Secondary NameNode, and the DataNodes. Here, we can configure hdfs-site.xml to specify default block replication and permission checking on HDFS. The actual number of replications can also be specified when the file is created. The default is used if replication is not specified in create time.

https://www.edureka.co/blog/explaining-hadoop-configuration/

HDFS

• core-site.xml
  • fs.defaultFS: HDFS의 네임노드와 기본 파일시스템 URI를 지정. (일반적으로는 네임노드와 기본 파일시스템 URI가 동일하지만, 다르게 지정할 수도 있음) URI의 호스트는 네임노드의 호스명이나 IP 주소고, 그 포트는 RPC(원격 프로시저 호출)를 위해 대기하는 네임노드의 포트 번호다. 기본은 8020 포트다. 상대경로도 가능하다. 
• hdfs-site.xml
  • dfs.namenode.name.dir: 영속적인 파일시스템의 메타데이터(에디트로그, 파일시스템 이미지)를 저장할 네임노드의 저장 디렉토리 목록으로 기본은 임시디렉토리 하위로 지정되어있다. NFS로 마운트된 원격 디스크뿐만 아니라 하나 이상의 로컬 디스크에 저장하여 장애에 대비할 수 있도록 설정을 권장함. 보조네임노드가 체크포인트를 수행하나, 최신 백업 데이터가 아니기 때문. 
    
    
  • dfs.datanode.data.dir: 데이터 노드가 블록을 저장할 콤마로 구분된 디렉토리 목록으로 기본은 임시디렉토리 하위로 지정되어있다. 여러개의 저장 디렉토리에 라운드 로빈 방식으로 쓰기 작업을 진행함. 
  • dfs.namenode.checkpoint.dir: 체크포인트 데이터가 저장될 콤마로 구분된 디렉토리 목록으로 기본은 임시디렉토리 하위로 지정되어있다. 장애를 대비해 여러 곳에 저장함

YARN

• yarn-site.xml
  • yarn.resourcemanager.hostname: 리소스 매니저를 수행할 머신의 호스트명이나 IP주소 목록.
  • yarn.resourcemanager.address: 리소스 매니저를 수행할 머신의 호스트-포트 쌍의 리스트 목록. 기본 호스트 값은 yarn.resourcemanager.hostname
  • yarn.nodemanager.local-dirs: YARN 컨테이너의 로컬 임시 저장소. 맵리듀스 작업이 수행되는 동안 중간 데이터 및 작업 파일이 임시로 저장되는 위치로, 가능한 모든 로컬 디스크를 사용하여 디스크 I/O가 분산되도록 해야한다. (역시 라운드 로빈!)
  • yarn.nodemanager.aux-services: 노드 매니저가 수행하는 보조 서비스 목록. YARN은 맵 출력을 리듀스 태스크에 제공하는 태스크 트래커가 없으므로, 노드 매니저에서 수행되는 보조 서비스인 셔플 핸들러를 사용해야한다. 맵리듀스는 mapreduce_shuffle, 스파크는 spark_shuffle.
• hdfs-site.xml
  • dfs.datanode.data.dir: 데이터 노드가 블록을 저장할 콤마로 구분된 디렉토리 목록으로 기본은 임시디렉토리 하위로 지정되어있다. 여러개의 저장 디렉토리에 라운드 로빈 방식으로 쓰기 작업을 진행함.

YARN 메모리 설정

메모리 매개변수를 설정할 때 작업이 실행되는 동안 태스크의 실제 메모리 사용량을 모니터링하면 유용하다. 맵리듀스의 태스크 카운터 PHYSICAL_MEMORY_BYTES, VIRTUAL_MEMORY_BYTES, COMMITED_HEAD_BYTES가 메모리 사용에 대한 스냅숏을 제공하므로 태스크 수행 과정을 관찰하기 적합하다.

• yarn-site.xml
  • yarn.nodemanager.resource.memory-mb: 노드 매니저가 수행할 컨테이너에 할당되는 물리 메모리 양. (기본값은 8192) 데이터 노드, 노드 매니저가 각각 사용하는 메모리와 그외 프로세스를 위한 충분한 메모리를 확보하고 설정하면 된다. 
  • yarn.nodemanager.vmem-pmem-ratio: 컨테이너가 지켜야하는 가상메모리 제약으로, 할당된 물리 메모리의 배수.
  • yarn.nodemanager.resource.cpu-vcores:
  • yarn.scheduler.minimum-allocation-mb: 메모리 할당의 최소 용량
  • yarn.scheduler.maximum-allocation-mb: 메모리 할당의 최대 용량
• mapred-site.xml
  • mapreduce.map.memory.mb, mapreduce.reduce.memory.mb: 컨테이너의 크기로, 애플리케이션 마스터가 클러스터에서 필요한 자원을 협상할 때, 노드 매니저가 태스크 컨테이너를 수행하고 모니터링할 때 사용한다.
  • mapreduce.child.java.opts: 맵과 리듀스 태스크를 실행하는 컨테이너 프로세스를 시작하는데 사용되는 JVM 옵션. 자바 프로세스의 힙 크기를 정할 수도 있고..
  • mapreduce.map.java.opts: 맵 태스크를 실행하는 자식 프로세스를 시작하는데 사용되는 JVM 옵션
  • mapreduce.reduce.java.opts: 리듀스 태스크를 실행하는 자식 프로세스를 시작하는데 사용되는 JVM 옵션
    • child.java.opt는 컨테이너, map.java.opt 와 reduce.java.opt는 프로세스에서 사용되는 JVM 옵션이다. 그러므로, child.java.opt + 오버헤드메모리로 map/reduce.java.opt 메모리를 커버할 수 있다.

YARN과 맵리듀스의 CPU 설정

YARN은 CPU 사용량에 대한 자원 관리도 수행한다. 애플리케이션은 YARN에게 필요한 코어 수를 요청할 수 있다. 스케줄링 하는 동안 코어 수는 기록되지만(CPU 코어가 남아있지 않은 머신에는 컨테이너가 할당되지 않는다.) 노드 매니저는 기본적으로 실행중인 컨테이너의 실제 CPU 사용률을 제한하지 않는다. 그러므로 컨테이너가 주어진 CPU보다 더 많은 CPU를 남용하여 같은 호스트의 다른 컨테이너가 CPU 자원을 못받게 할 수 있다. 

• yarn-site.xml
  • yarn.nodemanager.resource.cpu-vcores: 노드 매니저가 컨테이너에 할당하는 코어의 수. 머신의 전체 코어 수 - 머신에서 실행되는 각 데몬 프로세스(데이터노드, 노드 매니저, 다른 장기 수행 프로세스)수로 정한다.
  • yarn.nodemanager.containerexecutor.class: 리눅스 cgroup을 이용해 CPU 사용을 제어하기 위한 용도로 쓸 수 있는 옵션. 
• mapred-site.xml
  • mapreduce.map.cpu.vcores, mapreduce.reduce.cpu.vcores: 맵과 리듀스 컨테이너에 할당되는 CPU 코어의 수. 

10.3.4 하둡 데몬 주소 및 포트

하둡 데몬은 데몬 사이의 통신을 위한 RPC 서버와 사용자가 이용하는 웹 페이지를 제공하는 HTTP 서버를 일반적으로 모두 실행한다. 각각의 서버는 네트워크 주소와 대기하는 포트번호 설정으로 구성한다.

보통 서버의 RPC와 HTTP 주소를 설정하는 속성은 두가지 기능을 제공한다.
1. 서버가 연결할 네트워크 인터페이스를 결정
2. 사용자나 클러스터 내 다른 컴퓨터에서 서버로 접속하는 기능 

서버를 다수의 네트워크 인터페이스와 연결하는 것은 바람직하나, 서버의 네트워크 주소를 0.0.0.0으로 설정하면 두 번째 기능을 제공할 수 없다.
해결방법은 (1) 클라이언트와 서버를 위한 별도의 구성을 하는 것이다.
더 좋은 방법은 (2) yarn.resourcemanager.hostname을 외부에서 해석 가능한 호스트명이나 IP 주소로 설정하고, yarn.resourcemanager.bind-host를 0.0.0.0으로 설정한다.

리소스 매니저가 노드 매니저와 클라이언트에 해석 가능한 주소를 제공함과 동시에 컴퓨터상의 모든 주소와 바인드되는지 확인해야한다.

데이터 노드는 블록 전송을 위해 TCP/IP 서버도 실행한다. dfs.datanode.address 속성으로 설정하며 기본값은 0.0.0.0:50010 이다.

RPC 서버 속성

• hdfs-site.xml
  • dfs.namenode.rpc-bind-host: 네임노드의 RPC 서버가 바인드할 주소. 기본은 fs.defaultFS 속성의 값으로 정의된다.
  • dfs.datanote.ipc.address: 데이터노드의 RPC 서버 주소와 포트
• mapred-site.xml
  • mapreduce.jobhistory.address: 잡 히스토리 서버의 RPC 서버 주소와 포트. 클라이언트가 잡 히스토리를 쿼리하기 위해 사용
  • mapreduce.jobhistory.bind-host: 잡 히스토리 서버의 RPC와 HTTP 서버가 바인드할 주소
• yarn-site.xml
  • yarn.resourcemanager.hostname: 리소스 매니저가 수행될 머신의 호스트명
  • yarn.resourcemanager.bind-host: 리소스 매니저의 RPC와 HTTP 서버가 바인드 하는 주소
  • yarn.resourcemanager.address: 리소스 매니저의 RPC 서버 주소와 포트. 기본 8032 포트. 클라이언트가 리소스 매니저와 통신하기 위해 사용한다.
  • yarn.resourcemanager.admin.address: 리소스 매니저의 admin RPC 서버 주소와 포트. 기본 8030 포트. admin 클라이언트(일반적으로 클러스터 외부에서 yarn rmadmin으로 수행)가 리소스 매니저와 통신하기 위해 사용
  • yarn.resourcemanager.resource-tracker.address: 리소스 매니저 트래커의 RPC 서버 주소와 포트. 기본 8031 포트. 클러스터 내 노드 매니저가 리소스 매니저와 통신하기 위해 사용한다.
  • yarn.nodemanager.hostname: 노드매니저가 수행되는 머신의 호스트명
  • yarn.nodemanager.bind-host: 노드 매니저의 RPC와 HTTP 서버가 바인드할 주소
  • yarn.nodemanager.address: 노드 매니저의 RPC 서버 주소와 포트. 이 속성은 클러스터 내 애플리케이션 마스터가 노드 매니저와 통신하기 위해 서용한다.
  • yarn.nodemanager.localizer.address: 노드매니저 로컬라이저의 RPC 서버 주소와 포트

HTTP 서버 속성

• hdfs-site.xml
  • dfs.namenode.http-bind-host: 네임노드의 HTTP 서버가 바인드할 주소
  • dfs.datanote.http-address: 네임노드의 HTTP 서버 주소와 포트. 기본 50070 포트
  • dfs.namenode.secondary.http-address: 보조 네임노드의 HTTP 서버 주소와 포트
  • dfs.datanode.http.address: 네임노드의 HTTP 서버 주소와 포트. (네임노드의 속성명과 다르다! 실수했을까?)
• mapred-site.xml
  • mapreduce.jobhistory.webap.address: 맵리듀스 잡 히스토리 서버의 주소와 포트.
  • mapreduce.shulffle.port: 셔플 핸들러의 HTTP 포트 번호. 맵 출력을 처리하는데 사용되며, 웹 UI로 사용자가 접근할 수 없다. 
• yarn-site.xml
  • yarn.resourcemanager.webapp.address: 리소스 매니저의 HTTP 서버 주소 및 포트
  • yarn.nodemanager.webapp.address: 노드 매니저의 HTTP 서버 주소 및 포트
  • yarn.web-proxy.address: 웹 어플리케이션 프록시 서버의 HTTP 서버 주소와 포트. 설정하지 않으면 기본으로 웹 어플리케이션 프록시 서버가 리소스 매니저 프로세스 내에서 수행된다. 

또한 데이터 노드가 IP 주소(HTTP와 RPC 서버용)로 사용하는 네트워크 인터페이스를 제어하는 설정이 있다. 

10.3.5 다른 하둡 속성

• 클러스터 멤버십: 향후 노드 추가 및 삭제를 쉽게 하기 위해 데이터노드나 노드 매니저 역할로 클러스터에 연결이 인증된 컴퓨터 리스트
  • hdfs-site.xml의 dfs.hosts, yarn-site.xml의 yarn.resourcemanager.nodes.include-path로 지정이 가능
  • hdfs-site.xml의 dfs.hosts.exclude, yarn-site.xml의 yarn.resourcemanger.nodes.exclude-path로 제거가 가능
• 버퍼 크기: 하둡의 I/O 연산에 사용하는 버퍼
  • core-site.xml의 io.file.buffe.size 속성으로 바이트 단위로 설정
• HDFS 블록 크기: 블록의 크기를 설정해서 네임노드의 메모리 부담을 조절할 수 있다. 커질수록 매퍼가 더 많은 데이터를 처리하여 네임노드의 메모리 부담을 줄인다.
  • hdfs-site.xml의 dfs.blocksize 속성으로 바이트 단위로 설정
• 예약된 저장 공간: HDFS가 아닌 다른 용도로 저장 볼륨에 일정 공간을 남겨두기 위해 사용
  • hdfs-site.xml의 dfs.datanode.du.reserved 속성으로 바이트 단위로 설정
• 휴지통: 휴지통이다. 영구적으로 삭제하기 전에 최소 기간동안 보관된다. 기본 주기는 0이다.
  • core-site.xml의 fs.trash.interval 속성으로 설정한다.
• 잡 스케줄러: 4.3 YARN 스케줄링을 봐라
• 느린 리듀스 시작: 기본적으로 맵 태스크이 5%가 완료될 때까지 기다렸다가 동일한 잡의 리듀스 태스크를 스케줄링한다. 처리량이 적을 수 있으므로, 값을 조정하여 처리량을 증가시킬 수 있다.
  • mapred-site.xml의 maprecude.job.reduce.slowstart.completedmaps 속성을 0~1 사이로 정한다.
• 단락 지역 읽기: HDFS에서 파일을 읽을 때 클라이언트는 데이터노드와 교신하며 TCP 연결을 통해 클라이언트로 데이터를 전송한다. 블록이 클라이언트와 동일한 노드에 있다면 네트워크를 거치지 않고 직접 읽는것(단락 지역 읽기)이 효과적이다.
  • hdfs-site.xml의 dfs.client.read.shortcircuit를 true 설정시 활성화된다.

10.4 보안

하둡의 초기 버전은 공동 사용자가 HDFS와 맵리듀스 클러스터를 안전한 환경에서 사용한다고 가정했다. 따라서 접근 제한 기준은 권한 없이 데이터에 접근하는 것을 막기보다는 불의의 사고로 인한 데이터 유실을 막기 위한 목적으로 설계되었다. 보안 인증 (authentication) 메커니즘이 누락되어있다. 권한 부여(authorization) 매커니즘만 존재한다. 이러한 이슈를 해결하기 위해 커버로스를 도입하였다.

커버로스는 자격 증명을, 하둡은 권한 결정을 한다.

10.4.1 커버로스와 하둡

커버로스를 사용할 때 클라이언트가 이 서비스를 이용하려면 각 단계에서 서버와의 메시지 교환을 수반하는 다음 세 단계를 거쳐야 한다.

1. 인증: 클라이언트는 인증 서버에 자신을 인증하고, 시간 정보가 포함된 ticket-granting ticket(TGT)을 수신한다.
2. 권한 부여: 클라이언트는 TGT를 이용하여 티켓 승인 서버에 서비스 티켓을 요청한다.
3. 서비스 요청: 클라이언트는 서비스 티켓을 이용하여 클라이언트가 사용할 서비스를 제공하는 서버에 자신을 인증한다. 하둡의 경우 이 서버는 네임노드나 리소스 매니저가 될 것이다.

인증서버와 함께 티켓 승인 서버는 키 분배 센터(key distribution center - KDC)를 구성한다.

사용자는 인증 단계에서 암호 입력이 필요한 kinit 명령을 이용하여 인증하는 작업만 진행하며 기본 10시간 동안 유효한 TGT를 이용해 잡을 실행하거나 HDFS에 접근할 수 있다. 일반적으로 운영시스템 로그인 시에 인증을 자동화 하므로 하둡에 통합 인증을 제공할 수 있다. 

실행 예제

1. core-site.xml의 hadoop.security.authentication 속성을 kerberos로 설정
2. core-site.xml의 hadoop.security.authoriztion 속성을 true로 설정하여 서비스 수준의 권한 부여 활성화
3. hadoop-policy.xml 환경 설정 파일 안에 접근 제어 목록(ACL)을 구성하여 어느 사용자와 그룹이 각 하둡 서비스에 연결할 수 있는 권한이 있는지 설정할 수 있다.

10.4.2 위임 토큰

HDFS나 맵리듀스와 같은 분산 시스템에서는 클라이언트-서버 사이의 통신이 빈번하며 각각의 통신은 반드시 인증되어야 한다. 각 호출을 매번 인증하여 KDC에 높은 부하를 발생시키는 3단계의 커버로스 티켓 교환 프로토콜을 사용하는 대신 위임 토큰을 사용한다. 위임 토큰은 KDC에 다시 접근하지 않고 이에 대한 사후 인증을 허용한다. 사용자가 할 일은 없다.

위임토큰은 서버(이 경우 네임노드)에 의해 생성되며 클라이언트와 서버 사이에 공유되는 비밀과 같다.
클라이언트가 처음 네임노드로 RPC 호출을 할 때는 위임 토큰을 가지고 있지 않으므로, 커버로스를 사용한 인증을 수행하며 응답의 일부로 네임노드로부터 위임 토큰을 얻는다. 후속 호출에서 클라이언트는 네임노드가 확인할 수 있는 위임 토큰을 제공한다. (비밀키로 위임토큰을 생성했기 때문에.) 

클라이언트가 HDFS 블록에 대한 연산을 수행할 때 네임노드가 메타데이터 요청에 대한 응답으로 전달한 블록 접근 토큰이라는 특별한 종류의 위임 토큰을 사용한다. 이는 블록 접근 토큰을 검증할 수 있도록 네임노드가 블록 접근 토큰을 생성하기 위해 사용한 비밀 키를 데이터노드와 공유하기 때문에 가능하다(비밀 키는 하트비트 메시지 속에 실어 보낸다).

이 속성은 dfs.block.access.token.enable을 true로 설정해서 작성한다.

맵리듀스에서 잡 리소스와 메타데이터(JAR파일, 입력 분할, 구성파일 등)는 애플리케이션 마스터가 접근할 수 있도록 HDFS에서 공유된다. 그리고 사용자 코드는 노드 매니저 상에서 실행되어 HDFS의 파일에 접근한다. 
잡이 실행되는 동안 AM과 NM은 HDFS에 접근하기 위해 위임 토큰을 이용하고, 잡이 종료되면 위임 토큰도 무효화된다.

위임 토큰은 기본 HDFS 인스턴스를 자동으로 얻게 되며, 만약 잡이 다른 HDFS 클러스터에 접근할 필요가 있다면 mapreduce.job.hdfs-servers 잡 속성 값에 콤마로 구분된 HDFS URI 리스트를 설정하여 다른 HDFS에 대한 위임 토큰을 가져올 수 있다.

10.4.3 다른 보안 강화 사항

• yarn.nodemanager.container-executor.class=org.apache.hadoop.yarn.server.nodemanager.LinuxContainerExecutor
  • 노드 매니저를 실행한 사용자 계정이 아닌, 잡을 제출한 사용자의 운영 체제 계정으로 태크스를 실행할 수 있다.
  • 실행되는 태스크를 운영 체제로 격리하는 것이므로, 다른 사용자의 태스크끼리 신호를 보낼 수 없고, 각 태스크 데이터와 같은 로컬 정보는 로컬 파일 시스템 권한으로 비공개된다.
• 공유 캐시와 비공개 캐시로 분리되어 파일이 관리된다.
  • 태스크가 잡을 제출한 사용자 권한으로 실행될 때 분산하여 캐싱된다. (분산 캐시)
• mapreduce.cluster.acls.enabled = true
  • 자신이 소유한 잡만 보거나 수정할 수 있다.
  • mapreduce.job.acl-view-job과 mapreduce.job.acl-modify-job으로 특정 잡을 조회하거나 변경할 수 있는 사용자 리스트 설정도 가능하다
• 셔플은 안전하다.
  • 사용자별로 데이터가 맵 출력 결과 권한이 분리되어있기 때문이다.
• 접속을 하려는 데몬은 반드시 마스터 노드의 인증과정을 거치게 할 수 있다.
  • 악성의 보조 네임노드, 데이터노드, 혹은 노드 매니저를 실행하는 것을 방지할 수 있다.
  • ktutil 명령어로 이전에 생성한 keytab을 하둡이 사용하도록 구성하면 된다.
    • dfs.datanode.keytab.file = {keytab 파일명}
    • dfs.datanode.kerberos.principal = {데이터노드를 사용하는 사용자명}
    • hadoop-policy.xml 의 security.datanode.protocol.acl = {데이터 노드의 사용자명} 
      • DataNodeProtocol의 ACL이 데이터 노드의 접근 권한을 사용자명으로 제한
• 데이터 노드는 privileged port(1024 이하 포트)에서 실행될 수 있으므로, 클라이언트는 데이터노드가 안전하게 시작되었다는 것을 합리적으로 확신할 수 있다(???)
• 태스크는 오직 부모 애플리케이션 마스터와만 통신할 수 있다.
  • 공격자가 다른 사용자의 잡에서 맵리듀스 데이터를 획득하는것을 방지한다.
• 하둡의 다양한 부분 (RPC, HDFS 블록 전송, 맵리듀스 셔플, 웹UI 등)이 네트워크 데이터를 암호화하도록 구성할 수 있다.

10.5 하둡 클러스터 벤치마크

사용자가 사용하지 않는 상태에서 수행하자. 가능한 벤치마크는 다음과 같다.

10.5.1 하둡 벤치마크

하둡에서 지원하는 몇개의 벤치마크 기능이 있다. 

• TeraSort: 맵리듀스 벤치마킹이 가능. 입력 데이터 전체를 정렬하는 맵리듀스 프로그램으로, 임의의 데이터 생성, 정렬 수행, 결과 확인의 3단계로 구성되어있다.
• TestDFSIO: HDFS의 I/O 성능을 테스트. 편의 메서드를 이용해 병렬로 파일 읽기와 쓰기를 하는 MR 잡을 사용해 테스트
• MRBench: mrbench로 호출되며 작은 작을 여러 번 수행한다. TeraSort와 대조되는 작업으로 클러스터에서 작은 잡이 잘 실행되는지 테스트
• NNBench: nnbench로 호출되며 네임노드 하드웨어의 부하 테스트에 사용
• Grixmix: 실제 환경에서 관찰된 다양한 데이터 접근 패턴을 모방하여 실제 클러스터의 작업부하를 모델링 하기 위해 고안된 벤치마크 모음
• SWIM: 실제 맵리듀스의 작업부하 저장소로, 시스템을 대표하는 테스트 작업부하를 생성할 때 사용
• TPCx-HS: 트랜잭션 처리 성능 평의회에서 만든 TeraSort 기반의 표준화된 벤치마크

10.5.2 사용자 잡

직접 사용자가 만든 잡을 실행해서 클러스터를 튜닝하는게 가장 좋다.
매번 다른 데이터셋을 선택하여 벤치마크에 걸리는 시간을 서로 비교하는것이 좋고,
새로운 클러스터를 설치했거나 업그레이드 할 때는 동일한 데이터 셋을 사용하는 것이 좋다.