[구지탱] GFS, Bigtable, Chubby

created:2012-12-13

updated:2015-07-03

edit

**GFS(Google File System)**

– 대용량 데이터에 적합한 분산 파일시스템

– 1대의 머신에 다루기 힘든 데이터를 다루지만, 작은 데이터에는 비 적합

– 하나의 파일 = N 청크(64MB)

– 하나의 청크는 3개의 청크서버에 복제되어 저장.

– 파일 접근 방식

– 대용량 데이터의 효율적 전송에 설계 초점.

** **

**Bigtable**

– GFS를 이용하면서 작은 데이터를 효율적으로 쓸수 있게 하는 분산 스토리지.

– 거대한 테이블

– 로우키, 칼럼패밀리, 타임 스탬프 구조 = 다차원 맵(Multidimensional map)

– not use sql. 프로그래밍 방식으로 연동

***로컬리티(locality)**

– 필요한 데이터를 한곳에 모아서 두는 것.

– 분산 시스템의 성능향상을 위해서는 로컬리티를 고려한 디자인 필요.

** **

**Chubby**

– 작은 분산 파일 시스템

– 파일시스템, 잠금 서비스(배타제어), 이벤트 통지(상태 변경시 이벤트 통지)

– 1kb 미만의 파일대상

– chubby 5 cell -> 5 replica

– 읽기에 최적화 되어 있음.

– 파일은 부분업데이트를 할수 없으면, 파일 전체를 업데이트 해야함.

**파일 잠금**

– 공유 잠금 => 파일 수정 방지

– 배타적 잠금 => 안전한 파일 수정

**외부 리소스 잠금 **

**시퀀서 **

– 클라이언트의 요청 유효성 판별 데이터

**failover**

– 마스터 정지시, 다른 replica가 마스터로 전환.

– 마스터 전환 사이의 시간으로 타임아웃 발생 가능성 있음.

**이벤트**

– 파일 생성 또는 업데이트시, 이벤트 발생.

– 각 서버들은 시동시, 특정 디렉토리에 파일을 만들어서 자신의 주소 기록.

– 마스터는 그 디렉토리를 통해서 서버 시작/종료를 감시

– 역으로 서버가 마스터를 감시 할수도 있음.

**캐쉬 **

– chubby 파일을 읽으면, 그 내용을 캐쉬해서 클라이언트에서 다시 요청시, 해당 데이터 전송.

– 파일 내용 업데이트시, chubby는 모든 캐쉬를 파기(오래된 캐쉬의 사용 제거)

**마스터 선출 기법**

– 다양한 고장 발생이 있지만 마스터 선발 기준은 하나.

– 마스터는 절반 이상의 레플리카가 연결되어 있는 장소에서 나타난다.

– 기본 5개의 레플리카로 구성되기 때문에 정상작동을 위해서는 3개이상이 연결된 상태여야 한다.

*** 컨센서스 알고리즘(Consensus algorithm) – Paxos**

– 가장 높은 번호를 선택하고, 합의를 이끌어 내는.. ([http://wn.com/paxos_algorithm](http://wn.com/paxos_algorithm))

**마스터리스(master lease)**

– 일정한 시간으로 paxos의 제안과 약속을 생략하고 수락에서부터 시작

– 마스터가 주도하지만, 과반수 이상의 합의가 있어야 한다.

– 마스터리스는 마스터가 정상 동작하는한 계속 갱신.

– 정리하면, 마스터리스는 마스터가 살아있을때, 다음 마스터를 제안/약속 단계없이 합의를 주도하여 다음 마스터를 선출하는 시간을 말한다.완전히 새로운 선출은 마스터가 정지되어 리스가 갱신되지 않으면, 마스터가 없는 상태가 발생되는데, 그때 동작하여, 새로운 마스터를 선출한다.

#bigtable #Chubby #dev #GFS #구글을 지탱하는 기술