블록·파일·오브젝트 스토리지

세 가지 스토리지

flowchart TB
  app["애플리케이션"]
  app -->|"REST API (PUT/GET 키)"| obj["오브젝트 스토리지<br/>평평한 버킷 + 키 + 메타데이터"]
  app -->|"파일 경로 (open/read)"| file["파일 스토리지<br/>디렉터리 트리"]
  app -->|"블록 주소 (read block 1024)"| blk["블록 스토리지<br/>날것의 블록 볼륨"]
  obj & file -.->|"내부적으로 결국 블록 위에 쌓인다"| blk

블록 스토리지가 가장 먼저 나왔고, 파일 스토리지는 그 위의 추상화이며, 오브젝트 스토리지는 성능을 일부 내주고 내구성·규모·비용을 얻는 선택이다. 파일 시스템이 블록을 관리하는 방식은 파일 시스템에 있다.

컨테이너 볼륨을 고를 때도 같은 구분이 나온다. 여러 컨테이너가 NFS 공유 디렉터리를 쓰면 설정은 쉽지만 컨테이너별 격리와 용량 제한(quota)을 걸기 어렵다. 컨테이너마다 블록 장치(NBD 같은 네트워크 블록 장치, qcow2 이미지 파일)를 붙이면 볼륨 단위로 격리되고, 용량 제한과 스냅숏이 쉬워진다. 쿠버네티스의 PersistentVolume도 같은 선택을 접근 모드로 드러낸다. 노드 하나가 붙는 ReadWriteOnce는 대개 블록 볼륨(EBS 등)이, 여러 노드가 함께 쓰는 ReadWriteMany는 파일 스토리지(NFS, EFS 등)가 맡는다.

오브젝트 스토리지의 쓰임새

버킷과 객체: 업로드는 어떻게 저장되나

S3 같은 객체 스토리지는 내부에서 메타데이터 저장소와 데이터 저장소를 분리한다. 메타데이터는 작고 자주 조회되며 검색·목록이 필요하고, 데이터는 크고 한 번 쓰면 바뀌지 않으므로 서로 다른 저장 방식이 맞기 때문이다.

[버킷 생성] PUT /bucket-to-share

sequenceDiagram
  participant API as API 서비스
  participant IAM
  participant Meta as 메타데이터 저장소
  API->>IAM: 인증·쓰기 권한 확인
  API->>Meta: 버킷 항목 생성
  Note over API: 성공 응답

[객체 업로드] PUT /bucket-to-share/script.txt

sequenceDiagram
  participant API as API 서비스
  participant IAM
  participant Data as 데이터 저장소
  participant Meta as 메타데이터 저장소
  API->>IAM: 이 버킷에 대한 쓰기 권한 확인
  API->>Data: payload 저장
  Data-->>API: 객체 UUID 반환
  API->>Meta: { object_id(UUID), bucket_id, object_name, ... } 기록

• 경로처럼 보이는 /bucket-to-share/script.txt는 실제 디렉터리가 아니라 버킷 이름 + 객체 키다. 폴더는 키의 접두사로 흉내 낸다.
• 데이터 저장소는 이름이 아니라 UUID로 객체를 찾는다. 이름 → UUID 매핑은 메타데이터 저장소가 맡는다. 그래서 같은 이름으로 다시 올리면 새 UUID의 데이터가 생기고 메타데이터만 그쪽을 가리키게 된다(버전 관리의 바탕).
• 모든 요청은 먼저 IAM으로 권한을 확인한다. 공개 버킷 실수가 대형 유출로 이어지므로 기본은 비공개다.

이레이저 코딩

데이터를 잃지 않게 하는 가장 단순한 방법은 복제다. 같은 데이터를 3벌 두면 2대가 죽어도 남는다. 대신 저장 공간이 3배다. 이레이저 코딩(erasure coding) 은 데이터를 조각내고 수학적으로 계산한 패리티(parity) 조각을 더해, 일부 조각을 잃어도 나머지로 원본을 복원한다.

4 + 2 이레이저 코딩

flowchart TB
  orig["원본"] --> data
  subgraph data["데이터 조각 4개"]
    d1["d1"]
    d2["d2"]
    d3["d3"]
    d4["d4"]
  end
  subgraph parity["패리티 조각 2개 (리드-솔로몬 부호 등)"]
    p1["p1"]
    p2["p2"]
  end
  data -->|"계산"| parity

6개 조각을 서로 다른 서버(가능하면 다른 랙·가용 영역)에 둔다. d3, d4를 잃음 → d1, d2, p1, p2로 d3, d4를 다시 계산한다.

같은 장애 허용 수준에서 공간을 훨씬 적게 쓰고, 조각을 여러 장애 영역에 흩으면 내구성도 높아진다. 대형 오브젝트 스토리지가 「99.999999999%(11 nines)」 수준의 내구성을 설계 목표로 내세울 수 있는 기반이 이런 기법이다. RAID 5·6도 같은 원리(패리티)를 디스크 단위로 쓴 것이다. 메모리 계층 구조

멀티파트 업로드

몇 GB짜리 파일을 한 번에 올리면 오래 걸리고, 중간에 연결이 끊기면 처음부터 다시 올려야 한다. 멀티파트 업로드(multipart upload) 는 파일을 조각내 따로 올리고, 저장소가 마지막에 조립한다.

sequenceDiagram
  participant C as 클라이언트
  participant S as 오브젝트 스토리지
  C->>S: 1. CreateMultipartUpload
  S-->>C: 2. UploadId
  C->>S: 3. UploadPart(UploadId, part 1, 데이터)
  S-->>C: 4. ETag(part 1)
  Note over C,S: … part 2 ~ N (병렬로, 실패한 조각만 재시도)
  C->>S: 5. CompleteMultipartUpload(UploadId, [part번호, ETag] 목록)
  Note over S: 6. 번호순으로 조립
  S-->>C: 완료 응답

• ETag 는 조각마다 돌려받는 식별자다. 완료 요청에 조각 번호와 함께 넣어 저장소가 조각을 검증·조립한다. 무결성을 더 확실히 하려면 조각마다 체크섬(CRC32, SHA-256 등)을 함께 보낸다.
• S3 기준으로 조각은 마지막 조각을 빼고 최소 5MiB이고, 최대 10,000개까지 나눈다. S3는 100MB가 넘는 객체에 멀티파트 업로드를 권장한다.
• 끝내지 않은 업로드의 조각도 저장 요금이 붙는다. 미완료 멀티파트 업로드를 일정 기간 뒤 중단하는 수명 주기 규칙을 버킷에 걸어 둔다.
• 브라우저에서 바로 올릴 때는 서버가 조각마다 사전 서명 URL(presigned URL) 을 발급해, 파일이 애플리케이션 서버를 거치지 않게 한다. 서버를 거치는 업로드는 NestJS 파일 업로드(Multer)에 있다.

작은 파일이 많을 때: 청크 기반 BLOB 저장소

메신저 사진·동영상처럼 작은 파일이 엄청나게 많이 쌓이면 NAS·NFS 같은 파일 시스템이 먼저 한계에 닿는다. 파일 하나를 읽을 때도 이름 → inode 변환, inode 읽기, 데이터 읽기로 디스크 I/O가 여러 번 일어나고, 파일 수에 비례해 늘어나는 메타데이터가 병목이 된다. Facebook Haystack 같은 사내 BLOB 저장소는 이를 다음 구조로 푼다.

오늘날 대부분의 서비스는 이런 저장소를 직접 만들지 않고 S3 같은 관리형 오브젝트 스토리지를 쓴다. 하지만 오브젝트 스토리지 내부도 같은 아이디어(메타데이터와 데이터 분리, 큰 파일에 묶어 쓰기, 복제·이레이저 코딩)로 돌아간다.

정리

• 블록은 빠르고 한 서버가 독점하며, 파일은 여러 서버가 공유하는 계층 구조이고, 오브젝트는 느리지만 싸고 크고 튼튼하다.
• 미디어·백업·데이터 레이크처럼 크고 덜 자주 바뀌는 데이터는 오브젝트 스토리지에 두고 DB에는 키만 저장한다.
• 이레이저 코딩은 복제보다 훨씬 적은 공간으로 같은 장애를 견디는 대신, 읽기·복구에 계산 비용을 낸다.
• 큰 파일은 멀티파트 업로드로 조각내 병렬로 올리고, 미완료 업로드 정리 규칙을 함께 둔다.

관련 노트: 이미지·동영상 처리 서버 설계, 파일 시스템, 메모리 계층 구조, AWS 클라우드 기초: 인프라, 컴퓨팅, 보안 그룹, 고가용성과 재해 복구 설계, NestJS 파일 업로드(Multer), 용도별 데이터베이스와 고르는 법