MinIO - "온프레미스 S3"
CS/DataBase 2026. 5. 21. 19:39

MinIO - "온프레미스 S3"

@Beemo9
목차

레퍼런스

블록, 파일, 객체 — 스토리지 3종류를 제대로 이해하기 https://infinitecode.tistory.com/139
객체 스토리지 (Object Storage) https://infinitecode.tistory.com/140

MinIO(미니오)

객체 스토리지 시장에서 Amazon Web Services(AWS)의 S3는 사실상 글로벌 표준(Standard)입니다.

수많은 오픈소스와 기업용 솔루션들이 S3 API와 호환되도록 개발됩니다.

MinIO는 바로 이 S3 API와 100% 호환되도록 설계된 고성능 객체 스토리지입니다.

강력한 호환성으로 인해 개발자는 소스 코드를 작성할 때 AWS S3 라이브러리(SDK)를 그대로 사용하면서, 연결하는 엔드포인트 URL만 AWS가 아닌 로컬의 MinIO 주소(ex : http://localhost:9000)로 바꾸면 완전히 동일하게 동작하기 때문입니다.

 

인프라 비용을 아끼기 위해 개발·테스트 단계에서는 로컬이나 사내 서버의 MinIO를 바라보게 하고,

실제 운영 환경으로 배포할 때는 코드 수정 없이 설정(ENV)만 AWS S3로 스위칭하는 전략이 가능해집니다.

즉 마이그레이션에 굉장한 이점을 가지고 있습니다.


구성 요소

1️⃣데이터 저장 방식: 드라이브(Drive)와 세트(Set)

  • 드라이브(Drive): MinIO가 데이터를 저장하는 가장 하위 물리 단위(디스크 경로)입니다. 도커로 띄울 때 지정을 해주게 됩니다.
  • 서버(Server): MinIO 프로세스가 실행되는 노드입니다.
  • 세트(Erasure Set): 드라이브들의 집합입니다. MinIO는 들어온 데이터를 여러 드라이브에 쪼개서 분산 저장하는데, 이 묶음을 세트라고 부릅니다.

2️⃣Erasure Coding (데이터 보호)

일반적인 인프라에서는 디스크 고장을 대비해 RAID를 구성하거나 똑같은 파일을 2~3개 복제(Replication)해서 저장하느라 용량을 낭비하곤 합니다. 반면 MinIO는 이레이저 코딩이라는 수학적 알고리즘을 사용합니다.

  • 파일이 들어오면 데이터를 여러 개의 데이터 블록패리티(오류 정정) 블록으로 쪼갠 뒤, 여러 디스크에 분산합니다.
  • 예를 들어 총 16개의 디스크 중 8개가 고장 나더라도, 남은 8개의 블록만 있으면 수학적으로 원본 데이터를 완벽하게 복구해냅니다.
  • RAID에 비해 복구 속도가 압도적으로 빠르고 디스크 공간 효율이 좋습니다.

쉽게 말해서 한 곳에 저장하지않고, 잘개 쪼개서 여러 곳에 분산시킴으로서 복구에 이점을 가지게 됩니다.

※ SNSD 환경에서는 적용되지 않습니다.

3️⃣ Bucket (버킷)

객체 스토리지에서 버킷이란 최상위 폴더 개념.

// 모식도
파일시스템          객체 스토리지
/                  (없음, 버킷이 최상위)
├── documents/     ├── documents (버킷)
│   └── a.pdf      │   └── a.pdf (오브젝트)
└── images/        └── images (버킷)
    └── b.png          └── b.png (오브젝트)

주요 특징

  • Flat Namespace 특성으로 인해 중첩 버킷 구성은 불가능 (Depth <= 1)
  • 버킷 이름은 변경 불가, 변경 필요 시 새로운 버킷 생성 및 데이터 복제
  • 버킷/객체 권한 종류는 Private, Public(Read-Only), Public(Read-Write)로 3가지.
    • Presigned URL을 사용하면 일시적으로 Private 접근 가능하도록 설정 가능
  • S3 IAM 정책 문법으로 Bucket Policy 설정 가능 (Json 형태)

아키텍쳐

배포 모드

모드 구성 용도
Single Node Single Drive (SNSD) 서버 1, 디스크 1 개발/테스트
Single Node Multi Drive 서버 1, 디스크 N 소규모 운영
Multi Node Multi Drive 서버 N, 디스크 N 프로덕션
Distributed (K8s) MinIO Operator 대규모 클라우드 네이티브

1️⃣ Single Node Single Drive

MinIO Cluster
└── Server (노드 1개)
    └── Drive (디스크 1개)
        └── Bucket
            ├── object-a.png
            ├── object-b.pdf
            └── logs/2026/05/21/app.log   ← 경로처럼 보이지만 key 1개

특징

  • Erasure Set 없음 → 디스크 죽으면 데이터 소실
  • 복구 불가, 이중화 없음
  • 개발/테스트 전용

2️⃣Single Node Multi Drive

MinIO Cluster
└── Server (노드 1개)
    ├── Drive 1 (/mnt/disk1)
    ├── Drive 2 (/mnt/disk2)
    ├── Drive 3 (/mnt/disk3)
    └── Drive 4 (/mnt/disk4)
          │
          └── Erasure Set (드라이브 묶음)
                ├── Data Shard × 2    ← 실제 데이터 조각
                └── Parity Shard × 2  ← 복구용 패리티
                      │
                      └── Bucket
                            └── object.png  (4개 드라이브에 분산 저장)

특징

  • 드라이브 최소 4개부터 Erasure Set 구성 가능
  • 드라이브 N/2개까지 장애 허용 (4개 기준 → 2개 장애까지 복구 가능)
  • 노드 자체가 죽으면 끝 → 서버 이중화는 안 됨
  • 소규모 사내 파일 스토리지 정도는 이걸로 충분

3️⃣Multi Node Multi Drive

MinIO Cluster
// 마스터/슬레이브 구조가 없는 완전 분산형 구조
├── Server 1 (노드 1)          Server 2 (노드 2)
│   ├── Drive 1 (/mnt/disk1)   ├── Drive 1 (/mnt/disk1)
│   ├── Drive 2 (/mnt/disk2)   ├── Drive 2 (/mnt/disk2)
│   ├── Drive 3 (/mnt/disk3)   ├── Drive 3 (/mnt/disk3)
│   └── Drive 4 (/mnt/disk4)   └── Drive 4 (/mnt/disk4)
│
├── Server 3 (노드 3)          Server 4 (노드 4)
│   ├── Drive 1 (/mnt/disk1)   ├── Drive 1 (/mnt/disk1)
│   ├── Drive 2 (/mnt/disk2)   ├── Drive 2 (/mnt/disk2)
│   ├── Drive 3 (/mnt/disk3)   ├── Drive 3 (/mnt/disk3)
│   └── Drive 4 (/mnt/disk4)   └── Drive 4 (/mnt/disk4)
│
│   ← 전체 16개 드라이브 →
│
└── Erasure Set (클러스터 전체에 걸쳐 구성)
      │
      ├── Data Shard × 8   (8개 드라이브에 데이터 분산)
      └── Parity Shard × 8 (8개 드라이브에 패리티 분산)
            │
            └── Bucket
                  └── object.png
                        ├── shard 1 → Node1/Drive1
                        ├── shard 2 → Node1/Drive3
                        ├── shard 3 → Node2/Drive2
                        ├── shard 4 → Node2/Drive4
                        ├── ...
                        └── shard 16 → Node4/Drive4
//읽기,쓰기 플로우
Client
  │
  ▼
[Load Balancer / MinIO 내장 분산 라우팅]
  │
  ├──▶ Node 1  ─┐
  ├──▶ Node 2  ─┤  어느 노드로 요청이 와도
  ├──▶ Node 3  ─┤  내부적으로 shard 수집/조합
  └──▶ Node 4  ─┘

특징

  • 어느 노드에 요청해도 동일한 응답 (모든 노드가 라우팅 가능)
  • 쓰기: 과반수(N/2 + 1) 노드에 shard 기록 완료 시 성공 응답
  • 읽기: Data Shard만 있으면 복구 없이 바로 읽음, 일부 누락 시 Parity로 복구

※프로덕션은 Quorum 조건으로 인해 최소 4노드 × 4드라이브 권장 (Erasure Set 구성 조건).

'CS > DataBase' 카테고리의 다른 글

객체 스토리지 (Object Storage)  (0) 2026.05.21
블록, 파일, 객체 — 스토리지 3종류를 제대로 이해하기  (1) 2026.05.05
[TIL] RDBMS  (1) 2024.10.10
[MySQL] 인덱스(INDEX)  (1) 2023.12.29
[MySQL] View  (0) 2022.10.26
Beemo9
@Beemo9
개발 기술 블로그, Dev 포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!
image