MinIO 도입기 - HA 이해와 DR 전략 수립

ML 학습부터 서빙까지 쓰는 중요 데이터를 Ceph에서 분리해 MinIO 기반 Object Storage로 옮겼다. 대상은 학습 데이터셋(DVC), 모델 lineage(MLflow artifact storage), 서빙용 모델 가중치(MLflow model registry), CI/CD용 테스트 데이터(S3)였고, 공통 접근 프로토콜과 확장성을 이유로 분산 MinIO를 선택했다.

장애 대응을 위해 드라이브 장애, 노드 장애, IDC 레벨 장애를 별도 레벨로 정의하고, 서비스별 read/write 순단 허용 수준에 따라 DR 전략을 나눴다. 서비스 영향성이 중간 이하이고 데이터가 자주 바뀌지 않는 특성을 반영해, 최종적으로 Backup & Recovery를 기본 전략으로 채택했고 RPO는 최악의 경우 7 days로 잡았다.

백업 방식은 volume snapshot보다 원본 데이터 백업을 선호했다. distributed storage는 복구 시점의 state(서버 수, 용량 등)를 정확히 맞춰야 하고, snapshot 중 write 처리나 lock 같은 동작이 프레임워크에 의존적일 수 있어 복구 복잡도가 높다고 봤다.

검증 단계에서는 MinIO의 Erasure Coding과 Failover를 직접 확인했다. 4대 서버에 2 data block + 2 parity block으로 저장해 테스트했고, MinIO 문서 기준처럼 전체 디스크 수가 N일 때 N/2 이상이 살아 있으면 read가 가능하고, N/2 + 1이 있어야 새 object write가 가능하다는 점을 실험으로 확인했다.

서버 장애 테스트에서는 1~3대 failure 상황을 가정해 데이터 접근성과 정합성을 점검했다. 3대 장애가 나면 2대만 살아 있는 상태로는 read operation이 불가능했고, 대시보드 접속도 write를 유발해 2대 이상 장애 시 불가했다. 반대로 2대 장애 뒤 재기동하면, 3대 이상 정상 상태로 복구해야 다시 접근할 수 있었다.

드라이브 failover 테스트에서는 Pod와 PVC를 삭제한 뒤 재배포해 자동 복구 흐름을 확인했다. mc admin heal이 백그라운드로 동작하면서 읽기와 쓰기를 유지한 채 데이터를 복구했고, MinIO의 복구 메커니즘이 실제로 유효하다는 점을 검증했다. 다만 N/2 이상 실패하거나 손상이 크면 MinIO만으로는 복구가 불가능하므로, 그 경우에는 전체 리소스를 재배포한 뒤 백업 데이터로 복원해야 한다.

확장성도 함께 점검했다. Scale Up은 StatefulSet을 orphan으로 제거한 뒤 PVC 용량을 늘리고 rollout하면 되었고, 30GB 파일 복사 중에도 read/write 순단 없이 확장됐다. 반면 Scale Out은 server pool 증설 방식이라 테스트 중 read/write 순단이 발생했으며, MinIO가 pool 간 자동 리밸런싱을 제공하지 않는다는 점도 확인했다.