객체 스토리지 대 블록 스토리지 어느 쪽이 더 나은가

객체 스토리지는 사용자 업로드 파일, 정적 자산, 백업, 아카이브에서 승리합니다. 본질적으로 HTTP를 통해 접근하고 제자리에서 거의 변경하지 않는 모든 것입니다. 블록 스토리지는 낮은 지연 시간의 무작위 쓰기가 필요할 때 승리합니다. 데이터베이스, 부트 볼륨, 고 트랜잭션 파일 시스템. 파일 전송 워크로드의 경우 객체 스토리지가 거의 항상 정답입니다. 수평으로 확장되고, 블록 스토리지의 $0.08~0.125/GB/월 대비 $0.015~0.023/GB/월이며, 재파티셔닝 없이 페타바이트 규모 버킷을 처리합니다.

내부에서 실제로 다른 점

블록 스토리지는 OS가 ext4, XFS, NTFS로 포맷하는 원시 장치(LUN 또는 EBS 볼륨)를 노출합니다. 읽기와 쓰기는 일반적으로 4 KB 또는 16 KB의 고정 크기 블록으로 iSCSI, NVMe-oF, SCSI를 통해 발생합니다. OS가 파일 시스템을 소유하고, 블록 장치는 파일이 아닌 오프셋만 알고 있습니다.

객체 스토리지는 각 객체에 키, 바이트, 메타데이터가 있는 HTTP API(S3, Azure Blob, GCS)를 노출합니다. 아래에 파일 시스템이 없습니다. 객체는 전체를 PUT하고 GET하는 원자적 단위입니다. 쓰기는 새 버전을 생성합니다. 2 GB 객체의 바이트 1,000,000을 객체 전체를 다시 쓰지 않고는 수정할 수 없습니다. 이 불변성은 기능입니다. 블록 스토리지가 쉽게 맞출 수 없는 다중 리전 복제, 버전 관리, 라이프사이클 규칙을 가능하게 합니다.

빠른 비교

| 항목 | 객체 스토리지 | 블록 스토리지 | |------|--------------|--------------| | 일반적인 API | S3 HTTP REST | POSIX + iSCSI/NVMe | | 비용 (AWS 핫 티어) | $0.023/GB/월 | $0.08/GB/월 (gp3) | | 단일 단위 최대 크기 | 객체당 5 TB | EBS 볼륨당 64 TiB | | 지연 시간 | 10~100 ms | 밀리초 미만 | | 동시 읽기 | 무제한 | 보통 한 번에 한 호스트 | | 내구성 | 11 nine(S3) | 5~6 nine(EBS) | | 적합한 용도 | 파일, 미디어, 백업 | 데이터베이스, 부트 디스크 | | 부적합한 용도 | 대용량 파일 무작위 쓰기 | 하나의 볼륨을 넘는 수평 확장 |

처리량 대 지연 시간: 다른 승자

gp3 EBS 볼륨은 4 KB 읽기를 1 ms 미만에 제공합니다. 동일한 4 KB에 대한 S3 GET는 리전에 따라 20~80 ms가 걸립니다. 초당 5,000 트랜잭션을 처리하는 PostgreSQL 쓰기 선행 로그의 경우 이 지연 시간 차이는 치명적입니다. 사용자가 500 MB .zip을 다운로드하는 경우에는 첫 바이트 지연이 처리량 뒤에 사라지므로 무관합니다.

순차 처리량에서 객체 스토리지는 종종 규모에서 승리합니다. S3는 단일 버킷에서 접두사당 5,500 GET 요청/초를 제공할 수 있으며, 요청률 파티셔닝(해시 접두사 키)으로 수만 개까지 늘어납니다. 단일 gp3 볼륨은 1,000 MB/s와 16,000 IOPS에서 제한됩니다. 10 GB 파일을 동시에 다운로드하는 10명의 경우 객체 스토리지가 파이프를 포화시키고, 블록 스토리지는 병목이 됩니다.

규모에서의 비용

콜드 미디어 100 TB의 경우:

S3 Standard: 월 약 310만 원
S3 Standard-IA: 월 약 170만 원
S3 Glacier Instant Retrieval: 월 약 55만 원
S3 Glacier Deep Archive: 월 약 13만 원
EBS gp3: 월 약 1,080만 원
EBS st1(처리량 최적화 HDD): 월 약 605만 원

블록 스토리지는 티어링이 없습니다. 1년에 한 번 접근하는 데이터에 최대 접근 가격을 지불합니다. 객체 스토리지 라이프사이클 규칙은 자동으로 객체를 이동합니다. 30일은 핫, 60일은 Standard-IA, 90일 이후 Glacier. 7일 만료로 업로드를 저장하는 파일 전송 서비스의 경우 Expiration 규칙이 있는 객체 스토리지가 EBS 기반 서버보다 훨씬 저렴합니다.

일관성과 동시성

S3는 이제 전 세계적으로 PUT와 DELETE에 대해 강력한 쓰기 후 읽기 일관성을 제공합니다. Azure Blob와 GCS도 마찬가지입니다. 이것은 객체 스토리지의 역사적인 단점 중 하나를 제거했습니다. 이전에는 새로 업로드된 파일이 몇 초 동안 404를 반환하는 "최종 일관성" 문제가 있었습니다.

하지만 동시 쓰기 작업자는 여전히 중요합니다. 블록 스토리지는 보통 단일 쓰기 작업자를 가정합니다. 다중 연결 모드가 있지만 복잡도가 추가됩니다. 객체 스토리지는 백만 명의 클라이언트가 동시에 PUT하도록 허용하며, 마지막 쓰기가 이기는 시맨틱(또는 모두 보존하는 버전 관리)이 있습니다. 두 사용자가 같은 키로 다른 파일을 업로드할 수 있는 파일 공유 시스템의 경우 버킷의 버전 관리가 두 파일 모두 보존합니다.

파일 전송 앱이 블록 스토리지를 필요로 하는 경우

주의 사항: 객체 스토리지를 제공하는 애플리케이션은 종종 블록 기반 호스트에서 실행됩니다. 파일 업로드 API에는 임시 스풀링(멀티파트 청크, 바이러스 검사), 메타데이터 저장소(보통 EBS의 PostgreSQL), 로그를 위한 로컬 디스크가 필요합니다. 객체 자체는 S3/R2/Blob로 이동하고, 이를 관리하는 기계는 블록에 위치합니다.

고처리량 스트리밍 업로드의 경우 인메모리 파이프라인이 디스크보다 낫습니다. aws-sdk-js와 boto3 같은 라이브러리는 로컬 디스크에 닿지 않는 스트리밍 멀티파트 업로드를 지원합니다. 잘 조정된 업로드 서비스는 500 MB 미만의 RAM과 임시 파일 없이 클라이언트에서 객체 스토리지로 5 GB 파일을 푸시할 수 있습니다.

메타데이터: 미묘한 차이

객체 스토리지는 각 객체에 메타데이터를 담습니다. 시스템 메타데이터(크기, mtime, etag), 사용자 메타데이터(임의 키-값 쌍, x-amz-meta-* 헤더), 태그. S3 Object Lambda, Inventory 보고서, DynamoDB 연동으로 메타데이터를 검색할 수 있습니다. 블록 스토리지는 메타데이터를 전적으로 파일 시스템에 맡기며, 이는 1,000만 개 파일에 태그를 지정하려면 사용자 정의 데이터베이스가 필요함을 의미합니다.

"지난주에 한국 사용자가 업로드한 100 MB 초과 파일 모두 찾기"에 즉시 답해야 하는 전송 앱의 경우, 객체 메타데이터와 Parquet 인벤토리로 Athena에서 몇 초 안에 쿼리할 수 있습니다. NFS 마운트된 블록 볼륨에서 같은 질문은 몇 시간이 걸리는 find 명령입니다.

암호화와 접근 제어

두 스토리지 유형 모두 AES-256으로 저장 시 암호화를 지원합니다. 객체 스토리지는 객체별 접근 제어를 쉽게 합니다. 버킷 정책, 서명된 URL, 객체 ACL, IAM 조건. 블록 스토리지 접근은 더 거칩니다. 전체 볼륨이 연결되거나 연결되지 않거나.

시간 제한 다운로드 링크가 있는 안전한 파일 공유의 경우 서명된 S3 URL(최대 7일 유효)이 표준 패턴입니다. 서버 측 평문 노출이 없는 전송을 위해 업로드 전 클라이언트 측 암호화가 모든 객체 저장소에서 작동합니다. HexaTransfer는 브라우저에서 AES-256-GCM으로 암호화하고 암호문만 저장합니다. 객체 백엔드는 의미 없는 바이트를 봅니다.

간단한 결정 규칙

세 가지 질문을 하세요.

파일 시스템 API(POSIX, SMB, NFS)를 통해 데이터에 접근합니까? 예라면 블록 또는 파일 스토리지.
HTTP를 통해 접근하고, 가끔 변경하고, 무제한 확장을 원합니까? 예라면 객체 스토리지.
데이터셋이 10 TB 이상이고 성장 중입니까? 거의 항상 객체 스토리지.

파일 전송 워크로드의 경우 (2)에 대한 답은 항상 예입니다. 파일 자체에는 S3, R2, Azure Blob, GCS를 사용하고, 이를 관리하는 데이터베이스와 웹 티어에는 블록 스토리지를 남겨두세요.

hexatransfer.com에서 사용해보세요 — 무료, 계정 불필요, 최대 10 GB.