구글 파일 시스템
더 많은 작업
- Google File System; GFS
- 구글이 대규모 데이터 처리를 위해 만든 분산 파일 시스템. 값싼 범용 서버 수천 대에 큰 파일을 나눠 저장하며, 고장을 정상 상황으로 보고 복제로 견딘다
구글은 2003년 SOSP(Symposium on Operating Systems Principles)에서 발표한 논문 "The Google File System"(Sanjay Ghemawat, Howard Gobioff, Shun-Tak Leung)으로 GFS의 설계를 공개했다. 논문에 따르면 GFS는 데이터 집약적인 대규모 분산 애플리케이션을 위한 확장 가능한 분산 파일 시스템으로, 값싼 범용 하드웨어에서 돌아가면서도 장애를 견디고 많은 클라이언트에게 높은 총 처리량을 제공한다. 발표 당시 가장 큰 클러스터는 천 대가 넘는 서버의 수천 개 디스크에 수백 테라바이트를 저장했다.
GFS는 오픈 소스로 공개되지 않았지만, 그 설계를 본떠 만든 것이 하둡의 하둡 분산 파일 시스템(HDFS)이다. ADP 교재는 GFS를 분산 데이터 저장 기술의 대표 사례로 다룬다.
GFS는 기존 파일 시스템과 다른 가정에서 출발했다. 논문이 밝힌 주요 가정은 다음과 같다.
- 시스템은 고장이 잦은 값싼 부품으로 이루어지므로, 부품 고장은 예외가 아니라 일상이다. 늘 감시하고, 고장을 찾아내고, 스스로 복구해야 한다.
- 파일 수는 적당하지만 하나하나가 크다. 수백 MB에서 수 GB 이상인 파일이 흔하다.
- 읽기는 대부분 큰 연속 읽기(streaming read)이고, 작은 임의 읽기는 적다.
- 쓰기는 파일 끝에 덧붙이는(append) 큰 순차 쓰기가 대부분이며, 이미 쓴 내용을 고치는 일은 드물다.
- 여러 클라이언트가 같은 파일에 동시에 덧붙이는 경우를 효율적으로 지원해야 한다.
- 짧은 응답 시간보다 지속적으로 높은 대역폭(처리량)이 더 중요하다.
GFS 클러스터는 마스터 하나, 청크서버 여러 대, 그리고 여러 클라이언트로 이루어진다.
| 구성 요소 | 역할 |
|---|---|
| 마스터(master) | 파일 시스템의 모든 메타데이터를 관리한다. 청크 생성·복제 위치 결정, 고아 청크의 가비지 컬렉션, 청크서버 간 청크 이동을 맡고, 주기적인 하트비트(HeartBeat) 메시지로 청크서버에 지시를 내리고 상태를 받는다. |
| 청크서버(chunkserver) | 청크를 로컬 디스크에 일반 리눅스 파일로 저장하고, 청크 핸들과 바이트 범위로 지정된 데이터를 읽고 쓴다. |
| 클라이언트 | 애플리케이션에 링크되는 라이브러리. 메타데이터는 마스터에게 묻고, 실제 데이터는 청크서버와 직접 주고받는다. |
마스터가 하나뿐이라 설계가 단순해지고 청크 배치를 전체 정보를 보고 결정할 수 있다. 대신 마스터가 병목이 되지 않도록 클라이언트는 마스터에게서 청크 위치만 받아 캐시한 뒤, 데이터 읽기·쓰기는 청크서버와 직접 한다.
- 클라이언트가 파일 이름과 바이트 위치를 청크 번호(chunk index)로 바꿔 마스터에게 묻는다.
- 마스터는 해당 청크의 청크 핸들과 복제본이 있는 청크서버 위치를 알려 준다.
- 클라이언트는 그중 한 청크서버(보통 가장 가까운 곳)에 직접 데이터를 요청한다.
- 파일은 고정 크기의 청크(chunk)로 나뉜다. 청크 크기는 64MB로, 일반 파일 시스템의 블록보다 훨씬 크다.
- 각 청크는 마스터가 만들 때 부여하는 전역적으로 고유한 64비트 청크 핸들로 식별된다.
- 신뢰성을 위해 청크마다 여러 청크서버에 복제본을 두며, 기본값은 복제본 3개다.
- 청크가 크면 클라이언트가 마스터와 주고받는 횟수가 줄고, 마스터가 관리할 메타데이터 양도 줄어든다. 공간 낭비는 필요할 때만 파일을 늘리는 지연 공간 할당(lazy space allocation)으로 줄인다.
- 쓰기 순서는 마스터가 복제본 하나에 리스(lease)를 주어 주(primary) 복제본으로 정하고, 주 복제본이 나머지 복제본에 같은 순서를 적용하게 하는 방식으로 맞춘다.
마스터는 세 가지 메타데이터를 모두 메모리에 둔다.
| 메타데이터 | 영속 저장 |
|---|---|
| 파일과 청크의 네임스페이스 | 연산 로그(operation log)에 기록 |
| 파일에서 청크로의 매핑 | 연산 로그에 기록 |
| 각 청크 복제본의 위치 | 저장하지 않음. 마스터가 시작할 때와 청크서버가 합류할 때 청크서버에 물어 알아냄 |
연산 로그는 마스터의 로컬 디스크에 쓰고 원격 서버에도 복제한다. 마스터가 죽으면 체크포인트와 로그를 다시 읽어 상태를 되살린다.
이 밖에 GFS는 일반적인 생성·삭제·열기·닫기·읽기·쓰기 외에, 파일이나 디렉터리 트리를 적은 비용으로 복사하는 스냅숏(snapshot)과 여러 클라이언트가 같은 파일에 동시에 덧붙여도 각 덧붙이기가 원자적으로 처리되는 레코드 추가(record append)를 제공한다. 일관성 모델은 엄격하지 않은 완화된(relaxed) 모델이다.
| 항목 | GFS | HDFS |
|---|---|---|
| 메타데이터 서버 | 마스터 | 네임노드(NameNode) |
| 데이터 저장 서버 | 청크서버 | 데이터노드(DataNode) |
| 저장 단위 | 청크, 64MB | 블록, 일반적으로 128MB(파일마다 설정 가능) |
| 기본 복제 수 | 3 | 3(파일마다 설정 가능) |
| 메타데이터 변경 기록 | 연산 로그 | 에디트로그(EditLog) |
| 상태 보고 | 하트비트 | 하트비트 |
| 쓰기 모델 | 덧붙이기 위주, 동시 레코드 추가 지원 | 한 번 쓰고 여러 번 읽기(write-once-read-many), 덧붙이기·잘라내기만 허용 |
| 공개 여부 | 논문으로 설계만 공개 | 아파치 오픈 소스 |
- GFS의 구성 요소 세 가지(마스터, 청크서버, 클라이언트)와 각 역할, 클라이언트가 데이터는 청크서버와 직접 주고받는다는 점을 기억한다.
- 청크 크기 64MB, 기본 복제본 3개, 64비트 청크 핸들 같은 수치가 출제된다.
- 설계 가정: 고장은 일상, 큰 파일, 큰 순차 읽기와 덧붙이기 위주, 응답 시간보다 처리량 중시.
- GFS 마스터·청크서버가 HDFS의 네임노드·데이터노드에 대응하고, GFS를 기반으로 빅테이블이 만들어졌다는 관계를 알아 둔다.