MapReduce: Fault Tolerance, Locality, Large-Scale Indexing

Fault Tolerance

구글이 디자인한 MapReduce에서 Fault Tolerance는 어떻게 해결하는가이다.

Hdfs를 기억해보면 datanode가 namenode한테 주기적으로 heartbeat을 보냈다. 구글이 구현한 MapReduce같은 경우에는 master가 주기적으로 ping한다. 분산시스템에서 node의 failure를 detect하는 방법은 주기적인 메시지교환 밖에 없다.

 

master가 어떤 worker가 죽은것을 알았을 때, 그 map task를 reset해서 다른 worker에서 다시 돌린다. 그러면 complete된 map task는 failure가 일어나면 재실행(re execute) 되는건데, 왜그럴까요? 각각의 mapper가 생산해낸 중간결과물(Intermediate key value)은 어디있죠? 그 mapper가 실행되는 그 node의 로컬디스크에 저장되어있다. 당연히 fail했다는 의미는 로컬디스크에 접근이 안된다. 결과적으로 봤을 때 failure를 detect했을 때, 거기에 할당되는 모든 map task들은 다시 실행된다. 

 

반면에, reduce task가 끝난 다음에 죽었다. 그러면 얘네들을 굳이 다시 실행할 필요가 없다. 왜냐하면 reduce task의 결과는 항상 global file system, hadoop으로 따지면 hdfs에 저장되기 때문에 그 노드에 저장되는 것이 아니라 안정적으로 접근이 가능하다. (이미 그 노드를 떠난것이다. ) 의문을 가질 수 있는게 Intermediate key/value pair들도 hdfs에 저장해두면 다시 실행할 필요가 없는데, 구글 디자이너들이 생각할 때 intermediate data까지 global file system에 저장하는 것은 아니다고 생각했다. 왜냐하면 intermediate 라는 의미는 어차피 사라질 데이터 이기 때문이다. (reduce가 끝나고 나면 중간결과물이 필요없어진다)

 

(Resilient) 

실제로 구글에서 80개의 머신이 죽었는데 살아있는 것들 위주로 작업을 재실행 하면서 진행했다. 결과적으로 전체적인 MapReduce 작업을 무사히 끝마칠 수 있었다. 

failure들이 동시다발적으로 일어난다고 해도 MapReduce자체가 관리해주기 때문에 messy detail들에서 자유로울 수 있다. 이것이 가장 큰 장점이다.

 

Locality

Network bandwidth자체가 무한대 자원이 아니라 항상 부족할 수 있는 자원이다. 그러다보니 이걸 조금 아껴 써야하지 않나고 생각하며 디자인 철학이 생겼다. (일반적인 commodity computer 환경 에서) hdfs는 block단위로 쪼개서 데이터 노드들의 로컬디스크에 각각 다 저장이 되어있다. 그러면 그냥 로컬디스크에 있는 데이터를 읽게 하는 것이 좋겠다 라고 생각하는 것이죠. 그래서 “Moving computations close to the data”라는 개념이 나왔다. 기존의 슈퍼컴은 데이터를 computing 쪽으로 보내는 모델 이었는데 이렇게 하지 말고 데이터를 이미 분산 시켜놓은 다음에 거기에 computation (MapReduce관점에서 mapper)로 보내면 되겠다고 고민했다. 그래서 구글 mapreduce에서 master는 map task를 필요로 하는 input split 데이터를 실제로 소유하고 있는 machine에 allocation하기 위해 최선을 다한다. 만약에 그것을 실패하게 되면 그 노드가 바빠서 더이상 작업을 받아들이지 못할수도 있으니까, 그러면 그나마 input data 가까이에 배치하고 싶어한다.

 

가깝다는 개념은 hdfs에서도 다루었다. 

 

Data block과 최대한 가깝게 보낸다고 하는 것은, Node-2를 보면 저기 map task가 원하는 input split(data block)이 같이 있는 것이다. 이것을 data와 computation을 colocation 시킨다라고 표현했다. 이런 경우를 “data local”이라고 표현한다. Data local인 경우가 best case이다. 최적의 상황이다. 왜냐하면 여기서는 network 통신이 일어나지 않기 때문이다.(network bandwidth를 아낄 수 있음) 

만약에 Node-2처럼 이런 환경을 만들어낼 수 없다면, “rack local”도 생각할 수 있다. Node-3의 map task가 원하는 input split이 Node-4에 저장이 되어있다. 이런 경우에는 같은 Rack-1에 있는 다른 노드(node)의 데이터를 copy하는 것이 낫겠다고 생각하게 되는것이죠. 이것이 rack local이다. 그러나 data local, rack lock 둘 다 안되는 Node-5를 보면 다른 rack에서 copy해와서 실행한다.

 

hdfs의 블록 배치 방법이 mapreduce의 블록배치에도 도움이 되었다. 

 

 

Large-Scale Indexing

구글이 mapreduce를 개발해서 여러 분야에 했었는데, 그 중 대표적인 것이 Large-Scale Indexing이다. 검색엔진을 만들어야 하니까 index를 만들어야 했다. 

 

빅데이터를 다루는데 있어서 분산시스템은 피해갈 수 없는 숙명같은 것이다. 왜냐하면, 단일노드(단일 컴퓨터)에서는 처리할 수 없기 때문에, 클라우드 환경에서 빅데이터 분석(big data analytics)을 할때는 반드시 분산된 시스템에서 할 수밖에 없는 것이고, 그랬을 때 개발자(사용자)입장에서 좀 더 쉬운 API를 통해서 그들이 풀고자 하는 문제에 집중하게 해주고 나머지는 플랫폼(시스템)이 처리해주는 이런 모델로 가고있다고 보면된다.