26J05a
아래 방향을 권장합니다.
결론부터 말하면, Warm Tier는 기존 128노드 NVMe Hot AIStor ObjectStore에 pool로 붙이지 말고, 별도 AIStor ObjectStore로 구성하는 것이 좋습니다. 가능하면 별도 Kubernetes 클러스터, 최소한 같은 K8s 안이라도 별도 namespace / 별도 ObjectStore / 전용 노드 / 전용 DirectPV / 별도 S3 endpoint로 분리하는 편이 안전합니다.
1. 전체 권장 아키텍처
권장 구조는 다음과 같습니다.
[Application / Spark / Trino / Airflow / User]
|
| 기본 S3 endpoint
v
+---------------------------------------------------+
| Hot AIStor ObjectStore |
| - 128 NVMe nodes |
| - pool: 54 nodes + 74 nodes |
| - EC set=8, parity=3 |
| - 주요 업무 read/write endpoint |
| - bucket/prefix별 ILM, versioning, replication rule |
+---------------------------------------------------+
| |
| ILM Transition | Bucket Replication
| older / noncurrent object | critical bucket/prefix only
v v
+---------------------------------------------------+
| Warm AIStor ObjectStore |
| - 별도 AIStor deployment 권장 |
| - 가능하면 별도 Kubernetes cluster |
| - SATA/SAS SSD 재활용 장비 |
| - pool1: 7TiB x 20disk x 19node |
| - pool2: 3.5TiB x 20disk x 14node |
| - pool3: 3.5TiB x 10disk x 5node |
| - 향후 pool4: 3.5TiB x 20disk x 130node |
| |
| buckets: |
| 1) tier-hot-prod : ILM remote tier 전용 |
| 2) repl-critical-prod : 중요 데이터 복제 전용 |
+---------------------------------------------------+핵심은 Hot은 사용자와 분석 워크로드가 바라보는 주 endpoint로 유지하고, Warm은 Hot의 lifecycle target / replication target으로만 쓰는 것입니다. 이렇게 해야 Warm 장비의 성능 저하, 디스크 장애, node drain, 재활용 장비 이슈가 Hot의 read/write 경로로 직접 들어오지 않습니다.
2. 기존 Hot ObjectStore에 Warm pool을 직접 추가하지 않는 이유
MinIO/AIStor는 서버 풀을 추가하여 확장할 수 있지만, 이번 목적의 Warm Tier에는 부적합합니다. 공식 문서상 서버 풀 하나가 완전히 손실되면 전체 pool의 I/O가 중단될 수 있고, 어떤 erasure set이 write quorum을 잃으면 해당 set의 데이터 손실로 이어질 수 있습니다. 또한 MinIO는 새 object를 여유공간 가중치 기반으로 pool에 배치하므로, NVMe Hot pool과 SATA/SAS Warm pool을 같은 ObjectStore에 섞으면 신규 쓰기가 Warm 쪽으로 들어갈 수 있습니다. 이는 “Hot/Warm 계층 분리”가 아니라 “성능이 다른 pool을 가진 하나의 클러스터”가 됩니다. (MinIO AIStor Documentation)
또한 MinIO는 같은 server pool 내 drive의 용량, 타입, 제조사, 모델을 맞추는 것을 강하게 권장하고, direct-attached JBOD와 XFS 사용을 권장합니다. 혼합 디스크와 이기종 pool은 성능 병목과 운영 복잡도를 키웁니다. (MinIO AIStor Documentation)
따라서 선택지는 아래처럼 정리됩니다.
| 선택지 | 판단 |
|---|---|
| 기존 Hot ObjectStore에 Warm pool 추가 | 비권장. Hot/Warm 분리 실패, 신규 쓰기 Warm 유입 가능, pool 장애 영향이 전체로 전파 가능 |
| 기존 K8s cluster에 별도 Warm ObjectStore 추가 | 가능. 단, 전용 노드, taint, namespace, DirectPV, endpoint, Secret 분리 필수 |
| 별도 K8s cluster에 Warm AIStor 구성 | 가장 권장. 장애, 업그레이드, 성능, lifecycle, 운영 리스크 격리 가능 |
3. 별도 Kubernetes 클러스터를 권장하는 이유
Warm Tier 장비가 SATA/SAS SSD 재활용 장비라면 Hot NVMe 장비보다 장애율, 성능 편차, firmware/drive 이슈 가능성이 높습니다. 이 장비를 기존 K8s cluster의 node로 넣으면 다음 위험이 생깁니다.
첫째, DirectPV, kubelet, containerd, CNI, kernel 튜닝, node drain 작업이 기존 Hot 운영 영역과 섞입니다. 둘째, Warm 쪽 장애 분석과 유지보수를 하다가 Hot node 운영 절차와 충돌할 수 있습니다. 셋째, Cilium, BGP, routing, MTU, host namespace, observability 설정도 같은 cluster control-plane에 의존하게 됩니다.
따라서 가능하면 다음처럼 나누는 게 좋습니다.
K8s-HOT cluster
- NVMe AIStor
- 분석 서비스와 직접 연결
- 엄격한 변경관리
- 높은 SLO
K8s-WARM cluster
- SATA/SAS AIStor
- Hot의 ILM target / replication target
- Hot보다 낮은 성능 SLO
- 디스크 교체, node 교체, pool 증설이 잦아도 Hot 영향 최소화단, 인프라 사정상 별도 K8s cluster가 어렵다면 같은 cluster 내에서라도 다음은 반드시 분리하는 것이 좋습니다.
namespace:
hot-aistor
warm-aistor
node group:
hot-storage-nodes
warm-storage-nodes
scheduling:
nodeSelector
taints/tolerations
topology spread
anti-affinity
storage:
directpv-hot
directpv-warm
network:
s3-hot.internal
s3-warm.internal
secret:
hot admin/operator secret
warm admin/operator secret
ILM tier credential
replication credentialAIStor Operator의 ObjectStore 구성은 pool 배열을 가지며, 각 pool은 독립적으로 수평 확장되는 구조입니다. 같은 K8s 안에 여러 ObjectStore를 운영할 수는 있지만, 이번 경우에는 “같은 ObjectStore에 pool 추가”가 아니라 “별도 ObjectStore”로 구성해야 합니다. (MinIO AIStor Documentation)
4. Warm Tier 용량 산정
현재 Hot은 다음 정도로 볼 수 있습니다.
Hot raw capacity
= 128 node x 20 disk x 6.8 TiB
= 17,408 TiB
≈ 17.0 PiB raw
EC set size = 8
parity = 3
data shard = 5
usable ratio = 5 / 8 = 62.5%
Hot usable
= 17,408 TiB x 0.625
= 10,880 TiB
≈ 10.63 PiBWarm 1차 장비는 말씀하신 숫자를 그대로 계산하면 아래와 같습니다. 다만 주의할 점은, “1차적으로 node 54개”라고 하셨지만 뒤에 나열된 장비 수는 19 + 14 + 5 = 38 node입니다. 아래 표는 명시된 38대 기준입니다.
| Warm pool 후보 | Raw 계산 | Raw | EC10:3 usable |
|---|---|---|---|
| 7TiB x 20disk x 19node | 7 x 20 x 19 | 2,660 TiB | 1,862 TiB |
| 3.5TiB x 20disk x 14node | 3.5 x 20 x 14 | 980 TiB | 686 TiB |
| 3.5TiB x 10disk x 5node | 3.5 x 10 x 5 | 175 TiB | 122.5 TiB |
| 명시된 38대 합계 | 3,815 TiB | 2,670.5 TiB ≈ 2.61 PiB |
향후 130노드 추가분은 다음과 같습니다.
130 node x 20 disk x 3.5 TiB = 9,100 TiB raw
EC10:3 usable = 9,100 x 0.7 = 6,370 TiB
≈ 6.22 PiB usable따라서 명시된 1차 38대 + 향후 130대만 보면 Warm 전체는 대략 다음입니다.
Warm raw ≈ 3,815 + 9,100 = 12,915 TiB ≈ 12.61 PiB
Warm usable with EC10:3 ≈ 9,040.5 TiB ≈ 8.83 PiBHot + Warm usable은 단순 합산 시 약 19.45PiB 수준입니다.
다만 versioning과 replication을 함께 쓰는 prefix는 Warm에서 공간을 두 번 쓸 수 있습니다. 예를 들어 어떤 중요 prefix에 대해 ILM transition도 하고 replication도 하면, Warm에는 다음 두 종류의 데이터가 생깁니다.
1) ILM tiering으로 내려간 backing object
2) replication으로 복제된 독립 object즉 “중요 데이터 일부”에 대해서는 Hot 절감 효과와 보호 효과를 동시에 얻는 대신 Warm 용량 소모가 커진다고 봐야 합니다.
5. Warm Pool 구성 원칙
5.1 pool은 최대한 동질 장비끼리 묶기
Warm 장비를 하나의 거대한 혼합 pool로 만들지 말고, 디스크 크기와 node당 disk 수 기준으로 pool을 나누는 편이 좋습니다.
warm-pool-a
- 7TiB x 20disk x 19node
warm-pool-b
- 3.5TiB x 20disk x 14node
warm-pool-c
- 3.5TiB x 10disk x 5node
warm-pool-d
- 3.5TiB x 20disk x 130node, 4개월 뒤 추가MinIO는 같은 pool 내 drive의 용량, 타입, 모델을 맞출 것을 권장합니다. 또 drive는 RAID/LVM/SAN/NAS가 아니라 direct-attached JBOD 형태로 제공하고, XFS 파일시스템을 사용하는 구성을 권장합니다. (MinIO AIStor Documentation)
5.2 5노드 x 10disk pool은 중요 데이터용으로 신중하게
3.5TiB x 10disk x 5node pool은 raw 175TiB로 작고 node 수도 5대뿐입니다. EC set size 10, parity 3이면 object 하나가 10개의 shard로 나뉘고, 이 중 7개 data shard + 3개 parity shard 구조가 됩니다. AIStor의 erasure set은 pool 초기화 시 결정되며 이후 변경할 수 없습니다. (MinIO AIStor Documentation)
문제는 5노드 구성에서는 erasure set의 shard가 node당 여러 개씩 들어갈 가능성이 높고, node 2대 장애만으로도 한 erasure set에서 parity 3개를 초과하는 shard 손실이 날 수 있다는 점입니다. 따라서 이 pool은 다음 중 하나로 처리하는 것이 좋습니다.
- 중요 데이터 ILM/replication 대상에서 제외
- 추가 동일 장비가 확보될 때까지 보류
- 별도 low-SLA Warm ObjectStore로 구성
- 임시/재생성 가능 데이터용으로만 사용
5.3 EC10:3은 용량 효율은 좋지만, 재활용 장비라면 EC10:4도 검토
현재 계획인 set size=10, parity=3은 usable 비율이 70%입니다.
EC10:3
data shard = 7
parity shard = 3
usable = 70%재활용 SATA/SAS SSD라면 장애율과 성능 편차가 있을 수 있으므로, 정말 중요한 Warm 복제 대상이나 장기 보관 대상에는 EC10:4도 검토할 만합니다.
EC10:4
data shard = 6
parity shard = 4
usable = 60%AIStor의 parity 설정은 storage class 형태로 관리되며, parity 변경은 새로 쓰이는 object에만 적용됩니다. 이미 저장된 object의 parity가 자동으로 바뀌지는 않습니다. (MinIO AIStor Documentation)
현실적인 권장은 다음입니다.
| 대상 | 권장 EC |
|---|---|
| 일반 Warm historical data | EC10:3 가능 |
| 재활용 장비 중 상태 편차가 큰 pool | EC10:4 검토 |
| 중요 replication 대상 | EC10:4 또는 별도 안정 pool 우선 |
| 5노드 x 10disk 소형 pool | 중요 데이터 비권장 |
6. ILM Tiering과 Replication의 역할 분리
여기서 가장 중요한 개념은 ILM tiering은 백업/DR이 아니라 Hot 공간 절감 기능이라는 점입니다.
AIStor의 object tiering은 primary tier와 secondary tier의 단일 계층 구조를 지원합니다. 즉 Hot에서 Warm으로 내리는 구조는 가능하지만, Warm에서 다시 Cold로 이어지는 다단계 cascade 구조는 기본 모델이 아닙니다. (MinIO AIStor Documentation)
또한 remote tier로 내려간 object는 Warm에 data body가 있고 Hot에는 metadata가 남는 구조로 이해해야 합니다. 공식 문서도 remote tier의 데이터가 source metadata와 강하게 연결되어 있으며, remote tier가 source metadata 손실을 복구하는 수단이 아니라고 설명합니다. 따라서 Warm tiering은 backup이나 DR로 보면 안 됩니다. (MinIO AIStor Documentation)
반면 bucket replication은 별도 bucket에 object와 version, metadata를 복제하는 방식이므로, 일부 중요 데이터에 대해 독립적인 사본을 만들 수 있습니다. AIStor bucket replication은 source와 destination bucket이 서로 다른 AIStor cluster에 있고 같은 Object Store version을 실행해야 하며, source와 destination bucket 모두 versioning이 필요합니다. (MinIO AIStor Documentation)
따라서 역할은 이렇게 나눠야 합니다.
| 기능 | 목적 | Warm 장애 시 영향 | Hot 공간 절감 | 독립 복구성 |
|---|---|---|---|---|
| ILM transition | Hot NVMe 공간 절감 | tiered object read 영향 | 있음 | 낮음 |
| Bucket replication | 중요 데이터 보호/복구 사본 | 복제 지연/실패 영향 | 없음 또는 제한적 | 높음 |
| ILM + replication 동시 적용 | 중요 데이터 보호 + Hot 절감 | Warm 용량 많이 사용 | 있음 | 높음 |
7. Warm 내부 bucket 설계
Warm ObjectStore에는 최소한 bucket을 분리하는 것을 권장합니다.
warm/tier-hot-prod
- ILM remote tier 전용 bucket
- 사용자가 직접 접근하지 않음
- lifecycle rule 설정 금지
- 외부 수정/삭제 금지
- Hot AIStor의 ILM tier credential만 접근
warm/repl-critical-prod
- 중요 데이터 bucket replication 전용
- versioning enabled
- 복구 관리자 또는 제한된 서비스만 접근
- ILM tier bucket과 절대 섞지 않음ILM remote tier bucket에는 외부에서 object를 수정하거나 삭제하면 안 되고, remote tier bucket 자체에 lifecycle rule을 걸지 않는 것이 좋습니다. 공식 문서도 remote storage에 외부 mutation/deletion을 하지 말고 lifecycle rule을 적용하지 말 것을 요구합니다. (MinIO AIStor Documentation)
따라서 아래처럼 혼합하면 안 됩니다.
비권장:
warm/common-bucket/
├── ilm-tiered-data/
└── replicated-data/권장은 아래입니다.
권장:
warm/tier-hot-prod/
└── hot-prod/
warm/repl-critical-prod/
└── lake-prod/특히 ILM tiering target과 replication target을 같은 bucket/prefix로 섞으면, 장애 분석, lifecycle 정책, 삭제 정책, 권한 분리, 복구 절차가 매우 어려워집니다.
8. Bucket / Prefix별 Data Lifecycle 정책
전체 데이터를 같은 lifecycle로 처리하면 안 됩니다. 최소한 아래 5개 등급으로 나누는 것이 좋습니다.
8.1 데이터 등급
| 등급 | 예시 | Versioning | ILM | Replication | 정책 |
|---|---|---|---|---|---|
HOT-ACTIVE | 최근 파티션, 자주 조회되는 gold/silver, table metadata, checkpoint | 제한적 | 없음 또는 늦게 | 보통 없음 | NVMe 유지 |
WARM-HISTORICAL | 오래된 raw/bronze/silver partition, 조회 빈도 낮은 이력 | 보통 off | 30/60/90일 후 Warm | 없음 | Hot 공간 절감 대상 |
VERSIONED-RECOVERY | 실수로 overwrite/delete 위험이 있는 업무 데이터 | on | current/noncurrent 모두 Warm 가능 | 선택 | noncurrent 보존기간 명확화 |
CRITICAL-REPL | 재생성 불가, 감사/정산/핵심 결과 데이터 | on | 가능 | 있음 | delete replication 정책 명확화 |
TEMP-DERIVED | temp, staging, cache, 재생성 가능 데이터 | off | 보통 없음 | 없음 | 7/14/30일 expire |
Versioning은 공간 절감 기능이 아닙니다. MinIO versioning은 object 변경 시 이전 version을 보존하며, differential/incremental 저장 방식이 아니기 때문에 mutation이 많은 workload에서는 저장공간을 크게 소모할 수 있습니다. 따라서 versioning은 필요한 bucket/prefix에만 켜고, noncurrent version 만료 정책을 반드시 같이 설계해야 합니다. (MinIO AIStor Documentation)
9. 권장 lifecycle 정책 예시
9.1 일반 이력 데이터: Hot → Warm
대상:
bucket: lake-prod
prefix: raw/domain-a/정책:
- versioning: off 또는 suspended
- current object:
- 생성 후 60일 지나면 Warm으로 transition
- expiration:
- 업무 보존기간에 따라 2년, 3년, 5년 등 별도 결정
- replication:
- 없음적합한 데이터:
raw/year=2025/month=01/
raw/year=2025/month=02/
bronze/domain-a/dt=...
silver/domain-a/dt=...이 유형은 Hot 공간 절감 효과가 가장 큽니다.
9.2 Versioned Recovery 데이터
대상:
bucket: lake-prod
prefix: gold/domain-b/정책:
- versioning: enabled
- current object:
- 30일 후 Warm transition
- noncurrent version:
- noncurrent가 된 후 7일 뒤 Warm transition
- 180일 뒤 expire
- 최근 noncurrent version 3개는 보존
- replication:
- 업무 중요도에 따라 선택MinIO lifecycle rule은 prefix 단위로 적용할 수 있고, versioning bucket에서는 current version과 noncurrent version에 대해 transition/expire 정책을 분리할 수 있습니다. noncurrent version 보존 개수도 설정할 수 있습니다. (MinIO AIStor Documentation)
9.3 중요 데이터: ILM + Replication 동시 적용
대상:
bucket: lake-prod
prefix: critical/final/정책:
- versioning: Hot source bucket enabled
- versioning: Warm replica bucket enabled
- ILM:
- current object 30~60일 후 Warm tier로 transition
- noncurrent version 7일 후 Warm transition
- noncurrent version 180~365일 후 expire
- replication:
- Warm의 repl-critical-prod bucket으로 복제이때 중요한 결정은 delete replication을 어떻게 할 것인가입니다.
| 모드 | delete/delete-marker replication | 의미 |
|---|---|---|
| Protective copy | off | Hot에서 실수로 삭제해도 Warm replica에 남김 |
| Mirror copy | on | Hot 삭제가 Warm replica에도 반영됨 |
정말 중요한 데이터라면 처음에는 Protective copy가 더 안전합니다. 즉 object 생성/수정은 복제하되 delete와 delete-marker 복제는 끄고, Warm replica 쪽 삭제는 별도 승인된 lifecycle로만 처리합니다. MinIO replication은 delete 및 delete-marker 복제를 명시적으로 켤 수 있으며, 기존 object 복제도 옵션으로 지정해야 합니다. (MinIO AIStor Documentation)
9.4 임시/파생 데이터
대상:
bucket: lake-prod
prefix:
tmp/
staging/
spark-temp/
airflow-temp/
derived/rebuildable/정책:
- versioning: off
- replication: none
- ILM transition: 보통 없음
- expire:
- tmp: 7일
- staging: 14일
- derived/rebuildable: 30~90일이 데이터는 Warm으로 내릴 가치가 없는 경우가 많습니다. Warm tier도 결국 비용과 운영 부담이 있으므로, 재생성 가능한 데이터는 과감히 만료하는 것이 좋습니다.
10. Git 기반 정책 장부를 반드시 두는 것을 권장
지금 단계에서 가장 중요한 운영 체계는 “누가 어떤 bucket/prefix에 어떤 lifecycle을 걸었는지”를 Git으로 관리하는 것입니다.
예를 들어 다음과 같은 registry를 둡니다.
- bucket: lake-prod
prefix: raw/domain-a/
owner: data-platform
data_class: WARM-HISTORICAL
versioning: suspended
current_transition_days: 60
transition_tier: WARM_MAIN
noncurrent_transition_days: null
noncurrent_expire_days: null
replication: none
delete_replication: false
retention_note: "raw historical data, low access after 60 days"
- bucket: lake-prod
prefix: gold/domain-b/
owner: analytics-core
data_class: VERSIONED-RECOVERY
versioning: enabled
current_transition_days: 30
transition_tier: WARM_MAIN
noncurrent_transition_days: 7
noncurrent_expire_days: 180
keep_noncurrent_versions: 3
replication: none
delete_replication: false
- bucket: lake-prod
prefix: critical/final/
owner: business-critical
data_class: CRITICAL-REPL
versioning: enabled
current_transition_days: 60
transition_tier: WARM_MAIN
noncurrent_transition_days: 7
noncurrent_expire_days: 365
keep_noncurrent_versions: 5
replication: protective
replication_target: warm/repl-critical-prod
delete_replication: falseCI 검증에서는 최소한 아래를 막아야 합니다.
- replication 설정인데 source/destination versioning이 빠진 경우
- ILM tier target bucket에 lifecycle rule을 설정하려는 경우
- ILM tier target과 replication target이 같은 bucket/prefix인 경우
- delete replication 여부가 명시되지 않은 경우
- table metadata / checkpoint / active manifest 경로에 무심코 transition rule을 건 경우
- transition target 변경 시 기존 tiered object 이전 계획이 없는 경우
- expire rule이 replication backlog 확인 없이 먼저 동작할 수 있는 경우MinIO 문서상 lifecycle transition target을 바꿔도 기존에 이미 transition된 object가 자동으로 새 target으로 이동하지 않습니다. 따라서 tier target 변경은 반드시 migration/decommission 계획과 함께 해야 합니다. (MinIO AIStor Documentation)
11. 예시 명령 구조
아래는 개념 예시입니다. 실제 endpoint, access key, secret, bucket명은 운영 Secret으로 관리하고 Git에는 평문 저장하지 않는 것이 좋습니다.
11.1 alias 설정
mc alias set hot https://s3-hot.example.internal "$HOT_AK" "$HOT_SK"
mc alias set warm https://s3-warm.example.internal "$WARM_AK" "$WARM_SK"11.2 Warm bucket 생성
mc mb warm/tier-hot-prod
mc mb --with-versioning warm/repl-critical-prod11.3 Hot에 Warm tier 등록
mc ilm tier add minio hot WARM_MAIN \
--endpoint https://s3-warm.example.internal \
--access-key "$TIER_AK" \
--secret-key "$TIER_SK" \
--bucket tier-hot-prod \
--prefix hot-prod/ \
--storage-class STANDARDAIStor의 remote tier 등록은 대상 endpoint, bucket, prefix, credential, storage class를 지정하는 방식입니다. remote bucket은 사전에 존재해야 하고, tiering credential에는 read/write/list/delete 권한이 필요합니다. (MinIO AIStor Documentation)
11.4 일반 이력 prefix transition
mc ilm rule add hot/lake-prod \
--prefix "raw/domain-a/" \
--transition-tier WARM_MAIN \
--transition-days 6011.5 versioned prefix transition
mc version enable hot/lake-prod
mc ilm rule add hot/lake-prod \
--prefix "gold/domain-b/" \
--transition-tier WARM_MAIN \
--transition-days 30 \
--noncurrent-transition-days 7 \
--noncurrent-transition-tier WARM_MAIN
mc ilm rule add hot/lake-prod \
--prefix "gold/domain-b/" \
--noncurrent-expire-days 180 \
--noncurrent-expire-newer 3 \
--expire-delete-marker11.6 중요 prefix replication
Protective copy 방식, 즉 삭제는 복제하지 않는 예입니다.
mc replicate add \
--remote-bucket https://"$REPL_AK":"$REPL_SK"@s3-warm.example.internal/repl-critical-prod \
--replicate "existing-objects" \
--limit-upload 1Gi \
hot/lake-prod/critical/final/Mirror copy 방식, 즉 삭제와 delete marker까지 복제하는 예입니다.
mc replicate add \
--remote-bucket https://"$REPL_AK":"$REPL_SK"@s3-warm.example.internal/repl-critical-prod \
--replicate "existing-objects,delete,delete-marker" \
--limit-upload 1Gi \
hot/lake-prod/critical/final/Bucket replication은 새 object뿐 아니라 옵션에 따라 기존 object, delete, delete-marker, metadata까지 동기화할 수 있습니다. 대규모 prefix에 처음 적용할 때는 --limit-upload로 Hot/Warm 간 replication 부하를 제한하는 것이 좋습니다. (MinIO AIStor Documentation)
12. Site Replication은 이번 목적에는 비권장
AIStor에는 site replication도 있지만, 이번 상황에서는 권장하지 않습니다. site replication은 전체 site 단위의 BC/DR 성격이 강하고, 같은 IDP, 같은 Object Store version, encryption 설정 정합성 등 제약이 큽니다. 또한 site replication은 모든 bucket에 versioning을 요구하고, 같은 deployment 조합에서 bucket replication과 site replication을 동시에 쓰기 어렵습니다. (MinIO AIStor Documentation)
이번 요구사항은 다음에 가깝습니다.
- DR은 아직 계획 없음
- 전체 bucket이 아니라 주요 bucket/prefix 일부만 보호
- Hot 공간 절감이 1차 목적
- 정말 중요한 일부만 replication따라서 Site Replication이 아니라 ILM Transition + Bucket Replication 조합이 더 맞습니다. AIStor 문서에서도 site replication은 전체 cluster 단위, bucket replication은 개별 bucket 단위 복제 방식으로 구분합니다. (MinIO AIStor Documentation)
13. 4개월 뒤 130노드 추가 시나리오
4개월 뒤 3.5TiB x 20disk x 130node가 들어오면 이 장비가 사실상 Warm의 메인 용량이 됩니다.
이때 선택지는 두 가지입니다.
선택지 A: 기존 Warm ObjectStore에 pool4로 추가
장점:
- endpoint 유지
- 기존 tier 설정 유지
- 운영 단순단점:
- 기존 1차 pool들과 성능/장애 특성이 섞임
- 새 object는 free-space weighting으로 신규 pool에 많이 들어갈 수 있음
- 기존에 tiered된 object는 자동으로 pool4로 재배치되지 않음선택지 B: 130노드로 새 Warm-main ObjectStore 구성
장점:
- 동질적인 130노드 Warm 메인 구성 가능
- 1차 재활용 장비 pool과 명확히 분리
- 장기적으로 더 깔끔한 구조단점:
- 기존 tier target에서 새 target으로 전환 설계 필요
- 이미 tiered된 object 처리 계획 필요개인적으로는 다음 전략이 가장 현실적입니다.
1단계:
- 1차 38~54노드는 warm-temporary 또는 warm-initial로 구성
- 낮은 위험도의 historical prefix부터 ILM 적용
- replication은 아주 작은 critical prefix부터 제한적으로 적용
2단계:
- 130노드 도입 시 warm-main ObjectStore 또는 warm-main pool 구성
- 이후 신규 lifecycle rule은 warm-main을 target으로 설정
- 기존 warm-initial에 내려간 object는 즉시 무리하게 옮기지 않고,
사용률과 안정성을 보고 decommission/migration 여부 결정초기에 너무 많은 데이터를 1차 Warm으로 내리면, 4개월 뒤 130노드 도입 시 다시 재배치 문제를 겪을 수 있습니다. 따라서 1차 Warm은 공간 압박을 완화하는 완충 계층으로 쓰고, 장기 주력 Warm은 130노드 도입 후 확정하는 편이 안전합니다.
14. 운영 모니터링 항목
14.1 Hot/Warm 공통
반드시 봐야 할 지표는 다음입니다.
- cluster usable free capacity
- raw free capacity
- drive online/offline
- node online/offline
- erasure set read quorum
- erasure set write quorum
- erasure set health
- healing drive count
- 5xx error
- S3 GET/PUT latency p95/p99
- Hot ↔ Warm network throughput/drop/retransmitAIStor는 erasure set별 read/write quorum, online drive, healing drive, tolerance, cluster capacity, online/offline node/drive 등의 metric을 제공합니다. (MinIO AIStor Documentation)
14.2 ILM monitoring
mc admin scanner status hot봐야 할 항목:
- lifecycle scanner backlog
- transition action count
- delete action count
- missed expiry task
- scanner 지연 시간
- 특정 prefix transition 진행률MinIO는 ILM action count, expiry missed task, scanner status 등을 통해 lifecycle 처리 상태를 확인할 수 있습니다. (MinIO AIStor Documentation)
14.3 Replication monitoring
mc replicate status hot/lake-prod
mc replicate backlog hot/lake-prod봐야 할 항목:
- replication backlog 증가 여부
- failed replication count
- 특정 prefix의 unreplicated object
- replication latency
- delete/delete-marker replication 동작 여부mc replicate status와 mc replicate backlog는 replication 상태와 미복제 backlog를 확인하는 데 사용됩니다. (MinIO AIStor Documentation)
15. 장애/복구 관점에서 반드시 알아야 할 점
15.1 Warm 장애 시 ILM tiered object read가 영향받음
Hot의 object metadata는 남아 있어도, object body가 Warm remote tier에 있으면 Warm 접근이 실패할 때 해당 object read가 실패하거나 지연될 수 있습니다. 따라서 Warm은 “느려도 되는 저장소”일 수는 있지만, “불안정해도 되는 저장소”는 아닙니다.
15.2 ILM tiering은 Hot metadata 복구 수단이 아님
Warm에 내려간 tiered object만으로 Hot의 metadata 손실을 복구할 수 없습니다. 공식 문서도 tiering은 BC/DR 기능이 아니며, 보호가 필요한 workload에는 replication을 사용하라고 설명합니다. (MinIO AIStor Documentation)
15.3 Versioning은 삭제 방지 장치가 아니라 복구 window 제공 장치
Versioning bucket에서 일반 DELETE를 수행하면 delete marker가 생기고, 특정 version ID를 삭제하면 해당 version은 영구 삭제됩니다. 따라서 versioning을 켰더라도 lifecycle expire 정책과 권한 제어가 같이 필요합니다. (MinIO AIStor Documentation)
15.4 WORM은 지금 안 쓰더라도 bucket 설계에는 여지를 남기는 것이 좋음
지금 WORM/Object Lock을 사용하지 않는 것은 괜찮습니다. 다만 향후 감사/규제성 데이터에 WORM이 필요해질 수 있으므로, audit/, security/, settlement/, regulatory/ 계열 prefix는 처음부터 별도 bucket 또는 명확한 prefix로 분리해 두는 것이 좋습니다. 최근 AIStor release에서는 기존 bucket에도 object locking/retention 설정을 적용할 수 있는 기능이 있지만, 버전에 따라 동작이 다를 수 있으므로 향후 적용 전 릴리즈 기준 확인이 필요합니다. (MinIO AIStor Documentation)
16. 단계별 추진안
Phase 0. 설계 확정
- Warm을 기존 Hot ObjectStore pool로 붙이지 않기로 결정
- 별도 K8s cluster 가능 여부 결정
- 어렵다면 같은 K8s 내 별도 ObjectStore로 결정
- Hot/Warm AIStor version 정합성 확인
- TLS, KMS, LDAP/IDP, DNS, LB, routing 확인
- license가 raw 기준인지 usable 기준인지 확인
- versioning + replication에 따른 용량 증폭률 산정Phase 1. Warm 초기 구축
- 7TiB x 20disk x 19node pool 구성
- 3.5TiB x 20disk x 14node pool 구성
- 3.5TiB x 10disk x 5node는 중요 데이터 제외 또는 보류
- XFS, noatime/nodiratime, drive health, firmware 확인
- Warm 전용 endpoint 구성
- tier-hot-prod bucket 생성
- repl-critical-prod bucket 생성Phase 2. ILM canary
- low-risk prefix 하나 선정
- transition-days 7~14 정도로 짧게 테스트
- tiered object GET 확인
- scanner backlog 확인
- Hot 공간 감소 추세 확인
- Warm latency 및 5xx 확인Phase 3. 운영 prefix 확대
- raw historical prefix부터 확대
- bronze/silver historical 확대
- gold는 업무 owner 승인 후 적용
- table metadata, manifest, checkpoint, active dataset은 기본 제외Iceberg/Spark/Trino 계열에서는 metadata, manifest, checkpoint, transaction log 성격의 파일이 작은 object로 자주 접근될 수 있으므로, 이런 경로는 무심코 Warm으로 내리지 않는 것이 좋습니다. 데이터 파일은 historical 기준으로 내리되, metadata 계열은 별도 prefix 식별 후 Hot 유지 정책을 두는 편이 안전합니다.
Phase 4. 중요 데이터 replication 적용
- source/destination bucket versioning enable
- delete replication 정책 결정
- protective mode부터 시작 권장
- 기존 object replication은 prefix 단위로 제한
- bandwidth limit 적용
- backlog와 실패 건수 모니터링Phase 5. 130노드 Warm-main 도입
- 130노드 3.5TiB x 20disk를 장기 Warm main으로 설계
- 기존 warm-initial과 합칠지, 별도 warm-main으로 둘지 결정
- 신규 lifecycle target을 warm-main으로 전환
- 기존 tiered object의 이전 여부는 사용률과 안정성 기준으로 별도 판단17. 최종 권장안 요약
제가 이 환경이라면 다음처럼 결정하겠습니다.
1. 기존 128노드 NVMe AIStor에는 Warm pool을 직접 추가하지 않는다.
2. Warm은 별도 AIStor ObjectStore로 구성한다.
3. 가능하면 별도 Kubernetes cluster로 구성한다.
어렵다면 같은 K8s 내 전용 node group + namespace + ObjectStore + DirectPV로 강하게 분리한다.
4. Warm 내부 bucket은 최소 2개로 나눈다.
- tier-hot-prod: ILM transition 전용
- repl-critical-prod: bucket replication 전용
5. Site replication은 쓰지 않는다.
- DR 목적이 아니고 전체 bucket 복제도 아니므로 과함
- bucket/prefix 단위 replication이 더 적합
6. Lifecycle 정책은 bucket 단위가 아니라 prefix/data-class 단위로 설계한다.
- HOT-ACTIVE
- WARM-HISTORICAL
- VERSIONED-RECOVERY
- CRITICAL-REPL
- TEMP-DERIVED
7. Versioning은 필요한 곳에만 켠다.
- versioning은 공간을 줄이는 기능이 아니라 공간을 더 쓰는 기능
- noncurrent transition + noncurrent expire를 반드시 같이 둔다.
8. ILM + replication을 동시에 거는 prefix는 정말 중요한 소수로 제한한다.
- Warm에서 tiered copy와 replica copy가 모두 생겨 용량을 크게 사용한다.
9. 1차 Warm은 완충 계층으로 조심스럽게 사용한다.
- 특히 5노드 x 10disk pool은 중요 데이터용으로 쓰지 않는다.
10. 130노드 도입 후 그 구성을 장기 Warm-main으로 삼는다.가장 중요한 판단은 이것입니다.
Warm Tier를 “Hot cluster의 싸고 느린 pool”로 붙이면 안 되고, “Hot의 lifecycle/replication target이 되는 별도 AIStor 서비스”로 봐야 합니다.
그래야 NVMe Hot의 성능과 안정성을 지키면서, Warm을 통해 공간 절감과 중요 데이터 보호를 동시에 가져갈 수 있습니다.
