26J09b

업로드하신 2026-05-29 2-Tier 가이드와 AIStor 공식 문서를 기준으로 보면, 지금 상황에서는 Warm Tier를 “하나의 기능”으로 보지 말고, 버킷별로 3개 정책군으로 나눠 운영하는 것이 맞습니다.

핵심 결론은 이렇습니다.

기본값: Tiering only
중요 active 데이터: Replication only
Tiering + Replication: 같은 object에 무조건 동시 적용하지 말고,
                     bucket/prefix 분리 또는 lifecycle 단계 분리로 설계
Versioning: 전체 일괄 ON 금지, bucket/use case별 선택 적용
WORM/Object Lock: 현재는 제외
DR: 현재는 제외

특히 중요한 점은 ILM Tiering과 Replication은 목적이 다르다는 것입니다. Tiering은 Hot 용량 절감이고, Replication은 보호 사본 유지입니다. 업로드하신 가이드도 두 기능은 독립적이며 함께 사용할 수 있지만, tiering 후 replication target에는 실제 data가 아니라 stub metadata만 복제될 수 있어 target에서 직접 읽을 때 오류가 날 수 있다고 경고합니다. 공식 문서도 object transition은 business continuity나 DR 효과를 추가로 제공하지 않으며, 보호 목적은 server-side replication을 사용해야 한다고 설명합니다. (MinIO AIStor Documentation)

---

1. 전체 Warm Tier 구성 방향

현재는 DR도 없고 WORM도 안 쓸 예정이므로 Warm Tier의 역할을 세 가지로 나누는 것이 좋습니다.

[Hot AIStor / NVMe]
- active data
- catalog / metadata / manifest
- 최근 분석 데이터
- 사용자 write endpoint

        │
        ├─ 1) ILM Tiering
        │     목적: Hot 용량 절감
        │     대상: 오래된 data file, append-only log, archive prefix
        │
        ├─ 2) Bucket Replication
        │     목적: 중요 데이터 보호 사본
        │     대상: 중요 원천, catalog, user-upload, 설정/메타데이터
        │
        └─ 3) Tiering + Replication
              목적: 중요도도 있고 장기 보관도 필요한 데이터
              원칙: 같은 object에 단순 동시 적용은 신중
                    가능하면 bucket/prefix/lifecycle 단계 분리

[Warm AIStor / SATA·SSD]
- ILM tier target bucket: 시스템 전용, 직접 접근 금지
- replication target bucket: 보호 사본, 필요 시 read-only 운영 접근
- archive bucket: warm native 저장소

Warm ObjectStore 안에서도 bucket을 반드시 분리하는 게 좋습니다.

warm-aistor
├─ tier-hot-prod
│  └─ Hot → Warm ILM transition 전용 bucket
│     - 애플리케이션 직접 접근 금지
│     - lifecycle/expiration 자체 설정 금지
│     - Hot AIStor의 ILM user만 read/write/delete
│
├─ repl-critical-prod
│  └─ 중요 bucket replication target
│     - 보호 사본
│     - 운영자 read-only 확인 가능
│     - delete replication 여부는 bucket별 결정
│
├─ repl-catalog-prod
│  └─ catalog/metadata/manifest 보호 사본
│
└─ archive-native-prod
   └─ 애초에 Warm에 직접 저장하는 archive성 데이터

공식 문서는 remote tier bucket에 대해 MinIO AIStor가 독점 접근해야 하며, 외부 애플리케이션이나 사용자가 해당 bucket의 transitioned data를 직접 수정·삭제하면 데이터 손실이 날 수 있다고 설명합니다. 따라서 ILM target bucket과 replication target bucket은 절대 섞지 않는 것이 좋습니다. (MinIO AIStor Documentation)

---

2. Bucket 정책 조합 전체표

조합	Hot 용량 절감	Warm에 독립 readable copy	Versioning	적합한 use case	권장도
A. Tiering only, versioning OFF	큼	아님	OFF	append-only 로그, 오래된 파티션, 재생성 가능 데이터	높음
B. Tiering only, versioning ON	큼	아님	선택 ON	휴지통 필요 bucket, user data archive	중간~높음
C. Replication only, delete 미복제	없음	있음	강제 ON	중요 원천, 실수 삭제 보호, catalog 보호	높음
D. Replication only, delete 복제	없음	있음	강제 ON	warm을 mirror로 유지해야 하는 bucket	중간
E. Prefix 분리형 tiering + replication	일부	일부	대개 ON	같은 bucket 안에 critical/, archive/가 섞인 경우	높음
F. 같은 object에 tiering + replication	큼	불명확/위험	강제 ON	target 직접 read가 필요 없는 특수 경우	낮음
G. Bucket 단계 분리형 tiering + replication	큼 + 보호	있음	bucket별	active 기간에는 replication, archive 단계는 tiering	가장 권장

---

3. 조합 A — Tiering only + Versioning OFF

목적

Hot NVMe 용량 절감이 목적이고, 별도 보호 사본은 필요 없는 데이터에 씁니다.

적합한 데이터

- append-only 로그
- 오래된 raw ingest 데이터
- Iceberg/Parquet data file 중 immutable 성격이 강한 과거 파티션
- 재생성 가능한 중간 산출물 중 장기 보관만 필요한 것
- 조회 빈도가 낮지만 삭제하면 안 되는 archive성 데이터

피해야 할 데이터

- Iceberg metadata / manifest / catalog
- 자주 overwrite되는 object
- 사용자가 실수 삭제 복구를 요구하는 bucket
- low-latency query 대상

정책 예시

# Hot 쪽에 Warm tier target 등록
mc ilm tier add minio hot WARM_TIER \
  --endpoint https://s3-warm.company.internal \
  --access-key "${TIER_ACCESS_KEY}" \
  --secret-key "${TIER_SECRET_KEY}" \
  --bucket tier-hot-prod \
  --prefix hot-prod/ \
  --storage-class STANDARD

# logs/는 30일 후 Warm으로 transition
mc ilm rule add hot/raw-logs \
  --prefix "logs/" \
  --transition-days 30 \
  --transition-tier WARM_TIER

# raw/year=2025 이하 같은 archive prefix는 90일 후 Warm으로 transition
mc ilm rule add hot/raw-data \
  --prefix "archive/" \
  --transition-days 90 \
  --transition-tier WARM_TIER

AIStor의 ILM transition rule은 --transition-days와 --transition-tier로 구성하며, noncurrent version도 별도 transition 대상으로 지정할 수 있습니다. (MinIO AIStor Documentation)

운영 포인트

이 조합은 가장 단순하고 Hot 용량 절감 효과도 큽니다. 다만 Warm은 backup/DR 사본이 아니라 Hot metadata와 연결된 remote tier backend로 보는 게 맞습니다. 업로드하신 가이드도 tiering은 replication과 달리 비용 최적화 목적이라고 설명하고 있습니다.

---

4. 조합 B — Tiering only + Versioning ON

목적

Hot 용량을 줄이면서 휴지통 기능도 일부 제공하려는 경우입니다.

적합한 데이터

- 사용자 업로드 데이터
- 분석가 개인 workspace 중 삭제 복구 요구가 있는 데이터
- overwrite가 가끔 있는 업무 데이터
- 중요도는 중간이지만 “며칠 전 버전 복구”가 필요한 bucket

정책 예시 1 — current는 90일 후 Warm, noncurrent는 30일 보관

mc version enable hot/user-data \
  --excluded-prefixes "tmp/,logs/,cache/" \
  --exclude-folders

mc ilm rule add hot/user-data \
  --transition-days 90 \
  --transition-tier WARM_TIER \
  --noncurrent-expire-days 30 \
  --noncurrent-expire-newer 3 \
  --expire-delete-marker

Versioning을 켜면 overwrite 시 새 full version이 생성되고, DELETE는 실제 삭제가 아니라 delete marker 생성으로 동작합니다. 따라서 versioning bucket에는 noncurrent version 정리와 delete marker cleanup을 반드시 같이 둬야 합니다. (MinIO AIStor Documentation) 업로드하신 가이드도 versioning은 필요한 bucket에만 적용하고, version 수 증가가 storage·metadata·scanner·healing 부하를 키운다고 정리합니다.

정책 예시 2 — current는 Hot 유지, 이전 버전만 Warm으로 보냄

대용량 object가 자주 바뀌지만 current는 Hot에 있어야 하는 경우입니다.

mc version enable hot/model-checkpoints

mc ilm rule add hot/model-checkpoints \
  --noncurrent-transition-days 7 \
  --noncurrent-transition-tier WARM_TIER \
  --noncurrent-expire-days 365 \
  --expire-delete-marker

추천 use case

- AI/ML checkpoint
- Jupyter notebook output 중 롤백 필요 데이터
- 사용자 업로드 파일
- “최신은 빠르게 읽고, 이전 버전은 느려도 된다”는 데이터

---

5. 조합 C — Replication only + delete 미복제

목적

중요 데이터 보호가 목적입니다. Hot 용량 절감 효과는 없습니다. 대신 Warm에 독립적인 readable copy를 둡니다.

적합한 데이터

- 중요 원천 데이터
- 재수집 불가능하거나 비용이 큰 데이터
- catalog / table metadata / Iceberg metadata / manifest
- 사용자 중요 산출물
- 실수 삭제 보호가 필요한 bucket

핵심 정책

- Source bucket versioning ON
- Target bucket versioning ON
- delete replication OFF
- delete-marker replication OFF
- existing-objects ON
- noncurrent version 정리 rule 필수

AIStor bucket replication은 source와 destination bucket의 versioning을 요구하며, versioning에서 제외한 prefix나 folder는 replication할 수 없습니다. (MinIO AIStor Documentation) 또한 mc replicate는 모든 version과 metadata를 동기화하며, 기존 object, delete, delete-marker는 옵션으로 제어할 수 있습니다. (MinIO AIStor Documentation)

구성 예시 — 실수 삭제 보호형

mc mb warm/repl-critical-source

mc version enable hot/critical-source
mc version enable warm/repl-critical-source

mc replicate add hot/critical-source \
  --remote-bucket https://repl-user:${REPL_SECRET}@s3-warm.company.internal/repl-critical-source \
  --replicate "existing-objects"

이렇게 하면 신규 object와 기존 object는 Warm으로 복제하되, source에서 delete가 발생해도 target 사본은 즉시 지워지지 않는 보호 사본형으로 운영할 수 있습니다. 공식 문서의 historical record 예시도 existing-objects만 지정하면 source delete가 remote copy에 영향을 주지 않는 형태라고 설명합니다. (MinIO AIStor Documentation)

추가 ILM

# Hot source bucket의 noncurrent version 정리
mc ilm rule add hot/critical-source \
  --noncurrent-expire-days 30 \
  --noncurrent-expire-newer 5 \
  --expire-delete-marker

추천 use case

- 실수 삭제 보호가 중요한 원천 데이터
- 업무상 “삭제 전 상태를 Warm에서 찾아야 하는” bucket
- DR은 아니지만 Hot 장애/운영 실수에 대비하고 싶은 데이터

현재 WORM을 쓰지 않는다면, 이 조합이 사실상 가장 현실적인 중요 데이터 보호 방식입니다.

---

6. 조합 D — Replication only + delete 복제

목적

Warm을 보호 사본이라기보다 mirror target으로 유지하는 방식입니다.

적합한 데이터

- Hot과 Warm이 동일 상태여야 하는 업무 bucket
- Warm에서 동일 namespace로 read 검증이 필요한 bucket
- 삭제도 업무 이벤트로 간주되어 target에 반영되어야 하는 데이터

구성 예시 — mirror형

mc version enable hot/mirror-bucket
mc version enable warm/mirror-bucket

mc replicate add hot/mirror-bucket \
  --remote-bucket https://repl-user:${REPL_SECRET}@s3-warm.company.internal/mirror-bucket \
  --replicate "delete,delete-marker,existing-objects"

AIStor replication은 delete operation replication을 지원하지만, versioned delete와 delete marker replication은 명시적으로 켜야 합니다. (MinIO AIStor Documentation)

주의점

이 방식은 실수 삭제도 Warm에 전파됩니다. 따라서 “보호 사본” 목적이라면 delete/delete-marker 복제는 기본적으로 꺼두는 편이 안전합니다.

추천 use case

- 복구보다는 동기화 정합성이 더 중요한 bucket
- Warm에서 hot과 동일한 view를 제공해야 하는 bucket
- 운영 검증용 mirror

---

7. 조합 E — 같은 bucket 안에서 prefix별로 Tiering과 Replication 분리

목적

애플리케이션 구조상 bucket을 나누기 어렵고, 하나의 bucket 안에 성격이 다른 prefix가 섞인 경우입니다.

예시 구조

bucket: lakehouse-prod

metadata/
  - replication only
  - versioning ON
  - tiering OFF

data/current/
  - hot only 또는 replication only

data/archive/
  - tiering only
  - versioning OFF 또는 짧은 versioning

tmp/
_staging/
_temporary/
  - versioning 제외
  - replication 제외
  - 짧은 expiration

구성 예시

# bucket 전체 versioning은 켜되, 변경/임시 prefix는 제외
mc version enable hot/lakehouse-prod \
  --excluded-prefixes "tmp/,_temporary/,_staging/,logs/,cache/" \
  --exclude-folders

# metadata/는 Warm replication target으로 복제
mc version enable warm/repl-lakehouse-metadata

mc replicate add hot/lakehouse-prod/metadata/ \
  --remote-bucket https://repl-user:${REPL_SECRET}@s3-warm.company.internal/repl-lakehouse-metadata \
  --replicate "existing-objects"

# archive/는 90일 후 tiering
mc ilm rule add hot/lakehouse-prod \
  --prefix "data/archive/" \
  --transition-days 90 \
  --transition-tier WARM_TIER

# noncurrent 정리
mc ilm rule add hot/lakehouse-prod \
  --noncurrent-expire-days 30 \
  --noncurrent-expire-newer 3 \
  --expire-delete-marker

업로드하신 가이드도 prefix 기반 tiering 정책을 지원하고, prefix rule과 bucket default rule을 같이 둘 수 있다고 설명합니다. 단, prefix transition 기간이 bucket default transition 기간보다 길면 default rule이 먼저 실행되어 prefix rule이 무의미해질 수 있습니다.

추천 use case

- Iceberg/Delta/Hive warehouse bucket
- 사용자별 namespace가 하나의 bucket 안에 있는 경우
- catalog/metadata와 data/archive가 섞인 bucket
- bucket 수를 늘리기 어려운 기존 시스템

주의점

Replication이 걸리는 bucket은 versioning이 필요합니다. 그리고 versioning excluded prefix는 replication 대상이 될 수 없습니다. 따라서 metadata/처럼 replication해야 하는 prefix는 excluded-prefixes에 넣으면 안 됩니다. (MinIO AIStor Documentation)

---

8. 조합 F — 같은 object에 Tiering + Replication 동시 적용

판단

기술적으로 가능해도 기본 전략으로는 비권장입니다.

업로드하신 가이드에서 가장 중요한 경고가 이 부분입니다. Transition이 완료된 object는 Hot에 실제 data가 없고 metadata stub만 남으며, 이 상태에서 replication이 동작하면 target에도 stub만 복제될 수 있습니다. target cluster가 해당 transitioned object를 직접 읽으려 하면 오류가 날 수 있습니다.

사용 가능한 경우

- replication target을 독립 readable copy로 쓰지 않을 때
- target에서 transitioned object를 직접 GetObject하지 않는다는 운영 합의가 있을 때
- 목적이 보호 사본이 아니라 metadata 정합성 또는 제한적 동기화일 때

구성 예시

가능은 하지만, 아래처럼 해도 독립 보호 사본으로 해석하면 안 됩니다.

mc version enable hot/mixed-bucket
mc version enable warm/repl-mixed-bucket

mc replicate add hot/mixed-bucket \
  --remote-bucket https://repl-user:${REPL_SECRET}@s3-warm.company.internal/repl-mixed-bucket \
  --replicate "existing-objects" \
  --edge-sync-before-expiry

mc ilm rule add hot/mixed-bucket \
  --transition-days 365 \
  --transition-tier WARM_TIER \
  --noncurrent-expire-days 30 \
  --expire-delete-marker

--edge-sync-before-expiry는 replication 완료 전에 ILM expiration이 먼저 object를 삭제하는 경쟁 상태를 줄이는 데 필요합니다. 다만 replication backlog가 커지면 expiry가 지연되어 Hot 용량이 줄지 않는 것처럼 보일 수 있으므로 backlog와 Hot 사용률 알람을 같이 둬야 합니다.

제 권고

현재 DR도 없고 WORM도 없는 상태라면, 같은 object에 tiering + replication을 동시에 거는 방식은 예외 케이스로만 두는 것이 좋습니다.

---

9. 조합 G — Bucket 단계 분리형 Tiering + Replication

판단

중요 데이터이면서 장기적으로 Hot 용량도 줄여야 하는 경우의 가장 권장 패턴입니다.

핵심은 같은 object에 두 정책을 동시에 걸지 않고, active bucket과 archive bucket을 분리하는 것입니다.

hot/critical-active
- replication only
- current data는 Hot 유지
- Warm에 full readable copy 유지
- versioning ON
- delete replication은 기본 OFF

hot/critical-archive
- tiering only
- 일정 기간 지난 데이터만 이동
- versioning은 필요 시만 ON

데이터 흐름

1. 신규 중요 데이터
   app → hot/critical-active
   hot/critical-active → warm/repl-critical-active  # replication

2. 일정 기간 후 archive 전환
   batch/job → hot/critical-archive 로 copy 또는 move
   hot/critical-archive → warm/tier-hot-prod        # ILM transition

3. active bucket에서는 오래된 데이터 삭제 또는 expire
   단, warm repl target에는 일정 기간 보호 사본 유지 가능

구성 예시

# active bucket: 보호 사본 유지
mc version enable hot/critical-active
mc version enable warm/repl-critical-active

mc replicate add hot/critical-active \
  --remote-bucket https://repl-user:${REPL_SECRET}@s3-warm.company.internal/repl-critical-active \
  --replicate "existing-objects"

mc ilm rule add hot/critical-active \
  --noncurrent-expire-days 30 \
  --noncurrent-expire-newer 5 \
  --expire-delete-marker

# archive bucket: Hot 용량 절감
mc version enable hot/critical-archive \
  --excluded-prefixes "tmp/,logs/" \
  --exclude-folders

mc ilm rule add hot/critical-archive \
  --transition-days 30 \
  --transition-tier WARM_TIER \
  --noncurrent-expire-days 90 \
  --expire-delete-marker

추천 use case

- 중요 원천 데이터: 최근 90일은 active + replication, 이후 archive tiering
- AI 학습 데이터: curated dataset은 replication, 오래된 snapshot은 tiering
- Lakehouse 데이터: metadata는 replication only, 오래된 data partition은 tiering only
- 사용자 산출물: 최근 산출물은 replication, 장기 보관분은 archive bucket으로 이동 후 tiering

이 방식은 Hot 용량 절감과 보호 사본 유지라는 두 목적을 충돌 없이 분리할 수 있습니다.

---

10. Versioning 적용 전략

Versioning은 “휴지통”에는 유용하지만, 전체 bucket에 무작정 켜면 비용이 큽니다. AIStor versioning은 overwrite마다 새 version을 만들고, delete는 delete marker로 처리합니다. (MinIO AIStor Documentation) 업로드하신 가이드도 versioning이 storage, metadata 크기, scanner, LIST, healing 부하를 증가시킨다고 정리합니다.

Versioning 정책 기준

bucket 성격	Versioning	권장 정리
append-only logs	OFF	transition + expiration
immutable data files	OFF 또는 짧게 ON	transition 중심
user upload	ON	noncurrent 30~90일
catalog/metadata	ON	newer 5~10 + 30~90일
replication bucket	강제 ON	noncurrent 정리 필수
tmp/cache/staging	OFF 또는 excluded	짧은 expiration
WORM 대상	현재 미사용	추후 별도 bucket

기본 rule 예시

# 일반 휴지통: 최신 3개 또는 30일 이내만 보존
mc ilm rule add hot/user-data \
  --noncurrent-expire-days 30 \
  --noncurrent-expire-newer 3 \
  --expire-delete-marker

# 중요 metadata: 최신 10개 또는 90일 이내 보존
mc ilm rule add hot/metadata-bucket \
  --noncurrent-expire-days 90 \
  --noncurrent-expire-newer 10 \
  --expire-delete-marker

# 개발/테스트: 짧게 보존
mc ilm rule add hot/dev-bucket \
  --noncurrent-expire-days 7 \
  --noncurrent-expire-newer 2 \
  --expire-delete-marker

업로드하신 가이드에 따르면 --noncurrent-expire-days와 --noncurrent-expire-newer를 같이 쓰면 AND 조건으로 동작하므로, “90일 이상이면서 최신 5개 밖”인 version만 정리되는 식으로 해석해야 합니다.

---

11. Use case별 추천 조합

11.1. Iceberg / Lakehouse warehouse

metadata/, manifests/, catalog/
→ Replication only
→ Versioning ON
→ Tiering OFF

data/current/
→ Hot only 또는 Replication only
→ 조회 빈도와 중요도에 따라 결정

data/archive/, partition old/
→ Tiering only
→ Versioning OFF 또는 짧게 ON

tmp/, _temporary/, _staging/
→ Versioning 제외
→ Replication 제외
→ Expiration

추천 이유는 Iceberg metadata/manifest는 query planning과 commit에 영향을 주므로 Warm tiering 대상이 되면 안 되고, 과거 data file은 immutable 성격이 강해 tiering only가 잘 맞기 때문입니다.

---

11.2. 중요 원천 데이터

최근 90~180일:
→ Replication only
→ delete replication OFF
→ Versioning ON, noncurrent 30~90일

장기 보관 전환 후:
→ 별도 archive bucket으로 이동
→ Tiering only

추천 조합은 G: Bucket 단계 분리형입니다.

---

11.3. 로그/시계열/감사성 append-only 데이터

→ Tiering only
→ Versioning OFF
→ 30~90일 후 Warm
→ 보존기간 만료 시 expiration

구성 예시:

mc ilm rule add hot/logs \
  --transition-days 30 \
  --transition-tier WARM_TIER

mc ilm rule add hot/logs \
  --expire-days 730

단, 감사성 데이터가 법적 불변성을 요구하면 나중에는 WORM/Object Lock 별도 설계가 필요합니다. 지금은 WORM 미사용 전제이므로 단순 보관으로만 봐야 합니다.

---

11.4. AI/ML checkpoint, 모델 산출물

current checkpoint:
→ Hot 유지

이전 checkpoint:
→ noncurrent transition to Warm
→ noncurrent expire 180~365일

중요 모델:
→ Replication only 또는 Bucket 단계 분리

구성 예시:

mc version enable hot/ml-checkpoints

mc ilm rule add hot/ml-checkpoints \
  --noncurrent-transition-days 7 \
  --noncurrent-transition-tier WARM_TIER \
  --noncurrent-expire-days 365 \
  --expire-delete-marker

---

11.5. 사용자 workspace / Jupyter / 개인 sandbox

중요 사용자 산출물:
→ Replication only
→ delete replication OFF
→ Versioning ON 30일

대용량 오래된 결과물:
→ archive prefix로 이동 후 Tiering only

tmp/cache/logs:
→ versioning excluded
→ replication excluded

구성 예시:

mc version enable hot/user-workspace \
  --excluded-prefixes "tmp/,cache/,logs/,scratch/" \
  --exclude-folders

mc replicate add hot/user-workspace/results/ \
  --remote-bucket https://repl-user:${REPL_SECRET}@s3-warm.company.internal/repl-user-results \
  --replicate "existing-objects"

mc ilm rule add hot/user-workspace \
  --prefix "archive/" \
  --transition-days 30 \
  --transition-tier WARM_TIER

mc ilm rule add hot/user-workspace \
  --noncurrent-expire-days 30 \
  --noncurrent-expire-newer 3 \
  --expire-delete-marker

---

12. 운영 모니터링 기준

Warm tier 도입 후에는 성능보다 backlog, queue, orphan, version 폭증을 먼저 봐야 합니다.

영역	핵심 지표	이상 신호
ILM transition	minio_ilm_transition_pending_tasks	queue 포화
ILM transition missed	minio_ilm_transition_missed_immediate_tasks	worker 부족
tier journal	minio_ilm_expiry_missed_tier_journal_tasks	Hot에 orphan data 잔류 가능
replication	minio_replication_recent_backlog_count	복제 지연
expiry	minio_ilm_expiry_pending_tasks	expiry 지연
version 폭증	s3:ObjectManyVersions, s3:ObjectLargeVersions	versioning 정책 재검토

업로드하신 가이드도 transition queue 포화, tier journal 실패, replication backlog, expiry 지연을 핵심 모니터링 항목으로 제시합니다. 대규모 bucket에서는 transition worker와 expiration worker 조정이 필요할 수 있으며, 가이드 예시는 MINIO_ILM_TRANSITION_WORKERS, MINIO_ILM_EXPIRATION_WORKERS 조정을 제시합니다.

---

13. 최종 권장안

현재 조건에서는 아래 전략이 가장 안정적입니다.

1. Warm ObjectStore에는 bucket을 역할별로 분리한다.
   - tier-hot-prod: ILM target 전용
   - repl-critical-prod: 중요 데이터 replication target
   - repl-catalog-prod: metadata/catalog replication target
   - archive-native-prod: Warm 직접 archive용

2. 전체 bucket의 기본값은 Tiering only로 둔다.
   - append-only, 과거 partition, 로그, archive성 데이터
   - versioning OFF 또는 매우 짧게

3. 중요 active 데이터는 Replication only로 둔다.
   - Hot 용량 절감은 안 되지만 보호 사본 확보
   - delete replication은 기본 OFF
   - versioning + noncurrent cleanup 필수

4. Tiering + Replication은 같은 object에 단순 동시 적용하지 않는다.
   - 가장 권장: active bucket은 replication only, archive bucket은 tiering only
   - 차선: 같은 bucket 내 prefix 분리
   - 예외: target direct read가 필요 없는 경우에만 같은 object 동시 적용

5. Versioning은 bucket별로 선택한다.
   - replication bucket은 강제 ON
   - 휴지통 필요 bucket만 의도적 ON
   - tmp/log/cache/staging prefix는 excluded
   - 모든 versioning bucket에 noncurrent expire + expire-delete-marker 적용

6. WORM/Object Lock은 지금은 제외한다.
   - 다만 향후 규제/불변 보관 요구가 생기면 신규 bucket부터 별도 설계

한 문장으로 요약하면, Warm Tier는 “싸고 큰 단일 저장소”가 아니라 tiering backend, replication target, archive endpoint를 분리해 쓰는 보조 ObjectStore로 설계해야 합니다. 지금 가장 안전한 기본 조합은 대부분은 Tiering only, 정말 중요한 active 데이터는 Replication only, 둘 다 필요한 데이터는 bucket/prefix/lifecycle 단계 분리입니다.