📗MinIO 개요
MinIO EC(Erasure Coding)는 MinIO에서 데이터의 고가용성과 내결함성을 보장하기 위한 기능으로 디스크나 노드 일부가 손실되더라도 데이터를 복구할 수 있도록 하는 기술이다.

RAID처럼 데이터를 여러 조각으로 나누고, 여분(패리티)을 추가로 생성해서 일부 조각이 사라져도 원본을 복원할 수 있게 만드는 기술이다.

🏳️‍🌈 [궁금한점]

• MinIO EC 가 무엇인가.
• MioIO를 베어메탈에 설치하는 것과 쿠버네티스에 설치하는 것 중 어느 것이 나은 선택인가

목차

• MinIO EC 활용
  • MinIO EC 구조
  • EC 장점
  • EC 사용 시 주의할 점
• EC 사용 아키텍처
  • EC 기반 MinIO 아키텍처 장단점
  • 가장 현대적인 조합
  • Longhorn은 느리다.
  • 쿠버네티스 기반 아키텍처
  • 아키텍처 선택 전략
• 설치/운영 시 반드시 이해해야 하는 사항
  • 체크리스트

MinIO EC 활용

MinIO EC 구조

MinIO는 분산 모드(distributed mode)일 때 EC를 자동으로 적용된다.MinIO는 최소 4개의 디스크 이상일 때 EC를 활성화할 수 있다.

EC 장점

• 고가용성: 디스크나 노드 몇 개가 고장 나도 데이터 복원 가능 (최대 패리티 수만큼)
• 스토리지 효율성: RAID-1보다 효율적 (복제 대신 조각으로 저장)
• 스케일 아웃 가능: MinIO 노드/디스크를 추가해서 수평 확장이 쉬움
• S3 호환성: S3 API를 그대로 지원하면서 고가용성 보장

EC 사용 시 주의할 점

• EC는 계산이 필요하므로, 복제보다 CPU/메모리 사용량이 높음
• 성능을 최적화하려면 디스크/노드를 고르게 배분해야 함
• EC 구성을 위해서는 모든 노드에 동일 수의 디스크가 있어야 안정적
• MinIO가 내부적으로 N개의 데이터 조각 + M개의 패리티 조각을 만들어서 저장
• 디스크 일부가 죽어도 복구 가능
• RAID6 같은 기능을 소프트웨어 레벨에서 처리
• EC는 디스크 수 짝수 권장, 예를 들어 EC(4+2) 구성할 때 6개 디스크 필요, EC(8+3)이면 11개 필요.
• 노드/디스크 배치 전략, 가능한 한 디스크를 여러 노드에 분산하여 모든 데이터 조각이 한 노드에 몰리지 않게 처리
• 네트워크 품질 중요, EC는 데이터 저장/복구 시 네트워크를 아주 많이 쓰기 때문에, 10Gbps 이상 네트워크를 권장
• 스토리지 타입 신중히 선택
• CSI를 통해 연결된 스토리지가 빠르고 안정적이어야 함
• RBD, NVMe, 로컬 SSD 추천.

항목	영향도	비고
CPU 사용량	높음 (인코딩/디코딩)	특히 업로드/복구 시
디스크 I/O	많음	여러 디스크를 병렬로 접근
네트워크 트래픽	많음	패리티 조각 간 송수신 발생
레이턴시	높아질 수 있음	RAID보다 느릴 수 있음

MinIO의 패리티
MinIO는 정교한 수학적 계산을 이용해서, 여러 개의 블록 손실도 복구할 수 있다.예를들어 EC 구조가 12:4이면, 12개는 데이터, 4개는 패리티 블록이다. 여기서 4개까지 디스크가 사라져도 전체 데이터를 복구할 수 있다.

EC 사용 아키텍처

EC 기반 MinIO 아키텍처 장단점

구분	Bare Metal/VM	Kubernetes + HostPath	Kubernetes + CSI
EC 지원	O	O	O
장점	- 디스크 성능 최상 - EC 덕에 고가용성 - 튜닝 자유로움	- 쿠버네티스 관리 편의성 - 빠른 배포 가능 - PVC로 묶어서 간단 운영	- 고가용성 강화 - 스토리지 복구 자동화 - 대규모 확장에 적합
단점	- 수동 복구 필요 - 스케일 아웃 수동 작업 - 서버 장애 시 수작업 많음	- 노드 장애시 데이터 손실 가능성 - HostPath가 디스크에 강결합되어 이중화 약함	- 관리 복잡성↑ (스토리지 오케스트레이션 필요) - 네트워크 스토리지에 따른 성능 저하 가능성

가장 현대적인 조합

"EC + Kubernetes + CSI" 조합이 가장 현대적이고 운영에 적합한 조합이다.

조합	평가
EC + Bare Metal/VM	성능은 최강, 하지만 수작업 복구가 필요해서 대규모 운영에 불리함
EC + Kubernetes + HostPath	쿠버네티스 이점을 얻지만, 디스크가 노드에 묶여서 장애 복구/확장이 약함
EC + Kubernetes + CSI	고가용성, 복구 자동화, 대규모 확장성까지 확보 가능. 가장 이상적.

Longhorn은 느리다.

CSI는 Ceph, PowerFlex, Portworx 등이 추천되고 Longhorn의 경우 문제가 있다.

• Longhorn은 네트워크 I/O를 많이 먹는다.(모든 데이터가 네트워크로 2~3번 왕복)
• EC가 빠른데, Longhorn이 느린 스토리지 레이어라 병목 발생
• 대규모 확장성 빈약 - 수십~수백 노드 이상이면 관리 오버헤드 커짐
• 스토리지 볼륨 수가 많아지면 성능 급락하는 현상 있음.

쿠버네티스 기반 아키텍처

Kubernetes + CSI + MinIO StatefulSet

• Pod AntiAffinity 설정해서 같은 노드에 MinIO Pod 몰리지 않게
• StorageClass는 고성능 디스크 사용 (ex: Rook-Ceph/RBD, Longhorn NVMe 등)
• MinIO Distributed Mode + EC 활성화
• Service는 LoadBalancer 혹은 Ingress 붙이기

아키텍처 선택 전략

고성능, 고제어, 고가용성이 필요할 경우 → 베어메탈 추천

• EC의 디스크-패리티 블록 구조를 100% 활용 가능
• 디스크 I/O 성능도 직접 디바이스에 붙어서 가장 빠름
• 어떤 디스크가 죽었는지, 어디에 EC 조각이 저장되는지 명확하게 보임
• 장애 대응 시, 손실 디스크만 교체하면 되고 mc admin heal로 복구 끝
• 하나의 노드에 여러 PVC가 같은 물리 디스크에 올라갈 수도 있음
• EC 패리티 분산이 물리적으로는 되지 않을 가능성 존재
• 디스크 장애 시, PVC가 자동 복구되더라도 데이터 조각 무결성은 보장 안됨
• EC는 로컬 디스크 제어가 핵심이기 때문에 CSI 기반의 추상화가 오히려 독이 될 수 있음

Kubernetes + CSI 사용 시점

• 단일 노드 장애 시, Pod 자동 재배치 필요
• 스토리지가 Ceph, Longhorn, EBS 같은 고가용 스토리지를 기반으로 되어 있고, MinIO 자체 EC에 크게 의존하지 않도록 설계하는 경우
• 팀 내에 쿠버네티스 DevOps 자동화 체계가 잘 갖춰져 있고, Helm, Operator 기반으로 스케일링을 자주 할 계획인 경우

설치/운영 시 반드시 이해해야 하는 사항

디스크 수와 EC 구조가 연결되어 있다

MinIO는 EC 구성(데이터 블록 수, 패리티 블록 수)을 총 디스크 수에 따라 자동 결정한다.
설치 전에 아래를 반드시 고려해야 해:

EC 구조 예시	구성	내결함성
4 디스크	2 데이터 + 2 패리티	2개 손실
6 디스크	4 데이터 + 2 패리티	2개 손실
12 디스크	8 데이터 + 4 패리티	4개 손실
16 디스크	12 데이터 + 4 패리티	4개 손실

디스크를 더 넣으면 더 많은 손실을 견딜 수 있음. 단, 최소 4개 이상 필요.

모든 디스크는 동일한 역할을 한다

• MinIO는 복제 방식이 아니라 조각 저장 방식이므로 모든 디스크가 동시에 필요하다. (EC 계산 시 전체가 연관됨)
• 하나의 디스크라도 느리면 전체 성능에 영향이 간다.
• 스토리지가 다르면(속도나 크기), 병목 생김 → 성능 좋은 SSD와 느린 HDD 혼용 금지

EC 구조에 따라 성능과 자원 사용량이 달라진다

• EC는 업로드 시 인코딩, 다운로드 시 디코딩을 하기 때문에CPU 사용률이 복제 방식보다 훨씬 높음
• 작은 파일 많을 때 오버헤드 커짐
• 패리티 블록을 만들기 위한 디스크 I/O와 네트워크 I/O 증가
• 스펙이 낮은 환경에서는 파일 크기, 워크로드 유형 고려 필요
  (e.g., 잦은 소규모 PUT 요청 vs 대형 백업)

노드 장애 시에도 EC 구조가 깨지지 않아야 함

• 설치 시 노드당 디스크 수가 다르면 아래 문제가 생김:
• EC 블록이 특정 노드에 몰리는 불균형 발생
• 일부 노드 장애 시 EC 복구 불가능한 상태가 됨
• 모든 노드에 동일 수의 디스크를 할당하는 게 안정적

복구는 자동이지만, 완전 자동은 아니다

• 디스크/노드가 복구되면, MinIO가 자동으로 heal하지는 않음
• 수동 명령 필요

mc admin heal -r <alias>

• 디스크 교체 후 잊지 말고 heal 해줘야 데이터 복구 완료

체크리스트

체크 항목	설명
디스크 수는 충분한가?	최소 4개 이상 필요
노드/디스크 균형 맞췄나?	EC 분산을 위해 균형 필수
CPU/네트워크 여유 있는가?	EC 연산/트래픽 대비 필요
복구 프로세스 알고 있는가?	mc admin heal 기억
S3 호환 툴 사용 시 EC 영향을 아는가?	성능 이슈 대비