구글 파일 시스템
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
구글 파일 시스템(GFS)은 구글의 대규모 데이터 저장 및 처리를 위해 설계된 분산 파일 시스템이다. 64MB 크기의 청크로 파일을 분할하여 여러 청크 서버에 분산 저장하며, 마스터 노드가 메타데이터를 관리하고 청크 서버의 상태를 감시한다. GFS는 POSIX 인터페이스를 제공하지 않으며, 클라이언트와 청크 서버 간 직접 데이터 전송을 통해 높은 읽기 성능을 제공한다. 데이터 복제 및 자동 복구 기능을 통해 데이터 안정성과 가용성을 확보하며, Hadoop 분산 파일 시스템(HDFS) 등 관련 기술에 영향을 미쳤다.
더 읽어볼만한 페이지
- 리눅스 파일 시스템 - GlusterFS
GlusterFS는 클라이언트-서버 구조의 분산 파일 시스템으로, 여러 서버의 스토리지를 통합 볼륨으로 묶어 파일 기반 스트라이핑, 부하 분산, 볼륨 페일오버 등의 기능을 제공하며, 스토리지 브릭, 파일 기반 미러링 및 스테이트리스 클라이언트를 통해 확장성과 안정성을 확보한다. - 분산 파일 시스템 - 아파치 하둡
아파치 하둡은 대용량 데이터를 분산 처리하기 위한 자바 기반의 오픈 소스 프레임워크로, HDFS, 맵리듀스, YARN 등의 모듈로 구성되어 클라우드 환경에서도 사용된다. - 분산 파일 시스템 - 제로넷
제로넷은 중앙 서버 없이 P2P 방식으로 운영되어 검열에 저항성을 가지며 사용자가 직접 콘텐츠를 공유할 수 있는 분산 네트워크 플랫폼으로, 웹사이트 개발이 가능하고 제로넷-컨서번시 포크를 통해 기능 추가 및 새로운 P2P 네트워크로의 마이그레이션이 진행 중이다. - 네트워크 파일 시스템 - 클라우드 스토리지
클라우드 스토리지는 가상화 기술을 기반으로 데이터를 분산 저장하여 관리하며, 웹 또는 앱을 통해 파일 작업이 가능하고 용량 확장이 유연하며, 객체, 파일, 블록 스토리지의 세 가지 유형으로 발전했다. - 네트워크 파일 시스템 - 아마존 S3
아마존 S3는 AWS에서 제공하는 객체 스토리지 서비스로, 데이터 액세스 빈도 및 성능 요구 사항에 따라 다양한 스토리지 클래스를 제공하며 높은 확장성, 고가용성, 낮은 지연 시간, 높은 내구성을 제공한다.
| 구글 파일 시스템 - [IT 관련 정보]에 관한 문서 | |
|---|---|
| 개요 | |
| 라이선스 | 사유 |
| 운영체제 | 리눅스 |
| 상세 정보 | |
| 개발자 | 구글 |
| 프로그래밍 언어 | 불명 |
| 기타 | |
| 참고 자료 | Colossus: Google File System (GFS)의 후속 제품 |
2. 설계
구글 파일 시스템(GFS)은 검색 엔진을 비롯한 구글의 핵심 데이터 스토리지 및 사용 요구 사항을 충족하기 위해 개발되었다. 이는 래리 페이지와 세르게이 브린이 스탠퍼드 대학교에서 개발한 "빅파일"에서 발전한 것이다. GFS는 저렴한 범용 컴퓨터를 활용하여 대규모 데이터를 처리하도록 설계되었으며, 높은 처리량을 제공하는 데 중점을 두고 있다.
GFS는 하나의 '마스터' 노드와 여러 '청크 서버'로 구성된 클러스터 형태로 구성된다. 각 파일은 64메가바이트 크기의 '청크'로 나뉘어 여러 청크 서버에 분산 저장되며, 각 청크는 생성 시 마스터 노드에 의해 고유한 64비트 레이블을 할당받는다. 마스터 노드는 이 레이블을 통해 청크의 위치와 파일과의 매핑 정보 등 모든 메타데이터를 관리한다.
데이터 안정성을 위해 각 청크는 기본적으로 3번 복제되며, 이는 구성 가능하다. GFS는 사용자 공간 라이브러리로 제공되며, POSIX 인터페이스를 지원하지 않는다. 데이터의 읽고 쓰기는 클라이언트와 청크 서버 간에 직접 이루어지며, 캐시가 개입하지 않는다. 또한, 메타데이터가 메모리에 저장되어 빠른 검색이 가능하다.
2. 1. 마스터 서버
마스터 서버는 실제 청크를 저장하지 않고, 청크와 관련된 모든 메타데이터를 저장한다. 메타데이터에는 64비트 레이블, 청크 위치, 파일을 구성하는 청크 정보(파일-청크 매핑 테이블), 청크 사본 위치, 특정 청크에 접근 중인 프로세스 정보 등이 포함된다. 또한, 노드 오류 등으로 청크 사본 수가 설정된 값 미만으로 감소했을 때, 마스터 서버의 지시에 따라 청크를 복제("스냅샷")하는 프로세스 정보도 메타데이터로 관리한다.[2]마스터 서버는 각 청크 서버로부터 주기적으로 "하트비트 메시지"를 수신하여 메타데이터를 최신 상태로 유지한다.[2]
수정 권한은 시간 제한적인 "임대" 시스템으로 관리된다. 마스터 서버는 특정 프로세스에 한정된 기간 동안 청크 수정 권한을 부여하며, 이 권한은 다른 프로세스가 마스터 서버로부터 권한을 받기 전까지 유효하다.[2] 수정 권한을 가진 청크 서버(기본 청크 보유자)는 변경 사항을 백업 사본이 있는 청크 서버로 전파한다. 모든 청크 서버가 변경 사항을 승인해야만 변경이 완료되므로, 작업의 원자성이 보장된다.[2]
프로그램은 청크에 접근하기 위해 먼저 마스터 서버에 원하는 청크의 위치를 질의한다. 해당 청크에 대한 임대가 없는 경우, 마스터 서버는 위치 정보를 응답하고, 프로그램은 청크 서버에 직접 접속하여 데이터를 수신한다. 이는 Kazaa의 슈퍼노드와 유사한 방식이다.[2]
마스터 노드는 메타데이터 유지 외에도 청크 서버의 상태를 감시하는 역할도 수행한다.[7]
마스터 노드는 "네임스페이스(디렉토리 구조)", "액세스 권한", "원본 파일과 청크의 대응표", "청크가 저장되어 있는 서버의 위치" 등 모든 메타데이터 정보를 메모리에 저장한다.[7] 클라이언트는 먼저 마스터 노드와 통신하여 청크 ID와 위치를 질의하고, 이후 청크 서버에 직접 접근하여 청크를 수신한다. 마지막으로, 수신한 데이터를 결합하여 원본 파일을 복원한다.[7]
2. 2. 청크 서버
GFS 클러스터는 여러 노드로 구성되는데, 이 노드들은 크게 마스터 노드와 여러 개의 청크 서버로 나뉜다. 각 파일은 고정 크기의 청크로 나뉘며, 청크 서버는 이러한 청크들을 저장한다. 각 청크는 생성될 때 마스터 노드로부터 전역적으로 고유한 64비트 레이블을 할당받고, 파일과 구성 청크 간의 논리적 매핑이 유지된다.[6]청크 서버는 실제로 데이터를 저장하는 역할을 담당한다. 청크를 여러 개 복제하여 저장함으로써 데이터 안정성과 가용성을 높인다. 기본적으로 청크는 세 번 복제되지만, 필요에 따라 복제 횟수를 조절할 수 있다. 예를 들어, 자주 사용되는 파일은 더 많이 복제하고, 엄격한 스토리지 최적화를 사용하는 파일은 더 적게 복제할 수 있다.
파일은 64메가바이트의 고정 크기 ''청크''들로 나뉘는데, 덮어쓰거나 크기를 줄이는 경우가 극히 드물며 보통 추가되거나 읽혀진다.[6]
클라이언트 또는 애플리케이션이 GFS 영역에 데이터를 기록하는 과정은 다음과 같다.
# 데이터는 청크로 분할된다.
# 마스터 노드는 청크가 생성되었을 때, 각 청크에 64비트의 고유한 ID를 부여한다.
# 리눅스가 설치된 청크 노드는 로컬 디스크에 청크를 기록한다. 이때, 가용성 확보를 위해 여러 개의 서로 다른 청크 서버에 동일한 청크를 기록한다. (기본적으로 3개의 레플리카를 생성)
데이터를 읽을 때의 과정은 다음과 같다.
# 클라이언트는 먼저 마스터 노드와 통신하여 청크의 ID와 위치를 질의한다.
# 이어서 클라이언트는 청크 서버에 직접 액세스하여 청크를 받는다.
# 최종적으로 데이터를 결합하여 원본 파일을 복원한다.
마스터 서버는 수정 권한을 시간 제한적인 "임대" 시스템으로 관리한다. 마스터 서버는 프로세스에게 일정 기간 동안 청크를 수정할 수 있는 권한을 부여하고, 수정 청크 서버(항상 기본 청크 보유자)는 변경 사항을 백업 사본이 있는 청크 서버로 전파한다. 모든 청크 서버가 변경 사항을 승인해야만 변경 사항이 저장되므로, 작업의 완료와 원자성이 보장된다.
프로그램은 청크에 접근하기 위해 먼저 마스터 서버에 원하는 청크의 위치를 쿼리한다. 청크가 작동 중인 경우(미해결된 임대가 없는 경우), 마스터는 위치를 응답하고 프로그램은 청크 서버에 직접 연락하여 데이터를 수신한다.
2. 3. 클라이언트
애플리케이션은 API를 통해 파일 시스템에 접근한다.[6] 클라이언트는 먼저 마스터 노드와 통신하여 청크의 ID와 위치를 질의한다. 청크가 작동 중인 경우, 클라이언트는 청크 서버에 직접 액세스하여 청크를 받는다. 최종적으로 데이터를 결합하여 원본 파일을 복원한다.2. 4. 데이터 복제 및 가용성
GFS는 데이터 안정성과 가용성을 확보하기 위해 각 청크를 여러 청크 서버에 복제한다.[6] 기본적으로 3개의 복제본(레플리카)을 생성하며, 필요에 따라 복제 횟수를 조절할 수 있다. 이는 잦은 하드웨어 고장 환경에서도 데이터 손실을 최소화하고 자동 복구 기능을 제공하기 위함이다.[6]파일은 64메가바이트 크기의 '청크'로 나뉘어 여러 청크 서버에 분산 저장되며, 각 청크는 생성 시 마스터 노드에 의해 고유한 64비트 레이블을 할당받는다. 마스터 노드는 이 레이블을 통해 청크의 위치와 파일과의 매핑 정보 등 모든 메타데이터를 관리한다.
수요가 많은 파일은 더 많은 복제본을 가질 수 있으며, 스토리지 최적화를 사용하는 파일은 더 적은 복제본을 가질 수도 있다.
2. 5. 성능
벤치마킹 결과,[2] GFS는 단일 디스크와 비슷한 읽기 성능(80~100MB/s)을 보이지만, 쓰기 성능은 30MB/s로 감소하며, 기존 파일에 데이터를 추가하는 속도는 5MB/s로 비교적 느리다. 마스터 노드가 데이터 읽기에 직접 관여하지 않기 때문에(데이터는 청크 서버에서 읽기 클라이언트로 직접 전달됨), 읽기 속도는 청크 서버의 수에 따라 크게 증가하여 342개의 노드에서 583MB/s를 달성한다. 여러 서버를 집계하면 대용량을 확보할 수 있지만, 데이터를 세 개의 독립적인 위치에 저장하여(중복성을 제공하기 위해) 다소 감소한다.3. 인터페이스
구글 파일 시스템은 POSIX 인터페이스를 제공하지 않는다.[3] 파일은 디렉터리 내에서 계층적으로 구성되며 경로 이름으로 식별된다. 파일 생성, 삭제, 열기, 닫기, 읽기, 쓰기와 같은 파일 연산이 지원된다. 여러 클라이언트가 동일한 파일에 동시에 데이터를 추가할 수 있으며 원자성을 보장하는 레코드 추가 기능을 지원한다.
4. 한계점 및 비판
GFS는 잦은 업데이트가 필요한 작업에는 적합하지 않을 수 있다. GFS는 추가 및 읽기 중심의 작업에 최적화되어 있으며, 덮어쓰기 작업은 드물게 발생하도록 설계되었기 때문이다. 파일들은 일반적인 파일 시스템에서의 클러스터들과 섹터들과 비슷하게 64MB로 고정된 크기의 청크들로 나뉘는데, 이것들은 덮어쓰거나 크기를 줄이는 경우가 극히 드물며 보통 추가되거나 읽혀지기만 한다.
5. 관련 기술
- Hadoop 분산 파일 시스템 (HDFS): GFS와 거의 동일한 구조를 채택하고 있는 오픈 소스 분산 파일 시스템이다.[4]
- 빅테이블: GFS 위에 구축된 분산 데이터베이스 시스템이다.
- 맵리듀스: 대규모 데이터 처리를 위한 프로그래밍 모델로, GFS와 함께 구글의 핵심 기술 중 하나이다.
- 스패너 (데이터베이스): 구글의 글로벌 분산 데이터베이스 시스템이다.
참조
[1]
웹사이트
Colossus: Successor to the Google File System (GFS)
https://www.systutor[...]
SysTutorials
2012-11-29
[2]
서적
Data Intensive Storage Services for Cloud Environments
https://books.google[...]
IGI Global
[3]
간행물
GFS: Evolution on Fast-forward
https://queue.acm.or[...]
2009-08
[4]
문서
英語版Wikipediaより
[5]
웹사이트
Colossus: Successor to the Google File System (GFS)
https://www.systutor[...]
2018-01-01
[6]
웹사이트
The Google File System
https://static.googl[...]
2018-01-01
[7]
웹사이트
GFS: The Google File System
http://www.cs.cornel[...]
2018-01-01
[8]
월드 와이드 웹
High Scalability
http://highscalabili[...]
2010-09-11
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com