26M20a

Young-Kyoo Kim·2026년 5월 19일

문서의 큰 방향은 맞지만, 운영 설계서로 쓰기 전에는 몇 군데를 반드시 수정/검증해야 합니다. 특히 “Replication + ILM Tiering + DR”, “Warm Tier bucket의 역할”, “Object Lock 최신 동작”, “Versioning/ExcludedPrefixes/Replication 상호작용”은 그대로 적용하면 장애 복구 시나리오가 깨질 수 있습니다.

1. 가장 큰 이견: “DR 용도면 Replication + ILM Tiering을 같은 버킷에서 써도 유효”라는 부분

문서에서는 transition이 끝난 오브젝트는 Hot cluster에 실제 bytes 없이 xl.meta stub만 남고, 이 상태에서 replication되면 target cluster에도 stub만 복제되며 target에서 직접 읽으면 오류가 발생한다고 설명합니다. 그런데 바로 뒤에서는 “target에서 완전한 독립 읽기가 요구되지 않는 경우, 예: target이 재해 복구 목적으로만 사용되는 경우, Replication과 ILM Tiering을 같은 버킷에서 함께 사용하는 것은 유효”하다고 되어 있습니다. 이건 앞뒤가 위험하게 충돌합니다.

DR target은 평상시 직접 읽지 않더라도, 재해 시에는 결국 target에서 읽거나 resync/restore의 기준이 되어야 합니다. 그런데 문서 설명대로 target이 transitioned object를 직접 읽을 수 없다면, 그 target은 “완전한 DR 사본”이 아닙니다. 공식 문서도 object transition은 backup/recovery 기능을 제공하지 않으며, 원격 tier는 source metadata와 강하게 연결되어 있어 source metadata 손실 시 복구 소스로 쓸 수 없다고 설명합니다. (MinIO AIStor Documentation)

따라서 이 문장은 아래처럼 고쳐야 합니다.

Replication target이 독립 DR 사본이어야 하면, ILM으로 tiering된 stub만 복제되는 구조는 허용하지 않는다. Replication target에서 실제 데이터까지 읽을 수 있는지 POC로 검증하거나, replication 전용 bucket/cluster와 tiering 전용 bucket/cluster를 분리한다.

2. Warm Tier를 “tier target”과 “일반 archive/replication target”으로 동시에 쓰는 듯한 표현이 위험함

문서의 replication 예시에서 --remote-bucket https://USER:SECRET@WARM_ENDPOINT:9000/BUCKET 형태가 나오는데, 이게 Warm Tier를 replication target으로도 쓰는 것처럼 보입니다. 또한 Type C bucket을 “Warm only / archive / expiration 필요 시 설정”처럼 설명합니다.

이 부분은 명확히 분리해야 합니다. 공식 문서는 remote tier bucket에 대해 MinIO AIStor가 exclusive access를 요구하며, remote storage의 object를 외부에서 수정/삭제/마이그레이션하지 말아야 하고, remote bucket 자체에 lifecycle rule을 두지 말아야 한다고 설명합니다. (MinIO AIStor Documentation)

즉, 같은 Warm cluster를 쓰더라도 최소한 아래처럼 분리해야 합니다.

ILM Tier Target bucket/prefix: Hot AIStor ILM만 접근. 앱 직접 접근 금지. warm-side lifecycle 금지. replication target으로도 사용 금지.
일반 Archive bucket: 앱 또는 batch가 직접 쓰는 별도 bucket. 이건 ILM tier target과 섞으면 안 됨.
Replication target bucket: DR/복제용 별도 bucket. tier target bucket과 섞으면 안 됨.

문서의 Type C는 “Warm Tier의 일반 archive bucket”인지, “Hot에서 transition된 object가 저장되는 tier target bucket”인지가 섞여 있습니다. 이 구분은 반드시 문서에 추가해야 합니다.

3. Object Lock은 최신 AIStor 버전 기준으로 문서 내용이 outdated일 수 있음

문서에는 “Object Lock은 버킷 생성 시에만 활성화 가능하고 기존 버킷에는 사후 적용 불가”라고 되어 있습니다. 그런데 현재 공식 AIStor 문서는 RELEASE.2025-05-20T20-30-00Z부터 existing bucket에도 object locking/retention rule을 설정할 수 있다고 설명합니다. 단, 기존 unversioned bucket에 적용하려면 먼저 versioning을 켜야 합니다. (MinIO AIStor Documentation)

다만 공식 문서 내부에도 “S3 behavior상 bucket creation 시 enable”이라고 남아 있는 부분이 있어, 이건 실제 설치 버전 기준으로 MinIO에 확인해야 할 version-specific 항목입니다. (MinIO AIStor Documentation)

문서에는 이렇게 쓰는 게 안전합니다.

Object Lock 기존 버킷 적용 가능 여부는 AIStor Object Store/Client release에 따라 다르다. RELEASE.2025-05-20T20-30-00Z 이후에는 CLI 기준 existing bucket 적용이 가능하다고 문서화되어 있으나, 운영 반영 전 현재 설치 버전과 MinIO support 확인이 필요하다.

4. “Transition 최소 단위 1일”은 현재 문서 기준으로 과도하게 단정적임

문서는 ILM Transition이 최소 1일 이후 평가/이동되며 sub-day tiering은 지원되지 않는다고 합니다. 그런데 공식 mc ilm rule add 문서에는 remote tier가 다른 MinIO AIStor deployment인 경우 --transition-days 0을 설정해 새 object를 즉시 transition eligible 상태로 만들 수 있다고 되어 있습니다. (MinIO AIStor Documentation)

다만 scanner가 저우선순위로 동작하기 때문에 “0일 = 즉시 이동 완료”는 아니고, 실제 이동은 scanner cycle, workload, worker 상태에 따라 지연될 수 있습니다. 공식 문서도 lifecycle scanner가 workload/자원 상황에 따라 rule 적용을 지연할 수 있다고 설명합니다. (MinIO AIStor Documentation)

따라서 문서의 표현은 아래처럼 바꾸는 게 맞습니다.

일반적으로 ILM은 scanner 기반이라 분/초 단위 SLA를 보장하지 않는다. 다만 AIStor→AIStor remote tier에서는 --transition-days 0이 가능한지 현재 버전에서 확인해야 한다. 대량 기존 object 초기 transition은 scanner 지연과 queue 포화를 별도 검증한다.

5. Versioning 전략이 문서 안에서 약간 충돌함

초반에는 ILM tiering과 함께 versioning을 사용할 경우 --noncurrent-expire-days 설정이 필요하다고 되어 있습니다. 그런데 뒤쪽 use-case 표에서는 “Hot tier, ILM 이동 목적: Versioning Enabled, ILM Rule은 Transition rule만”이라고 되어 있습니다.

이건 위험합니다. Replication 때문에 versioning이 켜진 bucket에서 overwrite/delete가 발생하면 noncurrent version과 delete marker가 쌓일 수 있습니다. 공식 문서는 versioned bucket에서 transition rule은 기본적으로 current version에만 적용되고, noncurrent version transition은 --noncurrent-transition-days/--noncurrent-transition-tier가 필요하다고 설명합니다. Expiration도 current version 삭제 시 delete marker를 만들며, noncurrent version 삭제는 --noncurrent-expire-days, delete marker 정리는 --expire-delete-marker 같은 별도 처리가 필요합니다. (MinIO AIStor Documentation)

따라서 “Transition rule만”은 append-only이고 overwrite/delete가 거의 없는 bucket에 한정해야 합니다. 일반 bucket에는 최소 아래 정책 조합이 필요합니다.

current object transition rule
noncurrent version expire rule 또는 newer-retention rule
delete marker cleanup rule
필요 시 noncurrent version transition rule
replication 사용 시 versioning/excluded prefix 영향 검증

6. ExcludedPrefixes 권장은 Replication bucket에서는 매우 조심해야 함

문서는 tmp/, logs/, cache/ 같은 prefix를 versioning에서 제외해 metadata 부담을 줄이라고 권장합니다. 이 자체는 좋은 전략일 수 있지만, replication bucket에서는 치명적인 예외가 됩니다. 공식 문서는 source bucket에서 prefix나 folder를 versioning 제외하면 그 prefix/folder 안의 object는 replication할 수 없다고 설명합니다. (MinIO AIStor Documentation)

또한 --excluded-prefixes는 “prefix/name에 해당 문자열이 포함되는 object”를 매칭할 수 있고, prefix만 정확히 매칭하려면 prefix/* 형식을 쓰라고 되어 있습니다. (MinIO AIStor Documentation) 그래서 문서의 예시는 운영 문서에선 아래처럼 더 명확해야 합니다.

mc version enable HOT_ALIAS/BUCKET_NAME \
  --excluded-prefixes "tmp/*,logs/*,cache/*"

그리고 replication이 필요한 bucket에서는 ExcludedPrefixes를 쓰기 전에 “해당 prefix는 replication/DR 대상에서 제외됨”을 정책 장부에 명시해야 합니다.

7. Restore 동작 설명에 “restored object가 HEAD가 됨”이 빠져 있음

문서는 restore된 사본이 지정 기간 후 자동으로 다시 Warm tier로 돌아가며, 영구 복원은 지원되지 않는다고 설명합니다. 그런데 공식 문서에는 restored copy가 해당 namespace의 HEAD가 된다고 되어 있고, versioning 이력과 무관하게 application이 stale data를 읽을 수 있다고 경고합니다. (MinIO AIStor Documentation)

이건 Spark/Hadoop/AI 학습 데이터셋에서 중요합니다. 특정 version을 restore했는데 그게 HEAD가 되면, 애플리케이션이 기대한 최신 데이터가 아니라 임시 복원본을 읽을 수 있습니다. 문서에 아래 주의사항을 추가해야 합니다.

versioned bucket에서 restore는 반드시 --vid/--versions 사용 여부를 사전에 정의한다. restore된 copy가 HEAD가 되어 application read 결과가 바뀔 수 있으므로, restore 작업은 변경관리/작업계획서 대상이다.

8. Batch Expire 예시 YAML은 현재 공식 예시와 구조가 다름

문서의 Batch Expire 예시는 apiVersion, bucket, prefix, rules가 top-level로 시작합니다. 그런데 공식 Batch Expiration 예시는 top-level에 expire:가 있고 그 하위에 apiVersion, bucket, rules가 들어갑니다. 또한 batch expiration은 즉시 실행되어 일반 read/write 성능에 영향을 줄 수 있고, object locking이 활성화된 bucket에서는 실행할 수 없다고 되어 있습니다. (MinIO AIStor Documentation)

따라서 문서 예시는 아래 형태로 수정하고, 운영에서는 반드시 작은 prefix로 검증해야 합니다.

expire:
  apiVersion: v1
  bucket: BUCKET_NAME
  prefix: archive/2023/
  rules:
    - type: object
      olderThan: 720h
      purge:
        retainVersions: 3
    - type: deleted
      olderThan: 168h
      purge:
        retainVersions: 0

9. Worker 튜닝 설명은 방향을 나눠야 함

문서는 queue 포화 시 worker 수 증가를 대응으로 적어 놓고, 예시로는 기본값 100보다 낮은 MINIO_ILM_TRANSITION_WORKERS=32, MINIO_ILM_EXPIRATION_WORKERS=16을 제시합니다. 공식 문서 기준으로 두 값의 default는 100이고 유효 범위는 1~500이며, 환경변수와 config가 모두 있으면 환경변수가 우선합니다. (MinIO AIStor Documentation)

즉, 예시값 32/16은 “worker 증가”가 아니라 “운영 I/O 보호를 위한 throttling”에 가깝습니다. 문서에는 목적별로 분리해서 써야 합니다.

대량 transition을 빨리 밀어야 함: worker 증가 후보. 단, S3 GET/PUT latency, disk util, network, warm write latency 함께 측정.
운영 부하를 낮춰야 함: worker 감소 후보.
queue가 증가한다고 무조건 worker 증가 금지. warm tier 병목, network 병목, scanner 지연, object 수/metadata 병목을 먼저 확인.

10. Prefix 정책 “기본 정책보다 짧아야 한다”는 표현은 너무 단정적임

문서는 prefix 정책의 transition 기간이 bucket 기본 정책보다 짧아야 한다고 합니다. 실제로 catch-all default rule이 365일이고 특정 prefix rule이 730일이면, 365일 default가 먼저 적용될 수 있으므로 결과적으로 맞는 말입니다. 하지만 이것은 “항상 짧아야 한다”가 아니라 catch-all rule 설계상 긴 prefix 예외를 만들 수 없다는 의미입니다.

운영 정책으로는 아래처럼 정리하는 편이 좋습니다.

기본 catch-all rule을 둘 경우, 더 긴 보존/transition 기간을 가진 prefix 예외는 의도대로 동작하지 않을 수 있다. 긴 보존이 필요한 prefix가 있으면 catch-all rule 대신 prefix별 rule을 명시하거나, tag 기반 rule로 상호 배타적으로 설계한다.

공식 문서도 expiry와 transition rule이 같은 bucket/prefix에 함께 있을 수 있고, expiration은 transition status와 무관하게 실행될 수 있으므로 rule 간 상호작용을 mc ilm rule ls로 검토하라고 합니다. (MinIO AIStor Documentation)

11. Warm capacity와 대량 object scanner 리스크가 과소평가되어 있음

문서의 예시 구조는 Hot usable 약 10.6PiB, Warm usable 약 2.8PiB로 보입니다. 그런데 현재 환경이 Hot 90% 근접, 객체 수 수십억 단위라면, “365일 후 transition / 730일 후 삭제” 같은 단순 rule만으로는 Warm capacity가 충분한지 판단할 수 없습니다.

반드시 아래 모델링이 필요합니다.

최근 12/24/36개월 prefix별 object bytes, object count
transition 대상 중 overwrite/delete 비율
versioning으로 증가하는 noncurrent bytes
object lock/legal hold로 삭제 불가한 bytes
restore 임시 copy로 Hot에 재유입되는 bytes
scanner가 하루에 실제로 처리 가능한 object 수
warm tier ingest throughput과 disk/network 여유
replication backlog와 EdgeSyncBeforeExpiry로 인한 Hot 미삭제 기간

특히 EdgeSyncBeforeExpiry를 켜면 replication 완료 전 ILM expiry가 보류될 수 있고, backlog가 쌓이면 Hot 용량이 한계에 달해도 삭제가 안 되는 것처럼 보일 수 있다는 점은 문서에도 잘 적혀 있습니다. 공식 문서도 이 옵션이 ILM expiration이 replication 완료 전 삭제하지 않도록 하는 기능이라고 설명합니다. (MinIO AIStor Documentation)

12. 추가로 검증해야 할 POC 항목

운영 반영 전 아래는 꼭 직접 테스트하는 게 좋습니다.

Hot bucket에서 object transition 후 replication target에서 GET/HEAD/stat가 어떻게 되는지.
Hot cluster 장애 또는 metadata 손실 시, replication target만으로 transitioned object를 읽을 수 있는지.
Warm tier bucket을 tier target 전용으로 쓸 때, warm-side lifecycle/replication/direct access가 실제로 금지되어 있는지.
--transition-days 0이 현재 AIStor 버전에서 기존 object와 신규 object에 각각 어떻게 적용되는지.
versioned bucket에서 expire-days, noncurrent-expire-days, noncurrent-expire-newer, expire-delete-marker, purge-all-object-versions-* 조합별 실제 삭제 결과.
ExcludedPrefixes 적용 후 replication 대상에서 제외되는지.
restore 후 restored copy가 HEAD가 되는지, Spark/Trino/Jupyter/S3 client가 어떤 version을 읽는지.
Object Lock existing bucket 적용 가능 여부를 현재 설치된 AIStor release와 mc client version 기준으로 확인.
Batch Expire가 object lock bucket에서 실패하는지, 대량 실행 시 read/write latency에 어떤 영향을 주는지.
ILM worker 32/16, 100/100, 200/100 등 단계별로 queue 처리량과 서비스 latency를 비교.

정리하면, 이 문서는 “기능 설명 자료”로는 괜찮지만, 운영 설계서로는 Replication/DR/Warm Tier 역할 구분이 가장 위험합니다. 특히 Warm Tier = tier target, Warm Tier = archive, Warm Tier = replication target이 문서 안에서 섞여 보이는 부분은 반드시 분리해서 다시 써야 합니다.

===