[옛 글] [BigData] MapReduce - Locality 등...

최초 작성일 : 2013/02/25 12:56 

==================================================================

내용이 어려워짐에 따라 번역은 점점 발번역으로 치닫고 있습니다...ㅠ.ㅠ

첫 글에 링크해드린 원문 문서를 참조해서 보세요...

==================================================================

Locality(지역성)

네트워크 대역폭은 우리의 컴퓨팅 환경에서 비교적 부족한 자원이다.

우리는 클러스터를 구성하고 있는 머신들의 로컬 디스크에 GFS(Google File System)에 의해

관리되는 입력 데이터를 저장함으로써 네트워크 대역폭을 절약할 수있다.

GFS는 각각의 파일을 64Mb의 블럭으로 분할한 후 각각의 블럭에 대해 몇개의 복사본(보통 3개)을

서로 다른 머신들에 저장한다. MpaReduce의 master는 입력 파일들의 위치 정보를 고려하여

입력 데이터에 적합한 복사본이 있는 머신에서 map task의 스케쥴링을 시도한다.

만일 실패하는 경우 그 task의 입력 데이터의 복사본이 있는 가까운 머신(같은 네트워크 스위치에 물려있고

동일한 데이터를 가지고 있는 머신)에서 map task의 스케쥴링을 시도한다.

큰 규모의 MapReduce 작업이 클러스터 내의 중요한 부분에서 수행될 경우 대부분의 입력 데이터는

네트워크 대역폭을 사용하지 않고 로컬 디스크에서 읽혀지게 된다.

Task Granularity

우리는 위에 설명한 M개의 map 수행 단계와 R개의 reduce 수행 단계를 더 세분화 할 수 있다.

이상적으로 생각한다면 M과 R은 작업자 머신보다 더 많은 수여야 한다.

각각의 작업자가 서로 다른 많은 task들을 수행하는 것은 동적 로드밸런싱을 향상시키고

작업자가 실패했을 경우 복구시간을 빠르게 해준다. 전체 머신들에서 이렇게 완료된 map task들이

늘어나게 된다.

이 때문에 master가 O(M+R) 개의  스케쥴링 결정을 만들어야 하고 이전에 설명한 것과 같이 O(M*R)개의 상태가

메모리에 유지되어야 하기 때문에 우리의 구현에서는 M과 R의 크기가 얼마나 되어야 하는가 하는 실질적인 허용 범위가 있다.

(메모리 사용량에 대한 상수 인자들이 아무리 작아도 O(M*R) 개의 상태들은 하나의  map task / reduce task 쌍에 대하여

약 1byte의 데이터로 구성되어있다.)

 게다가 보통 R의 수는 사용자로부터 제약을 받는데 이는 각각의  reduce task의 출력들이 분할된 출력 파일들 내에서

처리되기 때문이다.

실제로 우리는 각각의 크기가 대체로 16Mb에서 64Mb정도인 입력 데이터를 가진 개별적인 task M개를 선택하고

(이러한 이유 때문에 위에 설명한 지역성의 최적화가 더욱 효과적인다.) 우리가 사용하고자 하는 다수의

작업자 머신에서 R을 약간 작게 만든다.

우리는 보통 M = 200,000 개, R = 5,000 개 2000의 작업자 머신에서 MapReduce 연산을 수행한다.

Backup tasks

MapReduce의 총 수행 시간이 길어지게 되는 일반적인 이유는 "straggler" 때문이다.

"straggler"는 전체 연산 중 가장 나중에 수행된 몇몇 map 또는 reduce task들의 완료가 매우 오래걸린

머신들을 말한다.

Straggler들은 전체 호스트에서 그 원인을 찾을 수 있다.

예를 들면, 결함있는 디스크를 가진 머신은 읽기 성능을 30MB/s에서 1MB/s까지 떨어뜨리는

수정 가능한 오류를 자주 발생시킨다. 클러스터 스케쥴링 시스템은 MapReduce 코드가 CPU, 메모리, 로컬디스크 또는

네트워크 등의 자원에 대한 경쟁에서 보다 느려지기 때문에 MapReduce가 아닌 다른 task를 이 머신에

할당하게 된다.

우리가 최근 겪었던 문제는 머신 초기화 코드에 있던 버그인데 이는 프로세서의 캐시를 사용할 수 없도록 했다.

이 문제에 영향을 받은 머신들에서 연산 속도가 1/100이상 감소했다.

우리는 stragglers의 문제를 완화시킬만한 일반적인 매커니즘을 가지고 있다.

MapReduce의 수행이 종료 시점에 다다를 쯤, master는 나머지 수행중인 task들을 실행하는

백업 스케쥴을 시행한다. task는 원본이든지 백업이든지 상관없이 실행이 완료되는 시점에 완료된 것으로 표시된다.

이 매커니즘을 조정하여 MapReduce 수행에 사용되는 컴퓨터상의 자원들을 전반적으로 증가시켰다.

우리는 이러한 작업이 큰 규모의 MapReduce의 수행에 있어 상당한 시간을 줄인다는 것을 발견하였다.

일례로, 이후에(원문상의 5.3절)에 설명하게되는 정렬 프로그램은 backup task 메커니즘을 사용하지 않을 경우

완료시간이 44%나 늘어나게 된다.