MIT 6.5840 구글 파일 시스템 GFS

GFS는 구글 파일 시스템으로 Sanjay Ghemawat, Howard Gobioff, Shun-Tak Leung 이 발표한 기술이다.

GFS는 분산파일 시스템으로 스케일이 가능한 데이터 중심의 큰 어플리케이션을 위해 설계되었다. 저렴한 상업용 하드웨어를 많이 사용하여 높은 성능과 fault tolerance, 내결함성을 제공한다. 여타 기존의 분산 파일 시스템과 목적은 비슷하지만, 근본적으로 다르게 설계되었다. 

서비스에 운영되는 데이터의 생성과 처리뿐만 아니라 대규모 데이터 세트를 필요로 하는 연구 및 개발 작업을 위한 저장 플랫폼으로 활용되며 천 대가 넘는 머신에 연결된 수천 개의 디스크에 걸쳐 수백 테라바이트의 저장공간을 제공한다. 동시에 수백 개의 클라이언트가 이 시스템에 접근한다.

GFS의 아키텍처는 위와같다. GFS Client, GFS Master, GFS Chunkserver로 구성된다.

GFS Master는 단 한대로 운영된다. Master는 전역적으로 파일이 어디에 위치하고 있는지 알고 있다. GFS는 파일이 한 머신에만 저징되는 것이 아니기에 그 복제본 까지 다른 머신에 저장되는데, Master는 그 위치까지 알고있다. 하지만 Master가 파일의 읽기 쓰기에 관여하게 된다면 병목이 되기 때문에, Client는 Master를 통해 읽지않고 Master에게 파일이 어떤 Chunkserver에 위치하고 있는지 질의한다. Client는 응답받은 것 중 가장 가까운 곳에 위치한 머신에 접근하고, 더이상 동일한 블록에 접근할 시 Master와는 통신하지 않고 캐싱된Chunkserver위치를 확인한다.

Chunk Size는 64MB를 두고있는데, 이는 기본 파일시스템보다 크다. 큰 chunk size는 master와 소통 비용을 적게 만든다. 왜냐하면 비교적 큰 파일들이 올라가기 때문이다. 그리고 적은 random reads에 대해서도 multi-TB working set에 해당하는 모든 위치 정보를 무리없이 캐싱할 수 있다. 데이터는 크지만 메타데이터는 작아서 클라이언트가 캐시가 가능하다는 것이다. 두 번째로, chunk가 크더라도 TCP 연결을 유지함으로써 얻는 이점이 있다. network overhead가 적다. 세번째로, master에 저장되는 metadata양이 적다. 그래서 master는 메모리상에 metadata를 저장할수 있다.

Metadata에 대해서 이야기해보자면, Master는 세가지의 메타데이터를 가지고있다.

- 파일과 chunk 네임스페이스
- 한 파일이 어떤 chunk들로 이루어져있는지
- chunk들의 복제본의 위치

이 메타데이터들은 기본적으로 인메모리에 저장되고, 앞에 두 메타데이터는 operation log 라고 불리는 파일로 로컬디스크와 원격 복제 머신에 추가적으로 저장된다. 이런 disk 사용은 마스터가 순간적으로 서비스가 불가능 해져도 내결함성을 가지게 해준다. 단 master는 chunk들의 위치는 디스크에 저장하지 않는데 master가 새로 뜨거나 chunkserver가 클러스터에 들어올 때 각 chunkserver에게 질의를 통해 알게 된다.

기본적으로 metadata가 인메모리에 저장되므로 작업이 매우 빠르다. 주기적으로 grabage collection도 수행하고, chunkserver의 실패를 감지하고 재 복제를 수행하기도, chunkserver 간에 disk usage 밸런스를 맞추기 위해 migration을 수행하기도 한다. 단점은, Master노드가 가질 수 있는 메모리의 상한이 중요하다. 그런데 실세계에서 크게 문제가 되진 않는다. 각 64MB Chunk에 대해 최대 64 bytes 메타데이터 정도를 가진다. 모든 chunk들이 기본적으로 모두 64MB를 모두 사용하고 연속적인 파일에서 마지막 chunk만 64MB 보다 적을테니까. prefix compression을 사용해서 효율적으로 압축하므로 64bytes 정도이다. 만약에 더 큰 파일 시스템을 지원한다 하더라도 메모리양을 크게 영향을 받지 않을 것이다.

Operation Log는 metadata의 크리티컬 변경점을 저장한다. GFS에서 중앙관리형이며, 영속적으로 저장되기도 하면서 또한 동시적인 작업에 대해 논리적인 시간을 부여한다. Operation Log는 매우 중요하므로, 신뢰성 있게 저장하여야하면서 클라이언트에게 변경이 영속적으로 저장되지 않은 경우에는, 변경안된 것 처럼 일관성있게 보여야한다. 신뢰성을 얻기 위해 이 로그를 원격 머신에 복제하고, 로컬 및 원격 모두에서 해당 로그 레코드가 디스크에 플러시된 이후에만 클라이언트 요청에 응답한다. 또한 마스터는 여러 개의 로그 레코드를 batch로 묶어 플러시하여, 플러시와 복제가 전체 시스템 처리량에 미치는 영향을 줄인다. 또한 Master 서비스가 새로 뜰때 이 로그를 replay해서 파일 시스템을 재현한다. 그래서 log파일의 크기가 작으면 작을수록 효율적이다.

 

약한 일관성 중 File Region

GFS는 약한 일관성 모델을 활용한다. GFS의 namespace mutation (파일 생성등)은 원자적이다. master에 의해 이루어지는데, namespace를 locking하여 원자성과 정확성을 보장한다. master는 operation log에 이러한 작업들을 기록한다. 데이터 변경 이후에 특정 파일의 영역의 상태는  변경의 유형 X 성공 여부 에 따라 달라지며, 이는 위 표 Table 1에 정리되어있다. 성공 여부는 연속적으로 성공하였을 경우, 동시에 변경하여 성공하였을 경우 등을 구분한다. 파일 영역이 consistent라는 것은 클라이언트가 어느 replica에서 읽어도 항상 동일한 데이터를 보게 됨을 의미한다. 파일 영역이 defined라는 것은 클라이언트가 변경 연산이 기록한 데이터를 완전하게 그대로 보게됨을 뜻한다.

1 동시작성이 없는 쓰기의 경우 파일영역은 defined이며 consistent일것이다.  모든 클라이언트가 같은 변경점을 읽을 것이다.
2 동시적으로 여러 변경을 썼을 때는 undefined이나 consisntent이다. 모든 클라이언트가 같은 결과를 볼것이지만, 변경 연산이 기록한 내용과 정확히 일치하지 않을 수 있다. AAAA, BBBB를 동시에 썼을때  모든 클라이언트가 같은결과를 보겠지만 그 결과가 ABAB나 AABB등 변경내용이 mingled 된채로 보이게된다. 의도한 결과라고 볼수없기때문에 undefined이다.
3 실패한 쓰기는 inconsitent 이며 undefined이다. 클라이언트들이 다른 결과값을 볼 수 있다. 

이를 통해 약한 일관성을 보장한다고 한다.

Lease 와 Mutation Order.

Mutation은 데이터 chunk 가 write 또는 append 할때 메타데이터를 변경하는 작업을 뜻한다. 메타데이터를 변경하는 Mutation 작업은 모든 chunk server replica에서 진행된다. mutation 작업을 모든 레플리카에서 진행할 때 일관성있게 진행하기 위해 leases 라는 기술을 사용한다. leases(wiki)https://en.wikipedia.org/wiki/Lease_(computer_science) https://kubernetes.io/ko/docs/concepts/architecture/leases/ 마스터는 chunk lease(~chunk lock)을 replica에게 주는데 이때 이 replica를 primary라고 부른다. 프라이머리는 chunk에 대한 모든 mutation을 순서대로 정리한다. 모든 chunk들은 이 명령에 따른다. 

Lease와 Mutation Order Flow

우선은 여기까지 하고. GFS에 대해 추가 배움이 있으면 계속하여 작성하겠다.

 

 

 

또한 과제 kv server에 대한  github 코드는 다음에서 확인가능하다. 

https://github.com/ingyeoking13/distributed-systems/tree/main/6.5840/src/kvsrv1