HDFS·Ceph·GlusterFS로 설계하는 분산 파일 처리

단일 스토리지의 한계를 넘는 방식

빅데이터와 클라우드 환경에서는 단일 서버만으로 스토리지 용량과 I/O 성능을 감당하기 어렵다. HDFS, Ceph, GlusterFS 같은 분산 파일 시스템은 노드를 추가하는 방식으로 페타바이트급 데이터를 처리하고, 샤딩과 복제를 조합해 가용성과 성능을 확보한다.

분산 파일 시스템 설계에서 반복해서 확인할 요구사항은 확장성, 고가용성, 일관성, 성능, 내구성이다. 노드 증가에 따라 용량과 성능이 선형으로 늘어나야 하며, 장애 중에도 서비스를 유지하고 복제본을 동기화해야 한다. 병렬 I/O는 처리량을 높이고, 데이터 손실 방지는 시스템의 기본 전제가 된다.

⤢✕

HDFS는 대규모 배치 처리에 맞춰진다

HDFS는 NameNode가 파일 시스템 네임스페이스와 블록 위치를 관리하고, DataNode가 실제 블록을 저장하는 구조다. DataNode는 하트비트로 상태를 보고한다. Secondary NameNode는 FsImage와 EditLog를 병합해 NameNode 복구를 지원하며, HA 구성에서는 Active-Standby NameNode와 QJM(Quorum Journal Manager)을 사용한다.

⤢✕

Hadoop 2.x 이후 기본 블록 크기는 128MB다. 블록을 크게 잡으면 관리해야 할 메타데이터가 줄고 시크 타임의 비중도 낮아진다. 기본 복제 계수는 3이며, Rack Awareness를 통해 서로 다른 랙에 복제본을 배치한다.

쓰기 요청은 NameNode에서 블록 ID와 DataNode 목록을 받은 뒤 DataNode 파이프라인으로 전달된다. 마지막 DataNode의 ACK는 다시 파이프라인을 거쳐 클라이언트까지 돌아온다.

⤢✕

읽을 때는 클라이언트가 NameNode에 파일 위치를 요청하고 블록 위치 목록을 받는다. 이후 가장 가까운 DataNode에서 블록을 직접 읽으며, 네트워크 토폴로지상 같은 랙을 우선한다.

Erasure Coding은 복제 대신 패리티를 사용해 스토리지를 50% 절감한다. 로컬 블록에는 Short-Circuit Local Reads로 네트워크를 우회할 수 있고, CacheDirective는 Hot 데이터를 메모리에 캐싱한다. Balancer는 노드 사이의 데이터 분포를 고르게 만든다.

HDFS는 MapReduce와 Spark 분석, HBase 스토리지, Hive·Impala의 SQL on Hadoop, 로그 아카이빙과 Cold Storage에 사용된다.

Ceph는 인터페이스와 데이터 배치를 분리한다

Ceph 클러스터는 Monitor, OSD, MDS, MGR로 구성된다. Monitor는 클러스터 상태를 관리하고, OSD는 Object Storage Daemon으로 동작한다. MDS는 메타데이터를 담당하며 MGR은 관리 기능을 제공한다. RBD, CephFS, RGW는 이 클러스터 위에서 각각 블록·파일·객체 인터페이스를 제공한다.

⤢✕

CRUSH(Controlled Replication Under Scalable Hashing)는 데이터 위치를 결정론적으로 계산하므로 별도 메타데이터가 필요하지 않다. Placement Rule은 호스트, 랙, 데이터센터 같은 장애 도메인을 반영한다. 해시 기반의 Pseudo-Random 분산과 OSD 용량에 비례한 가중치를 함께 사용한다.

root default {
    rack rack1 {
        host host1 { osd.0, osd.1 }
        host host2 { osd.2, osd.3 }
    }
    rack rack2 {
        host host3 { osd.4, osd.5 }
        host host4 { osd.6, osd.7 }
    }
}

rule replicated_rule {
    step take default
    step chooseleaf firstn 3 type host
    step emit
}

객체는 해시 함수를 거쳐 PG(Placement Group)에 매핑되고, CRUSH 알고리즘이 Primary와 Secondary OSD를 포함한 OSD 목록을 선택한다.

⤢✕

Ceph의 Replication은 기본 3-way 복제를 사용하며 스토리지 효율은 33%다. Erasure Coding은 k+m 방식이며, 예로 4+2 구성의 효율은 67%다. Scrubbing은 주기적으로 데이터 무결성을 검사하고, OSD 장애 후 교체가 이뤄지면 Recovery가 자동 복구를 수행한다.

RBD(RADOS Block Device)는 VM 디스크 같은 블록 스토리지에, CephFS는 멀티클라이언트 마운트가 필요한 POSIX 파일 시스템에 쓰인다. RGW(RADOS Gateway)는 S3·Swift 호환 객체 스토리지를 제공하고, librados는 네이티브 객체 접근 API다.

성능 측면에서는 BlueStore가 FileStore를 대체하는 전용 스토리지 백엔드다. NVMe·SSD를 OSD 저널과 WAL 전용으로 둘 수 있으며, 10GbE·25GbE 네트워크 대역폭을 확보한다. OSD당 CPU 1-2 코어, RAM 2-4GB가 권장된다.

OpenStack에서는 Cinder, Glance, Swift의 백엔드로 사용되며, Kubernetes에서는 Rook operator를 통해 PV를 제공한다. Private Cloud의 S3 호환 객체 스토리지나 Proxmox·oVirt의 VM 스토리지 백엔드도 Ceph의 적용 영역이다.

GlusterFS는 파일 서버 확장을 단순화한다

GlusterFS에서 Brick은 서버:경로 형식의 기본 스토리지 단위이고, Volume은 여러 Brick의 논리적 집합이다. 중앙 메타데이터 서버 없이 탄력적 해싱을 사용한다. FUSE 기반으로 POSIX 파일 시스템을 제공하며, Native Client는 libgfapi로 FUSE 오버헤드를 제거한다.

Volume은 Distributed, Replicated, Distributed-Replicated, Dispersed 방식으로 구성할 수 있다. Distributed는 샤딩을 통해 용량을 넓히지만 단일 장애점이 될 수 있다. Replicated는 고가용성을 제공하는 대신 용량이 1/N이 되며, Distributed-Replicated는 성능과 가용성의 균형을 노린다. Dispersed는 Erasure Coding으로 스토리지 효율을 높이지만 복구 오버헤드가 있다.

⤢✕

Distributed-Replicated Volume에서 Brick이 6개이고 복제 계수가 2라면 샤드는 3개이며, 각 샤드는 2 Brick에 복제된다. 이 구성의 용량은 전체 Brick 용량의 50%이고 Brick 1개 장애를 허용한다.

Volume: vol1
Type: Distributed-Replicate
Bricks:
  Replica Set 1: server1:/brick1, server2:/brick1
  Replica Set 2: server3:/brick1, server4:/brick1
  Replica Set 3: server5:/brick1, server6:/brick1

탄력적 해싱은 DHT(Distributed Hash Table)를 바탕으로 파일명 해시를 Brick에 매핑한다. Brick을 추가하거나 제거할 때 일부 데이터만 재배치하며, 메타데이터 서버 없이 클라이언트가 위치를 직접 계산한다.

Geo-Replication은 원격 사이트에 비동기 복제를 수행한다. Snapshot은 CoW(Copy-on-Write) 스냅샷을 제공하고, Quota는 디렉터리별 용량을 제한한다. Bitrot Detection은 주기적 체크섬 검증을 수행하며, Self-Heal은 복제본 불일치를 자동으로 복구한다.

성능 튜닝에는 read-ahead, write-behind, io-cache 같은 Performance Translators를 사용할 수 있다. 네트워크는 RDMA(InfiniBand)를 지원하며, Brick에는 XFS 파일 시스템과 inode64 옵션이 권장된다. 관련 설정으로 performance.cache-size, network.ping-timeout이 있다.

GlusterFS는 중앙 집중식 파일 서버를 대체하는 NFS, 동영상·이미지 파일 서빙, oVirt·Proxmox 통합 VM 이미지 저장, Bacula·Amanda 백엔드의 백업 스토리지에 적용할 수 있다.

샤드 이동을 줄이는 배치 전략

Hash-based Sharding은 키 해시 값으로 데이터를 나누고, Range-based Sharding은 키 범위를 기준으로 파티셔닝한다. Directory-based Sharding은 메타데이터 룩업 테이블을 사용한다. Consistent Hashing은 노드가 추가되거나 제거될 때 재배치를 최소화한다.

⤢✕

샤딩에서는 Hot Spot을 피하기 위한 균등 분산과 가상 노드(Virtual Node)가 필요하다. 샤드가 너무 작으면 오버헤드가 커지고, 너무 크면 불균형이 생긴다. 재샤딩은 온라인 재배치로 다운타임을 줄이는 방향으로 다루며, 샤드 간 조인은 성능을 낮추므로 NoSQL 모델을 선호한다.

복제는 일관성과 응답 방식의 선택이다

Synchronous Replication은 모든 복제본의 쓰기 완료 뒤 ACK를 반환한다. Asynchronous Replication은 Primary 기록 후 즉시 ACK를 보내고 복제는 백그라운드에서 수행한다. Semi-Synchronous는 최소 1개 복제본의 쓰기를 확인한 후 ACK를 반환한다. HDFS 파이프라인처럼 Chain Replication을 사용하면 네트워크 대역폭을 효율적으로 쓸 수 있다.

CAP 관점에서 Consistency는 모든 노드가 동일한 데이터를 반환하는 성질이고, Availability는 모든 요청이 응답을 받는 성질이며, Partition Tolerance는 네트워크 분할 중에도 동작하는 성질이다. 분산 시스템에서는 이 3가지 중 2가지만 선택 가능하다.

⤢✕

Quorum 기반 복제에서는 W가 쓰기 성공에 필요한 복제본 수, R이 읽을 때 확인할 복제본 수, N이 전체 복제본 수다. 강한 일관성 조건은 W + R > N이며, Ceph 기본 예시는 N=3, W=2, R=2다.

복제본은 Rack Awareness로 서로 다른 랙에 배치해 랙 단위 장애에 대응할 수 있다. Data Center Awareness는 지리적 분산과 재해 복구를 위한 방식이다. HDFS에서는 topology.script.file.name의 Topology Script를 사용하고, Ceph에서는 CRUSH Hierarchy로 다층 장애 도메인을 표현한다.

워크로드별로 달라지는 선택

시스템	순차 읽기	순차 쓰기	랜덤 읽기	랜덤 쓰기
HDFS	높음	중간	낮음	낮음
Ceph (Replicated)	높음	중간	중간	중간
GlusterFS	중간	중간	중간	낮음

Hadoop 생태계가 중심이면 HDFS가 필요하다. 블록·객체·파일 스토리지를 함께 다뤄야 하면 Ceph가 맞고, NFS 대체와 간단한 설정이 우선이면 GlusterFS가 적합하다. 고성능이 필요하면 Ceph와 NVMe, RDMA를 조합하며, 용량 효율을 중시하면 Ceph Erasure Coding을 고려한다.

⤢✕

운영에서 확인할 지점

디스크 사용률은 임계치 80% 미만으로 유지하고, 네트워크 대역폭 병목과 Secondary 노드의 복제 지연을 확인한다. 디스크 I/O 포화 여부는 IOPS로 점검하며, 장애 노드가 발생하면 자동 복구 진행 상태를 추적한다.

용량 계획에는 복제 계수를 반영해야 한다. 3-way 복제에서는 실제 사용 가능 용량이 1/3이 된다. 월별 증가량을 바탕으로 1-2년의 여유를 확보하고, 노드를 추가할 때는 클러스터 재균형 시간을 고려한다. Hot·Cold 데이터는 SSD와 HDD 계층으로 나눈다.

백업은 주기적 스냅샷, 지리적으로 분산된 원격 복제, Cold 데이터의 테이프·객체 스토리지 아카이빙으로 구성할 수 있다. 정기적인 복원 테스트로 백업 결과를 검증한다.

인증에는 HDFS의 Kerberos와 Ceph의 CephX를 사용한다. 전송 중에는 TLS, 저장 중에는 Encryption at Rest를 적용하고 ACL과 POSIX 권한으로 접근을 제어한다. 관리 네트워크와 스토리지 네트워크도 분리한다.