26M15b
첨부 문서와 현재 MinIO AIStor 공식 문서를 같이 기준으로 보면, 이 문서의 핵심은 “Hot/Warm tiering은 비용 최적화이고, replication은 DR/가용성 목적이므로 둘을 같은 것으로 보면 안 된다”는 점입니다. 특히 ILM으로 Warm으로 이동한 object는 Hot에 metadata/stub만 남고 실제 data는 Warm에 있기 때문에, 이후 replication과 섞으면 “replication target에서 독립적으로 읽을 수 있는가?”가 가장 중요한 설계 기준이 됩니다.
0. 먼저 결론
권장 설계 방향은 세 가지로 나누는 것입니다.
| 목적 | 권장 방식 | 핵심 주의점 |
|---|---|---|
| 실시간/중요 데이터 보호 | Hot bucket + replication | ILM transition은 걸지 않는 쪽이 안전 |
| 오래된 데이터 비용 절감 | Hot bucket → ILM transition → Warm tier | Warm은 직접 읽는 저장소가 아니라 Hot을 통해 읽는 remote tier |
| 장기 아카이브/삭제 정책 | 별도 Warm-only bucket 또는 archive bucket | ILM tier target bucket과 일반 archive bucket을 혼동하면 안 됨 |
가장 중요한 운영 판단은 이것입니다.
Replication target에서 Warm tier 접근 없이 object를 직접 읽어야 한다면, 그 bucket에는 ILM transition과 replication을 같이 걸지 않는 것이 안전합니다. 첨부 문서도 tiering 후 replication target에는 xl.meta 같은 stub만 복제되고 실제 bytes는 복제되지 않으므로, target에서 직접 GetObject를 하면 오류가 날 수 있다고 설명합니다.
반대로 replication target을 평상시 직접 읽지 않고 DR/복구 목적의 보조 위치로만 본다면, 같은 bucket에 replication과 ILM tiering을 함께 쓰는 설계도 가능하지만, stub-only 복제, expiry race, replication backlog, restore traffic까지 모두 감안해야 합니다.
1. 전체 아키텍처: Hot/Warm 2-tier의 의미
여기서 Hot tier는 NVMe 기반 AIStor이고, Warm tier는 SSD 기반 AIStor입니다. ILM transition은 object를 “복사본으로 백업”하는 기능이 아니라, Hot에 있던 object data를 Warm으로 이동하고 Hot에는 metadata를 남기는 기능입니다. 공식 문서도 object가 다른 tier로 이동되면 object metadata는 primary tier에 남고 object data만 secondary tier로 이동한다고 설명합니다. (MinIO AIStor Documentation)
따라서 Warm tier의 object는 일반 app이 Warm endpoint로 직접 접근해서 쓰는 구조로 보면 안 됩니다. 원칙적으로 app은 계속 Hot endpoint로 S3 API 요청을 보내고, Hot AIStor가 필요할 때 Warm에서 데이터를 가져와 응답하는 구조입니다. 공식 문서도 transitioned data는 Hot의 metadata와 Warm의 data가 강하게 연결되어 있으며, 모든 접근은 MinIO AIStor를 통해 이뤄져야 하고 remote storage를 직접 수정하면 object data 손실이 날 수 있다고 경고합니다. (MinIO AIStor Documentation)
또한 Warm tier는 backup/recovery 용도가 아닙니다. 공식 문서는 object transition이 비용 절감용이며, 데이터 손실 시 remote tier를 복구 소스로 사용할 수 없고, backup/DR 요구사항은 site replication이나 bucket replication을 사용해야 한다고 명시합니다. (MinIO AIStor Documentation)
2. ILM Tiering의 동작 제약
2-1. Hot → Warm은 가능하지만 Warm → Cold 같은 chain tiering은 불가
첨부 문서의 “chain tiering 불가”는 다음 의미입니다.
Hot(A) → Warm(B)으로 이동한 object를 다시 Warm(B) → Cold(C)로 보내는 식의 다중 hop tiering은 지원되지 않습니다. 공식 문서도 AIStor는 primary/secondary의 single level tiering만 지원하고, warm에서 또 다른 cold tier로 이동하는 것은 지원하지 않는다고 설명합니다. (MinIO AIStor Documentation)
다만 source인 Hot cluster에서 object 또는 prefix별로 서로 다른 remote tier에 직접 보내는 것은 가능합니다.
예를 들면:
archive/2023/* → Warm SSD tier
archive/2020/* → 별도 Cold-compatible tier이런 식은 가능하지만, 둘 다 출발점은 Hot이어야 합니다. 이미 Warm으로 넘어간 object를 다시 다른 tier로 보내는 것은 피해야 합니다.
2-2. Transition 시점은 “즉시 보장”이 아님
첨부 문서에는 최소 전환 단위가 1일이라고 되어 있습니다. 다만 현재 공식 mc ilm rule add 문서에는 remote tier가 다른 AIStor deployment인 경우 --transition-days 0을 설정해 새 object를 즉시 transition 대상, 즉 eligible 상태로 만들 수 있다고 되어 있습니다. 이 부분은 첨부 문서와 현재 공식 문서 사이에 차이가 있으므로, 실제 운영 버전 기준으로 MinIO에 재확인하는 것이 좋습니다. (MinIO AIStor Documentation)
중요한 점은 0일 또는 1일 여부와 별개로, eligible이 곧 즉시 이동 완료를 의미하지는 않는다는 것입니다. AIStor는 scanner process로 lifecycle rule을 평가하며, IO 부하나 리소스 부족이 있으면 transition/expiration 적용이 지연될 수 있습니다. (MinIO AIStor Documentation)
3. Replication과 ILM Tiering을 같이 쓸 때의 핵심
3-1. Replication과 ILM은 목적이 다름
첨부 문서의 표현대로, replication과 ILM tiering은 독립 기능입니다.
Replication은 장애, DR, remote copy 보존 목적입니다. ILM tiering은 오래된 데이터를 저비용 tier로 옮기는 비용 최적화 목적입니다. 공식 문서도 transition은 backup/recovery 기능이 아니며, 보호가 필요한 workload는 server-side replication을 구현해야 한다고 설명합니다. (MinIO AIStor Documentation)
따라서 “Hot에서 Warm으로 ILM 이동했으니 백업된 것”으로 보면 안 됩니다.
3-2. 가장 큰 함정: transitioned object는 replication target에 full copy로 가지 않을 수 있음
첨부 문서에서 가장 중요한 부분입니다.
ILM transition이 완료되면 Hot에는 object의 실제 data bytes가 없고 metadata/stub만 남습니다. 이 상태에서 replication이 돌면 replication target에도 stub만 복제될 수 있습니다. 이 경우 target cluster는 Warm tier에 접근할 수 없으므로, target에서 해당 object를 직접 읽으면 오류가 발생할 수 있습니다.
즉, 다음 설계는 위험합니다.
Hot bucket
├─ ILM transition → Warm tier
└─ Replication → DR target
DR target에서 app이 직접 GetObject 수행이 설계에서 DR target이 Warm tier에 접근할 수 없거나, stub이 가리키는 remote data를 해석할 수 없다면 target은 완전한 독립 copy가 아닙니다.
안전한 패턴은 둘 중 하나입니다.
패턴 A: 독립 read 가능한 DR copy가 필요함
Hot bucket: Replication O, ILM Transition X
별도 archive 이동은 batch job/copy/replicate로 분리
패턴 B: Warm은 archive tier 전용
Hot bucket: ILM Transition O
Warm tier bucket: app 직접 접근 X, replication X첨부 문서도 target에서 완전한 독립 읽기가 필요하면 Hot bucket에는 replication만 두고 ILM transition을 제외하거나, Warm tier bucket은 archive 전용으로 두는 패턴을 제시합니다.
4. EdgeSyncBeforeExpiry의 의미
--edge-sync-before-expiry는 ILM expiry가 replication 완료 전에 source object를 삭제하는 것을 막기 위한 옵션입니다. 공식 CLI 문서도 이 옵션이 ILM expiration rule이 target으로 replication되기 전에 object를 삭제하지 못하게 한다고 설명합니다. (MinIO AIStor Documentation)
하지만 이 옵션을 오해하면 안 됩니다.
이 옵션은 expiry 삭제 전에 replication 완료를 기다리는 기능이지, transition된 object를 full data copy로 replication target에 만들어주는 기능이 아닙니다. 즉, stub-only 복제 문제를 해결하는 옵션은 아닙니다.
또 하나의 주의점은 backlog입니다. replication backlog가 많이 쌓이면 EdgeSyncBeforeExpiry=true 상태에서는 expiry가 계속 보류될 수 있습니다. 그러면 Hot 용량이 임계치에 가까워져도 ILM expiry가 작동하지 않는 것처럼 보일 수 있습니다. 첨부 문서도 이 경우 Hot capacity alert와 replication backlog monitoring을 같이 설정하라고 설명합니다.
추가로, lifecycle expiration으로 삭제된 object는 일반 client-driven delete와 다르게 replication되지 않는다는 점도 중요합니다. 공식 문서는 MinIO AIStor가 lifecycle expiration rule로 삭제된 object는 replicate하지 않으며, active-active 구성에서는 각 replication bucket에 같은 expiration rule을 설정하라고 설명합니다. (MinIO AIStor Documentation)
정리하면:
client delete → replicate delete/delete-marker 옵션으로 복제 가능
ILM expiry delete → 일반 delete replication으로 전파된다고 보면 안 됨
edge-sync-before-expiry → expiry 전 replication 완료 여부를 확인하는 안전장치5. Warm tier target bucket 설계
Warm cluster 안에서도 bucket 역할을 구분해야 합니다.
5-1. ILM remote tier target bucket
Hot에서 ILM transition으로 사용하는 Warm bucket은 Hot AIStor가 관리하는 remote tier target입니다. 이 bucket은 일반 app이 직접 접근하거나, 별도 lifecycle rule을 걸거나, 수동 삭제/수정하는 대상으로 보면 안 됩니다. 공식 문서는 remote tier data에 대해 exclusive access가 필요하며, external mutation/delete나 remote bucket 자체 lifecycle rule이 없어야 자동 transition과 transparent retrieval이 정상 동작한다고 설명합니다. (MinIO AIStor Documentation)
따라서 이 bucket은 다음처럼 운영하는 것이 안전합니다.
warm-tier-target-bucket
- app 직접 read/write 금지
- 별도 ILM expiration 금지
- 별도 tiering 금지
- 운영자 수동 삭제 금지
- Hot AIStor lifecycle user만 read/write/delete 권한5-2. 일반 Warm archive bucket
반면 Warm cluster에 별도의 일반 archive bucket을 만들고, 거기에 application이나 batch job이 직접 저장하는 구조라면 이야기가 다릅니다. 이 bucket은 ILM remote tier target이 아니므로 별도 expiration rule을 설정할 수 있습니다.
즉, 문서의 Type C “Warm only archive”는 두 가지로 나눠서 이해해야 합니다.
| Warm bucket 유형 | 별도 ILM expiration 가능 여부 |
|---|---|
| Hot ILM의 remote tier target bucket | 원칙적으로 금지 |
| 별도 archive 용도 Warm-only bucket | 가능 |
이 구분이 없으면 Warm tier에서 의도치 않게 source Hot의 transitioned data를 삭제해 장애를 만들 수 있습니다.
6. Bucket Type A/B/C 해석
첨부 문서의 bucket 설계 표는 다음처럼 이해하면 됩니다.
Type A: 활성 데이터 bucket
Type A는 Hot에 계속 남아야 하는 bucket입니다.
위치: Hot only
Replication: 사용
ILM transition: 미사용
Versioning: 사용
목적: HA/DR/중요 데이터 보호사용 예시는 현재 분석 workload에서 자주 읽고 쓰는 dataset, 장애 시 다른 site에서 직접 읽어야 하는 데이터, RPO/RTO가 중요한 데이터입니다.
이 bucket은 replication target에서 직접 읽을 수 있어야 하므로 ILM transition을 섞지 않는 것이 안전합니다.
Type B: 수명 관리 bucket
Type B는 일정 기간 지난 데이터를 Warm으로 이동하는 bucket입니다.
위치: Hot → Warm
ILM transition: 사용
ILM expiration: 필요 시 사용
Versioning: 선택
Replication: 함께 사용 가능하지만 주의 필요이 bucket에서는 “replication target을 직접 읽을 것인지”가 핵심입니다.
직접 읽어야 한다면 replication과 ILM을 분리해야 합니다. 직접 읽지 않고 DR 보조/metadata 보존 목적이라면 같이 사용할 수 있지만, stub-only 복제와 EdgeSyncBeforeExpiry 영향을 설계에 반영해야 합니다.
Type C: 아카이브 bucket
Type C는 Warm에만 존재하는 archive bucket입니다.
위치: Warm only
Versioning: 보통 disabled
Replication: 보통 disabled
ILM transition: 없음
ILM expiration: archive 정책에 따라 가능단, 앞에서 말한 것처럼 Hot ILM의 remote tier target bucket을 Type C archive bucket처럼 직접 운영하면 안 됩니다. remote tier target bucket은 Hot AIStor가 독점 관리해야 합니다. (MinIO AIStor Documentation)
7. Prefix 기반 ILM 정책
Prefix 기반 tiering은 같은 bucket 안에서 특정 prefix만 더 빨리 Warm으로 보내는 방식입니다.
예를 들면:
# bucket 전체는 365일 후 Warm
mc ilm rule add HOT_ALIAS/BUCKET_NAME \
--transition-days 365 \
--transition-tier WARM_TIER
# archive/ prefix는 30일 후 Warm
mc ilm rule add HOT_ALIAS/BUCKET_NAME \
--transition-days 30 \
--prefix "archive/" \
--transition-tier WARM_TIER첨부 문서의 핵심 주의점은 prefix rule의 transition 기간이 bucket default rule보다 짧아야 의미가 있다는 것입니다. default가 365일이고 prefix가 30일이면 archive/는 30일에 이동합니다. 반대로 default가 30일이고 prefix가 365일이면 default가 먼저 적용되어 prefix도 30일에 이동될 수 있습니다.
운영 관점에서는 처음부터 bucket 전체에 rule을 거는 것보다, 대규모 object가 있는 환경에서는 prefix별로 순차 적용하는 것이 안전합니다. scanner와 transition queue 부하를 분산할 수 있기 때문입니다.
8. Versioning 운영 전략
8-1. Versioning은 필요한 bucket에만 켜는 것이 안전
Versioning은 “이전 버전을 보존한다”는 장점이 있지만, object가 자주 overwrite되는 workload에서는 storage, metadata, scanner, healing 부하가 커집니다. 첨부 문서도 version 수가 늘면 object data 전체가 버전 수만큼 저장되고, xl.meta가 커지며, scanner/list/healing 부담이 증가한다고 설명합니다.
공식 문서도 versioning enabled bucket에서 PUT은 새 full version을 만들고, DELETE는 0-byte delete marker를 latest version으로 만드는 soft delete 동작을 한다고 설명합니다. (MinIO AIStor Documentation)
즉, versioning bucket에서 단순히 object를 삭제해도 실제 data가 바로 사라진다고 보면 안 됩니다. delete marker가 생기고, 기존 version은 noncurrent version cleanup rule이 있어야 정리됩니다.
8-2. Replication bucket은 versioning이 필요
AIStor bucket replication은 versioning을 필요로 합니다. 공식 문서도 replication과 resynchronization을 위해 versioning이 필요하며, source와 remote bucket의 versioning 상태를 확인하고 필요 시 enable하라고 설명합니다. 또한 source bucket에서 versioning excluded prefix/folder를 지정하면 그 prefix/folder의 object는 replication할 수 없다고 되어 있습니다. (MinIO AIStor Documentation)
따라서 replication 대상 bucket에서는 다음을 확인해야 합니다.
mc version info HOT_ALIAS/BUCKET
mc version info TARGET_ALIAS/BUCKET그리고 필요한 경우:
mc version enable HOT_ALIAS/BUCKET
mc version enable TARGET_ALIAS/BUCKET8-3. Versioning을 켰다면 noncurrent cleanup rule은 사실상 필수
첨부 문서의 --noncurrent-expire-days 또는 --noncurrent-expire-newer는 version 누적을 막기 위한 핵심입니다. 예를 들어 최신 noncurrent version 3개만 유지하거나, 90일 이상 된 noncurrent version을 삭제하면서 최신 5개는 보존하는 방식입니다.
예시는 다음과 같습니다.
# 최신 noncurrent version 3개만 유지
mc ilm rule add HOT_ALIAS/BUCKET_NAME \
--noncurrent-expire-newer 3
# 90일 이상 된 noncurrent version 삭제, 단 최신 5개는 유지
mc ilm rule add HOT_ALIAS/BUCKET_NAME \
--noncurrent-expire-days 90 \
--noncurrent-expire-newer 5다만 공식 lifecycle 문서 기준으로 versioned bucket에서 current version expiry는 delete marker를 만들고, noncurrent version 삭제는 --noncurrent-expire-days 같은 별도 rule이 필요합니다. delete marker 자체도 별도 cleanup rule 없이는 남을 수 있습니다. (MinIO AIStor Documentation)
9. Object Locking / WORM
Object Lock은 WORM, 즉 보존 기간 동안 삭제나 overwrite를 막는 기능입니다. COMPLIANCE는 root를 포함한 누구도 보존 기간 전 해제할 수 없는 가장 강한 모드이고, GOVERNANCE는 s3:BypassGovernanceRetention 권한이 있는 관리자가 우회할 수 있는 모드입니다. 공식 문서도 GOVERNANCE와 COMPLIANCE의 차이를 이 기준으로 설명합니다. (MinIO AIStor Documentation)
9-1. Object Lock과 versioning은 같이 봐야 함
Object Lock은 versioned object를 보호하는 기능입니다. 공식 문서도 object locking은 versioning이 필요하고, bucket 생성 시 object locking을 enable하면 versioning이 자동으로 enable된다고 설명합니다. (MinIO AIStor Documentation)
첨부 문서에는 “Object Lock은 bucket 생성 시에만 활성화 가능”이라고 되어 있습니다. 다만 현재 공식 문서에는 RELEASE.2025-05-20T20-30-00Z부터 AIStor Client를 통해 기존 bucket에도 object locking/retention rule을 설정할 수 있다고 되어 있습니다. 이 부분도 첨부 문서와 현재 공식 문서 사이에 차이가 있으므로, 실제 사용 중인 AIStor 버전에서 지원되는지 MinIO에 확인해야 합니다. (MinIO AIStor Documentation)
9-2. Object Lock은 ILM expiry보다 우선
Object Lock이나 Legal Hold가 걸린 object는 ILM expiry가 있어도 보존 기간 전에는 삭제되지 않습니다. 공식 문서도 expiration rule이 active object lock/retention setting을 존중하며, noncurrent version도 retention 기간이 지나거나 legal hold가 해제된 후에만 expire될 수 있다고 설명합니다. (MinIO AIStor Documentation)
따라서 다음 정책은 실제로는 730일 삭제가 아닙니다.
ILM Expiry: 730일 후 삭제
Object Lock: COMPLIANCE 3년이 경우 object는 730일째 삭제되지 않고, 3년 보존 기간 만료 후에야 삭제 가능해집니다. 첨부 문서도 더 긴 보호가 항상 우선한다고 설명합니다.
9-3. Object Lock + Replication
Object Lock된 object를 replication하려면 source와 target bucket 모두 object locking이 enabled되어 있어야 합니다. 공식 replication requirements 문서도 WORM locked object replication을 위해 양쪽 replication bucket 모두 object locking이 enabled되어야 한다고 설명합니다. (MinIO AIStor Documentation)
따라서 WORM bucket을 replication하려면 다음을 사전에 맞춰야 합니다.
source bucket: versioning enabled + object lock enabled
target bucket: versioning enabled + object lock enabled
retention mode/rule: 가능하면 동일하게 정렬COMPLIANCE 모드와 --edge-sync-before-expiry를 같이 쓰면, replication 완료와 보존 기간 만료 조건이 모두 충족되어야 삭제가 진행됩니다. 첨부 문서도 보존 만료 시점이 대량으로 몰리면 expiry backlog가 커질 수 있다고 설명합니다.
10. ILM Transition Worker 튜닝
대규모 bucket에서 많은 object가 동시에 transition 대상이 되면 queue가 포화될 수 있습니다. 첨부 문서는 minio_ilm_transition_pending_tasks, minio_ilm_transition_missed_immediate_tasks, minio_ilm_expiry_pending_tasks 같은 metric을 보라고 설명합니다.
공식 ILM settings 문서 기준으로 transition worker와 expiration worker는 각각 MINIO_ILM_TRANSITION_WORKERS, MINIO_ILM_EXPIRATION_WORKERS로 설정 가능하며, 값 범위는 1~500이고 기본값은 100입니다. 환경변수와 mc admin config set이 모두 설정된 경우 환경변수가 우선합니다. (MinIO AIStor Documentation)
다만 worker를 늘린다고 항상 좋은 것은 아닙니다. worker를 늘리면 Hot disk, Warm disk, network, scanner, metadata 처리 부하가 같이 증가할 수 있습니다. 특히 object 수가 매우 많은 환경에서는 처음부터 큰 범위에 ILM을 걸기보다 prefix 단위로 나눠 적용하고, metric을 보면서 worker를 조정하는 방식이 안전합니다.
11. Restore 운영 시 주의점
mc ilm restore는 Warm tier로 이동된 object를 Hot으로 임시 복원하는 기능입니다. 공식 문서도 사용자가 고정된 기간 동안 object data를 primary tier로 임시 복원할 수 있고, 시간이 지나면 AIStor가 다시 secondary tier로 돌려보내며 영구 복원은 지원하지 않는다고 설명합니다. (MinIO AIStor Documentation)
따라서 restore는 “Warm에서 Hot으로 영구 회수”가 아닙니다.
mc ilm restore HOT_ALIAS/BUCKET/path/to/object --days 7이렇게 하면 7일 동안 Hot copy가 유지되고, 기간이 지나면 다시 Warm tier 상태로 돌아갑니다. 첨부 문서는 replication 대상 bucket에서 restore된 hot copy가 replication되어 불필요한 traffic이 발생할 수 있다고도 경고합니다.
12. 모니터링 포인트
운영 시 최소한 아래 항목은 alert로 잡는 것이 좋습니다.
| 영역 | 봐야 할 항목 | 의미 |
|---|---|---|
| Hot capacity | Hot 사용률 80% 이상 | ILM/expiry/replication 지연 시 위험 |
| ILM transition | minio_ilm_transition_pending_tasks 증가 | transition queue 적체 |
| ILM transition miss | minio_ilm_transition_missed_immediate_tasks 증가 | 즉시 처리 못한 transition 누락 |
| Tier journal | minio_ilm_expiry_missed_tier_journal_tasks 증가 | Hot에 orphan data가 남을 가능성 |
| Replication | replication backlog 증가 | expiry 지연, DR lag 증가 |
| Versioning | s3:ObjectManyVersions, s3:ObjectLargeVersions | version 누적으로 성능/용량 영향 |
| Object Lock | retention 만료 예정 object 수 | 만료 시점 집중 시 expiry backlog |
첨부 문서의 체크리스트도 replication backlog, Hot capacity, tier journal 실패, version 누적 이벤트, object lock 보존 기간 충돌을 주요 확인 항목으로 제시합니다.
13. 운영 설계상 재확인해야 할 애매한 부분
MinIO에 다시 확인하면 좋은 항목은 아래입니다.
-
--transition-days최소값
첨부 문서에는 최소 1일이라고 되어 있지만, 현재 공식 CLI 문서에는 AIStor remote tier의 경우0도 가능하다고 되어 있습니다. 실제 배포 버전에서0지원 여부와 scanner 동작 기준을 확인해야 합니다. (MinIO AIStor Documentation) -
기존 bucket에 Object Lock 적용 가능 여부
첨부 문서에는 bucket 생성 시에만 가능하다고 되어 있지만, 현재 공식 문서에는 AIStorRELEASE.2025-05-20T20-30-00Z이후 기존 bucket에도 AIStor Client로 설정 가능하다고 되어 있습니다. 사용 중인 AIStor 버전 기준 확인이 필요합니다. (MinIO AIStor Documentation) -
ILM tier target bucket과 일반 Warm archive bucket의 구분
Hot ILM이 사용하는 remote tier target bucket에는 별도 lifecycle rule이나 직접 접근을 두지 않는 것이 원칙입니다. 별도 expiration이 필요한 archive는 remote tier target과 다른 bucket/prefix로 분리해야 합니다. (MinIO AIStor Documentation) -
Replication target에서 직접 read가 필요한지 여부
직접 read가 필요하면 ILM transition과 replication을 같은 bucket에 섞지 않는 것이 안전합니다. stub-only 복제 때문에 target에서 object read 오류가 날 수 있습니다. -
Lifecycle expiry 삭제를 target에도 반영할 방식
lifecycle expiration으로 삭제된 object는 일반 replication delete처럼 전파된다고 보면 안 됩니다. replication target에도 동일한 retention/expiration 정책을 둘지, 별도 purge 절차를 둘지 결정해야 합니다. (MinIO AIStor Documentation)
제 기준의 최종 권고는 이렇습니다. DR/독립 read가 필요한 bucket은 Hot-only + replication으로 두고, 비용 절감을 위한 ILM tiering bucket은 별도 Type B로 분리하는 것이 가장 안전합니다. Warm tier target은 Hot AIStor가 관리하는 전용 bucket으로 두고, app 직접 접근이나 별도 ILM은 피하는 구조가 좋습니다.
