GFS(Google File System) papaer 요약
source: https://static.googleusercontent.com/media/research.google.com/ko//archive/gfs-sosp2003.pdf
구글 파일시스템은 분산된 데이터 집약적인 대규모 애플리케이션을 위한 확장가능한 분산 파일 시스템이다.
구글에는 비교적 값이 싸고, 평범한 서버 컴퓨터들을 클러스터화하여 자사의 서버로 구축한다. 이를 통해 집약적인 성능을 수 많은 클라이언트들에게 선사할 수 있으며, scale-out 방식으로 자유로운 수평 확장으로 서버 컴퓨터를 추가할 수 있는 장점이 있다. 하지만 평범한 컴퓨터는 그 만큼 고장이나 에러가 발생할 가능성이 큰데 이러한 특성을 반영하여 구글 파일시스템은 fault-tolerance를 제공한다.
source: https://www.scaleoutsoftware.com/technology/reports-of-scale-outs-demise-are-greatly-exaggerated/
다른 기존의 분산 파일시스템의 목적을 공유하면서 동시에 구글 그들의 애플리케이션의 워크로드나 자사의 기술적 환경을 관찰한 결과를 반영하여 설계한 것이 GFS이다.
2003년 SOSP에서 발표된 GFS 페이퍼를 요약하며 정리하고자한다.
Introduction and Design Overview
GFS는 이전의 분산 파일시스템과 같은 목적을 공유하지만, 그와 동시에 자사의 에플리케이션 워크로드와 기술 환경에 대한 관찰이 GFS 디자인의 핵심이 된다. 따라서 설계에 앞서 다음과 같은 가정(assumption)들이 있다.
(1) 구글 서버의 많은 컴퓨터들은 비교적 싸고, 평범한(commodity) 스토리지 머신들이 포함되어 있다. 따라서 일부는 작동하지 않을 수 있고, failure로 부터 회복되지 않을 가능성이 크다는 것을 암시한다. 이러한 문제는 에플리케이션의 버그, OS 버그, 인간이 발생한 에러, 그리고 디스크, 메모리, 커넥터, 네트워크, 파워 서플라이 등의 장애로 부터 기인한다. 따라서 이러한 여러 컴포넌트 고장 및 장애를 예외 상황이라기 보단 일반적인 것(norm)으로 간주한다. 그러므로 지속적인 모니터링, 에러 탐지, fault tolerance 그리고 원자적 회복이 필수적으로 시스템에 필요하다는 것으로 여긴다.
source: https://ko.wikipedia.org/wiki/%EC%BB%B4%ED%93%A8%ED%84%B0%ED%81%B4%EB%9F%AC%EC%8A%A4%ED%84%B0
(2) 파일의 크기는 기존에 비해 거대해져간다. Multi-GB 파일이 흔해졌다. 구글과 같은 웹 기반의 거대 IT 회사에서 다루는 거대한 파일은 웹 문서와 같은 에플리케이션 객체를 포함할 것이다. 이러한 거대한 파일을 키로바이트 크기의 파일로 다루는 것은 매우 까다롭다. 따라서 파일 시스템의 전반적인 설계 가정이나 I/O 오퍼레이션이나 블록 사이즈같은 파라미터에 대한 재고찰이 요구된다.
source: https://techengage.com/how-to-send-large-files-free
(3) 대부분의 파일들에서 기존의 데이터에 overwrite 하기 보단 새로운 데이터를 append 한다는 것을 관찰하였다. 또한 파일에 임의 쓰기 작업은 거의 일어나지 않는다. 한 번 파일이 쓰이고 나선 읽는 작업이 대다수이고, 거의 순차적으로 이루어진다.
" Some may constitute large repositories that data analysis programs scan through. Some may be data streams continuously generated by running applications. Some may be archival data. Some may be intermediate results produced on one machine and processed on another, whether simultaneously or later in time."
(GFS paper, page 1)
대부분의 거대한 파일에 대한 접근 패턴을 고려한다면 appending은 성능 최적화의 초점이 된다.
(4) 동시적으로 같은 파일에 append 작업을 하는 많은 클라이언트를 고려해야한다. 생산자-소비자 큐와 같은 자료구조를 도입하여 수 많은 생산자(클라이언트)들이 동시적으로 파일에 append하게 한다.
source: https://hamait.tistory.com/550
(5) 빠른 반응속도(low latency)보다는 높은 대역폭이 더 중요하다라 간주한다. 대부분의 구글 에플리케이션은 대량의 데이터 처리 속도를 높이면서, 개별 읽기 또는 쓰기에 대한 엄격한 음답 시간을 요구하지 않기 때문이다.
source: https://redstarhong.tistory.com/74
마지막으로, 에플리케이션과 파일 시스템 API 모두를 고려한 co-design은 전반적 시스템에 이득을 가져다 준다. 예를 들어 GFS의 일관성 모델은 에플리케이션 딴의 부담을 줄여주는 단순한 방식으로 구현되었으며, 클라이언트에서 동시적으로 하나의 파일에 append 하는 작업에서 과도한 동기화 과정없이 원자적으로 수행할 수 있 원자적인 append 오퍼레이션을 제공한다.
