에라스처 코딩

에라스처 코딩 (Erasure Coding)

디스크 몇 개가 고장나도 데이터를 잃지 않게 하는 게 객체 스토리지의 핵심 요구죠. MinIO(현 AIStor)는 이걸 에라스처 코딩으로 해결해요. 객체를 데이터 조각과 패리티 조각으로 나눠 여러 드라이브에 분산 저장해 둠으로써, 드라이브나 노드가 일부 죽어도 데이터를 온전히 복원할 수 있게 해 줘요.

출처: Erasure Coding — MinIO AIStor Documentation

본문

에라스처 셋 (Erasure Set)

AIStor는 각 서버 풀(pool)에 있는 드라이브들을 같은 크기의 에라스처 셋(Erasure Set) 으로 묶어요. 기본적으로 에라스처 셋 하나는 2~16개의 드라이브를 담을 수 있어요. RELEASE.2026-02-02T23-40-11Z 이상이라면 MINIO_ERASURE_SET_DRIVE_COUNT 환경 변수로 최대 32개까지 설정할 수 있어요.

에라스처 셋의 수와 크기는 서버 풀이 초기화될 때 정해져요. 초기 설정 이후에는 바꿀 수 없다는 점 기억해 두세요.

데이터 샤드와 패리티 샤드

쓰기 연산마다 AIStor는 객체를 데이터(data) 샤드와 패리티(parity) 샤드로 나눠요.

데이터 샤드는 객체의 일부분을 담고, 패리티 샤드는 손상된 데이터 샤드를 복원하는 데 쓰는 수학적 표현을 담아요.

mc admin object info로 디스크에 있는 특정 객체의 샤드(일명 "parts") 요약을 확인할 수 있어요.

에라스처 셋의 스트라이프 크기가 배포의 최대 패리티를 결정해요. 데이터·패리티 샤드 수를 계산하는 공식은 다음과 같아요.

N ( ERASURE SET SIZE ) = K ( DATA ) + M ( PARITY )

패리티 값은 0에서 에라스처 셋 크기의 1/2 사이로 설정할 수 있어요.

나중에 패리티 값을 바꿔도, 그전에 쓴 객체는 자동으로 갱신되지 않아요.

읽기 쿼럼 (Read Quorum)

AIStor가 객체를 읽으려면 어떤 종류든 최소 K개의 샤드가 필요해요.

이 값 K가 배포의 읽기 쿼럼이에요. 따라서 에라스처 셋에 읽기 연산을 지원하려면 최소 K개의 정상 드라이브가 있어야 해요.

읽기 쿼럼을 잃은 객체는 재구성할 수 없어요. 다만 복제 재동기화(replication resynchronization) 같은 다른 방법으로 복구할 수도 있어요.

쓰기 쿼럼 (Write Quorum)

AIStor가 객체를 쓰려면 최소 K개의 에라스처 셋 드라이브가 필요해요.

이 값 K가 배포의 쓰기 쿼럼이에요. 쓰기 연산을 지원하려면 에라스처 셋에 최소 K개의 온라인 드라이브가 있어야 해요.

AIStor는 항상 에라스처 셋의 모든 드라이브에 N개 샤드를 모두 쓰려고 시도해요. K개만 쓰는 게 아니에요.

K는 성공 임계값이지, AIStor가 쓰는 드라이브 수가 아니에요. PUT마다 AIStor는:

  1. 객체의 N개 샤드를 전부 생성해요 — K개 데이터 샤드 + M개 패리티 샤드.
  2. 모든 샤드를 병렬로 에라스처 셋의 각 드라이브에 분배해요.
  3. 실패하거나 타임아웃된 드라이브를 포함해 모든 드라이브의 응답을 기다려요.
  4. 최소 K개 드라이브(단, M이 에라스처 셋의 정확히 절반이면 K+1, 아래 참고)가 성공적으로 쓰기를 확인한 뒤에만 클라이언트에 성공을 돌려줘요. 그렇지 않으면 실패를 돌려줘요.

예를 들어 16드라이브 에라스처 셋에 EC:4 패리티라면 PUT마다 드라이브 16개 쓰기를 시도하고, 객체당 실패한 쓰기가 4개까지는 오류 없이 허용돼요. 12드라이브 에라스처 셋에 EC:3이라면 12개 쓰기를 시도하고 최소 9개가 성공해야 해요.

패리티 EC:M이 에라스처 셋 크기의 정확히 절반이면 쓰기 쿼럼은 K+1이에요.

이건 네트워크 이슈로 에라스처 셋의 절반 드라이브가 서로 격리되는 것 같은 분할-뇌(split-brain) 상황을 막아줘요.

K+1 로직은 클라이언트가 같은 객체를 두 번 — 에라스처 셋의 "각 절반"에 한 번씩 — 쓸 수 없게 보장해 줘요.

에라스처 셋이 쓰기 쿼럼을 잃었지만 읽기 쿼럼은 유지하는 동안, AIStor는 읽기 연산은 계속 서빙하고 쓰기 연산은 거절해요. 쓰기 쿼럼을 복원하기에 충분한 드라이브가 다시 온라인이 될 때까지요.

PUT 시점에 드라이브가 오프라인이면 AIStor는 기본적으로 패리티를 자동으로 올려요.

쓰기 시점에 오프라인인 드라이브마다 객체 패리티를 1씩 올리고, 올린 패리티를 객체 메타데이터에 기록해요. 예를 들어 16드라이브 에라스처 셋에 EC:4 패리티에서 2개 드라이브가 오프라인이라면, 객체를 EC:6으로 써요. 이렇게 하면 부분 장애 중에 쓴 객체도 완전히 정상인 에라스처 셋에 쓴 객체와 같은 수준의 보호를 받아요.

이 동작은 MINIO_ERASURE_PARITY_FAILURE 설정으로 바꿀 수 있어요.

읽기 쿼럼을 유지하는 객체라면, AIStor는 어떤 데이터·패리티 샤드로든 손상된 샤드를 복구(heal)할 수 있어요.

에라스처 코딩 계산기를 쓰면 계획한 토폴로지에 가능한 에라스처 셋 크기와 분포를 탐색해 볼 수 있어요. 토폴로지 계획과 드라이브/에라스처 셋 분포를 단순화하려면 되도록 노드 수와 노드당 드라이브 수를 짝수로 맞추는 걸 권장해요.

장애 도메인에 에라스처 셋 분산

Kubernetes 배포에서는 스프레드 존(spread zone)을 설정해 객체 데이터·패리티 샤드가 랙이나 가용 영역 같은 서로 다른 물리적·논리적 장애 도메인에 분산되게 할 수 있어요. 같은 에라스처 셋의 여러 조각이 동시에 실패할 위험을 최소화하는 전략이에요.

스프레드 존을 설정하면 Operator가 파드를 라벨링된 노드에 라운드-로빈 방식으로 분산해요. 예를 들어 16드라이브 에라스처 셋에 EC:4 패리티를 4개 가용 영역에 설정하면, Operator는 각 영역이 에라스처 셋의 드라이브를 갖도록 보장해요. 그 결과 존 단위 장애로부터 보호받을 수 있어요.

에라스처 패리티와 저장 효율

배포의 패리티 설정은 가용성과 사용 가능한 총 저장 공간 사이의 균형이에요. 패리티가 높을수록 드라이브/노드 장애에 대한 복원력은 커지지만 사용 가능한 저장 공간은 줄고, 낮을수록 저장 공간은 최대가 되지만 드라이브/노드 장애 허용도는 떨어져요.

아래 표는 1노드 16개 1TB 드라이브 배포에서 에라스처 패리티 수준을 바꿨을 때의 결과예요.

패리티 총 저장 공간 저장 비율 읽기 최소 드라이브 쓰기 최소 드라이브
EC: 4 (기본) 12 Tebibytes 0.750 12 12
EC: 6 10 Tebibytes 0.625 10 10
EC: 8 8 Tebibytes 0.500 8 9

객체의 에라스처 저장 요약

AIStor 클라이언트는 객체와 그 모든 샤드(일명 "parts")의 현재 상태를 에라스처 셋 전체에 걸쳐 요약해 줘요. mc admin object info로 객체와 각 샤드의 상태를 확인할 수 있는데, 다음을 포함해요.

  • 파트 번호 (Part number)
  • 풀 번호 (Pool number)
  • 노드 (Node)
  • 에라스처 셋 (Erasure set)
  • 드라이브 (Drive)
  • 파일명 (Filename)
  • 크기 (Size)

더 알아보기