[구지탱] GFS, Bigtable, Chubby
**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
#구글을 지탱하는 기술