[논문 리뷰] The Google File System (GFS)

2022-08-06 18 분 소요

“The Google File System” 논문을 개인 공부 및 리뷰를 위해 쓴 글이다. 분산 파일 시스템에 입문하거나 관련 논문을 처음 접하는 독자를 위해 기초 컴퓨터 공학 용어 설명도 함께 덧붙였다.

논문 출처: https://dl.acm.org/doi/10.1145/1165389.945450 ¹

구글 파일 시스템(Google File System, GFS)은 저가형 상용 서버 수천 대로 구성된 대규모 클러스터에서 빈번한 하드웨어 장애를 일상적인 상태로 가정하고, 멀티 GB 크기의 대용량 파일과 대규모 순차 추가(append) 중심 워크로드를 높은 처리량으로 다루기 위해 설계된 분산 파일 시스템이다. 단일 마스터를 통한 메타데이터 중앙 제어와 실제 데이터 I/O 분리, 그리고 64MB 대형 청크 설계를 통해 메타데이터 병목을 최소화하고 확장성과 높은 가용성을 동시에 달성했다.

1. Introduction

구글의 폭발적인 데이터 처리 요구를 충족하기 위해 기존 분산 파일 시스템의 가정을 근본부터 재검토하여 설계된 분산 파일 시스템이 바로 GFS다.

Google File System(GFS)은 구글의 급증하는 데이터 처리 요구 사항을 충족하기 위해 설계되고 구현되었다.
GFS는 성능(performance), 확장성(scalability), 신뢰성(reliability), 가용성(availability) 같은 기존 분산 파일 시스템의 목표를 공유한다.
하지만 구글의 실제 프로덕션 환경과 데이터 액세스 패턴을 분석한 저자들은 이러한 목표를 달성하기 위한 기본 가정들을 완전히 새로운 관점에서 재정립했다.

컴포넌트 고장은 예외가 아니라 일상이다: 수천 대의 상용(commodity) 하드웨어로 구성되므로 지속적인 모니터링, 장애 감지, 내결함성(fault tolerance), 자동 복구가 필수적이다.
- 컴포넌트(component): 여러 개의 프로그램 함수들을 모아 하나의 특정한 기능을 수행할 수 있도록 구성한 작은 기능적 단위 ²
멀티 GB 단위의 대형 파일이 일반적이다: 수백만 개의 수 KB 단위 작은 파일보다 수십억 바이트 규모의 대용량 파일이 표준이므로, I/O 연산과 블록 크기 등 핵심 파라미터를 완전히 재설계해야 한다.
파일 변경은 기존 덮어쓰기보다 새로운 데이터 추가(append)가 지배적이다: 데이터 스트림이나 아카이브 등 순차적 추가가 대부분이므로, 임의 덮어쓰기 최적화나 클라이언트 캐싱보다 순차적 append의 원자성과 성능 보장이 핵심이다.
애플리케이션과 파일 시스템 API의 공동 설계: 파일 시스템의 일관성 모델을 현실적인 수준으로 완화하여 시스템 복잡도를 낮추고, 동시 동기화 오버헤드 없이 안전하게 추가할 수 있는 원자적 레코드 추가(atomic record append) 연산을 도입했다.
- API(Application Programming Interface): 애플리케이션에서 사용할 수 있도록 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스 ³

결국 GFS는 하드웨어 결함을 전제로 깔고, 대용량 순차 append 워크로드에 모든 구조를 집중시켰다.

2. Design Overview

2.1 Assumptions

GFS는 범용 파일 시스템이 아닌 구글 고유의 워크로드와 상용 클러스터 환경을 철저히 반영한 다섯 가지 핵심 가정 위에 구축되었다.

저렴한 상용 컴포넌트 환경: 빈번하게 고장 나는 저비용 부품으로 구성되므로, 시스템 수준의 상시 모니터링과 신속한 자동 복구가 필수적이다.
멀티 GB 대형 파일 중심: 수 기가바이트 크기의 파일들이 일반적이므로 대규모 파일을 효율적으로 다루는 설계가 요구된다.
스트리밍 읽기 위주의 워크로드: 수백 KB에서 수 MB에 달하는 대규모 연속 스트리밍 읽기가 대부분이며, 작은 임의 읽기는 국소적이다.
- 워크로드(workload): 주어진 기간에 시스템에 의해 실행되어야 할 작업의 할당량
다중 클라이언트의 동시 추가(append): 동일한 파일에 여러 클라이언트가 동시에 데이터를 추가할 때 명확하고 원자적인 시맨틱을 제공해야 한다.
지연 시간보다 지속적인 높은 대역폭 우선: 개별 읽기/쓰기의 낮은 지연 시간(latency)보다는 지속적이고 높은 처리 대역폭(throughput)을 우선한다.

2.2 Interface

GFS는 표준 POSIX 인터페이스를 그대로 따르지 않고, 구글 애플리케이션의 필요에 맞춘 간결하면서도 강력한 파일 시스템 인터페이스를 제공한다.

GFS에서 파일은 디렉토리 계층 구조로 구성되며 경로 이름(pathname)으로 식별된다.
- create, delete, open, close, read, write 같은 친숙한 기본 연산을 지원한다.
특히 GFS는 대규모 분산 처리에 특화된 snapshot과 record append 연산을 제공한다.
- 스냅샷(snapshot): 파일이나 디렉토리 트리의 복사본을 매우 적은 비용으로 즉각 생성한다.
- 레코드 추가(record append): 여러 클라이언트가 동일한 파일에 동시에 데이터를 추가하더라도 각 클라이언트의 추가 작업이 원자적(atomic)으로 최소 한 번 이상 기록됨을 보장한다.

2.3 Architecture

GFS 클러스터는 메타데이터를 전담하는 단일 마스터와 실제 데이터를 저장하는 다수의 청크서버로 역할을 명확히 분리하여 병목을 없앴다.

GFS 클러스터는 단일 master와 다수의 chunkserver로 구성되며, 다수의 client가 이에 동시 접근한다.
- 클러스터(cluster): 여러 대의 컴퓨터들이 네트워크로 연결되어 하나의 단일 시스템처럼 동작하는 컴퓨터들의 집합 ⁴
청크(Chunk) 분할과 식별:
- 파일은 고정 크기의 청크(fixed-size chunks)로 나뉜다.
- 각 청크는 불변(immutable)하며 전역적으로 고유한 64비트 chunk handle로 식별된다.
- 청크 핸들은 청크가 생성될 때 마스터가 할당한다.
청크서버(Chunkserver)의 역할:
- 청크서버는 로컬 디스크에 청크를 일반 리눅스 파일 형태로 저장하며, 청크 핸들과 바이트 범위를 기반으로 청크 데이터를 읽거나 쓴다.
- 데이터 신뢰성 확보를 위해 각 청크는 여러 청크서버에 걸쳐 복제된다.
- 기본 복제본 수: 3개 (default: 3 복제본)
마스터(Master)의 메타데이터 관리:
- 마스터는 네임스페이스, 접근 제어 정보, 파일-청크 매핑, 청크의 현재 위치 등 모든 파일 시스템 메타데이터(metadata)를 관리한다.
- 청크 리스(lease) 관리, 고아 청크 가비지 컬렉션, 청크서버 간 부하 분산을 위한 마이그레이션 등 시스템 전반의 조율을 총괄한다.
- 마스터는 주기적인 HeartBeat 메시지를 통해 각 청크서버와 통신하며 명령(instruction)을 전달하고 상태(state)를 수집한다.
클라이언트(Client)와 데이터 흐름:
- 클라이언트는 메타데이터 조회만을 위해 마스터와 통신할 뿐, 실제 파일 데이터 입출력은 청크서버와 직접 수행한다.
- 청크서버는 청크를 일반 로컬 파일로 저장하므로 파일 데이터를 별도로 캐시할 필요가 없으며, 리눅스 커널의 페이지 버퍼 캐시가 자주 접근하는 데이터를 자동으로 메모리에 유지한다.
  - 캐시(cache): 데이터나 값을 미리 복사해 놓아 후속 요청을 빠르게 처리하는 임시 저장소 ⁵

제어 흐름과 데이터 흐름을 물리적으로 완전히 분리한 것이 마스터 병목을 제거한 비결이다.

2.4 Single Master

단일 마스터 아키텍처는 전역 메타데이터 관리를 단순화하지만, 마스터가 병목이 되지 않도록 데이터 I/O 경로에서 배제되어야 한다.

단일 마스터 구조 덕분에 마스터는 클러스터 전체에 대한 전역 정보를 바탕으로 정교한 청크 배치(chunk placement) 및 복제 결정을 내릴 수 있다. 클라이언트는 실제 데이터를 마스터로부터 읽지 않고 청크서버의 위치만을 마스터에 질의한다.

클라이언트의 읽기 요청 흐름은 다음과 같다.

클라이언트는 고정 청크 크기를 바탕으로 애플리케이션이 지정한 파일 이름과 바이트 오프셋(offset)을 파일 내 청크 인덱스로 변환한다.
- 오프셋(offset): 기준이 되는 시작 주소로부터 떨어진 상대적인 바이트 거리 ⁶
클라이언트는 파일 이름과 청크 인덱스를 포함한 요청을 마스터에 전송한다.
마스터는 해당 청크 핸들과 복제본들이 위치한 청크서버 목록으로 응답한다.
클라이언트는 이 정보를 (파일 이름, 청크 인덱스)를 키로 삼아 로컬 메모리에 캐시한다.
클라이언트는 복제본 중 네트워크상 가장 가까운 청크서버로 직접 요청을 전송하여 데이터를 읽는다.
- 요청은 청크 핸들과 청크 내 바이트 범위를 지정한다.

2.5 Chunk Size

청크 크기는 GFS의 핵심 설계 파라미터로, 일반적인 파일 시스템 블록(수 KB)과 대비되는 대형 단위인 64MB를 채택했다.

각 청크 복제본은 청크서버에 일반 리눅스 파일로 저장되며, 내부 단편화로 인한 낭비를 막기 위해 실제 데이터가 쓰일 때만 지연 할당되어 필요한 만큼 확장된다. 64MB라는 대형 청크 크기는 다음과 같은 세 가지 결정적 이점을 제공한다.

마스터 통신 빈도 감소: 동일한 청크에 대한 후속 읽기/쓰기는 마스터에 다시 위치를 물어볼 필요가 없으므로 마스터의 네트워크 및 RPC 부하가 줄어든다. 대용량 순차 I/O 워크로드에서 이는 특히 효과적이다.
네트워크 오버헤드 절감: 클라이언트는 하나의 청크와 긴 시간 통신하므로 지속적인 TCP 연결을 유지하여 연결 수립 오버헤드를 최소화할 수 있다.
- 전송 제어 프로토콜(TCP): 두 종단 호스트 간에 신뢰성 있는 데이터 스트림 교환을 보장하는 네트워크 전송 프로토콜 ⁷
- 오버헤드(overhead): 본래 처리 목적 외에 부가적인 제어나 통신을 위해 소비되는 간접적 시간 및 메모리 자원 ⁸
마스터 메모리 메타데이터 크기 최소화: 청크 수가 적어지므로 마스터가 관리해야 할 메타데이터의 양이 수십 메가바이트 수준으로 작아져, 전체 메타데이터를 마스터 메모리에 상주시키는 것이 가능해진다.

대형 청크 덕분에 수백 테라바이트의 클러스터 메타데이터를 단일 마스터 메모리 안에서 가볍게 다룰 수 있게 되었다.

2.6 Metadata

마스터는 모든 메타데이터를 메모리에 상주시켜 극도의 고성능을 얻고, 영속성이 필요한 핵심 변경 사항만 연산 로그(operation log)에 순차 기록한다.

마스터가 관리하는 메타데이터는 크게 세 가지 유형으로 나뉜다.

파일 및 청크 네임스페이스(namespace)
파일에서 청크로의 매핑(mapping)
각 청크 복제본이 위치한 청크서버 위치(chunk locations)

모든 메타데이터는 마스터의 메모리에 보관된다. (1) 네임스페이스와 (2) 파일-청크 매핑 정보는 마스터 로컬 디스크에 기록되고 원격 머신들로 복제되는 연산 로그(operation log)에 변경 사항(mutation)을 추가함으로써 영속적으로(persistent) 유지된다. 이 로그 방식을 통해 마스터 크래시 발생 시에도 데이터 불일치 위험 없이 마스터 상태를 안전하게 복구할 수 있다.

반면 (3) 청크 위치 정보는 디스크에 영속적으로 저장하지 않는다. 대신 마스터가 시작할 때와 새로운 청크서버가 클러스터에 합류할 때 각 청크서버로부터 보유 청크 목록을 직접 질의하여 메모리를 구성한다.

2.6.1 In-Memory Data Structures

모든 메타데이터가 메모리에 상주하므로 마스터의 작업 처리가 극도로 빠르고, 백그라운드에서 전체 상태를 주기적으로 스캔하기도 수월하다.

이 주기적 메모리 스캔은 청크 가비지 컬렉션(garbage collection), 청크서버 장애 시 청크 재복제(re-replication), 청크서버 간 부하 및 디스크 사용량 균형을 맞추기 위한 청크 마이그레이션(chunk migration)을 매우 효율적으로 수행하게 해준다.

마이그레이션(migration): 대량의 데이터를 옮기는 프로세스를 말함 ⁹

2.6.2 Chunk Locations

마스터가 청크 위치 정보를 디스크에 영속 저장하지 않는 설계는 청크서버와 마스터 간의 동기화 문제를 근원적으로 제거한다.

마스터는 청크서버 목록을 디스크에 영구 기록하지 않고, 부팅 시 청크서버에 질의하여 위치 정보를 파악한다.

폴링(polling): 프로그램에 의한 입출력 방식. 데이터의 입출력이 CPU가 수행하는 프로그램의 입출력 명령에 의해 실행되고 입출력을 수행할 준비가 되었는지 알기 위해 CPU가 주변장치의 상태를 계속 감시한다. ¹⁰

청크서버는 디스크 에러나 장비 고장으로 언제든 청크를 잃거나 참여/이탈할 수 있다. 따라서 청크 위치의 최종 진실은 각 청크서버의 로컬 디스크에 맡기고, 마스터는 주기적인 HeartBeat 메시지로 최신 상태를 동기화하여 마스터-청크서버 간 상태 불일치 문제를 방지한다.

2.6.3 Operation Log

연산 로그(Operation Log)는 GFS의 영속적 메타데이터를 담는 유일한 중심 축이자, 동시 연산들의 전역 실행 순서를 결정하는 논리적 타임라인이다.

파일 및 청크와 그 버전은 생성된 논리적 시간에 의해 고유하게 식별된다. 연산 로그는 무결성이 절대적으로 요구되므로, 여러 원격 복제본 머신에 복제되며 로컬 및 원격 머신의 디스크에 성공적으로 플러시(flush)된 후에만 클라이언트 작업에 성공 응답을 보낸다.

플러시(flush): 버퍼에 임시 저장된 변경 내용을 영속 저장 장치(디스크)에 즉시 반영하는 것을 말한다. ¹¹

처리량을 높이기 위해 마스터는 여러 로그 레코드를 묶어 일괄(batch) 플러시함으로써 I/O 오버헤드를 줄인다.

로그가 일정 크기 이상 커지면 마스터는 상태를 체크포인트(checkpoint)하여 디스크에 저장한다. 덕분에 장애 복구 시 전체 로그를 처음부터 재생할 필요 없이, 최신 체크포인트를 메모리로 로드한 뒤 그 이후의 소수 로그만 빠르게 재생(replay)하여 수 초 안에 복구할 수 있다.

체크포인트(checkpoint)는 별도의 파싱(parsing) 오버헤드 없이 메모리에 직접 매핑되어 네임스페이스 조회에 활용할 수 있는 컴팩트한 B-트리(B-tree) 형태를 갖춘다.
- B-트리(B-tree): 이진 트리를 확장해 하나의 노드가 가질 수 있는 자식 노드의 최대 숫자가 2보다 큰 균형 트리 구조 ¹²

체크포인트와 연산 로그의 결합으로 마스터의 빠른 복구와 강력한 메타데이터 영속성을 모두 확보했다.

2.7 Consistency Model

GFS는 전통적인 엄격한 일관성 대신 대규모 분산 환경에 최적화된 완화된 일관성 모델(relaxed consistency model)을 채택하여 단순성과 고성능을 얻었다.

파일 시스템의 보증(guarantee)과 이것이 실제 애플리케이션 개발에 미치는 영향을 살펴본다.

2.7.1 Guarantees by GFS

GFS는 네임스페이스 변경에 대해서는 완전한 원자성을 보장하지만, 데이터 변경 영역에 대해서는 동시성과 성공 여부에 따라 일관된 상태(consistent)와 정의된 상태(defined)를 구분한다.

네임스페이스 연산 원자성: 파일 생성 등의 네임스페이스 변경은 마스터 락(lock)에 의해 순차적으로 직렬화되며 원자적(atomic)으로 처리된다.
데이터 변형 상태 분류:
- 정의됨(defined): 모든 클라이언트가 항상 동일한 데이터를 보며, 변형이 기록한 데이터 내용 전체를 온전히 읽을 수 있는 상태.
- 일관되지만 정의되지 않음(consistent but undefined): 모든 클라이언트가 동일한 데이터를 보지만, 어떤 단일 변경의 데이터인지 명확히 구분되지 않고 여러 동시 쓰기가 뒤섞인 상태.
- 일관되지 않음(inconsistent): 변형 실패 등으로 복제본 간 데이터가 일치하지 않아 서로 다른 클라이언트가 서로 다른 데이터를 보게 되는 상태.
데이터 변형은 일반 쓰기(writes)와 레코드 추가(record appends)로 나뉜다.
- write: 클라이언트가 지정한 파일 오프셋에 직접 데이터를 쓴다.
- record append: 클라이언트가 오프셋을 정하지 않고 데이터만 넘기며, 동시 요청이 있더라도 최소 한 번 이상(at least once) 원자적으로 추가되고 GFS가 결정한 오프셋을 반환한다.

2.7.2 Implications for Applications

애플리케이션은 무작위 덮어쓰기 대신 append 중심 워크플로와 자체 체크섬을 활용하여 GFS의 완화된 일관성 모델 위에서도 안전하게 동작한다.

GFS 환경에서 구글의 애플리케이션들은 다음과 같은 기법으로 완화된 일관성을 쉽게 수용한다.

임의 덮어쓰기 대신 Append 지향: 대부분의 애플리케이션은 기존 파일 덮어쓰기를 피하고 순차적 append 방식으로 데이터를 기록한다.
자기 검증(self-validation) 레코드와 체크포인트: 기록되는 레코드 안에 체크섬과 식별자를 포함시켜 중복 레코드나 불완전한 단편을 애플리케이션 수준에서 쉽게 필터링한다.
원자적 체크포인트 커밋: 라이터(writer)는 검증이 완료된 영역까지만 파일 오프셋을 진행시켜 리더(reader)가 항상 정의된 상태의 데이터만 읽도록 한다.

결과적으로 완화된 일관성 모델 덕분에 파일 시스템의 내부 구현 복잡도는 낮아졌고, 동시 append 처리량은 향상되었다.

3. System Interactions

GFS는 모든 데이터 변형에서 마스터의 개입을 최소화하도록 설계되었으며, 리스(lease) 기반 제어 흐름과 네트워크 토폴로지 기반 데이터 파이프라인을 엄격히 분리하여 처리량을 극대화한다.

The structure of the Google File System (GFS) 이미지출처 ¹³

클라이언트, 마스터, 청크서버가 상호 작용하여 데이터 변경(mutation), 원자적 레코드 추가, 스냅샷을 어떻게 구현하는지 단계별로 살펴본다.

3.1 Leases and Mutation Order

마스터는 모든 청크서버에 일일이 쓰기 순서를 지시하는 대신, 복제본 중 하나에 리스(lease)를 주어 primary로 지정하고 쓰기 순서 결정을 위임한다.

변형(mutation)은 쓰기 또는 추가 작업과 같이 청크의 내용이나 메타데이터를 변경하는 작업이며, 모든 청크 복제본에 동일하게 적용되어야 한다.

GFS는 복제본 간에 일관된 변형 순서를 유지하기 위해 리스(lease) 메커니즘을 사용한다.

리스(lease): 소유자에게 제한된 기간 동안 특정 자원에 대한 특정 권한을 부여하는 계약 ¹⁴

마스터는 복제본 중 하나에 청크 리스를 부여하며, 이를 primary라 부른다.

이미지출처 ¹⁵

primary: 변형 연산의 순서를 결정하고 쓰기를 주도
secondary(replica): primary가 지정한 순서대로 변형을 로컬에 적용

전역 변형 순서는 마스터가 선택한 리스 허가 순서에 의해 먼저 결정되고, 개별 리스 내에서는 primary가 부여한 일련 번호(serial number)에 의해 확정된다.

리스는 마스터의 관리 오버헤드를 최소화하도록 설계되었다. 리스의 초기 타임아웃(timeout)은 60초이다. 하지만 해당 청크에 지속적인 변형이 일어나는 동안 primary는 마스터와의 HeartBeat 통신을 통해 리스를 계속해서 연장(extend)할 수 있다.

쓰기(write) 작업의 구체적인 제어 흐름은 아래 다이어그램과 같다.

리스 조회: 클라이언트는 마스터에게 해당 청크의 리스를 보유한 primary와 다른 secondary 복제본들의 위치를 질의한다. 리스를 가진 서버가 없다면 마스터가 복제본 중 하나를 골라 새 리스를 부여한다.
메타데이터 캐싱: 마스터가 primary 식별자와 secondary 위치를 응답하면, 클라이언트는 이를 로컬에 캐시한다. 이후 primary와 연락이 끊기거나 리스가 만료되기 전까지는 마스터에 다시 질의하지 않는다.
데이터 선형 파이프라인 푸시: 클라이언트는 기록할 데이터를 모든 복제본 청크서버에 파이프라인 방식으로 푸시한다. 각 청크서버는 데이터를 수신하여 내부 LRU 버퍼 캐시에 임시 저장한다.
- LRU(Least Recently Used): 가장 오래전에 사용된 것은 디스크에 저장하고 메모리에는 가장 최근에 사용된 데이터를 저장함으로써 디스크 I/O를 줄이고 시스템 성능을 향상시키는 캐시 교체 알고리즘 ¹⁶
- 스케줄링(scheduling): 여러 프로세스가 번갈아가며 사용하는 자원을 어떤 시점에 어떤 프로세스에게 할당할지 결정하는 관리 기법 ¹⁷
쓰기 요청 전송: 모든 복제본이 데이터 수신을 확인(ack)하면, 클라이언트는 primary에 실제 쓰기(write) 명령을 보낸다. primary는 동시 유입된 여러 변형 연산에 연속적인 일련 번호를 매겨 순서를 확정하고, 자신의 로컬 청크에 순서대로 적용한다.
secondary로 쓰기 명령 전파: primary는 동일한 일련 번호 순서를 secondary 복제본들에 전달하여 로컬 청크에 그대로 적용하도록 지시한다.
secondary 완료 응답: 모든 secondary 복제본이 데이터 적용을 완료하면 primary에 성공 응답을 회신한다.
클라이언트 완료 응답: primary가 클라이언트에 최종 완료 응답을 보낸다. 어느 복제본에서라도 오류가 발생하면 실패가 보고되며, 해당 영역은 불일치(inconsistent) 상태로 남는다. 클라이언트 라이브러리는 실패한 연산을 재시도하여 이를 해결한다.

애플리케이션의 쓰기 크기가 청크 크기(64MB)를 초과하거나 경계에 걸치는 경우, GFS 클라이언트 라이브러리는 이를 여러 번의 독립적인 쓰기 작업으로 자동 분할한다. 이때 다른 동시 클라이언트의 작업과 인터리빙(interleaving)될 수 있다.

인터리브(interleave): 여러 프로세스의 작업이나 데이터를 교차로 번갈아 가며 배치하는 방식 ¹⁸

3.2 Data Flow

제어 흐름과 데이터 흐름을 분리함으로써, 제어 명령은 논리적 순서를 유지하고 대용량 데이터는 물리적 네트워크 토폴로지에 최적화된 파이프라인으로 전송된다.

제어 명령(RPC)이 클라이언트에서 primary를 거쳐 secondary로 흐르는 동안, 실제 데이터는 신중하게 선택된 청크서버 체인을 따라 선형(linear) 파이프라인 방식으로 전송된다.

데이터 파이프라인(data pipeline): 데이터를 출발지에서 수집하여 일련의 처리 단계를 거쳐 목적지까지 효율적으로 전달하는 흐름 구조 ¹⁹

GFS 데이터 전송의 핵심 목표는 다음 세 가지다.

개별 머신의 네트워크 대역폭 완전 활용: 각 머신이 데이터를 수신하면서 동시에 다음 머신으로 송신(전이중 통신)하게 만든다.
병목 구간 및 고지연 링크 회피: 네트워크 토폴로지상 IP 주소 거리가 가장 가까운 머신으로 우선 전송한다.
지연 시간(latency) 최소화: TCP 스트림 전송을 파이프라인화하여 이전 데이터 블록이 다음 서버로 전달되는 동안 다음 블록을 병렬 전송한다.

3.3 Atomic Record Appends

레코드 추가(record append)는 다수의 분산 클라이언트가 별도의 외부 분산 락(lock) 없이도 하나의 파일에 대규모 데이터를 안전하게 병렬 기록할 수 있게 해주는 핵심 연산이다.

일반 쓰기(write)에서는 클라이언트가 오프셋을 지정하므로 동일 영역에 동시 쓰기가 발생하면 데이터가 덮어써져 손상될 위험이 있다. 반면 레코드 추가(record append)에서는 클라이언트가 오프셋을 지정하지 않고 데이터만 전달한다.

GFS는 청크 경계를 넘지 않는 범위에서 자신이 결정한 오프셋에 데이터를 원자적으로 최소 한 번 이상(at least once) 추가하고, 그 오프셋을 클라이언트에 반환한다.

만약 레코드를 추가하려는데 현재 64MB 청크의 남은 공간이 레코드 크기보다 작다면, GFS는 청크의 남은 공간을 패딩(padding)으로 채운 뒤 클라이언트에게 다음 청크에 재시도하도록 안내한다.

레코드 추가의 일관성 특성은 다음과 같다.

원자성 보장: 레코드는 어떤 청크의 모든 복제본에서 동일한 오프셋에 최소 한 번 온전히 기록된다.
중복 가능성(at least once): 전송 오류나 복제 실패 후 재시도 과정에서 동일한 레코드가 중복 기록되거나 단편 패딩이 생길 수 있다.
애플리케이션 처리: 수신 애플리케이션은 레코드 내의 고유 ID나 체크섬을 통해 중복 레코드를 쉽게 필터링한다.

3.4 Snapshot

스냅샷(Snapshot)은 파일이나 디렉토리 트리의 사본을 실행 중인 변경 작업에 영향을 주지 않고 거의 즉각적으로(near-instantaneous) 생성한다.

사용자는 대규모 데이터셋의 브랜치 사본을 만들거나, 롤백이 필요한 실험적 작업을 수행하기 직전에 스냅샷을 생성한다.

GFS는 AFS(Andrew File System)와 유사한 표준 Copy-On-Write(COW) 기법을 사용하여 스냅샷을 구현한다.

마스터가 스냅샷 요청을 받으면 해당 파일 청크들의 모든 리스(lease)를 취소한다.
마스터는 새로운 메타데이터 엔트리를 생성하여 기존 청크들을 그대로 가리키게 하고 참조 카운트(reference count)를 증가시킨다.
이후 클라이언트가 해당 청크에 쓰기를 시도하면, 참조 카운트가 1보다 큰 것을 감지한 마스터가 새 청크를 생성하고 복사하도록 지시한 뒤에야 쓰기를 진행한다.

복제본을 즉시 복사하지 않고 메타데이터 참조만 복사함으로써, 수백 기가바이트의 스냅샷도 수 밀리초 만에 완성된다.

4. Master Operation

마스터는 모든 네임스페이스 연산을 실행하며, 청크의 생성·복제·재조정·회수 등 클러스터 전반의 생명주기를 총괄 제어한다.

시스템 전체의 일관성과 고가용성을 지탱하는 마스터의 내부 동작 메커니즘을 살펴본다.

4.1 Namespace Management and Locking

마스터는 네임스페이스 트리의 각 노드에 읽기-쓰기 락(Read-Write Lock)을 적용하고 엄격한 레벨 순서로 획득하여 교착 상태(deadlock) 없이 높은 동시성을 달성한다.

마스터의 여러 작업이 동시에 병렬 실행될 수 있도록 네임스페이스 영역별 세분화된 락(lock)을 사용한다.

잠금(lock): 트랜잭션 처리의 순차성을 보장하기 위한 상호 배제 기법 ²⁰
트랜잭션(transaction): 데이터베이스 및 시스템에서 분할할 수 없는 최소한의 업무 처리 단위
직렬화(serialization): 동시 실행되는 여러 트랜잭션이나 연산의 결과가 어떤 순차적 실행 결과와 동일하도록 보장하는 것 ²¹

전통적인 파일 시스템과 달리 GFS는 디렉토리별 내부 파일 목록 구조를 두지 않으며, 심볼릭 링크나 하드 링크 같은 별칭(alias)도 지원하지 않는다. 대신 전체 경로명(pathname)을 메타데이터에 매핑하는 룩업(lookup) 테이블을 유지하며, 접두사 압축(prefix compression)을 적용해 파일당 64바이트 미만의 컴팩트한 메타데이터 메모리를 유지한다.

네임스페이스 트리의 각 노드(디렉토리 또는 파일)는 개별 Read-Write Lock을 갖는다. 연산이 수행될 때 상위 디렉토리들은 Read Lock을 획득하고, 대상 파일이나 디렉토리 노드는 Write Lock을 획득한다.

이미지출처 ²²

스냅샷 작업: /home 및 /save에 대해 Read Lock을 획득하고, /home/user 및 /save/user에 대해 Write Lock을 획득한다.
파일 생성 작업: /home 및 /home/user에 대해 Read Lock을 획득하고, /home/user/foo에 대해 Write Lock을 획득한다.
위 두 작업은 /home/user 노드에서 한쪽은 Write Lock, 다른 쪽은 Read Lock을 요구하므로 충돌이 감지되어 올바르게 직렬화(serialization)된다.

교착 상태(deadlock)를 원천 차단하기 위해 락은 항상 트리의 깊이(level) 순서대로 획득되며, 동일 깊이 내에서는 사전식(lexicographical) 경로 순서로 획득된다.

4.2 Replica Placement

청크 복제본 배치 정책은 데이터 신뢰성과 고가용성을 극대화하는 동시에 네트워크 대역폭 활용을 최적화하는 다중 목표를 수행한다.

GFS 클러스터는 수백 대의 청크서버가 여러 개의 머신 랙(rack)에 나뉘어 설치되어 있다.

랙(rack): 서버나 네트워크 스위치 등 장비를 수직으로 장착하는 철제 프레임 캐비닛 ²³

복제본 배치 정책의 핵심은 서로 다른 랙 간 복제(cross-rack replication)다.

장애 내구성: 단일 서버 고장뿐 아니라 랙 스위치 고장이나 전원 차단으로 전체 랙이 다운되어도 다른 랙의 복제본을 통해 데이터 가용성이 유지된다.
대역폭 분산: 읽기 작업 시 여러 랙의 네트워크 대역폭을 동시에 활용할 수 있다. 쓰기 시에는 랙 간 트래픽이 추가로 발생하지만, 이는 가용성 확보를 위해 치러야 할 정당한 비용이다.

4.3 Creation, Re-replication, Rebalancing

청크 복제본은 청크 생성(chunk creation), 재복제(re-replication), 재조정(rebalancing)이라는 세 가지 계기로 생성되고 클러스터 전체에 균등하게 재배치된다.

마스터는 새 청크를 생성할 때 다음 기준을 종합적으로 고려하여 배치 위치를 결정한다.

디스크 활용률: 평균 이하의 디스크 공간을 사용하는 청크서버에 우선 배치하여 용량 불균형을 방지한다.
최근 생성 빈도 제한: 한 청크서버에 “최근” 생성 작업이 과도하게 몰리지 않도록 제한하여 동시 대량 쓰기 부하를 분산한다.
랙 간 분산: 복제본들을 서로 다른 랙에 걸쳐 분산 배치한다.

가용 복제본 수가 목표치(기본 3개) 미만으로 떨어지면 마스터는 우선순위(복제본 손실 심각도)에 따라 청크를 선별해 즉각 복제본을 복제(클론)하도록 지시한다. 이때 복제 트래픽이 일반 클라이언트 트래픽을 저해하지 않도록 활성 복제 작업 수와 전송 대역폭을 엄격히 제한한다.

또한 마스터는 주기적으로 복제본 분포를 점검하는 재조정(rebalancing)을 수행하여 디스크 여유 공간과 읽기/쓰기 부하를 점진적으로 평탄화한다.

4.4 Garbage Collection

파일이 삭제될 때 물리적 스토리지를 즉시 회수하지 않는 지연 가비지 컬렉션(Lazy Garbage Collection)은 대규모 분산 시스템의 신뢰성과 운영 안정성을 높인다.

4.4.1 Mechanism

애플리케이션이 파일을 삭제하면 마스터는 이를 연산 로그에 즉시 기록하지만, 물리적 리소스는 바로 회수하지 않는다.

히든 네임(Hidden Name) 변환: 삭제된 파일은 삭제 타임스탬프를 포함하는 숨김 파일명으로 이름이 변경된다.
주기적 네임스페이스 스캔: 마스터의 정기 백그라운드 스캔 과정에서 숨김 파일이 3일 이상 유지된 경우 네임스페이스에서 최종 제거된다.
고아 청크(Orphaned Chunk) 제거: 숨김 파일이 제거되면 메모리 내 메타데이터가 삭제되며, 후속 청크 스캔 시 어떤 파일과도 연결되지 않은 고아 청크를 식별하여 해당 메타데이터를 지운다. 이후 청크서버와의 HeartBeat 메시지 교환 시 청크서버에 삭제를 지시한다.

4.4.2 Discussion

지연 가비지 컬렉션 방식은 즉각 삭제 방식에 비해 다음과 같은 세 가지 결정적 이점을 제공한다.

장애 발생 시 높은 단순성과 신뢰성: 복잡한 분산 분산 2단계 커밋 없이도, 마스터가 인지하지 못하는 모든 청크를 가비지로 간주하여 백그라운드에서 균일하게 정리할 수 있다.
백그라운드 일괄 배치 처리: 스토리지 회수 작업을 정기 백그라운드 스캔과 HeartBeat 핸드셰이크에 병합(merge)하여 일괄 처리하므로 마스터의 CPU 오버헤드가 크게 분산된다.
- 핸드셰이크(handshake): 통신을 시작하기 전 양측이 정상 통신 파라미터를 동적으로 확인하고 조율하는 협상 과정 ²⁴
우발적 삭제에 대한 안전망 제공: 실수로 파일을 삭제하더라도 유예 기간(3일) 동안 복구할 수 있는 완충 장치를 제공한다.

4.5 Stale Replica Detection

청크서버가 다운되어 변경 사항을 전달받지 못한 경우 발생하는 오래된 복제본(stale replica)은 버전 번호(chunk version number)를 통해 정밀하게 감지된다.

마스터는 각 청크에 대해 최신 복제본과 지연된 복제본을 구분하기 위한 버전 번호를 관리한다.

버전 증가: 마스터가 청크에 새로운 리스를 부여할 때마다 청크 버전 번호를 1 증가시키고 최신 복제본들에 알린다.
오래된 복제본 감지: 만약 다운되었던 청크서버가 복구되어 보고한 버전 번호가 마스터의 현재 버전 번호보다 낮다면, 마스터는 해당 복제본을 오래된(stale) 것으로 판정한다.
가비지 정리: 오래된 복제본은 클라이언트 읽기 요청 대상에서 즉시 제외되며, 정기 가비지 컬렉션 주기에서 안전하게 삭제된다.

5. Fault Tolerance And Diagnosis

수천 대의 서버가 동작하는 클러스터에서는 장애가 상시 발생하므로, 빠른 자동 복구(fast recovery)와 다중 복제(replication), 그리고 블록 단위 체크섬을 통해 무결성과 고가용성을 지켜낸다.

5.1 High Availability

GFS 클러스터 내의 수백~수천 개 서버 중 일부는 언제나 오프라인이 될 수 있다. 시스템 가용성을 유지하는 두 가지 핵심 전략은 빠른 복구(fast recovery)와 복제(replication)다.

5.1.1 Fast Recovery

마스터와 청크서버는 모두 비정상 종료(kill)되더라도 몇 초 만에 이전 상태를 온전히 복구하고 재시작할 수 있도록 설계되었다.

정상 종료와 비정상 종료를 구분하지 않으며, 서버 프로세스가 종료되면 클러스터 인프라가 즉시 새 프로세스를 띄워 신속하게 클러스터에 재참여시킨다.

5.1.2 Chunk Replication

각 청크는 서로 다른 랙에 위치한 청크서버들에 복제되며, 기본 복제 수준은 3이다(default: 3).

사용자는 파일 네임스페이스 경로별로 복제본 수를 다르게 지정할 수 있다. 마스터는 청크서버가 오프라인이 되거나 손상된 복제본이 감지되면 즉시 다른 정상 복제본으로부터 새 복제본을 복사(re-replication)하여 목표 복제 수준을 항상 유지한다.

체크섬(checksum): 데이터 전송이나 저장 중 발생한 오류를 검출하기 위해 데이터 바이트를 계산해 붙이는 오류 검출용 해시값 ²⁵

5.1.3 Master Replication

단일 마스터의 신뢰성을 확보하기 위해 마스터의 작업 로그와 체크포인트는 여러 원격 복제 머신에 실시간 복제된다.

상태 변경은 로그 레코드가 로컬 마스터뿐 아니라 모든 원격 마스터 복제본의 디스크에 플러시(flush)된 후에만 최종 커밋된다. 단일 마스터 프로세스가 죽으면 외부 모니터링 시스템이 즉시 복제본 중 하나를 새 마스터로 승격시킨다. 또한 읽기 부하를 분산하기 위해 약간의 지연(수초 이내)을 감수하고 읽기 전용으로 서비스하는 섀도(shadow) 마스터도 활용된다.

5.2 Data Integrity

각 청크서버는 독자적인 체크섬(checksum) 검증을 통해 저장 데이터의 비트 손상이나 디스크 오류를 자율적으로 감지한다.

각 64MB 청크는 64KB 블록으로 세분화되며, 각 블록마다 32비트 체크섬이 부여된다.

체크섬 보관: 체크섬은 사용자 데이터와 물리적으로 분리되어 메모리에 상주하며, 연산 로그와 함께 디스크에 영속 저장된다.
읽기 시 검증: 클라이언트가 데이터를 요청하면 청크서버는 데이터를 반환하기 전에 64KB 블록 단위로 체크섬을 검증한다. 손상이 발견되면 청크서버는 즉시 에러를 반환하고 마스터에 보고하여 다른 정상 복제본으로부터 복구하도록 유도한다.
백그라운드 스캔: 유휴(idle) 시간 동안 청크서버는 거의 읽히지 않는 비활성 청크들을 주기적으로 스캔하여 데이터 손실을 사전에 감지하고 복구한다.

5.3 Diagnostic Tools

GFS 서버는 모든 중요한 이벤트와 전체 RPC 요청/응답을 기록하는 상세한 진단 로그(diagnostic log)를 남긴다.

RPC 로그에는 실제 파일 데이터 본문만을 제외한 모든 요청과 응답 메타데이터가 정확히 기록된다. 여러 머신의 RPC 레코드를 시간순으로 취합함으로써 장애 발생 시 전체 상호작용 타임라인을 정확히 재구성(reconstruct)하여 근본 원인을 진단할 수 있으며, 실제 워크로드 트레이스를 추출해 부하 테스트에 활용한다.

6. Measurements

소규모 테스트 클러스터 마이크로 벤치마크와 실제 대규모 구글 프로덕션 환경에서 수집한 성능 수치는 GFS 설계의 실질적 효용성을 명확히 입증한다.

6.1 Micro-benchmarks

1개의 마스터, 2개의 마스터 복제본, 16개의 청크서버, 16개의 클라이언트로 구성된 테스트 클러스터에서 표준 성능을 측정했다.

6.1.1 Reads

N개의 클라이언트가 파일 시스템에서 동시에 읽는 환경에서 처리량을 측정했다. 각 클라이언트는 320GB 파일 셋에서 임의로 선택된 4MB 영역을 읽으며, 이를 256번 반복하여 클라이언트당 총 1GB의 데이터를 읽는다.

청크서버 전체 메모리가 32GB에 불과하므로 리눅스 버퍼 캐시 적중률(hit rate)은 최대 10% 수준으로 억제되어 실제 디스크 I/O 성능이 측정된다.

단일 클라이언트 읽기 속도는 네트워크 제한의 80% 수준인 10MB/s를 기록했다.
16개 클라이언트가 동시 읽기를 수행할 때의 총 읽기 속도는 링크 한계(125MB/s)의 약 75%인 94MB/s(클라이언트당 약 6MB/s)에 도달했다.

6.1.2 Writes

N개의 클라이언트가 N개의 서로 다른 파일에 1MB 연속 쓰기로 각 1GB의 데이터를 동시에 기록했다.

단일 클라이언트의 쓰기 속도는 대역폭 한계의 절반 수준인 6.3MB/s였다. 데이터를 3개의 복제본으로 파이프라인 전파하는 과정의 네트워크 지연이 반영된 결과다.
16개 클라이언트가 동시에 기록할 때의 총 쓰기 속도는 이론적 한계의 절반에 해당하는 35MB/s에 도달했다.

6.1.3 Record Appends

N개의 클라이언트가 단일 파일에 동시에 원자적 레코드 추가(record append)를 수행하는 벤치마크 결과다.

동시 클라이언트 수와 무관하게, 성능은 해당 파일의 마지막 청크를 호스팅하는 청크서버의 네트워크 대역폭에 의해 근본적으로 제한된다.
단일 클라이언트 시 6.0MB/s에서 시작하여 16개 동시 클라이언트에서는 4.8MB/s로 소폭 하락하는데, 이는 네트워크 전송 속도 편차와 스위치 혼잡(congestion)에 기인한다.

6.2 Real World Clusters

구글 프로덕션 환경의 대표적 두 클러스터(Cluster A, Cluster B)를 실측한 결과는 GFS 설계의 실효성을 뒷받침한다.¹

클러스터 규모 및 스토리지 구성 (Table 2):
- Cluster A (R&D 워크로드): 342대의 청크서버로 72TB 디스크(사용 55TB, 3중 복제 기준 파일 데이터 18TB)를 운영하며, 735,000개 파일과 992,000개 청크를 관리한다. 청크서버 메타데이터 합계는 13GB이며, 단일 마스터 메모리 메타데이터는 48MB에 불과하다.
- Cluster B (프로덕션 데이터 처리 워크로드): 227대의 청크서버로 180TB 디스크(사용 155TB, 파일 데이터 52TB)를 운영하며, 737,000개 파일(삭제 유예 대기 파일 232,000개 포함)과 1,550,000개 청크를 관리한다. 청크서버 메타데이터 합계는 21GB이고, 마스터 메모리 메타데이터는 60MB에 머문다.
- 파일당 마스터 메타데이터 메모리는 평균 100바이트 미만으로 유지된다.
실측 처리량 및 마스터 부하 (Table 3):
- Cluster A의 지속 읽기 처리량은 주간 평균 580MB/s(네트워크 한계 750MB/s의 약 77%)를 기록했다.
- Cluster B는 최대 1,300MB/s의 피크 읽기를 지원하며, 쓰기 버스트 시 100MB/s(3중 복제 네트워크 부하 300MB/s)를 처리했다.
- 마스터에 인입되는 연산 빈도는 초당 200~500 Ops/s 수준으로, 단일 마스터의 연산 처리 한계 내에서 병목 없이 수용되었다.
장애 복구 실측 (Recovery Time):
- Cluster B에서 약 15,000개 청크(600GB 데이터)를 보유한 청크서버 1대가 비정상 다운되었을 때, 클러스터 스케줄러는 일반 트래픽 보호를 위해 최대 91개 동시 복제(클론당 최대 6.25MB/s)로 제한하면서도 23.2분 만에 모든 청크 복제본을 전량 복원(실효 복제율 440MB/s)했다.

7. Experiences

초기 프로덕션 백엔드로 시작한 GFS는 점차 연구 개발 및 일상 엔지니어링 전체를 지탱하는 구글의 핵심 스토리지 기반으로 자리 잡았다.

실제 운영 과정에서 리눅스 파일 시스템의 한계(버퍼 캐시 문제, fsck 지연 등)를 경험하며 사용자 공간 청크 관리와 디스크 I/O 최적화를 고도화했다.

AFS, NFS, Frangipani 등 기존 분산 파일 시스템과 비교했을 때, GFS는 엄격한 POSIX 준수보다 구글 고유의 대규모 데이터 처리 요구에 특화된 실용주의 설계를 택했다.

위치 투명성(Location Independence): 로드 밸런싱과 내결함성을 위해 청크를 시스템 전역에서 자유롭게 마이그레이션한다.
클라이언트 캐싱 배제: 대용량 스트리밍 읽기와 대규모 추가 워크로드는 캐시 재사용률이 극히 낮으므로, 클라이언트 데이터 캐싱을 과감히 제거하여 복잡도를 줄였다.
중앙 집중식 단일 마스터: 메타데이터 전담 마스터를 단일화하되 데이터 I/O 경로에서 완전히 배제하여, 복잡한 분산 합의 없이도 전역 최적화 결정을 가능하게 했다.

GFS는 이론적 분산 일관성보다 대규모 상용 클러스터의 고장 빈도와 워크로드 특성에 맞춘 실용적 분산 파일 시스템 설계 기준을 제시했다.

8.1 한계와 트레이드오프

GFS가 대규모 배치 및 스트리밍 워크로드에서 거둔 성공 이면에는 다음과 같은 설계적 한계와 트레이드오프가 존재한다.¹

단일 마스터의 메타데이터 메모리 및 연산 병목: 모든 메타데이터를 마스터의 메모리(RAM)에 상주시키는 설계는 64MB 대형 청크를 통해 메타데이터 크기를 파일당 64~100바이트 수준으로 억제했으나, 파일 수가 수억 개 이상으로 증가하거나 네임스페이스 트리가 극도로 비대해지면 단일 머신의 물리 RAM 용량 한계와 메타데이터 서빙 RPC 처리량 병목에 직면한다.
작은 파일 및 임의 쓰기 비효율: 64MB 대형 청크는 수십 KB 단위의 작은 파일이 다수 존재하는 환경에서 내부 단편화와 특정 청크서버로의 부하 집중(hot spot)을 유발한다. 또한 완화된 일관성 모델은 순차 추가(append)에 최적화되어 있어, 파일 중간 영역에 대한 임의 덮어쓰기(random write)나 엄격한 POSIX 파일 락이 필요한 애플리케이션에는 적합하지 않다.
완화된 일관성과 레코드 중복(At-least-once) 부담: 레코드 추가(record append)는 원자적 추가를 보장하지만 네트워크 실패 재시도 과정에서 ‘최소 한 번 이상(at least once)’ 의미론으로 인해 중복 레코드와 패딩 영역이 남을 수 있으며, 이를 식별하고 필터링하는 검증 로직을 애플리케이션 계층이 직접 구현해야 한다.

9. 핵심 요약 및 시사점

Google File System(GFS) 논문이 현대 분산 시스템에 남긴 핵심 통찰과 설계 원칙은 다음과 같이 요약할 수 있다.

장애를 표준으로 수용(Fault Tolerance as Norm): 저렴한 상용 하드웨어의 빈번한 고장을 예외가 아닌 일상으로 가정하고, 3중 복제와 빠른 무상태 복구, 백그라운드 무결성 검증을 아키텍처 중심에 두었다.
제어와 데이터의 물리적 분리(Decoupling Control and Data): 단일 마스터는 메타데이터와 리스(lease) 관리만 전담하고 실제 데이터 I/O는 클라이언트와 청크서버 간 직결 파이프라인으로 처리하여 단일 마스터의 I/O 병목을 최소화했다.
64MB 대형 청크와 인메모리 메타데이터: 청크 크기를 64MB로 대형화하여 수백 테라바이트 클러스터의 전체 메타데이터를 단일 마스터의 메모리(RAM)에 상주시키고 낮은 지연 시간의 인메모리 조회를 실현했다.
Append 중심 워크로드와 완화된 일관성 모델: 임의 덮어쓰기 대신 순차적 원자적 레코드 추가(Atomic Record Append)에 집중하고 일관성 모델을 실용적으로 완화하여 동시성 처리량과 시스템 단순성을 극대화했다.
빅데이터 생태계의 기틀 마련: GFS 아키텍처는 이후 하둡 분산 파일 시스템(HDFS)의 모태가 되었으며, MapReduce 및 BigTable과 결합되어 현대 분산 빅데이터 컴퓨팅의 사실상 표준 패러다임을 확립했다.

References

KakaoTalk Twitter Facebook LinkedIn