jaso extends j2ee

*필자도 지금 막 File System에 대해 학습하기 시작했기 때문에 파일 시스템들에 대한 기초 지식은 많이 부족합니다. 본 컬럼에서 설명되는 File System 대한 내용 중 틀린 부분이 있으면 언제든지 피드백 주시기 바랍니다.*

File System에 대한 일반적인 생각은 OS에서 기본적으로 제공하는 기능으로 생각하고 있다. 물론 Windows와 Linux와 같은 OS는 기본적으로 파일을 관리하는 기능을 제공하고 있다. 파일 관리 기능 역시 OS가 제공해야 하는 기능 중의 하나이기 때문이다. 하지만 OS에서 제공하는 File System 만으로는 시스템이 요구하는 Scalability, Reliablity 등을 충분히 제공 받을 수 없는 경우가 있다. 이런 여러 가지 이유로 인해 OS에서 기본적으로 제공하는 File System 외에 추가로 특수한 목적으로 만들어진 File System을 사용하게 된다. Google, Hadoop에서 말하는 File System은 분산 컴퓨팅 환경을 목적으로 만들어진 파일시스템이라고 할 수 있다.

Hadoop은 Google File System의 기본 개념을 그대로 가져와 구현하고 있다. 따라서 Hadoop을 이해하기 위해서는 Google File System 에 대한 이해가 필수이다. Google File System은 다음과 같은 특징을 가지고 있다.

- PC와 같은 일반적으로 값싼 장비를 이용한다.
- NAS 등과 같은 고비용의 장비를 사용하지 않고 소프트웨어로 해결한다.
- 많은 수의 대용량 파일(수백 MB ~ 수 GB)을 처리할 수 있어야 한다.
- 추가로 데이터에 대한 백업을 하지 않는다.
- 장비의 추가 및 제거가 자유로워야 한다.
- 특정 노드 장애 시에도 별도의 복구 절차 없이 지속적인 서비스 제공이 가능하다.



위의 그림은 Google File System의 기본 아키텍처이다. Google File System은 GFS master, GFS chunkserver 두 개의 데몬 서버와 이 데몬 서버와 통신을 통해 파일을 처리할 수 있게 하는 client로 구성된다. GFS master는 파일이름, 크기 등과 같은 파일에 대한 메타데이터를 관리한다. 이것은 커널 레벨에서 운영되는 애플리케이션이라기 보다는 WAS(Web Application Server)나 DBMS와 같은 사용자 애플리케이션 수준이라고 할 수 있다.
GFS chunkserver는 실제 파일을 저장하는 역할을 수행하는 노드이다. GFS는 수백 MB ~ 수 GB 이상의 크기를 가지고 있는 하나의 파일을 여러 조각으로 나눈 다음, 이것을 여러 chunkserver에 저장시킨다. GFS에서는 이렇게 나누어진 파일의 조각을 chunk라고 부른다. 환경설정을 통해 조정할 수 있지만 default 에서는 64MB로 설정되어 있다. GFS chunkserver 역시 사용자 애플리케이션으로 만들어진 데몬 프로그램이다.
GFS Client는 GFS master와 GFS chunkserver와의 통신을 통해 파일의 생성, 읽기, 쓰기 등의 작업을 수행하는 역할을 한다. 일반적으로는 API 형태로 제공되고 내부적으로 socket 등의 통신을 이용하여 서버와 통신한다.
파일에 대한 처리 순서를 설명하면 다음과 같다.


이런 방식으로 동작하기 때문에 client와 master 사이에는 파일에 대한 정보만 주고 받을 뿐 실제 파일 데이터의 이동 및 처리는 client와 chunkserver 사이에만 발생하게 된다. 이것은 수백 ~ 수천대의 chnukserver와 수 ~ 수십 PT의 데이터 불륨, 수 억개의 파일을 관리해야 하는 상황에서 master의 부하를 최소화 하도록 한 것이다.
Google File System의 가장 큰 특징 중의 하나는 바로 replication 기능이라고 할 수 있다. Google File System은 chunk를 하나의 chunkserver에만 저장시키는 것이 아니라 여러 개의 chunkserver에 복사본을 저장한다. 기본적으로는 3개의 복사본을 가지도록 한다. Chunkserver의 down 등으로 인해 정해진 복사본 수만큼 가지고 있지 않는 경우 master는 새로운 복사본을 만들도록 관리하고 있다. 이렇게 복사본을 관리할 경우 다음과 같은 장점이 있다.

- chunk를 저장하고 있는 chunkserver가 down 되어도 장애 없이 서비스를 제공할 수 있도록 한다.
- 항상 복사본이 존재하고 있기 때문에 파일 시스템 수준에서 RAID1 수준의 미러링 백업을 제공한다.
(실제로 Google은 NAS아 같은 고비용의 스토리지 장비를 사용하지 않기 때문에 Yahoo와 같은 다른 경쟁업체에 비해 월등하게 싼 가격으로 시스템을 운영하고 있다.)
- 특정 파일 또는 chunk에 read에 대한 access가 집중되는 경우 하나의 chunkserver로 집중되는 부하를 분산시킬 수 있으며 서버에 대한 분산뿐만 아니라 Disk head 와 같은 물리적인 장치에 대한 분산 효과가 있다.

장점이 있으면 물론 단점도 있다.
- Google File System에서의 복사본을 생성하는 것은 비동기적인 방식이 아니라 동기적인 방식으로 생성한다. 이것은 파일을 생성하는 시점에 복사본까지 완전히 저장된 후에 파일 생성에 대한 완료처리를 한다는 것이다. 따라서 일반 파일 시스템에 비해 기본적으로 3배 이상의 write 속도 저하가 발생한다. 따라서 Google File System의 경우 온라인 실시간 시스템에서는 사용하기 부적합 할 수 있으며 파일을 한번 생성한 다음부터는 계속해서 읽기 작업만 발생하는 시스템에 적합하다고 할 수 있다. 대표적인 시스템이 검색, 동영상, 이미지, 메일(Mime 파일) 서비스 등이다(모두 Google의 핵심 서비스라고 할 수 있다.).
- 3개의 복사본을 저장하기 때문에 3배의 디스크 공간을 필요로 한다. Google File System의 경우 기본적으로 PC에 붙어 있는 값싼 디스크도 사용할 수 있기 때문에 NAS와 같이 고비용의 스토리지를 사용하는 엔터프라이즈 환경에서는 단점이라고 할 수 없다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 김형준