26J09d

Young-Kyoo Kim·약 20시간 전

아래는 “정책별로 AIStor에서 실제로 무엇을 설정해야 하는가” 중심으로 정리한 것입니다. 전제는 말씀하신 대로 WORM/Object Lock 미사용, 별도 DR 미구성, Hot NVMe ObjectStore + Warm SATA/SSD ObjectStore 분리입니다. 업로드하신 2-Tier 가이드도 Replication과 ILM Tiering을 독립 기능으로 보고, 버킷별·prefix별로 조합하되 stub-only 복제, version 정리, transition queue, tier journal 모니터링을 반드시 반영하라고 정리하고 있습니다.

0. 먼저 전체 공통 설정

0.1 Warm ObjectStore bucket 역할 분리

Warm AIStor에는 최소한 아래 bucket들을 분리해서 두는 것이 좋습니다.

warm-aistor
├─ tier-hot-prod
│  └─ Hot → Warm ILM Transition 전용
│     - 애플리케이션 직접 접근 금지
│     - 별도 ILM/lifecycle 금지
│     - replication target으로 사용 금지
│
├─ repl-critical-prod
│  └─ 중요 데이터 replication target
│     - 독립 readable copy
│     - 운영자 read-only 확인 가능
│
├─ repl-lakehouse-meta
│  └─ Iceberg/Spark metadata/manifest/catalog 보호용
│
├─ repl-audit-logs
│  └─ 보안/감사 log replication target
│
└─ archive-native-prod
   └─ StarRocks/OpenSearch backup, 장기 archive 직접 저장

특히 tier-hot-prod는 AIStor ILM 전용 backend bucket으로 봐야 합니다. AIStor 공식 문서는 remote tier bucket의 데이터는 source Hot cluster의 metadata와 강하게 연결되므로, 외부 애플리케이션이나 사용자가 remote tier object를 직접 수정·삭제하면 데이터 손실이 날 수 있고, remote tier bucket에는 별도 lifecycle rule을 두지 말라고 설명합니다. (MinIO AIStor Documentation)

0.2 기본 alias와 endpoint

예시는 아래처럼 잡겠습니다.

mc alias set hot  https://s3-hot.company.internal  HOT_ACCESS_KEY  HOT_SECRET_KEY
mc alias set warm https://s3-warm.company.internal WARM_ACCESS_KEY WARM_SECRET_KEY

실제 운영에서는 명령어에 secret을 직접 남기기보다 Vault/KES/Secret 기반으로 관리하고, mc 실행용 운영 Job 또는 bastion에서 환경변수로 주입하는 방식이 좋습니다.

0.3 Warm tier 등록

Hot AIStor가 Warm AIStor를 remote tier로 사용하려면 Hot 쪽에 tier target을 등록합니다.

mc mb warm/tier-hot-prod

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

AIStor 공식 절차도 remote MinIO AIStor bucket을 미리 만들고, mc ilm tier add minio로 endpoint, access key, secret key, bucket, prefix, storage class를 지정한 뒤 mc ilm rule add로 bucket별 transition rule을 추가하는 흐름을 설명합니다. remote tier credential에는 대상 bucket에 대한 list/read/write/delete 권한이 필요합니다. (MinIO AIStor Documentation)

확인 명령:

mc ilm tier ls hot
mc ilm tier info hot WARM_TIER
mc ilm tier check hot WARM_TIER

0.4 공통 모니터링

Warm tier 도입 후에는 다음을 Prometheus/Grafana에 반드시 넣는 것이 좋습니다.

ILM transition:
- minio_ilm_transition_pending_tasks
- minio_ilm_transition_missed_immediate_tasks
- minio_ilm_transitioned_objects
- minio_ilm_transitioned_bytes

ILM expiry:
- minio_ilm_expiry_pending_tasks
- minio_ilm_expiry_missed_tier_journal_tasks

Replication:
- minio_replication_recent_backlog_count
- mc replicate status
- mc replicate backlog

Versioning:
- s3:ObjectManyVersions
- s3:ObjectLargeVersions
- mc admin scanner info

대규모 bucket에서는 transition/expiration worker도 조정 대상입니다. AIStor 공식 문서는 MINIO_ILM_TRANSITION_WORKERS와 MINIO_ILM_EXPIRATION_WORKERS가 각각 기본 100, 유효 범위 1~500이라고 설명합니다. 처음부터 크게 올리기보다는 backlog, Warm 부하, Hot scanner 부하를 보면서 조정하는 게 안전합니다. (MinIO AIStor Documentation)

# 예: Hot ObjectStore 환경변수 또는 config로 관리
MINIO_ILM_TRANSITION_WORKERS=64
MINIO_ILM_EXPIRATION_WORKERS=32

1. 정책별 AIStor 설정 요약표

정책	대표 대상	Versioning	ILM Transition	Replication	Expiration	Warm bucket
P1. Hot only + Expire	Spark `_temporary/`, staging, tmp, scratch, checkpoint 일부	OFF 권장	OFF	OFF	ON	없음
P2. Tiering only	Airflow 일반 log, observability app log, 오래된 Parquet partition	OFF 권장	ON	OFF	선택	`tier-hot-prod`
P3. Tiering only + versioning	사용자 workspace, 모델 산출물 이전 version	ON 선택	current 또는 noncurrent만 ON	OFF	noncurrent 정리	`tier-hot-prod`
P4. Replication only, 삭제 미복제	중요 원천, 보안 log, catalog/metadata	ON 필수	OFF	ON	noncurrent 정리	`repl-*`
P5. Replication only, 삭제 복제	mirror 성격 bucket	ON 필수	OFF	ON	noncurrent 정리	`repl-*`
P6. Prefix 분리형	같은 bucket에 metadata/data/tmp 혼재	bucket ON + prefix 제외	prefix별 ON	prefix별 ON	prefix별 ON	`tier-`, `repl-`
P7. Tiering + Replication 단계 분리	중요 active + 장기 archive	bucket 분리	archive bucket만 ON	active bucket만 ON	각각 별도	`tier-`, `repl-`
P8. Warm direct archive	StarRocks backup, OpenSearch snapshot	OFF 권장	OFF	OFF	app retention 또는 bucket expire	`archive-native-*`

2. P1 — Hot only + Expire

대상

Spark:
- _temporary/
- .spark-staging/
- staging/
- tmp/
- scratch/
- checkpoint 일부

ETL:
- staging/
- work/
- failed-attempt/
- intermediate/

StarRocks load:
- incoming/ 중 load 전 임시 위치
- failed/ 단기 보관

AIStor 설정

이 정책은 Warm 관련 설정이 없어야 합니다.

Versioning: OFF
Replication: OFF
ILM Transition: OFF
ILM Expiration: ON
Warm bucket: 없음

버킷 전체 versioning이 꺼져 있으면 단순합니다.

mc ilm rule add hot/spark-etl \
  --prefix "_temporary/" \
  --expire-days 3

mc ilm rule add hot/spark-etl \
  --prefix "staging/" \
  --expire-days 7

mc ilm rule add hot/spark-etl \
  --prefix "tmp/" \
  --expire-days 3

만약 같은 bucket 안에서 replication 때문에 versioning이 켜져야 한다면, 임시 prefix는 versioning에서 제외합니다.

mc version enable hot/lakehouse-prod \
  --excluded-prefixes "_temporary/,tmp/,staging/,scratch/,cache/" \
  --exclude-folders

AIStor versioning은 overwrite 시 새 version을 만들고 delete marker도 누적되므로, Spark/Hadoop류의 임시·폴더 marker가 많은 prefix에는 제외 설정을 적극 사용하는 것이 좋습니다. 공식 문서도 versioning이 특정 object version 조회·복구를 지원하지만 mutation-heavy workload에서는 capacity 사용량이 크게 늘 수 있다고 설명합니다. (MinIO AIStor Documentation)

3. P2 — Tiering only

대상

Airflow 일반 task log
Observability app log archive
오래된 ETL validated data
오래된 Parquet/ORC partition
StarRocks load 완료 후 source file
재생성 가능한 중간 산출물 중 장기 보관분

AIStor 설정

Versioning: OFF 권장
Replication: OFF
ILM Transition: ON
ILM Expiration: 선택
Warm target: tier-hot-prod

예시 1 — Airflow log

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

예시 2 — Observability app log

mc ilm rule add hot/observability-logs \
  --prefix "app/" \
  --transition-days 7 \
  --transition-tier WARM_TIER \
  --expire-days 180

예시 3 — Lakehouse archive partition

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

AIStor lifecycle rule은 prefix, current transition, noncurrent transition, expiration을 조합할 수 있고, remote tier는 사전에 mc ilm tier add로 등록되어 있어야 합니다. (MinIO AIStor Documentation)

4. P3 — Tiering only + Versioning

대상

사용자 workspace 중 휴지통 기능 필요
AI/ML 모델 산출물
중요하지만 replication까지는 필요 없는 결과물
current는 Hot에 두고 이전 version만 Warm으로 보내고 싶은 bucket

AIStor 설정

Versioning: ON
Replication: OFF
ILM Current Transition: 선택
ILM Noncurrent Transition: 선택
ILM Noncurrent Expire: 필수
Delete Marker Cleanup: 필수
Warm target: tier-hot-prod

버전이 있는 bucket에는 반드시 noncurrent 정리 rule을 같이 둡니다. AIStor 공식 문서는 versioned bucket의 noncurrent version 만료에 --noncurrent-expire-days, delete marker 정리에 --expire-delete-marker를 사용한다고 설명합니다. (MinIO AIStor Documentation)

예시 1 — 사용자 workspace, archive prefix만 Warm 이동

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

mc ilm rule add hot/user-workspace \
  --prefix "archive/" \
  --transition-days 30 \
  --transition-tier WARM_TIER \
  --noncurrent-expire-days 30 \
  --noncurrent-expire-newer 3 \
  --expire-delete-marker

예시 2 — 모델 산출물: current는 Hot, 이전 version만 Warm

mc version enable hot/ml-artifacts \
  --excluded-prefixes "tmp/,cache/" \
  --exclude-folders

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

이 방식은 “최신 모델은 Hot에서 빠르게 읽고, 이전 모델 version은 Warm에 두되 365일 뒤 정리”하는 구조입니다.

5. P4 — Replication only, 삭제 미복제

대상

중요 원천 데이터
보안/감사 log
Iceberg metadata/manifest/catalog
수작업 업로드 데이터
삭제 실수로부터 보호해야 하는 데이터

AIStor 설정

Versioning: source/target 모두 ON
Replication: ON
Delete replication: OFF
Delete marker replication: OFF
ILM Transition: OFF
ILM Noncurrent Expire: source/target 모두 필요
Warm target bucket: repl-*

Replication을 쓰려면 source와 destination bucket 모두 versioning이 필요합니다. AIStor mc replicate는 모든 version 정보와 metadata를 동기화하며, existing-objects, delete, delete-marker, metadata-sync, --sync 같은 옵션을 선택할 수 있습니다. delete 관련 옵션을 넣지 않으면 source delete가 target의 historical copy에 영향을 주지 않는 보호 사본형으로 운영할 수 있습니다. (MinIO AIStor Documentation)

예시 — 중요 원천 데이터

mc mb warm/repl-critical-raw

mc version enable hot/critical-raw \
  --excluded-prefixes "tmp/,staging/,failed/" \
  --exclude-folders

mc version enable warm/repl-critical-raw

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

source bucket의 version 정리:

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

target bucket의 version 정리:

mc ilm rule add warm/repl-critical-raw \
  --noncurrent-expire-days 365 \
  --noncurrent-expire-newer 10 \
  --expire-delete-marker

이 방식은 실수 삭제 보호에 가장 적합합니다. 단, Hot 용량 절감 효과는 없습니다.

6. P5 — Replication only, 삭제 복제

대상

Warm을 Hot의 mirror view로 유지해야 하는 bucket
삭제도 업무 이벤트로 target에 동일하게 반영해야 하는 bucket
운영 검증용 mirror bucket

AIStor 설정

Versioning: source/target 모두 ON
Replication: ON
Delete replication: ON
Delete marker replication: ON
ILM Transition: OFF
ILM Noncurrent Expire: source/target 모두 필요
Warm target bucket: repl-*

예시

mc mb warm/repl-mirror-bucket

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

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

delete replication을 켜면 source의 delete marker와 versioned delete가 target으로 복제됩니다. 즉, 이 정책은 보호 사본이 아니라 동일 상태 mirror에 가깝습니다. AIStor 공식 문서도 delete operation replication은 명시적으로 켜야 한다고 설명합니다. (MinIO AIStor Documentation)

source와 target 모두 delete marker 정리를 둡니다.

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

mc ilm rule add warm/repl-mirror-bucket \
  --noncurrent-expire-days 30 \
  --noncurrent-expire-newer 3 \
  --expire-delete-marker

7. P6 — Prefix 분리형 정책

대상

하나의 bucket 안에 여러 성격의 데이터가 섞인 경우입니다.

lakehouse-prod/
├─ metadata/       → replication only
├─ manifests/      → replication only
├─ data/current/   → hot only 또는 replication only
├─ data/archive/   → tiering only
├─ _temporary/     → expire only
├─ tmp/            → expire only
└─ checkpoints/    → hot only

AIStor 설정

Versioning: bucket 단위 ON, 단 tmp/cache/staging 등 제외
Replication: prefix 단위
ILM Transition: prefix 단위
ILM Expiration: prefix 단위
Warm target: tier bucket과 repl bucket 분리

AIStor mc replicate add의 대상 ALIAS는 bucket 또는 bucket prefix 경로를 지정할 수 있습니다. 따라서 hot/lakehouse-prod/metadata/처럼 prefix 단위 replication rule을 구성할 수 있습니다. (MinIO AIStor Documentation)

예시

mc version enable hot/lakehouse-prod \
  --excluded-prefixes "_temporary/,tmp/,staging/,scratch/,cache/,data/archive/" \
  --exclude-folders

metadata prefix replication:

mc mb warm/repl-lakehouse-meta
mc version enable warm/repl-lakehouse-meta

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

archive prefix tiering:

mc ilm rule add hot/lakehouse-prod \
  --prefix "data/archive/" \
  --transition-days 30 \
  --transition-tier WARM_TIER

temporary prefix expiration:

mc ilm rule add hot/lakehouse-prod \
  --prefix "_temporary/" \
  --expire-days 3

mc ilm rule add hot/lakehouse-prod \
  --prefix "tmp/" \
  --expire-days 3

주의할 점은, bucket 기본 transition rule과 prefix transition rule을 같이 둘 경우입니다. 기본 rule이 90일 transition이고 특정 prefix rule이 180일 transition이면 기본 rule이 먼저 적용되어 prefix rule이 의미 없어집니다. 따라서 prefix별 transition 기간은 기본 rule보다 짧게 하거나, 기본 rule을 아예 두지 않고 prefix별 rule만 두는 편이 안전합니다.

8. P7 — Tiering + Replication 단계 분리

대상

중요하지만 오래된 데이터는 Hot에서 빼야 하는 경우
최근 90일은 보호 사본이 필요하고, 이후는 archive로 넘기고 싶은 경우
중요 원천 + 장기 archive가 같이 필요한 경우

권장 구조

같은 object에 replication과 tiering을 단순 동시 적용하지 말고 bucket 또는 lifecycle 단계를 분리합니다.

hot/critical-active
→ replication only
→ Warm repl bucket에 full readable copy

hot/critical-archive
→ tiering only
→ Warm tier bucket으로 이동

이유는 명확합니다. Tiering이 완료된 object는 Hot에 실제 bytes가 없고 metadata stub만 남습니다. 이 상태에서 replication이 동작하면 target에 stub만 복제될 수 있고, target이 Warm tier backend에 접근할 수 없다면 직접 GetObject가 실패할 수 있습니다. 업로드하신 가이드도 이 stub-only 복제 동작을 주요 설계 주의사항으로 다루고 있습니다.

AIStor 설정

active bucket

mc mb warm/repl-critical-active

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 90 \
  --noncurrent-expire-newer 5 \
  --expire-delete-marker

archive bucket

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

운영 흐름은 다음처럼 잡습니다.

1. 애플리케이션/ETL은 hot/critical-active에 write
2. AIStor replication으로 warm/repl-critical-active에 보호 사본 생성
3. 90~180일 후 archive job이 hot/critical-archive로 copy/move
4. hot/critical-archive는 ILM으로 Warm tiering
5. active bucket의 오래된 object는 업무 확인 후 expire/delete

9. P8 — Warm direct archive / backup repository

대상

StarRocks BACKUP repository
OpenSearch snapshot repository
장기 archive 직접 저장
복구용 dump
재처리 가능한 대용량 백업 파일

AIStor 설정

애플리케이션 endpoint: s3-warm.company.internal
Versioning: OFF 권장
ILM Transition: OFF
Replication: OFF
Expiration: backup retention 정책에 맞게 선택
Warm bucket: archive-native-* 또는 backup-*

예시:

mc mb warm/backup-starrocks
mc mb warm/backup-opensearch
mc mb warm/archive-native-prod

StarRocks backup repository 90일 보관 예시:

mc ilm rule add warm/backup-starrocks \
  --expire-days 90

OpenSearch snapshot repository 180일 보관 예시:

mc ilm rule add warm/backup-opensearch \
  --expire-days 180

이 유형은 “Hot에서 Warm으로 이동”하는 게 아니라 처음부터 Warm에 직접 쓰는 구조입니다. backup/snapshot 도구가 자체 metadata와 retention을 관리하는 경우 bucket versioning은 오히려 삭제·정리 동작을 방해할 수 있으므로 특별한 이유가 없으면 OFF가 낫습니다.

10. EdgeSyncBeforeExpiry 적용 기준

--edge-sync-before-expiry는 replication과 ILM expiration이 같이 걸린 bucket에서 유용합니다. 이 옵션은 ILM expiration이 replication 완료 전에 object를 삭제하지 않도록 막습니다. AIStor 공식 문서도 이 옵션이 ILM expiration이 replication 완료 전 object를 지우는 것을 방지한다고 설명합니다. (MinIO AIStor Documentation)

적용 권장:

- replication bucket에 expire rule이 있음
- source bucket에 noncurrent expire가 있음
- 기존 object replication backlog가 큰 상태에서 expire가 같이 동작함

예시:

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

기존 rule에 추가:

mc replicate ls hot/security-audit-logs

mc replicate update hot/security-audit-logs \
  --id "${RULE_ID}" \
  --edge-sync-before-expiry enable

단, replication backlog가 큰 상태에서 이 옵션을 켜면 expiry가 계속 보류되어 Hot 용량 회수가 지연될 수 있습니다. 따라서 mc replicate backlog, minio_replication_recent_backlog_count, Hot 사용률 알람을 같이 봐야 합니다.

11. StarRocks / Spark / Airflow / Observability별 최종 매핑

워크로드	경로 예시	권장 정책	AIStor 설정
Spark temp	`_temporary/`, `staging/`, `tmp/`	P1	versioning 제외, expire 3~7일
Spark checkpoint	`checkpoints/`, `_spark_metadata/`	P1	versioning OFF, tiering OFF, 수동/별도 정리
Spark/Iceberg metadata	`metadata/`, `manifests/`	P4 또는 P6	versioning ON, replication only, noncurrent 정리
Parquet 과거 partition	`data/archive/`	P2 또는 P6	transition 30~180일
ETL raw incoming	`raw/incoming/`	Hot only 또는 P4	load 전 Hot, 중요 원천만 replication
ETL validated	`raw/validated/`	P2	transition 90일
ETL intermediate	`intermediate/`, `work/`	P1	expire 7~14일
StarRocks load source	`starrocks-load/loaded/`	P2 또는 expire	load 후 transition 또는 expire
StarRocks failed load	`starrocks-load/failed/`	P1	expire 30일
StarRocks storage volume	내부 table storage	Hot only	AIStor ILM 직접 적용 비권장
StarRocks backup	`warm/backup-starrocks`	P8	Warm direct, versioning OFF, expire
Airflow normal logs	`airflow-logs/`	P2	transition 30일, expire 365일
Airflow audit logs	`airflow-audit-logs/`	P4	replication only, delete 미복제
Observability app logs	`observability/app/`	P2	transition 7~30일, expire
Security logs	`security-audit/`	P4	replication only, delete 미복제
OpenSearch snapshots	`warm/backup-opensearch`	P8	Warm direct, versioning OFF

12. 정책별 “하지 말아야 할 설정”

상황	피해야 할 설정
Spark temp/staging	versioning ON, replication ON, tiering ON
Spark checkpoint	aggressive expiration, tiering, replication
Iceberg metadata/manifest	tiering only로 Warm 이동
StarRocks storage volume	AIStor lifecycle로 임의 transition/expire
Warm tier bucket `tier-hot-prod`	애플리케이션 직접 read/write, 별도 lifecycle
replication target bucket	tier target bucket과 공유
보호 사본 목적 replication	`delete,delete-marker` 무조건 ON
versioning bucket	noncurrent expire 없이 방치
tiering + replication 같은 object	target readable copy로 오해
backup repository	bucket versioning 무조건 ON

13. 검증 명령 세트

구성 후 아래는 SOP에 넣는 것이 좋습니다.

# Tier 확인
mc ilm tier ls hot
mc ilm tier info hot WARM_TIER
mc ilm tier check hot WARM_TIER

# Lifecycle rule 확인
mc ilm rule ls hot/BUCKET
mc ilm rule ls hot/BUCKET --transition
mc ilm rule ls hot/BUCKET --expiry

# Versioning 확인
mc version info hot/BUCKET
mc ls --versions hot/BUCKET/path/to/object

# Replication 확인
mc replicate ls hot/BUCKET
mc replicate status hot/BUCKET
mc replicate backlog hot/BUCKET

# Scanner / version 과다 확인
mc admin scanner info hot

14. 최종 권장 기본값

현재 환경의 기본값은 아래처럼 잡는 것을 권합니다.

1. Spark/ETL tmp/staging/checkpoint
   → P1: Hot only + Expire

2. Airflow 일반 log / observability app log / 오래된 partition
   → P2: Tiering only

3. 사용자 workspace / 모델 산출물 이전 version
   → P3: Tiering only + Versioning

4. 중요 원천 / audit / security / metadata / manifest
   → P4: Replication only, delete 미복제

5. 정확한 mirror가 필요한 특수 bucket
   → P5: Replication only, delete 복제

6. 기존 lakehouse bucket처럼 prefix가 섞인 경우
   → P6: Prefix 분리형

7. 중요 active + 장기 archive가 모두 필요한 경우
   → P7: active는 replication, archive는 tiering

8. StarRocks/OpenSearch backup
   → P8: Warm direct archive

가장 중요한 운영 원칙은 두 가지입니다. 첫째, tier-* bucket과 repl-* bucket을 절대 섞지 않는 것. 둘째, versioning을 켠 모든 bucket에는 noncurrent 정리와 delete marker 정리를 반드시 같이 넣는 것입니다.

Young-Kyoo Kim

engineer

이전 포스트

26J09d

0. 먼저 전체 공통 설정

0.1 Warm ObjectStore bucket 역할 분리

0.2 기본 alias와 endpoint

0.3 Warm tier 등록

0.4 공통 모니터링

1. 정책별 AIStor 설정 요약표

2. P1 — Hot only + Expire

대상

AIStor 설정

3. P2 — Tiering only

대상

AIStor 설정

4. P3 — Tiering only + Versioning

대상

AIStor 설정

예시 1 — 사용자 workspace, archive prefix만 Warm 이동

예시 2 — 모델 산출물: current는 Hot, 이전 version만 Warm

5. P4 — Replication only, 삭제 미복제

대상

AIStor 설정

예시 — 중요 원천 데이터

6. P5 — Replication only, 삭제 복제

대상

AIStor 설정

예시

7. P6 — Prefix 분리형 정책

대상

AIStor 설정

예시

8. P7 — Tiering + Replication 단계 분리

대상

권장 구조

AIStor 설정

active bucket

archive bucket

9. P8 — Warm direct archive / backup repository

대상

AIStor 설정

10. EdgeSyncBeforeExpiry 적용 기준

11. StarRocks / Spark / Airflow / Observability별 최종 매핑

12. 정책별 “하지 말아야 할 설정”

13. 검증 명령 세트

14. 최종 권장 기본값

26J09c

0개의 댓글