MinIO 도입기— HA 이해 및 DR 전략 구성

네이버 G플레이스AI개발 팀에서는 ML 학습과 모델 서빙 과정에서 필요한 데이터 아카이빙을 위한 스토리지로 MinIO를 운영하고 있습니다. MinIO 도입을 위한 실험과, 백업/복구 시스템 구축 내용을 공유합니다.

업무 진행 배경

1 — 중요도 높은 데이터 아카이빙

• G플레이스AI개발 팀에서는 AI 모델 학습부터 모델 서빙까지 머신러닝 과제의 전체 프로세스에서 필요한 학습 및 테스트 데이터, 모델 아티팩트 등을 모두 ceph 저장소에 저장하고 있었습니다.
• 용도별로 버킷을 분리하고, 데이터가 필요한 K8s Pod에 Ceph bucket을 file system 형태(cephfs)로 마운트해 데이터에 접근하였습니다.
• cephfs의 사용성에 맞지 않게 사용하는 세션(pod) 수가 과도하게 많아져 Cephfs의 장애를 유발하였고, 모델 서빙 환경에서 필요한 파일에 접근하지 못해 서비스 장애로 이어지는 이슈가 있었습니다.
• 데이터 유실을 허용할 수 없는 수준의 중요도가 높은 데이터에 대한 관리가 필요한 상황이었습니다. 이러한 데이터는 아카이빙을 진행하고, 데이터가 필요한 시점에 데이터를 받아오는 방식으로 접근 방식을 변경하기로 결정하습니다.
• 이를 위해, 데이터 아카이빙을 위한 스토리지를 결정하고, 해당 스토리지의 장애 상황에 대한 강건성을 파악하고, 데이터 유실 상황에 대한 대비가 필요했습니다.

2 — 중요도 높은 데이터 정의

• 학습 관련 데이터셋(Train, Valid, Test): dvc
• Model lineage: mlflow artifact storage
• 서빙 관련 데이터셋(Model Weight): mlflow model registry
• CI/CD 관련 데이터셋(testset for Continuous Testing): s3

3 — MinIO를 활용한 분산 S3 Object Storage 구축

• G플레이스AI개발 팀에서는 머신러닝 과제의 전체 프로세스에서 아카이빙이 필요한 데이터를 정의하고, 이를 관리하기 위한 툴을 도입하는 과정에 있었습니다.
• 데이터 접근 인터페이스를 공통적으로 맞추고자 공통된 스토리지를 결정하고자 하였습니다. dvc, mlflow 툴에서 공통으로 지원하는 프로토콜을 고려하였습니다. 또한 팀원들이 동시 접근가능하고, 확장성이 높은 Object Storage를 사용하기로 결정하였습니다.
• 이전에 팀 내에서 구축했던 경험이 있는 Distributed MinIO 서버를 구성하여 테스트를 진행하였습니다.

Naver k8s platform n2c에 Distributed MinIO 서버를 구축하였고, cephrbd pvc를 statefulset pod에서 마운트해 구축하였습니다.

문제 정의

• 중요 데이터를 MinIO 스토리지에 저장하고, k8s 환경에서 MinIO 스토리지를 운영하기로 결정한 상황
• 스토리지 운영에서 발생 가능한 장애 상황 대비를 위한, MinIO 스토리지의 HA, Failover 이해의 필요성
• 최악의 상황은 데이터 유실이며, 이를 방지하기 위한 백업의 필요성

문제 해결 원칙 4가지

1 — 대비하고자 하는 장애 레벨 정의

장애 레벨:
1. 드라이브 장애
2. 노드 장애
3. IDC 레벨 장애

• k8s 환경에서 MinIO 스토리지를 운영하면서 발생할 수 있는 장애 레벨을 정의하고, 각 장애 상황에 따른 대응 방법을 메뉴얼화하고자 하였습니다.
• 특히 스토리지 운영에서 발생할 수 있는 드라이브 장애 / 노드 장애 상황 시나리오에 대해 고민하고 대비하고자 하였습니다.
• 클러스터 레벨에서의 장애는 MinIO를 구축할 때 연계한 사내 외장 블록 스토리지 Cephrbd 및 백업 대상 스토리지 hdfs의 데이터 IDC 이중화를 고려하고 싶었습니다.

2 — 데이터 유실 최소화

• 최악의 상황은 데이터 유실이며, 데이터 유실을 최소화하는 방안을 고민하였습니다.
• MinIO 자체 Failover 기능을 이용하는 방법과, 데이터 센터 레벨에서 장애 상황에 대비해 Disaster Recovery 플랜을 실행하는 방법을 고려하였습니다.
• 특히 데이터에 접근하는 서비스의 특성을 고려해 서비스 영향성을 정의하고, 이에 따라 데이터 유실을 방지하고 복구 시간을 최적화하고자 하였습니다.

3 — 서비스 영향성에 따른 DR 플랜 설정

DR 전략은 크게 4가지로 분류됩니다. 스토리지에 접근하는 서비스에 따라 서비스 영향성을 정의하고, 이에 따른 DR 전략을 선택하고자 했습니다.

DR 전략:
1. Back up & Recovery — (RPO/RTO: Hours or Days)
2. Pilot Light — (RTO: Over 10 Minutes)
3. Warm Standby— (RTO: Minutes)
4. Multi-site active/active*— (RTO: Real-Time)

운영 시스템에서 장애 발생 시 복구의 기준이 되는 수치인 RTO(Recovery Time Objective, 복구 목표 시점)와 RPO(Recovery Point Objective, 복구 목표 시간)

데이터에 접근하는 서비스의 read/write operation 순단 허용 수준에 따라 서비스 영향성을 3가지 기준으로 잡았습니다.

• 서비스 영향성 분류:

• 영향성이 중간인 케이스에는 multi cluster 구축(distributed minio cluster 별 분산 2 / 2)을 진행하면, IDC 레벨 장애가 발생하더라도 Read Operation에 영향을 주지 않습니다. 이 케이스에도 데이터 손실에 대비하기 위해 Backup & Recovery 전략을 사용하기로 결정하였습니다.

위 기준을 바탕으로 아카이빙 데이터에 접근하는 서비스와 서비스의 영향성에 대해 정리했습니다.

• 아카이빙 데이터에 접근하는 서비스와 서비스 영향성 분류:

• 현재 스토리지에 접근하는 서비스의 영향성이 모두 중간 이하로 분류된 점을 참고하여, Backup & Recovery 전략을 사용하기로 결정하였습니다.
• 아카이빙 데이터가 자주 업데이트 되지 않는 데이터입니다. 이 점을 참고해서 RPO는 최악의 경우 7 days로 공통적으로 설정하였습니다.
• 또한 서비스 영향성 정도에 따라 Backup & Recovery의 우선순위를 부여해 영향성이 높은 서비스에 대한 RTO를 줄이는 방향을 고려하였습니다. (ex| 서빙, CI/CD)

4 — 백업 데이터(볼륨 vs 원본)

• 스토리지를 백업하는 방법에 대한 리서치를 진행했을 때, 여러 가지 방안이 존재했습니다.
• 대표적으로 k8s volume snapshot을 백업하는 방법과, block storage 볼륨을 백업하는 방법 그리고 가장 쉬운 방법인 데이터를 복제하는 방법이 존재했습니다.
• 볼륨을 백업하는 방법에서 distributed storage에서는 백업 당시 State(server 개수, 용량 등)를 어딘가에 기록하고 그대로 복구해야한다는 점이 우려스러웠습니다. State 기록이 없어지거나 잘 관리되지 못한다면, 데이터 복구가 어려울 수 있다는 판단을 했습니다.
• OS와 볼륨이 바라보는 수준을 넘어서 외부에서 볼륨을 카피할 때 생길 수 있는 문제에 대해 알기 어렵고(write 중간에 snapshot을 허용하는지, lock 등), 프레임워크나 툴에 의존적으로 진행하거나 자체적인 테스트가 추가로 필요하다고 판단하였습니다.
• 따라서 볼륨에 대한 카피보다 원본 데이터를 백업하는 방향성을 고려하였습니다.

문제 구체화

검증

• MinIO 스토리지의 HA, Failover 정책에 대해 이해한다.
• 스토리지 운영에서 발생할 수 있는 드라이브 장애 / 노드 장애 상황 시나리오에 대해 고민하고 대비한다.
• 클러스터 레벨에서의 장애를 대비해 데이터 IDC 이중화를 고려한다.

구현

• 아카이빙 데이터에 접근하는 서비스 별 영향성 정도에 따라 Backup & Recovery의 우선순위를 부여해 RTO를 조절한다.
• 원본 데이터를 백업한다.

결과물

• k8s 환경에서 MinIO 스토리지를 운영하면서 발생할 수 있는 장애 레벨을 정의하고, 각 장애 상황에 따른 대응 방법을 메뉴얼화한다.

검증을 철저히

MinIO 스토리지의 HA에 대해 검증하기 위해 MinIO의 데이터 복원 기술인 Erasure Coding를 이해하고, Failure 시나리오를 세우고 Failover 기능을 점검하였습니다.

0 — Erasure Coding of MinIO

• `Erasure Coding` : 데이터 손실 시 미리 준비된 별도의 데이터(패리티)로 복구하는 기술
• Object를 데이터 블록과 패리티 블록으로 분할해서 저장하며, 패리티 블록은 데이터 손상이나 누락이 있을 때 데이터 블록의 재구성을 지원합니다.
• 데이터를 인코딩하고, 데이터가 손실되면 디코딩을 통해 원본데이터를 복제하는 기법입니다.

참고:
https://blog.min.io/erasure-coding/
https://tech.gluesys.com/blog/2020/07/22/storage_6_intro.html
https://blog.naver.com/redhattt/221386458958

1 — 고가용성(HA) 점검을 위한 MinIO 구축

HA 테스트를 위해 4개의 서버로 구성된 Distributed MinIO를 구축하였습니다. 사내 외장 블록 스토리지 Cephrbd PVC를 생성하고 이를 각각의 서버에 마운트해 파일 시스템처럼 사용할 수 있습니다.

4대의 서버에서 Object를 2개의 Data Block과 2개의 Parity Block으로 분할해 저장합니다.

erasure-code-cacluator를 이용하면 용량 효율성과 Drive / Server Failure Tolerance 정보에 대해 확인할 수 있습니다.

MinIO에서는 N개의 디스크를 가질 때, (N/2+1)개의 디스크를 사용할 수 있는 상황이라면 계속해서 읽기와 쓰기가 가능하다고 안내하고 있습니다. (N/2)개의 디스크를 사용할 수 있는 상황이라면 읽기가 가능합니다.

A stand-alone MinIO server would go down if the server hosting the disks goes offline. In contrast, a distributed MinIO setup with n disks will have your data safe as long as n/2 or more disks are online. You’ll need a minimum of (n/2 + 1) Quorum disks to create new objects though.
출처: https://docs.min.io/docs/distributed-minio-quickstart-guide.html

MinIO에서 안내한 수준으로 데이터 접근이 가능한지 테스트를 진행하였습니다. 이 과정에서 데이터 접근 뿐만 아니라, 데이터의 정합성이 깨지는지 테스트하였습니다. 또한 Failover 기능이 어떻게 동작하는지 확인하였습니다.

• 서버 failure 상황에서의 데이터 접근 테스트 / 데이터 정합성 테스
• failover 동작 테스트

2 — 고가용성(HA) 점검: 서버 failure

k8s 환경에서 스토리지 운영하면서 발생할 수 있는 서버 failure 시나리오는 아래의 상황이 존재합니다. Cephrbd PVC는 보존되어 있는 상황을 가정합니다.

“서버 재배포 중 리소스가 부족해 minio server가 띄워지지 않는 상황”

“k8s node에 문제가 생겨 minio server가 재시작(rescheduleing)되는 상황”

이러한 상황을 가정하고, 총 4대의 서버 중 1–3대가 failure가 발생했을 때 데이터 접근이 가능한지 테스트를 진행하였습니다. 이 과정에서 데이터 접근 뿐만 아니라, 데이터의 정합성이 깨지는지 테스트하였습니다.

데이터 정합성 체크 방법은 50GB 파일을 저장해두고, 장애 상황에서 read 하여 파일 비교하는 방법으로 수행하였습니다.

• 3대 장애 발생 상황에서, 1대가 재시작되어 총 2대가 running 상태로 변경되더라도 read operation 수행 불가능. 즉, 서버 장애 발생 시 3대 이상 정상 상태로 복구해야 한다.
• 대시보드 접속할 때 write operation이 수행되며 2대이상 장애 시 접속 불가능

결과를 요약하자면, MinIO 문서에서 안내되어 있는대로 동작하는 것을 확인하였습니다. 테스트 환경 구성에서 2대 서버가 장애 상황이라면 read operation은 수행 가능하지만, write operation은 수행이 불가능하다는 점을 직접 확인했습니다.

테스트를 진행하면서 발견한 특이사항은 서버 3대 이상 장애가 발생했다면, 3대 이상 정상 상태로 복구한 뒤 데이터에 접근 가능하다는 점입니다. 또한 대시보드에 접속할 때 write operation이 수행되기 때문에 2대 이상 장애 발생 시 접속이 불가능 하다는 점을 발견했습니다.

2 — 고가용성(HA) 점검: 드라이브 failover

운영하면서 발생할 수 있는 드라이브 failover 시나리오는 아래의 상황이 존재합니다. 이때 Cephrbd PVC를 삭제하는 상황을 가정합니다. k8s PVC로 데이터의 영구 보존이 가능하기 때문에 운영하면서 발생할 상황에 대해 특정하기는 어려웠지만, PVC를 지워야 하는 상황이 생길 가능성을 염두해 위의 상황을 가정하였습니다.

“스토리지 시스템에 문제가 생겨, PVC의 일부 데이터가 손상된 상황”

“PVC가 영구적으로 손상된 경우”

총 4대의 서버 중 1–3대가 failure가 발생했을 때, K8s Pod, PVC를 삭제하고 재배포한 상황의 failover 동작에 대해 테스트를 진행하였습니다. 재배포 시 새로운 PVC가 Dynamic provisioning으로 생성됩니다.

아래는 2대 드라이브 failure 상태에서 Pod, PVC를 모두 삭제한 상황입니다.

그 후 Pod를 재배포 하였고, `mc admin heal minio-dest — verbose` 명령을 통해 서버의 상태를 확인할 수 있습니다. 재배포한 서버 두 대에서 HEALING 상태임을 확인 가능합니다.

추가적인 명령 실행 없이, MinIO에서 자동으로 데이터를 복구하고 있었습니다. 드라이브 실패 혹은 데이터 손상이 발생했을 때 MinIO에서 mc-admin-heal 명령을 통해 데이터를 복구합니다. background로 실행되는 작업으로 해당 작업이 수행될 때 읽기 및 쓰기 작업을 수행할 수 있습니다.

결론적으로 MinIO의 Failover 기능은 강력했습니다. 내부적으로 mc-admin-heal 명령을 통해 자동으로 데이터를 복구하며, 드라이브 개수(N)/2 개수 만큼의 드라이브가 실패했을 때 데이터 복구가 가능하다는 점을 확인하였습니다. M대 이상의 드라이브가 실패하거나 데이터 손상이 발생했을 때, MinIO에서 제공하는 Failover 기능으로는 데이터 복구가 불가능합니다. 따라서, 배포된 모든 리소스를 삭제하고 재배포 한 뒤, 백업해둔 데이터를 이용해 복구해야 합니다.

3 — 확장성 점검: Scale Up, Scale Out

추가적으로, MinIO에 할당된 드라이브 사용량이 지속적으로 증가하는 경우를 대비하고자 확장성을 점검하였습니다. 특히 AI 모델 학습의 artifacts를 저장하는 용도로 사용할 때 실험이 추가될수록 데이터가 누적되는 구조이기 때문에 확장성 점검이 필요했습니다. Scale Up과 Scale Out이 자유롭게 되는지 점검하였으며, Scale Up/Out 과정에서 Read/Write 작업의 순단이 발생하는지 확인하였습니다.

Scale Up 진행 절차는 다음과 같습니다:

1. StatefulSet 리소스를 orphan으로 제거합니다.
2. PVC의 저장소 리소스를 조절합니다.
3. Pod를 재배포하기 위해 rollout을 실행합니다.

아래는 30GB 용량의 파일을 복사 중인 상황에서 Scale Up 절차를 수행한 결과입니다. minio-source에서 minio-dest로 파일을 복사하는 상황이며, minio-dest로 설정된 MinIO 서버의 Scale Up을 진행했습니다. 그 결과 순단 없이 데이터 쓰기가 가능함을 확인하였습니다.

또한 30GB 용량의 파일을 다른 클라이언트로 복사하는 상황(Read)에서의 Scale Up 수행한 결과, 데이터 읽기 접근에 대한 순단이 발생하지 않았습니다. 즉, 데이터 읽기/쓰기 접근에 대한 문제 없이 Scale Up이 가능하다는 것을 확인하였습니다.

Scale Out의 진행 절차는 다음과 같습니다:

1. helm values의 statefulset zone을 늘립니다.
2. StatefulSet 리소스를 orphan으로 제거합니다.
3. helm release를 반영합니다.

MinIO에서 지원하는 Scale Out 방식은 Server Pool을 증설하는 방식입니다. 이 방식은 각각 자신만의 Failure Domain을 가지고 있습니다. MinIO에서는 하나의 Server Pool 내에서 Erasure Set을 계산합니다. MinIO는 새로운 server pool로의 데이터 리밸런싱을 자동으로 제공하지 않습니다. 대신, 가장 여유 스토리지가 많은 Pool에 새로운 쓰기 작업을 수행합니다.

https://min.io/docs/minio/linux/operations/install-deploy-manage/expand-minio-deployment.html

minio:
 statefulset:
 zones: 2

bitnami helm charts 레포지토리의 minio helm template을 베이스로 이용하고 있습니다.

Scale Out 데이터 읽기/쓰기 실험은 Scale Up과 동일하게 진행하였고, 결과는 데이터 접근에 순단이 발생하였습니다.

동작을 확인해보니, zone 2에 해당하는 모든 서버가 동시에 배포되며, 배포가 완료된 후 zone 1 내 존재하는 모든 파드가 역순으로 재시작됩니다. 0번째 MinIO 서버 파드에 토폴로지가 업데이트 되기 전까지 순단이 발생하는 것을 확인하였습니다. 즉, Scale Out 요청 후 파드가 모두 재배포되는 되기까지 걸린 시간만큼 데이터 접근이 불가능합니다. 현재 구조에서 10분 정도의 순단이 발생하며, 클라이언트에서 순단에 대한 방어 로직을 작성해 대응하였습니다.

4 — 백업 대상 스토리지, Minio PVC 스토리지 IDC 이중화 고려

클러스터 레벨에서의 장애는 MinIO를 구축할 때 연계한 사내 외장 블록 스토리지 Cephrbd와 백업 대상 스토리지 hdfs의 IDC 이중화를 고려하고자 하였습니다.

데이터 IDC 이중화를 위해 다른 IDC에 데이터를 백업하고자 하였습니다. 백업을 위한 스토리지를 추가로 운영하는 리소스에 대한 부담이 있었습니다. G플레이스AI개발 팀에서는 Data Engineering과 Feature Engineering 용도로 hdfs를 사용 중이었고, 사내 호환 스토리지이며 별도의 운영 리소스가 요구되지 않는 사내 hdfs를 백업 대상 스토리지로 선택하였습니다.

운영중인 MinIO 및 사내 외장 블록 스토리지(Cephrbd)와 다른 IDC에 위치한 백업 대상 스토리지 hdfs에 백업합니다. hdfs에 데이터를 백업한다면, IDC 레벨 장애 시 hdfs에 백업된 데이터를 가용한 다른 IDC에 복제해 복구하는 방안을 세울 수 있습니다.

구축 내역

MinIO 스토리지의 HA에 대해 이해하고, 장애 상황에서 데이터 복구를 위한 Failover 기능 검증을 진행했습니다. 그 결과, 대비하고자 했던 장애 레벨 중 드라이브 / 노드 장애 시나리오에 대해 대비가 가능하다는 것을 검증하였습니다. 추가적으로 위 검증에서 데이터 유실이 발생할 수 있는 상황과, 클러스터 레벨에서의 장애를 대비해 데이터 Backup & Restore 시스템을 구축하고자 하였습니다.

0 — 아키텍처

최종적으로 아래와 같은 아키텍처를 구성해 Backup & Restore를 수행하기로 결정하였습니다. MinIO는 S3 API를 지원합니다. Hadoop-AWS 모듈을 이용해 Hadoop 클러스터 내부에서 S3와 직접 통신할 수 있습니다. hdfs distcp 명령을 수행해 데이터를 S3에서 HDFS로, HDFS에서 S3로 복제할 수 있습니다. distcp는 기본적으로 MapReduce 기능으로 복사를 수행하기 때문에, 병렬적으로 데이터를 복사하고 저장할 수 있습니다.

Backup는 팀 내 구축되어 있는 Airflow에서 스케줄링 기능을 이용하여 주기적으로 백업을 실행하는 구조로 정했습니다. 데이터는 HDFS distcp 명령으로 MinIO에서 HDFS로 복제하도록 구성하였습니다. 이때 `distcp udate` 옵션을 사용하여 변경된 데이터만 가져올 수 있도록 구성하였습니다. 따라서 데이터 백업 시간을 단축할 수 있습니다.

Restore 기능도 Airflow Dag로 구성하여, 복구가 필요한 버킷 대상으로 수동 스케줄링할 수 있는 구조로 정했습니다. 데이터 복구는 Backup과 동일한 방법인 hdfs distcp 명령을 수행하도록 구성했습니다.

hadoop distcp \
 $6 \
 -Dmapred.job.queue.name=batch \
 -D fs.s3a.path.style.access=true \
 -D fs.s3a.endpoint=$1 \
 -D fs.s3a.access.key=$2 \
 -D fs.s3a.secret.key=$3 \
 -update -i -m 10 -bandwidth 100 \
 $4 $5

1 — 구현 세부사항

서비스 레벨 관리 방법을 차용해 영향도가 높은 서비스를 사전에 정의하고, 장애 발생 상황에서 데이터 복구의 우선순위를 두고자 하였습니다. 아래는 구현 세부사항입니다.

• 버킷 단위로 백업 Task 실행
• 서버-버킷 단위 영향성 정의
  — Server / Bucket 단위 영향성(높음, 중간, 낮음) 정의
  — 영향성 수준에 따라 Backup & Restore의 우선순위를 부여
  — 영향성이 높은 서비스에 대한 RTO를 줄이는 방향 (ex| 서빙, CI/CD)
• 서버 단위로 pool 지정
  — 서버에 한번에 영향을 줄 수 있는 트래픽 조정 목적
  — airflow pool 이용
• 버킷 단위로 priority 지정
  — 풀 내에서 백업/리스토어 우선순위 조정 목적
  — airflow priority 이용

# 서비스/버킷 단위 SLA 수준 명세
minio_backup_service_list = [
    {
        "name": "minio-artifact", # Server 명
        "endpoint_url_format": default_minio_endpoint_url_format,
    ...
        "bucket_list": [
            {
                "name": "pai-artifacts", # Bucket 명
                "priority": BucketPriority.MEDIUM.value, # 우선순위
            },
            {
                "name": "test",
                "priority": BucketPriority.LOW.value,
            },
        ],
        "pool": {
            "name": "minio_artifact_pool",
            "pool_size": default_airflow_task_pool_size,
        },
    },
  {...}
]

2 — 결과

Backup, Restore 를 수행하는 Airflow DAG를 구성하였습니다.

Backup Dag의 실행 예시입니다.

서버-버킷 단위로 Backup을 수행할 Task instance를 생성합니다. 이때, 서버 단위로 생성할 수 있는 Task instance pool 수를 제한하였기 때문에, 2개의 태스크 인스턴스가 실행됩니다. 서버-버킷 단위로 우선순위를 부여하였기 때문에, 가용한 Pool 내에서 우선순위가 높은 태스크가 먼저 실행됩니다.

Restore Dag의 실행 예시입니다.

복구가 필요한 버킷만 복구할 수 있도록, 기본적으로 모든 태스크를 skipped 상태로 세팅하였습니다. 복구가 필요한 버킷은 수동으로 run 버튼을 클릭하면 실행됩니다.

3 — 성능 측정

구현한 Backup & Restore 기능이 서비스 별 정의한 RTO/RPO를 만족하는지 여부를 성능 측정을 통해 검증하였습니다. HDFS distcp 소스와 대상 클러스터가 위치한 IDC가 다르기 때문에 복사할때 트래픽관리를 해야합니다. HDFS distcp 수행 시 map 개수를 10 이하, bandwidth를 100MB/sec으로 제한했습니다. 성능 측정 결과, 1TB 데이터를 복사하는 과정은 대략 3시간 소요되었습니다.

• BackUp & Restore 성능 측정

4 — DR objectives

성능 측정을 바탕으로 서비스 별 정의한 RTO/RPO를 만족하는지 확인하였습니다. 자주 업데이트 되지 않는 아카이빙 데이터를 백업하는 것이 주 목적이기 때문에, RPO는 최악의 경우 7 days로 공통적으로 설정했습니다.

Backup의 경우 초기 백업에 소요되는 시간이 깁니다. 백업 대상 버킷 중 최대 용량인 17TB 데이터를 백업한다고 가정했을 때, 51시간이 소요됩니다. 현재는 7일마다 백업하므로 RPO 7일을 만족합니다. 초기 백업 이후에는 증분 업데이트를 진행하기 때문에 매일 백업 가능하며, RPO 1일 이내 축소 가능합니다.

Restore의 경우에도 위와 마찬가지로 3일이 소요됩니다. 버킷 용량이 커질수록 RTO는 증가합니다. 따라서 버킷을 사용 서비스와 서비스 영향도에 따라 분리한다면 RTO를 줄일 수 있습니다.

따라서 초기 서비스 별 정의한 RTO/RPO를 만족하는 것을 확인하였습니다.

장애 상황에 따른 대응 방법 메뉴얼

k8s 환경에서 MinIO 스토리지를 운영하면서 발생할 수 있는 장애 레벨을 정의하고, 각 장애 상황에 따른 대응 방법을 메뉴얼하였습니다.

0 — node 수준 장애

• 장애 pod 재시작
  — Volume은 삭제하지 않고, 장애 서버만 재시작합니다.
• 중단 시간
  — (N/2)대 미만 장애 발생 시 중단 시간 없음
  — (N/2)대 장애 발생 시 write 작업 중단 발생: 5분 이내로 예상(alert 후에 pod 재시작)
  — (N/2+1)대 이상 장애 발생 시 write/read 작업 중단 발생: 5분 이내로 예상(alert 후에 pod 재시작)

### 1 — drive 수준 장애

• (N/2)대 이하 장애
  — 장애가 발생한 Volume을 삭제하고, Pod를 재시작합니다.
• (N/2+1)대 이상 장애
  — Minio helm release 삭제 후 재배포합니다.
  — 이 경우 Backup & Restore 방식으로 데이터 복구를 진행합니다.
• 중단 시간
  — (N/2)대 미만 장애 발생 시 중단 시간 없음: 재시작된 pod의 드라이브가 복구되는 시간은 환경에 따라 다를 수 있습니다. (ex| 68 Mib/s)
  — (N/2)대 장애 발생 시 write 작업 중단 발생 (1TB 복구 시간 28초 예상): 재시작된 pod의 드라이브가 복구되는 시간은 환경에 따라 다를 수 있습니다. (ex| 34 MiB/s)
  — (N/2+1)대 이상 장애 발생 시 write/read 작업 중단 발생 (RTO: 3days)

2 — IDC 수준 장애

• 대응
  — 가용한 IDC에 Minio Server를 배포합니다.
  — Backup & Restore 방식으로 데이터 복구를 진행합니다.
• 중단 시간
  — HDFS → Minio 데이터 복제 완료 시점 (RTO: 3 days 이하)

Backup / Restore를 사용하는 케이스 정리

• (N/2+1)대 이상 Drive 수준 장애(Cephrbd)가 발생한 케이스
• MinIO 재배포가 안되는 케이스
  — minio port 변경하여 재배포를 하려고 했으나, 기존 volume에 있는 정보와 충돌하여 배포가 진행되지 않는 케이스가 있었습니다. 이런 케이스에는 helm, pvc를 삭제하고, 배포한 이후에 restore를 수행해야 합니다.
• 중요한 데이터가 유실된 케이스
  — K8s 환경에서 스토리지를 운영하면서 휴먼 에러 등의 특수한 상황*에서 데이터가 유실될 수 있습니다.
  — 특수한 상황으로 실수로 인해 Bucket 삭제, Data Migration 과정에서 데이터 유실을 고려하였습니다.
  — 이러한 경우 Restore Dag를 실행하여 데이터를 복구할 수 있습니다.
• IDC 레벨의 장애가 발생한 케이스(DR)

맺으며…

문제를 해결하는 과정에서 진행했던 고민과 의사결정에서 배울점이 많았던 프로젝트로 기억에 남습니다. 작성했던 코드라인이 많지 않지만, 스토리지를 운영하기 위한 검증 과정을 통해 기술적인 내용을 심도있게 탐구해본 좋은 경험이었습니다. 추후 과제를 어떤 프로세스로 과제를 수행해야 하는지에 대한 배움을 얻었습니다.

추가로 RTO와 RPO를 줄이는 방법에 대한 고민도 더 필요하며, Backup & Restore 이외에 다른 DR 플랜도 도입이 필요한 시점이 생길 것으로 예상됩니다. 그 시점에 이렇게 깊이 파고들었던 경험이 도움이 되면 좋겠습니다. 👍