💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

프롤로그 — 2026년, "S3가 새로운 디스크다"

2010년대까지 스토리지의 답은 단순했다. **블록 스토리지(SAN, iSCSI), 파일 스토리지(NFS, SMB), 객체 스토리지(S3, Swift).** 세 카테고리가 명확히 분리되어 있었고, 각자 다른 워크로드를 맡았다.

2026년의 풍경은 완전히 다르다.

- **객체 스토리지가 디스크가 됐다.** AWS가 S3 Express One Zone(단일 AZ, 마이크로초 지연)을 내놓고, S3 Tables가 Iceberg를 1급 시민으로 끌어올리면서 "S3 위에서 데이터베이스를 돌린다"가 진지한 옵션이 됐다. Crunchy Bridge for Analytics가 Postgres 데이터를 S3 위에 두고, DuckDB가 parquet on S3를 표준 인터페이스로 다룬다.

- **블록 스토리지는 CSI로 추상화됐다.** K8s 환경에서 "EBS를 마운트한다"는 말은 사실 "EBS CSI 드라이버가 PV를 만든다"는 말이고, 그 자리에 OpenEBS·Longhorn·Rook이 들어와 있다.

- **egress 비용이 새로운 lock-in이 됐다.** Cloudflare R2는 egress 0원을 무기로 S3를 위협하고, Backblaze B2와 Wasabi는 같은 카드를 쓴다. AWS는 S3 Standard 가격을 사실상 동결한 채 Express One Zone과 Storage Lens로 차별화를 시도한다.

그리고 이 모든 흐름의 한가운데에 **MinIO**가 있다. 단일 바이너리, S3 API, 모든 곳에서 같은 코드. MinIO는 사실상 "S3 프로토콜의 참조 구현"이 됐다.

이 글은 2026년 5월 기준 분산 스토리지 스택 전체를 정리한다 — MinIO·SeaweedFS·Ceph·Garage·JuiceFS·OpenEBS·Longhorn·Rook·Portworx·Lightbits·DRBD·GlusterFS·HDFS·R2·B2·Wasabi·Storj·S3 Express·S3 Tables·NHN Cloud·Naver Cloud·KT Cloud·Sakura·IIJ GIO, 그리고 ZFS·btrfs·XFS·ext4·bcachefs·F2FS까지.

1장 · 분산 스토리지 지도 — 객체·블록·파일의 삼각구도

도구를 보기 전에, 어떤 카테고리가 어디에 끼는지부터 봐야 한다.

|---|---|---|---|---|

기억할 한 줄: **"객체 스토리지가 새로운 디스크다. 블록과 파일은 CSI 추상화 뒤로 숨었다."**

핵심 통찰은 객체 스토리지가 더 이상 "사진을 두는 곳"이 아니라는 점이다. 2024년 S3 Express One Zone이 single-digit ms 지연을 약속하면서, 데이터베이스 엔진들이 "WAL을 S3에 쓰고, 그 위에서 직접 쿼리한다" 같은 패턴을 진지하게 검토하기 시작했다. Neon·Crunchy Bridge·DuckLake·Apache Iceberg가 모두 이 방향으로 간다.

2장 · MinIO — 단일 바이너리 S3의 표준

MinIO는 Go로 작성된 단일 바이너리 객체 스토리지다. 2014년에 시작해서 2026년에는 사실상 "S3 프로토콜의 참조 구현"이 됐다. Kubernetes 위에서, 베어메탈에서, 라즈베리파이에서 같은 코드가 돈다.

핵심 특징은 S3 API 100% 호환, Erasure Coding 기본 제공(데이터 4 + 패리티 2 같은 구성), 단일 바이너리(의존성 0, 설치 30초), AGPL v3 라이선스(상용은 MinIO Enterprise)다.

가장 간단한 도커 실행부터 K8s Operator까지 살펴보자.

MinIO 컨테이너 실행 — 단일 노드, 4개 디스크

docker run -d --name minio \

-p 9000:9000 -p 9001:9001 \

-e "MINIO_ROOT_USER=admin" \

-e "MINIO_ROOT_PASSWORD=changeme123" \

-v /mnt/data1:/data1 -v /mnt/data2:/data2 \

-v /mnt/data3:/data3 -v /mnt/data4:/data4 \

quay.io/minio/minio server /data{1...4} --console-address ":9001"

mc(MinIO Client)로 버킷 생성

mc alias set local http://localhost:9000 admin changeme123

mc mb local/backups

mc cp ./backup.tar.gz local/backups/

mc ls local/backups

K8s 위에서는 MinIO Operator를 쓴다. 다음은 분산 4노드 16디스크 클러스터 매니페스트의 핵심.

apiVersion: minio.min.io/v2

kind: Tenant

metadata:

namespace: minio

spec:

pools:

- servers: 4

volumesPerServer: 4

volumeClaimTemplate:

spec:

accessModes: ["ReadWriteOnce"]

resources:

requests:

storage: 1Ti

storageClassName: local-nvme

mountPath: /export

requestAutoCert: true

features:

bucketDNS: true

domains:

console: console.minio.example.com

minio:

- s3.minio.example.com

MinIO의 진짜 강점은 단순함이다. Ceph처럼 OSD·MON·MGR·MDS를 따로 운영할 필요가 없다. 그래서 2026년에 새로 S3 백엔드를 깔 때 "일단 MinIO"가 디폴트가 됐다.

3장 · SeaweedFS — Facebook Haystack에서 영감을 받은 객체 스토리지

SeaweedFS는 Facebook의 Haystack 논문에서 영감을 받아 만든 객체 스토리지다. MinIO와 비슷한 카테고리지만 설계 철학이 다르다.

- **Master/Volume 분리** — 작은 파일에 최적화된 Volume Server.

- **WebDAV·S3·FUSE 게이트웨이** — POSIX·S3·WebDAV 동시 지원.

- **Tiered Storage** — Hot은 SSD, Cold는 HDD/S3로 자동 이동.

- **Erasure Coding + Replication 혼합** — 핫 데이터는 복제, 콜드는 EC.

단일 노드 — Master + Volume + Filer + S3 게이트웨이 한 번에

weed server -dir=/data -master.port=9333 -volume.port=8080 \

-filer -s3 -s3.port=8333

별도 머신에 Volume 노드 추가

weed volume -dir=/mnt/disk1 -mserver=master.example.com:9333 \

-port=8080 -max=100

S3 API로 업로드 (AWS CLI 그대로)

aws --endpoint-url http://localhost:8333 s3 cp ./video.mp4 s3://media/

FUSE 마운트 — POSIX처럼 보이게

weed mount -filer=filer.example.com:8888 -dir=/mnt/seaweed -filer.path=/

SeaweedFS는 "작은 파일이 많은" 워크로드(이미지 썸네일, 로그 청크)에 특히 강하다. Volume Server가 파일을 하나의 큰 컨테이너 파일에 패킹하기 때문에 inode 압박이 없다.

4장 · Ceph — 여전히 엔터프라이즈 온프레미스의 표준

Ceph는 2007년 Sage Weil의 박사논문에서 시작해 2026년에도 여전히 엔터프라이즈 온프레미스 스토리지의 디폴트 답이다. 한 시스템으로 객체·블록·파일을 다 한다.

- **RGW (Rados Gateway)** — S3/Swift API.

- **RBD (Rados Block Device)** — 분산 블록 디바이스, QEMU·KVM이 직접 마운트.

- **CephFS** — POSIX 분산 파일시스템.

- **CRUSH 알고리즘** — 중앙 메타데이터 없이 데이터 위치 계산.

핵심 진실: Ceph는 강력하지만 운영 복잡도가 높다. OSD·MON·MGR·MDS·RGW를 다 신경써야 한다. 그래서 2018년쯤 등장한 `cephadm`이 표준이 됐고, K8s 환경에서는 **Rook**이 그 자리를 차지했다.

cephadm으로 부트스트랩

cephadm bootstrap --mon-ip 10.0.0.10 \

--initial-dashboard-user admin \

--initial-dashboard-password changeme123

OSD 추가 — 노드별 모든 가용 디스크

ceph orch host add node2 10.0.0.11

ceph orch host add node3 10.0.0.12

ceph orch apply osd --all-available-devices

RGW 배포 (S3 API)

ceph orch apply rgw default --placement="3 node1 node2 node3"

풀 생성 + 사용자 발급

ceph osd pool create rgw-data 256 256 erasure

radosgw-admin user create --uid=appuser --display-name="App User"

RBD 이미지 생성 + 매핑

rbd create app-disk --size 10G --pool rbd-pool

rbd map app-disk --pool rbd-pool

mkfs.xfs /dev/rbd0

5장 · Rook — Kubernetes 위의 Ceph Operator

Rook은 Ceph를 K8s Operator로 감싼 프로젝트다. CNCF Graduated. 한 줄 요약: "K8s 위에서 Ceph를 운영하는 표준 방법." CephCluster CR(custom resource)를 받아서 OSD DaemonSet을 만들고, MON·MGR·MDS를 배포한다. RGW와 CephFS도 별도 CR로 정의한다.

apiVersion: ceph.rook.io/v1

kind: CephCluster

metadata:

namespace: rook-ceph

spec:

cephVersion:

image: quay.io/ceph/ceph:v19.2.0

dataDirHostPath: /var/lib/rook

mon:

allowMultiplePerNode: false

mgr:

dashboard:

enabled: true

ssl: true

storage:

useAllNodes: true

useAllDevices: true

config:

osdsPerDevice: "1"

apiVersion: ceph.rook.io/v1

kind: CephFilesystem

metadata:

namespace: rook-ceph

spec:

metadataPool:

replicated:

size: 3

dataPools:

- name: data

replicated:

size: 3

preservePoolsOnDelete: true

metadataServer:

activeCount: 2

activeStandby: true

2026년에 K8s 위에서 분산 파일 시스템이 필요할 때 가장 검증된 옵션이 Rook이다. 다만 Ceph 자체의 복잡도는 그대로 들고 와야 한다.

6장 · Garage — Deuxfleurs의 가벼운 S3

Garage는 프랑스 Deuxfleurs 협동조합이 만든 S3 호환 객체 스토리지다. "Ceph는 무겁고 MinIO는 distributed mode가 무거우니, 우리는 더 가벼운 게 필요했다"는 동기에서 시작됐다.

특징은 Rust로 작성(메모리 안전성, 낮은 자원 사용량), 3개 노드부터 시작(가정용 라즈베리파이 클러스터에서도 동작), S3 호환(대부분의 S3 SDK가 그대로 동작), CRDT 기반 메타데이터(분할 복구 단순), AGPL v3 라이선스다.

3개 노드 클러스터 부트스트랩

garage node id # 노드 ID 출력

garage layout assign -z dc1 -c 1T <node-id-1>

garage layout assign -z dc1 -c 1T <node-id-2>

garage layout assign -z dc2 -c 1T <node-id-3>

garage layout apply --version 1

S3 키 발급

garage key create app-key

garage bucket create photos

garage bucket allow --read --write photos --key app-key

aws CLI 그대로 사용

aws --endpoint http://garage.example.com:3900 \

s3 cp ./photo.jpg s3://photos/

Garage의 차별점은 "지리적으로 분산된 작은 클러스터"에 최적화돼 있다는 점이다. DC1-DC2-DC3가 각각 가정용 회선으로 연결돼 있어도 동작하도록 설계됐다. 그래서 self-hosting 커뮤니티에서 빠르게 채택됐다.

7장 · JuiceFS · S3FS · Goofys — POSIX over Object Storage

JuiceFS는 객체 스토리지(S3, MinIO, R2 등) 위에 POSIX 파일 시스템을 얹는다. 메타데이터는 Redis·MySQL·TiKV에 두고, 데이터는 S3에 둔다.

JuiceFS는 ML 학습 데이터셋 공유, 미디어 편집 워크플로, 백업 같은 "큰 파일·읽기 위주" 워크로드에 특히 잘 맞는다. 메타데이터를 Redis/TiKV에 두기 때문에 메타데이터 성능이 객체 스토리지보다 훨씬 빠르다.

비슷한 카테고리에 `s3fs-fuse`, `goofys`, `geesefs`, `rclone mount`가 있지만, JuiceFS만 POSIX 시맨틱(하드링크, atomic rename, fcntl lock)을 제대로 구현한다. 다른 옵션들은 POSIX 시맨틱이 완벽하지 않아서 백업·로그 수집·미디어 스트리밍 같은 단방향 워크로드에 적합하고, DB 데이터 디렉토리로는 부적합하다.

메타데이터 백엔드(Redis) + 데이터 백엔드(S3)로 포맷

juicefs format \

--storage s3 \

--bucket https://my-bucket.s3.us-east-1.amazonaws.com \

--access-key AKIA... \

--secret-key SECRET... \

redis://meta.example.com:6379/1 \

my-jfs

마운트

juicefs mount redis://meta.example.com:6379/1 /mnt/jfs

일반 파일시스템처럼 사용

cp -r /home/user/dataset /mnt/jfs/datasets/

ls -la /mnt/jfs/datasets/

rclone으로 R2 마운트 (간이 옵션)

rclone mount r2:my-bucket /mnt/r2 \

--vfs-cache-mode writes \

--dir-cache-time 1m \

--buffer-size 32M

8장 · OpenEBS — K8s 네이티브 컨테이너 어태치드 스토리지

OpenEBS는 K8s를 위한 "Container Attached Storage"를 표방한다. 노드 로컬 스토리지를 다양한 엔진으로 추상화해서 PV로 제공한다.

| 엔진 | 특징 | 사용처 |

|---|---|---|

| Mayastor | NVMe-oF + SPDK 기반 고성능 | DB, 고성능 워크로드 |

| cStor | ZFS 기반 스냅샷·복제 | 일반 stateful 앱 |

| Jiva | 가벼움, longhorn 비슷 | 개발·테스트 |

| NDM | Node Device Manager — 디스크 발견 | 모든 엔진의 기반 |

| LocalPV | hostpath/lvm/zfs 로컬 PV | 단일 노드, 빠른 IO |

apiVersion: storage.k8s.io/v1

kind: StorageClass

metadata:

provisioner: io.openebs.csi-mayastor

parameters:

repl: "3"

protocol: nvmf

ioTimeout: "30"

fsType: xfs

allowVolumeExpansion: true

reclaimPolicy: Delete

Mayastor는 SPDK(Storage Performance Development Kit)를 써서 커널 우회 IO를 한다. 그래서 NVMe SSD에서 90% 이상의 raw 성능을 PV에서도 낸다. 단점은 NVMe-oF target/initiator 설정이 복잡하다는 것.

9장 · Longhorn — Rancher의 분산 블록 스토리지

Longhorn은 Rancher Labs가 만들고 CNCF Graduated인 K8s 네이티브 분산 블록 스토리지다. SUSE 인수 이후로도 활발히 개발 중이다.

- **iSCSI 기반** — 호환성이 좋다.

- **per-volume controller** — 각 볼륨마다 controller pod이 떠서 isolation.

- **백업 to S3/NFS** — 스냅샷 + 외부 백업 1급 기능.

- **DR 볼륨** — 다른 클러스터로 비동기 복제.

apiVersion: longhorn.io/v1beta2

kind: Volume

metadata:

namespace: longhorn-system

spec:

size: "10Gi"

numberOfReplicas: 3

frontend: blockdev

staleReplicaTimeout: 30

dataLocality: best-effort

accessMode: rwo

운영상 Longhorn은 OpenEBS Mayastor보다 설정이 쉽다. 단 성능은 Mayastor가 우위. 그래서 "DB는 Mayastor, 일반 앱은 Longhorn" 같은 구성이 흔하다.

10장 · Portworx · Lightbits · DRBD · 레거시 옵션

엔터프라이즈에서는 다음 옵션들이 후보에 들어간다.

- **Portworx (Pure Storage 인수)** — PX-Store가 K8s 네이티브 블록·파일을, PX-Backup이 K8s 백업을 담당. 상용이지만 K8s 친화적인 운영 모델.

- **Lightbits Labs** — NVMe-oF 전용 어플라이언스. 베어메탈 K8s에서 EBS급 성능을 노린다.

- **DRBD (LINBIT)** — 1999년부터 있던 "리눅스의 RAID over network". 2026년에도 stateful 워크로드의 HA 옵션으로 살아있다.

- **GlusterFS (legacy)** — Red Hat이 EOL을 선언했지만 일부 레거시 환경에서 여전히 가동 중.

- **Hadoop HDFS (legacy)** — 빅데이터 시대의 표준이었지만 객체 스토리지 + Iceberg 조합에 밀려서 축소 중.

- **LizardFS** — MooseFS의 fork. POSIX 분산 파일 시스템이지만 커뮤니티가 작다.

핵심 진실: 2026년에 새로 시작하는 워크로드라면 GlusterFS와 HDFS는 후보에서 빠진다. "기존 시스템 유지보수"의 영역이다.

11장 · AWS S3 — Standard, Express One Zone, S3 Tables

AWS S3는 2006년에 나와서 2026년에도 객체 스토리지의 사실상 표준이다. 2024-2026년 사이에 세 가지 큰 변화가 있었다.

1. **S3 Express One Zone** — 단일 AZ, 디렉토리 버킷, single-digit ms 지연. 가격은 Standard의 약 7배지만 지연이 10배 짧다. 데이터베이스·게임·실시간 분석에 들어간다.

2. **S3 Tables** — Iceberg 테이블을 S3가 직접 호스팅. compaction·snapshot expiry를 AWS가 알아서 해준다. Athena·EMR·Redshift Spectrum이 직접 쿼리.

3. **S3 Storage Lens** — 계정 전체의 스토리지 사용 패턴을 대시보드로. 비용 최적화에 1순위.

일반 Standard 버킷

aws s3 mb s3://my-archive-bucket --region us-east-1

Express One Zone 디렉토리 버킷 (이름이 .s3express-az1--x-s3로 끝남)

aws s3api create-bucket \

--bucket fast-bucket--use1-az4--x-s3 \

--region us-east-1 \

--create-bucket-configuration '{"Location":{"Type":"AvailabilityZone","Name":"use1-az4"},"Bucket":{"Type":"Directory","DataRedundancy":"SingleAvailabilityZone"}}'

S3 Tables (Iceberg)

aws s3tables create-namespace --table-bucket-arn arn:aws:s3tables:... --namespace analytics

aws s3tables create-table --namespace analytics --name events --format ICEBERG

Object Lock으로 불변 백업 활성화

aws s3api create-bucket --bucket immutable-backups \

--object-lock-enabled-for-bucket

aws s3api put-object-retention \

--bucket immutable-backups \

--key backup-2026-05-19.tar \

--retention 'Mode=COMPLIANCE,RetainUntilDate=2026-08-19T00:00:00Z'

S3가 "디스크"가 되는 결정적 변화는 Express One Zone + S3 Tables 조합이다. Crunchy Bridge for Analytics는 Postgres의 WAL을 S3에 두고, DuckDB는 parquet on S3를 1급 인터페이스로 다룬다. Apache Iceberg + S3 Tables는 데이터레이크의 새 표준이 됐다.

12장 · Cloudflare R2 — egress 0원 시대

Cloudflare R2는 2022년에 GA되면서 객체 스토리지 시장에 단순한 칼을 꽂았다 — egress 0원. S3 API 호환이고, 데이터를 빼낼 때 GB당 0달러다.

R2의 핵심 가치는 egress 비용이다. 비디오 호스팅, 사진 갤러리, ML 모델 배포 같은 "다운로드가 많은" 워크로드에서 S3 대비 70-90% 비용 절감이 흔하다. R2의 한계는 멀티리전 일관성과 일부 S3 기능(Object Lock의 일부 모드, Versioning 시맨틱 일부 차이)이다. 2025-2026년에 점차 좁혀지고 있다.

wrangler로 R2 버킷 생성

wrangler r2 bucket create my-bucket

S3 API endpoint를 통해 일반 S3 클라이언트로 접근

aws --endpoint https://<account-id>.r2.cloudflarestorage.com \

s3 cp ./video.mp4 s3://my-bucket/

rclone으로 S3 -> R2 동기화

rclone sync s3:my-bucket r2:my-bucket \

--transfers 32 --checkers 64 --fast-list

13장 · Backblaze B2 · Wasabi · Storj · Filebase · Tigris

R2가 길을 텄지만, 비슷한 모델의 객체 스토리지가 그 전에도 여럿 있었다.

- **Backblaze B2** — 2015년부터 GB당 0.005달러대. egress는 Cloudflare 경유 시 0원(Bandwidth Alliance). B2 Live Read로 대용량 미디어 스트리밍에도 강함.

- **Wasabi Hot Storage** — egress 0원, API 호출 0원. 단 90일 minimum storage 약정.

- **Storj DCS** — 분산형(decentralized) 스토리지. 데이터를 80개 노드에 erasure-coded 청크로 흩뿌린다.

- **Filebase** — IPFS·Sia 같은 분산 스토리지를 S3 API 뒤에 추상화.

- **Tigris Data** — DynamoDB 호환 serverless 객체 + 글로벌 분산.

선택 가이드: 다운로드가 거의 없는 백업이면 B2가 가장 싸다. 다운로드가 많으면 R2. 압축 데이터셋이면 Storj가 분산 특성으로 적합. 그리고 "S3 API 호환"이 절대적 요구라면 Wasabi가 가장 충실하다.

14장 · GCP Cloud Storage · Azure Blob — 하이퍼스케일러의 답

GCP Cloud Storage와 Azure Blob도 S3와 같은 카테고리에 있지만 디자인이 조금 다르다.

**GCP Cloud Storage:**

- 단일 글로벌 네임스페이스 (region/dual-region/multi-region 모두 동일 URL 패턴).

- Standard / Nearline / Coldline / Archive 4단 티어.

- XML API(S3 호환)와 JSON API 둘 다 제공.

- Lifecycle 룰로 자동 티어 이동.

**Azure Blob:**

- Hot / Cool / Cold / Archive 4단 티어.

- Block Blob / Append Blob / Page Blob 세 타입.

- ADLS Gen2(Hierarchical Namespace)로 HDFS 시맨틱 제공.

- AzCopy로 대용량 마이그레이션.

핵심 차별: GCS는 글로벌 네임스페이스가 강점이고, Azure Blob은 ADLS Gen2가 HDFS 대체로서 빛난다. Synapse·Databricks가 ADLS Gen2를 1급 인터페이스로 다룬다.

15장 · 한국·일본 클라우드 객체 스토리지

지역 클라우드도 무시할 수 없다.

**한국:**

- **NHN Cloud Object Storage** — S3 호환, 광역 멀티리전, 게임/미디어 워크로드 강함.

- **Naver Cloud Object Storage** — S3 호환, 한국 내 데이터 주권 요구 환경에 적합.

- **KT Cloud Object Storage** — S3 호환, 공공 클라우드 인증.

**일본:**

- **Sakura Internet Object Storage** — S3 호환, 도쿄/이시카리 리전.

- **IIJ GIO Object Storage** — 엔터프라이즈 SLA, 일본 내 데이터센터.

- **NTT Communications, Fujitsu Cloud** — 통신사 계열 클라우드.

데이터 주권 요구사항(개인정보보호법, 일본 APPI)이 있으면 지역 클라우드가 우선 후보가 된다. S3 API 호환성 덕에 클라이언트 코드는 endpoint만 바꿔서 마이그레이션이 가능하다.

16장 · 로컬 파일시스템 — ZFS, btrfs, XFS, ext4, bcachefs, F2FS

분산 스토리지를 깔기 전에, 그 아래에 깔리는 로컬 파일시스템도 중요하다. 2026년 5월 기준 후보군.

| FS | 특징 | 사용처 |

|---|---|---|

| ext4 | 표준, 가장 검증 | 일반 리눅스 서버 디폴트 |

| XFS | 대용량·고병렬 강함 | Ceph OSD, 대형 파일 서버 |

| ZFS (OpenZFS) | 스냅샷·압축·dedup·체크섬 | NAS, DB, OpenEBS cStor 기반 |

| btrfs | ZFS와 비슷, 메인라인 커널 | Synology NAS, 일부 페도라 |

| bcachefs | 2024년 메인라인 진입 | 차세대 카피온라이트, 실험적 사용 |

| F2FS | Flash 최적화 | 안드로이드, 모바일 |

| LizardFS POSIX | 분산 FS이지만 POSIX | 일부 미디어 워크플로 |

ZFS의 강점은 스냅샷이 거의 무료라는 점이다. 2024년에 bcachefs가 리눅스 메인라인에 들어왔다. ZFS의 기능(스냅샷·체크섬·압축·티어드 캐시)을 GPL 코드로 구현. 2026년 시점에서는 아직 "early production"이지만, 향후 5년 동안 btrfs 자리를 위협할 가능성이 높다.

ZFS pool 생성 (mirrored) + 스냅샷 + 원격 송신

zpool create tank mirror /dev/sdb /dev/sdc

zfs set compression=zstd tank

zfs snapshot tank@daily-$(date +%F)

zfs send -i tank@yesterday tank@today | ssh backup-host zfs receive tank/replica

ZFS special vdev로 메타데이터를 NVMe에

zpool add tank special mirror /dev/nvme0n1 /dev/nvme1n1

zfs set dedup=on tank/backups

17장 · CSI — Kubernetes가 스토리지와 대화하는 방법

K8s의 모든 스토리지 통합은 **CSI(Container Storage Interface)** 위에서 동작한다. 2017년에 표준화됐고, 2026년에는 사실상 K8s 스토리지의 단일 인터페이스다.

CSI 드라이버는 보통 다음 컨테이너로 구성된다:

- **csi-provisioner** — PVC를 받아 PV 생성.

- **csi-attacher** — VolumeAttachment를 처리.

- **csi-resizer** — 온라인 볼륨 확장.

- **csi-snapshotter** — 스냅샷·복원.

- **node-driver-registrar** — 노드 등록.

- **driver** — 실제 스토리지 제공자별 로직 (예: ebs.csi.aws.com, rbd.csi.ceph.com).

| 제공자 | CSI 드라이버 |

|---|---|

| AWS | ebs.csi.aws.com, efs.csi.aws.com, s3.csi.aws.com |

| GCP | pd.csi.storage.gke.io, filestore.csi.storage.gke.io |

| Azure | disk.csi.azure.com, file.csi.azure.com, blob.csi.azure.com |

| Ceph | rbd.csi.ceph.com, cephfs.csi.ceph.com |

| OpenEBS | mayastor.openebs.io, openebs.io/lvm, openebs.io/zfs |

| Longhorn | driver.longhorn.io |

| MinIO | s3.csi.min.io (DirectPV) |

대부분의 K8s 클러스터는 1차로 클라우드 제공자 CSI를 쓰고, 2차로 OpenEBS·Longhorn·Rook 중 하나를 깔아서 베어메탈 노드의 로컬 디스크도 PV로 만든다.

18장 · Object Lock · WORM · 불변 백업 패러다임

2020년대 중반부터 랜섬웨어 공격이 폭증하면서 백업의 디폴트가 "불변(immutable)"으로 옮겨갔다. Object Lock과 WORM(Write Once Read Many) 모드가 핵심.

- **AWS S3 Object Lock** — Governance 모드와 Compliance 모드. Compliance는 루트 사용자도 못 지운다.

- **MinIO Object Lock** — S3 호환.

- **Ceph RGW Object Lock** — Reef 릴리스 이후 지원.

- **R2 Object Lock** — 2024년 GA.

이 패러다임을 활용하는 백업 벤더가 Veeam·Rubrik·Cohesity·Druva다. 그들 모두 "MinIO 또는 S3에 immutable backup을 쓴다"가 표준 워크플로다. 활성 데이터는 hot(NVMe), 콜드는 HDD/Tape로 자동 티어링하는 패턴이 함께 표준화됐다.

19장 · 데이터 티어링 · Dedup · 라이프사이클 · 멀티클라우드 복제

저장 비용을 줄이고 데이터 복원력을 높이는 자동화 패턴들.

1. **라이프사이클 룰** — N일 후 cold tier로, M일 후 archive로, K일 후 삭제. S3 라이프사이클, GCS Lifecycle, Azure Blob Management Policy가 모두 같은 패턴.

2. **데이터 티어링** — 활성 데이터는 hot(NVMe), 콜드는 HDD/Tape. ZFS의 special vdev, OpenZFS의 ARC/L2ARC, SeaweedFS의 tiered storage가 이 패턴.

3. **데이터 중복 제거(Dedup)** — ZFS dedup, Veeam built-in dedup, NetApp ONTAP volume dedup. 백업 워크로드에서 5-30배 절감이 흔하다.

4. **멀티클라우드 복제** — MinIO Mirror Mode, rclone sync, AWS S3 Replication(Cross-Region, Cross-Account), GCS Object Replication, R2 to S3 via Workers.

핵심 진실: 2026년의 절약은 "어떻게 cold 데이터를 자동으로 cold tier로 옮기느냐"의 자동화에서 나온다. S3 Standard에 다 두면 비싸고, 모두 Glacier에 두면 복구가 느리다. 그리고 cross-region replication은 데이터 전송 비용이 비싸기 때문에 비용 함정을 조심해야 한다.

20장 · "S3가 새로운 디스크다" — Iceberg · DuckDB · Postgres on S3

2024-2026년 사이의 가장 큰 패러다임 전환. 데이터베이스가 S3 위에서 직접 도는 시대.

- **Apache Iceberg + S3 Tables** — 트랜잭션이 있는 테이블 포맷이 S3에 직접 산다. Athena·EMR·Trino·Spark·Snowflake가 직접 쿼리.

- **DuckDB + parquet on S3** — `read_parquet('s3://...')`이 1급 시민. 로컬 분석이 S3 데이터를 그대로 본다.

- **Crunchy Bridge for Analytics** — Postgres 데이터를 S3에 두고, FDW(Foreign Data Wrapper)로 쿼리.

- **Neon, DuckLake** — WAL/checkpoint를 S3에 둬서 "stateless DB" 구현.

- **MotherDuck** — DuckDB의 SaaS 버전, 로컬·클라우드 하이브리드.

DuckDB에서는 `INSTALL httpfs; LOAD httpfs;` 후 `SET s3_region='us-east-1'`과 액세스 키를 설정하면 `read_parquet('s3://bucket/events/year=2026/*.parquet')` 같은 쿼리가 1급 시민으로 동작한다. 별도의 ETL 없이 S3 위의 parquet을 그대로 분석한다.

이 패턴의 결과: "전통적인 DBMS의 스토리지 레이어"와 "객체 스토리지" 사이의 경계가 사라지고 있다. NVMe Flash Array(Pure Storage, NetApp ONTAP, Dell PowerStore) 벤더들이 "S3 객체 인터페이스를 우리 NVMe 어레이 앞단에 둔다"는 답으로 대응 중이다.

21장 · NVMe Flash Array 벤더 — Pure · NetApp · Dell PowerStore

엔터프라이즈 하드웨어 측에서 2026년의 답은 **NVMe Flash Array**다.

- **Pure Storage FlashArray //X · //XL** — 모든 NVMe, 인라인 dedup·압축. Portworx 인수로 K8s 스토리지까지 통합.

- **NetApp ONTAP AFF (All-Flash FAS)** — ONTAP 9.14 이후 S3 객체 인터페이스를 1급으로 제공. SnapMirror·SnapVault는 여전히 차별점.

- **Dell PowerStore** — Dell의 NVMe-oF 어레이. Container Storage Module로 K8s CSI 제공.

- **HPE Alletra** — HPE Nimble Storage 후속. AI 기반 예측 분석.

- **VAST Data** — DASE(Disaggregated Shared-Everything) 아키텍처. AI 학습 데이터셋에 강점.

핵심 진실: 2026년의 엔터프라이즈 스토리지는 "Pure/NetApp/Dell/HPE 중 하나" + "K8s CSI 드라이버" + "S3 객체 인터페이스" 세 가지를 모두 갖춰야 채택 후보에 든다.

22장 · 운영 체크리스트 — 분산 스토리지를 깔기 전에

새로 깔 때 체크할 것.

- **RPO/RTO 정의** — 데이터 손실 허용 시간(RPO), 복구 시간(RTO)을 먼저 합의.

- **3-2-1 백업 룰** — 데이터 3 copies, 2 different media, 1 offsite.

- **Object Lock 활성화** — 백업 버킷은 무조건 immutable.

- **암호화** — at-rest(SSE-S3/SSE-KMS), in-transit(TLS) 둘 다.

- **모니터링** — Prometheus + Grafana로 IOPS·throughput·latency·error rate.

- **백업 복구 리허설** — 분기당 1회. 백업이 있다는 게 아니라 복구가 된다는 걸 확인.

- **비용 알람** — 갑작스러운 egress 비용 폭증은 보통 보안 사고의 신호.

- **CSI 드라이버 버전 관리** — K8s 마이너 버전 업그레이드 시 호환성 확인.

- **메타데이터 백업 별도** — JuiceFS·Ceph 메타데이터는 데이터와 따로 백업.

핵심 교훈: 분산 스토리지의 실패는 보통 디스크 고장이 아니라 "메타데이터 백업이 없었다"거나 "복구를 한 번도 안 해봤다"에서 온다.

23장 · 의사결정 매트릭스 — 무엇을 언제 쓸까

| 상황 | 추천 | 이유 |

|---|---|---|

| 온프레미스 S3가 처음 필요할 때 | MinIO | 단일 바이너리, 30초 설치 |

| 큰 엔터프라이즈, 객체+블록+파일 다 필요 | Ceph + Rook | 검증된 통합 스택 |

| 작은 클러스터, self-hosting | Garage | Rust, 가정용 회선에서도 동작 |

| 작은 파일이 많은 워크로드 | SeaweedFS | Haystack 모델, inode 압박 없음 |

| ML 학습 데이터셋 공유 | JuiceFS | POSIX over S3 |

| K8s에서 DB용 고성능 PV | OpenEBS Mayastor | NVMe-oF + SPDK |

| K8s 일반 stateful 앱 | Longhorn | 운영 단순 |

| egress 많은 워크로드 | Cloudflare R2 | egress 0원 |

| 백업 콜드 저장 | Backblaze B2 | GB당 가장 싸다 |

| 데이터 주권 (한국) | NHN Cloud / Naver Cloud | 국내 데이터센터 |

| 데이터 주권 (일본) | Sakura / IIJ GIO | 일본 데이터센터 |

| 데이터레이크 (Iceberg) | AWS S3 + S3 Tables | Athena·EMR 직접 통합 |

| 초저지연 객체 | AWS S3 Express One Zone | single-digit ms |

| 불변 백업 | MinIO/S3 + Object Lock | 랜섬웨어 방어 |

| 멀티클라우드 복제 | rclone / MinIO mirror | 벤더 lock-in 회피 |

24장 · 2026년 이후를 보는 전망

- **객체 스토리지의 디스크화 가속** — Iceberg·DuckLake·Neon이 표준화되면 "DB는 곧 S3 클라이언트"가 디폴트 멘탈 모델이 된다.

- **egress 전쟁의 결말** — Cloudflare R2가 S3에서 점유율을 끌어오는 게 멈추지 않을 거고, AWS가 결국 어떤 형태로든 egress 가격 인하 카드를 꺼낼 것이다.

- **K8s 스토리지의 통합** — OpenEBS·Longhorn·Rook 중 두 개가 합쳐지거나 한 표준으로 수렴할 가능성이 있다.

- **NVMe-oF 대중화** — Mayastor·Lightbits가 견인하는 NVMe-oF가 "K8s에서 RDMA급 성능"의 표준 답이 된다.

- **bcachefs 부상** — 메인라인 진입 후 5년 동안 btrfs를 위협. ZFS는 라이선스 문제로 여전히 카피레프트 외부에서 강세.

- **AI 워크로드의 스토리지 요구** — 학습 데이터셋 공유(JuiceFS·Alluxio), 체크포인트 저장(S3 Express), 모델 배포(R2)가 별개 카테고리로 떠오른다.

2026년에 분산 스토리지를 선택할 때 가장 중요한 질문은 더 이상 "어떤 백엔드를 쓸까"가 아니다. **"어떤 API 호환성을 유지하면서 어떤 비용 곡선을 그릴까"** 다. 그리고 그 답의 대부분은 S3 API와 CSI다.

References

- MinIO 공식 문서 — [https://min.io/docs](https://min.io/docs)

- SeaweedFS GitHub & Docs — [https://seaweedfs.github.io](https://seaweedfs.github.io)

- Ceph 공식 문서 — [https://docs.ceph.com](https://docs.ceph.com), [https://ceph.io](https://ceph.io)

- Garage by Deuxfleurs — [https://garagehq.deuxfleurs.fr](https://garagehq.deuxfleurs.fr)

- JuiceFS — [https://juicefs.com](https://juicefs.com), [https://github.com/juicedata/juicefs](https://github.com/juicedata/juicefs)

- OpenEBS — [https://openebs.io](https://openebs.io), [https://github.com/openebs/openebs](https://github.com/openebs/openebs)

- Longhorn — [https://longhorn.io](https://longhorn.io)

- Rook — [https://rook.io](https://rook.io), [https://github.com/rook/rook](https://github.com/rook/rook)

- Portworx (Pure Storage) — [https://portworx.com](https://portworx.com)

- Lightbits Labs — [https://www.lightbitslabs.com](https://www.lightbitslabs.com)

- DRBD (LINBIT) — [https://linbit.com/drbd](https://linbit.com/drbd)

- Cloudflare R2 — [https://www.cloudflare.com/products/r2](https://www.cloudflare.com/products/r2)

- Backblaze B2 — [https://www.backblaze.com/cloud-storage](https://www.backblaze.com/cloud-storage)

- Wasabi Hot Cloud Storage — [https://wasabi.com](https://wasabi.com)

- Storj DCS — [https://www.storj.io](https://www.storj.io)

- Filebase — [https://filebase.com](https://filebase.com)

- Tigris Data — [https://www.tigrisdata.com](https://www.tigrisdata.com)

- AWS S3 — [https://aws.amazon.com/s3](https://aws.amazon.com/s3), S3 Express One Zone, S3 Tables

- GCP Cloud Storage — [https://cloud.google.com/storage](https://cloud.google.com/storage)

- Azure Blob Storage — [https://learn.microsoft.com/azure/storage/blobs](https://learn.microsoft.com/azure/storage/blobs)

- NHN Cloud Object Storage — [https://www.nhncloud.com/kr/service/storage/object-storage](https://www.nhncloud.com/kr/service/storage/object-storage)

- Naver Cloud Object Storage — [https://www.ncloud.com](https://www.ncloud.com)

- KT Cloud Object Storage — [https://cloud.kt.com](https://cloud.kt.com)

- Sakura Internet Object Storage — [https://manual.sakura.ad.jp/cloud/objectstorage](https://manual.sakura.ad.jp/cloud/objectstorage)

- IIJ GIO Object Storage — [https://www.iij.ad.jp/biz/gio](https://www.iij.ad.jp/biz/gio)

- OpenZFS — [https://openzfs.github.io](https://openzfs.github.io)

- bcachefs — [https://bcachefs.org](https://bcachefs.org)

- Kubernetes CSI — [https://kubernetes-csi.github.io/docs](https://kubernetes-csi.github.io/docs)

- Apache Iceberg — [https://iceberg.apache.org](https://iceberg.apache.org)

- DuckDB — [https://duckdb.org](https://duckdb.org)

- Veeam — [https://www.veeam.com](https://www.veeam.com), Rubrik — [https://www.rubrik.com](https://www.rubrik.com), Cohesity — [https://www.cohesity.com](https://www.cohesity.com), Druva — [https://www.druva.com](https://www.druva.com)