GFS의 구조를 단적으로 보여주는 그림이다.
Master서버에 거의 부하가 가지 않는 그런 구조로 되어 있고, 여러 replics를 두어서 chunk 서버 하나가 다운이 되도 그대로 수행이 가능하게끔 구성이 되어 있다.

64MB의 크기로 chunk가 나뉘어져 있어서 chunk 인덱스를 계산하기가 편하게 되어 있고, 네임 스페이스 검색은 Trie 구조로 되어 있다는것을 그림으로 살짝 엿볼 수 있다.

이런 구조의 가장 큰 장점은 부하가 한곳에 집중이 되지 않고, 시스템이 대체적으로 안정적이다라는 장점이 있다. 그리고 Application 단에서는 그냥 파일 이름과 자신이 접근하고자 하는 file byte offset을 날리면 되고 추가적인 정보를 제공하지 않는다.(이것은 우리가 File에 접근하는 방식하고 비슷하다.)

이런 방식의 read operation을 이해하기는 쉽고 쉽게 수긍이 간다. 하지만 서버의 부하가 증가해 다른 서버를 추가 시킬 경우 이놈이 어떻게 Data Leveling을 유지하느냐가 키포인트 일거 같다. 그걸 re-replacate라고 하는데, 이것의 목적은 여분의 공간을 효율적으로 쓰기 위함이고 또한 접근 속도를 증가 시키기 위함이다.
만일 데이터의 특정 chunk에 과잉되어서 어느 임계점 이상으로 그 정도가 높아지면 re-replacate와 re-balance가 이루어 진다. 이 메커니즘은 아직 공개가 안되어 있고, GFS의 가장 중요한 Key issue가 아닐까 한다.  자동적으로 데이터의 leveling이 이루어 지는 그 메커니즘이 궁금하긴 하다. 좀 생각해보면 가능할거 같기도 하고…쩝

이에 따라 MapReduce의 이야기가 안나올 수가 없는데,

Map과 Reduce는 일종의 프레임 웍이라고 생각이 든다. 객체 지향 언어로 구현하는게 맞을 정도니까… (참고로 map함수와 reduce는 hadoop에서 interface로 구현이 되어 있다.)

위의 그림만으로 충분히 설명이 가능하지 않을까 한다.wordcount 예제인데, page 단위로 읽어 들여서 색인을 추출한 다음에 그에 대한 word 출현 빈도수를 계산하는것인데,

map 함수로 (page num, sentence)를 (word, 1) 형식의 Key/Value 형식으로 출력하고 그것을 분산해서 그룹핑을 하고 다시 reduce함수를 이용해 (word, freq)형식의 데이터를 출력하는것이다.

map 함수에서 키워드 별로 분산 시킴으로서 그룹핑을 하는게 가장 중요한 부분이지 않을까 한다. 그렇게 되면 상대적으로 reduce에서 할일이 줄어들기 때문이다.

위와 같은 구글 파일 시스템에 적용하는것또한 map과 reduce를 어떻게 구현하느냐의 문제이고 이것은 임시 Key와 Value를 어떻게 구성하는지의 문제이지 않을까 한다.

구현된 라이브러리를 찾아 봤는데, Ruby의 Starfish라는 프로젝트정도만 발견한거 같다. 근데 이거 돌려볼라고 하니 잘 안돌아 간다. gem 설치는 정상적으로 되긴 하는데 말이다. ㅜㅜ

에궁… 가상 파일 시스템이 이제 어떤건지 대충 감은 잡은거 같다.

MapReduce와 GFS by from __future__ import dream is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.