26M15c
첨부된 두 사례를 2-tier 가이드 기준으로 보면, 고객사 D는 “보호/복제 중심의 Hot-only 운영 사례”로 참고 가치가 크고, 고객사 A는 “Iceberg/Dremio 같은 고변경 워크로드에서 Versioning/Object Lock을 잘못 적용하면 어떤 문제가 생기는지 보여주는 반면교사”로 보는 것이 맞습니다.
핵심 결론은 아래와 같습니다.
| 사례 | 2-tier Hot/Warm 구성에 대한 평가 | 그대로 적용 가능 여부 |
|---|---|---|
| 고객사 D | VOD/Video Vault처럼 큰 파일을 보호하고 3-way replication하는 Type A: 활성 데이터 bucket 사례에 가까움 | 부분 적용 가능. 단, 같은 bucket에 Hot→Warm ILM Transition을 추가하면 위험 |
| 고객사 A | Iceberg/Dremio/ML처럼 overwrite/delete가 많은 Data Lakehouse 워크로드에서 Versioning, Delete Marker, Object Lock, ILM 정리 이슈를 잘 보여줌 | 운영 교훈으로 매우 중요. 다만 Object Lock과 purge rule은 신중히 선별 적용 필요 |
1. 고객사 D 사례 평가
1-1. Versioning 적용은 “Video Vault” 목적에는 적절함
고객사 D는 비디오 파일 변경/삭제 시 이전 버전을 보존하고, 실수나 공격으로 인한 영구 손실을 방지하기 위해 bucket 생성 시 versioning을 활성화했습니다. 일반 delete는 delete marker를 만들고, versionId를 명시한 삭제는 영구 삭제로 처리되는 구조입니다.
이 방식은 VOD 콘텐츠, 중요 미디어 파일, 변경 빈도가 낮고 파일 크기가 큰 object에는 적절합니다. 사용자가 파일을 잘못 삭제해도 delete marker 이전 버전을 복구할 수 있기 때문입니다.
다만 이 방식을 Iceberg table, Spark 임시 파일, Dremio backup, checkpoint, staging path 같은 고변경 workload에 그대로 적용하면 위험합니다. 고객사 A 사례처럼 delete marker와 non-current version이 폭증할 수 있습니다. 고객사 A는 잦은 overwrite/delete 환경에서 1.8억 개 delete marker가 누적된 사례를 보고했습니다.
평가:
고객사 D 방식은 “중요하고 변경 빈도가 낮은 콘텐츠 bucket”에는 좋지만, Data Lakehouse 전체 bucket에 일괄 적용할 방식은 아닙니다.
1-2. --noncurrent-expire-days 90 정책은 적절하지만, “tiering”은 아님
고객사 D는 non-current version을 90일 후 삭제하는 ILM을 적용했습니다. 문서상 이 정책은 non-current 상태가 된 시점부터 90일 후 만료되며, current version에는 영향을 주지 않습니다.
이 정책은 versioning bucket에서 반드시 필요한 용량 관리 장치입니다. 공식 문서도 versioned bucket에서 일반 --expire-days는 current version에만 적용되고, non-current version 정리는 --noncurrent-expire-days 또는 유사 옵션을 사용해야 한다고 설명합니다. (MinIO AIStor Documentation)
하지만 여기서 주의할 점은, 이 정책은 Hot→Warm tiering이 아니라 non-current version 삭제 정책이라는 점입니다. 즉, 고객사 D 사례는 “2-tier ILM Transition 사례”가 아니라 Hot bucket 내부의 version 수명 관리 사례입니다.
2-tier에서 이 사례를 적용하려면 다음처럼 구분해야 합니다.
D 사례의 ILM:
non-current version 90일 후 삭제
2-tier ILM Transition:
current 또는 non-current object/version을 Warm tier로 이동평가:
--noncurrent-expire-days 90은 좋은 정책이지만, Hot 용량 절감을 위해 Warm tier로 데이터를 이동하는 정책과는 별개입니다. Warm tier를 쓰려면 별도 --transition-days, --transition-tier 정책이 필요합니다.
1-3. Object Lock 대신 IAM DenyDeleteObjectVersion을 쓴 것은 “현실적인 우회책”이지만 WORM은 아님
고객사 D는 “파일이 non-current가 되는 시점부터 compliance lock을 시작하고, 잠금 기간 동안 admin도 삭제하지 못하게 하고 싶다”는 요구를 가졌습니다. 하지만 S3 Object Lock의 retention 기준은 non-current 전환 시점이 아니라 object version 생성 시점 기준이므로, 요구사항 그대로는 S3 spec과 맞지 않는다고 정리되어 있습니다. 그래서 최종적으로는 s3:DeleteObjectVersion을 IAM Policy로 deny하여 versionId 명시 삭제를 막는 방식을 채택했습니다.
이 접근은 실무적으로 유용합니다.
{
"Effect": "Deny",
"Action": ["s3:DeleteObjectVersion"],
"Resource": ["arn:aws:s3:::bucket/*"]
}이렇게 하면 일반 delete는 delete marker만 생성하므로 허용하고, versionId를 지정한 영구 삭제는 차단할 수 있습니다.
다만 이것은 Object Lock Compliance Mode와 동일한 보호가 아닙니다. IAM 정책은 관리자 권한, 정책 변경 권한, root/console 운영 방식에 따라 우회 가능성이 있습니다. 반면 COMPLIANCE Object Lock은 보존 기간 전에는 root를 포함해 해제할 수 없는 WORM 보호입니다. Object Lock된 object를 replication하려면 source와 target bucket 모두 object locking이 활성화되어 있어야 합니다. (MinIO AIStor Documentation)
평가:
고객사 D의 IAM 방식은 “실수 방지 + 일반 운영자 삭제 방지”에는 적절하지만, 규제/감사 목적의 진짜 WORM으로 보면 안 됩니다. 진짜 compliance가 필요하면 Object Lock을 별도 bucket 설계로 가져가야 합니다.
1-4. 3-way Active-Active Replication은 Type A에는 적합하지만, Hot→Warm tiering과 섞으면 위험
고객사 D는 VOD bucket을 3개 site 간 active-active 형태로 복제하고, Sidekick/LB, replication backlog 확인, replication 수신 trace 등을 운영했습니다.
이 구조는 2-tier 가이드의 Type A: 활성 데이터 bucket에 가깝습니다.
Type A: 활성 데이터
- 위치: Hot only
- Versioning: Enabled
- Replication: Enabled
- ILM Transition: Disabled
- 목적: HA / DR / 독립 read 가능 copy가이드에서도 Type A는 Hot-only + replication 구조로 분류되어 있고, Type B인 Hot→Warm ILM bucket은 replication과 함께 쓸 수는 있지만 transitioned object는 target에 stub만 복제될 수 있다고 경고합니다.
이게 가장 중요한 포인트입니다.
고객사 D의 3-way replication bucket에 나중에 Hot→Warm ILM Transition을 추가하면, transition된 object는 Hot에 실제 bytes가 없고 metadata/stub만 남습니다. 이 상태에서 replication이 동작하면 target에도 stub만 복제될 수 있고, target cluster가 Warm tier에 접근하지 못하면 직접 GetObject가 실패할 수 있습니다. 2-tier 가이드도 이 stub-only replication 문제를 명확히 경고하고 있습니다.
따라서 D 사례를 2-tier에 적용할 때는 아래 둘 중 하나가 안전합니다.
안전 패턴 A
중요 VOD / 직접 serving / DR 필요 bucket:
Hot only + Replication
ILM Transition 없음
안전 패턴 B
오래된 archive:
별도 bucket 또는 prefix를 Hot → Warm ILM Transition
이 bucket은 replication target에서 직접 read하는 용도로 쓰지 않음평가:
고객사 D의 replication 운영 방식은 좋지만, 동일 bucket에 Hot→Warm ILM Transition을 추가하면 안 됩니다. DR site에서 독립적으로 읽어야 하는 bucket은 Hot-only replication으로 유지하는 것이 맞습니다.
1-5. Replication + ILM Expiry를 같이 쓴다면 --edge-sync-before-expiry가 필요
고객사 D는 versioning + non-current expiry + replication을 함께 씁니다. 이 경우 replication이 끝나기 전에 ILM expiry가 먼저 삭제를 수행하면 target이 해당 version을 받지 못할 수 있습니다.
2-tier 가이드는 EdgeSyncBeforeExpiry=true를 권장하고, 이 옵션이 없으면 scanner가 expiry 조건을 보고 먼저 삭제하면서 replication pending object가 target에 영원히 가지 못하는 상황을 설명합니다.
공식 문서도 --edge-sync-before-expiry가 ILM expiration rule이 target으로 replication되기 전 object를 삭제하지 않도록 막는 옵션이라고 설명합니다. (MinIO AIStor Documentation)
또 하나 중요한 점은, lifecycle expiration으로 삭제된 object는 일반 client-driven delete처럼 replication되지 않습니다. 공식 문서도 bucket replication에서 명시적 client delete는 복제되지만 lifecycle expiration으로 삭제된 object는 복제되지 않으며, active-active 구성에서는 각 replication bucket에 동일한 expiration rule을 설정해야 한다고 설명합니다. (MinIO AIStor Documentation)
평가:
D 사례처럼 replication과 ILM expiry가 함께 있으면, 각 site의 lifecycle rule 일치 여부와 --edge-sync-before-expiry 적용 여부를 반드시 확인해야 합니다.
2. 고객사 A 사례 평가
2-1. A 사례는 Data Lakehouse workload에 훨씬 더 직접적인 경고 사례
고객사 A의 workload는 Iceberg table, Dremio backup, ML/분석 파이프라인입니다. 이는 현재 사용자가 검토 중인 Cloud Native Data Lakehouse 환경과 성격이 더 비슷합니다. 문서에서도 Python 기반 application, Iceberg vacuum, Dremio backup처럼 object overwrite/delete가 잦은 workload에서 versioning을 사용했다고 되어 있습니다.
여기서 나온 핵심 교훈은 명확합니다.
고변경 workload + Versioning
→ delete marker 증가
→ non-current version 증가
→ scanner/list/healing/metadata 부담 증가
→ storage 사용량 예측 실패고객사 A는 delete marker가 대량 누적되었고, 이를 정리하기 위해 여러 ILM rule과 batch expiry를 시도했습니다.
평가:
A 사례는 “따라 할 모범 사례”라기보다, Data Lakehouse bucket에 versioning/object lock을 무분별하게 켜면 어떤 운영 문제가 생기는지 보여주는 사례입니다.
2-2. Iceberg/Dremio bucket에는 Versioning을 기본값으로 켜면 안 됨
Iceberg는 snapshot, manifest, data file 정리를 자체 table maintenance와 vacuum/expire_snapshots 로직으로 수행합니다. 그런데 bucket versioning이 켜져 있으면 application이 삭제한 object가 실제로는 지워지지 않고 delete marker와 non-current version으로 남습니다.
고객사 A도 Iceberg vacuum이 삭제한 파일들이 delete marker로 남아 storage를 차지하는 문제를 해결하는 데 가장 많은 시간을 썼습니다.
따라서 Iceberg/Dremio/ML pipeline bucket은 아래처럼 분리하는 것이 안전합니다.
권장:
- Iceberg table data bucket: Versioning Disabled 또는 제한적 적용
- 중요 metadata/audit bucket: Versioning Enabled
- backup/DR bucket: Replication 요구 시 Versioning Enabled
- tmp/log/cache/staging prefix: Versioning 제외 또는 별도 bucket공식 문서상 versioning은 replication에 필요하지만, versioning 자체가 object locking을 의미하지는 않습니다. 또 versioning을 켜면 object당 매우 많은 version이 허용될 수 있으므로, 필요 없는 version을 제거하는 expiration rule을 함께 정의해야 합니다. (MinIO AIStor Documentation)
평가:
A 사례의 가장 중요한 교훈은 “Data Lakehouse 전체에 versioning을 일괄 적용하지 말라”입니다. bucket/prefix별로 목적을 나눠야 합니다.
2-3. Delete Marker 정리는 rule의 의미를 정확히 구분해야 함
고객사 A는 delete marker 정리를 위해 여러 규칙을 시도했습니다.
가장 단순한 --expire-delete-marker는 일부 케이스에서 동작하지 않았습니다. 이유는 non-current version이 남아 있으면 delete marker만 단독 삭제할 수 없기 때문입니다. 실제로 공식 문서도 --expire-delete-marker는 delete marker가 유일하게 남은 version일 때 제거하는 옵션이라고 설명합니다. (MinIO AIStor Documentation)
고객사 A의 Object Lock 없는 bucket에서는 아래 조합이 최종 해결책으로 정리되어 있습니다.
mc ilm rule add minio/<bucket> \
--purge-all-object-versions-days 1 \
--purge-all-object-versions-delete-marker이 정책은 topmost version이 delete marker인 object에 대해 delete marker와 하위 version을 함께 정리하는 방식입니다.
하지만 이 정책은 “application이 이미 삭제했다고 판단한 object를 실제로 완전히 제거”하는 데 적합한 정책입니다. 모든 bucket에 일반 적용하면 안 됩니다.
특히 Iceberg에서는 다음 순서가 안전합니다.
1. Iceberg engine에서 expire_snapshots / remove_orphan_files / vacuum 수행
2. object store에는 delete marker 또는 non-current version이 남음
3. ILM 또는 batch expiry로 topmost delete marker 대상만 정리반대로 object store ILM이 단순히 “오래된 파일”을 먼저 지우면 Iceberg table metadata가 아직 참조 중인 파일을 삭제할 위험이 있습니다.
평가:
A 사례의 purge rule은 강력하지만 위험합니다. Iceberg/Dremio bucket에는 application lifecycle이 끝난 object, 즉 topmost delete marker 상태의 object 정리에 한정해서 써야 합니다.
2-4. Object Lock을 Iceberg bucket에 켜는 것은 피해야 함
고객사 A는 Object Lock이 의도치 않게 활성화된 bucket에서 ILM 적용 제약을 겪었습니다. Object Lock bucket에는 특정 AllVersionsExpiration, DelMarkerExpiration rule을 적용할 수 없었고, 결국 Batch Expiry Framework를 우회책으로 사용했습니다.
2-tier 가이드도 Object Lock과 ILM은 독립적으로 동작하지만, retention 중인 object version은 ILM expiry 대상이 되지 않고 retention 만료 후에야 ILM 삭제가 가능하다고 설명합니다.
따라서 Iceberg/Dremio/ML pipeline 같은 고변경 workload에서는 Object Lock을 기본적으로 피하는 것이 맞습니다.
Object Lock 권장:
- 규제 컴플라이언스
- 감사 로그
- 장기 보존 증적
- 법적 보존 대상
Object Lock 비권장:
- Iceberg table data
- Spark temporary/staging path
- Dremio backup rotation path
- ML checkpoint가 자주 overwrite되는 path다만 첨부 사례와 가이드에는 “Object Lock은 bucket 생성 시에만 가능”하다고 되어 있는데, 현재 AIStor 문서 기준으로는 RELEASE.2025-05-20T20-30-00Z부터 기존 bucket에도 object locking과 retention rule 설정이 가능하다고 안내되어 있습니다. 즉, 이 부분은 사용 중인 AIStor 버전에 따라 달라질 수 있으므로 반드시 실제 버전 기준으로 확인해야 합니다. (MinIO AIStor Documentation)
평가:
A 사례는 Object Lock을 사전에 설계 없이 켜면 ILM 운영이 매우 복잡해진다는 강한 경고입니다. 현재 버전에서 기존 bucket 적용 가능 여부와 별개로, Iceberg 계열 bucket에는 Object Lock을 기본 적용하지 않는 것이 안전합니다.
2-5. Batch Expiry는 “대량 정리 도구”로 유용하지만 상시 ILM 대체재는 아님
고객사 A는 Object Lock bucket 또는 기존에 누적된 delete marker/version 정리를 위해 Batch Expiry를 사용했습니다. 문서상 batch expiry는 delete marker가 topmost version인 object와 하위 version을 일괄 삭제하는 방식으로 활용되었습니다.
공식 문서에서도 batch expiration은 purge 시 유지할 version 수를 지정할 수 있고, 기본적으로 0이면 모든 version을 삭제하는 방식으로 동작합니다. (MinIO AIStor Documentation)
이 도구는 유용하지만, 운영 관점에서는 매우 조심해야 합니다.
적합한 용도:
- 이미 쌓인 delete marker / non-current version 일회성 정리
- 특정 prefix 단위 cleanup
- ILM으로 처리하기 어려운 예외 bucket 정리
부적합한 용도:
- 모든 bucket에 대한 상시 자동 정리
- prefix 검증 없이 광범위 적용
- Iceberg active data에 대한 나이 기반 삭제평가:
Batch Expiry는 “복구/정리 작업 도구”로 가져가야지, 일반적인 lifecycle 설계의 기본 수단으로 보면 안 됩니다.
2-6. A 사례의 replication은 Hot/Warm tiering과 성격이 다름
고객사 A의 replication은 MinIO↔MinIO active-active라기보다, AWS S3, NetApp ONTAP S3 같은 외부 object store로 batch backup/replication하는 요구가 중심입니다. 문서에서도 Azure ADLS/Blob은 S3 비호환 문제로 실패했고, AWS S3와 NetApp ONTAP S3는 Batch Replication으로 성공했다고 되어 있습니다.
이것은 2-tier Hot→Warm ILM Transition과는 목적이 다릅니다.
Hot→Warm ILM Tiering:
- 비용 최적화
- Hot metadata + Warm data 구조
- application은 원칙적으로 Hot endpoint로 접근
Batch Replication / Backup:
- 외부 백업 또는 복사본 생성
- target에 독립 object copy 생성
- 주기적/일괄성 성격공식 문서도 AIStor의 Hot→Warm tiering은 NVMe 기반 Hot deployment에서 SSD 기반 Warm deployment로 object를 transition하는 비용 관리 전략이라고 설명합니다. (MinIO AIStor Documentation)
평가:
A 사례의 batch replication은 외부 백업에는 참고 가능하지만, Warm tier target을 구성하는 방식으로 보면 안 됩니다. Warm tier target bucket은 Hot AIStor가 관리하는 ILM tier target이어야 하고, 일반 backup target과 역할을 분리해야 합니다.
3. 두 사례를 2-tier 설계에 반영하면 이렇게 나눠야 함
3-1. 고객사 D에서 가져올 것
고객사 D에서 가져올 만한 것은 다음입니다.
적용 권장:
- 중요 bucket에 versioning 적용
- non-current version cleanup rule 필수 적용
- versionId 직접 삭제를 IAM으로 제한
- replication backlog, failed object, receive trace 모니터링
- active-active replication 시 각 site lifecycle rule 정렬다만 아래는 그대로 적용하면 안 됩니다.
주의:
- replicated serving bucket에 Hot→Warm ILM Transition을 섞지 않기
- IAM DenyDeleteObjectVersion을 Compliance Object Lock으로 오해하지 않기
- non-current expiry만으로 Hot/Warm tiering이 된다고 착각하지 않기3-2. 고객사 A에서 가져올 것
고객사 A에서 가져올 만한 것은 다음입니다.
적용 권장:
- Iceberg/Dremio/ML bucket에는 versioning을 선별 적용
- tmp/cache/staging/high-churn prefix는 versioning 제외 또는 별도 bucket화
- delete marker / non-current version 누적을 사전에 모니터링
- 이미 쌓인 version/delete marker는 batch expiry로 일회성 정리
- Object Lock bucket은 별도 WORM 목적 bucket으로만 사용그대로 적용하면 안 되는 것은 다음입니다.
주의:
- Iceberg bucket에 Object Lock 기본 적용 금지
- 모든 bucket에 purge-all-object-versions rule 일괄 적용 금지
- object age만 보고 Iceberg active file 삭제 금지
- Batch Expiry를 일반 ILM 대체재로 오해 금지4. 사용자 환경 기준 권장 bucket 분류
현재처럼 Hot NVMe AIStor + Warm SSD AIStor 2-tier를 구성한다면, 사례 D/A를 섞어 아래처럼 설계하는 것이 가장 안전합니다.
| Bucket 유형 | Versioning | Replication | ILM Transition | ILM Expiry | Object Lock |
|---|---|---|---|---|---|
| 중요 Active/DR bucket | Enabled | Enabled | Disabled | non-current cleanup | 선택 |
| VOD/대형 콘텐츠 serving bucket | Enabled | Enabled | Disabled 권장 | non-current cleanup | 필요 시 |
| 오래된 archive 이동 bucket | 선택 | 보통 Disabled | Enabled, Hot→Warm | 필요 시 | 보통 Disabled |
| Iceberg table data bucket | 보통 Disabled 또는 제한적 | 요구 시만 | 신중히 prefix 단위 | app vacuum 이후 cleanup | 비권장 |
| Spark/Dremio tmp/staging | Disabled | Disabled | 보통 불필요 | 짧은 expiration | Disabled |
| Warm tier target bucket | Disabled 권장 | Disabled | N/A | 별도 설정 금지 권장 | 비권장 |
| 규제/WORM bucket | Enabled | 필요 시 Enabled | 가능하지만 신중 | retention 이후 | Enabled |
가이드의 bucket 타입 기준으로 보면, Type A는 Hot-only + replication, Type B는 Hot→Warm ILM, Type C는 Warm-only archive입니다. 특히 Type B에서 replication을 함께 쓰면 transitioned object가 target에 stub만 복제될 수 있다는 점을 설계에 반영해야 합니다.
5. 최종 평가
고객사 D 사례는 “DR/HA가 필요한 중요 bucket 운영 방식”으로는 좋은 참고 사례입니다.
하지만 이 사례는 본질적으로 Hot-only + versioning + replication + non-current expiry 구조입니다. 여기에 Hot→Warm ILM Transition을 같은 bucket에 추가하면, 2-tier 가이드에서 경고한 stub-only replication 문제가 발생할 수 있습니다. 따라서 D 사례는 Type A bucket에만 적용하고, tiering 대상은 별도 Type B bucket/prefix로 분리하는 것이 안전합니다.
고객사 A 사례는 사용자의 Data Lakehouse 환경에 더 직접적인 경고입니다.
Iceberg, Dremio, ML pipeline처럼 object 변경과 삭제가 많은 workload에서는 versioning과 Object Lock이 storage 폭증, delete marker 누적, ILM 제약, scanner 부하로 이어질 수 있습니다. A 사례의 핵심 교훈은 “versioning/object lock을 보호 장치로 무조건 켜지 말고, bucket/prefix 단위로 목적을 나눠라”입니다.
최종 권고는 다음과 같습니다.
1. DR/서비스 연속성이 중요한 bucket
→ Hot-only + Replication + Versioning + non-current cleanup
2. 비용 절감을 위한 오래된 데이터
→ 별도 bucket/prefix에서 Hot→Warm ILM Transition
3. Iceberg/Dremio/ML 고변경 workload
→ Versioning/Object Lock 기본 비활성화
→ application vacuum 이후 delete marker/non-current cleanup 중심
4. WORM/Compliance 데이터
→ 별도 Object Lock bucket
→ replication target도 lock-enabled
→ ILM expiry보다 retention이 우선함을 전제로 용량 산정즉, D 사례는 보호/복제 설계의 참고 사례, A 사례는 Data Lakehouse에서 피해야 할 실수와 cleanup 운영의 참고 사례로 활용하는 것이 가장 적절합니다.
