Lead DevOps이자 아키텍트로서 현재 128대(Hot) 규모에서 총 286대 규모로 확장하며, 성능(NVMe 추정)과 용량(SATA/SAS SSD)을 분리하는 매우 중요한 전환점에 서 계십니다.

단순히 용량을 늘리는 것을 넘어, 데이터의 생애주기(Lifecycle)를 관리하고 비용 효율적인 대규모 스토리지(Cold Tier)를 구축하기 위한 전략적 아키텍처를 제안해 드립니다.

---

1. 계층별 풀(Pool) 정의 및 특성 분류

먼저 추가되는 자원들의 특성을 기반으로 계층(Tier)을 논리적으로 분리해야 합니다.

계층 (Tier)	구성 자원	특성 및 목적	권장 Erasure Coding (EC)
Hot (기존)	128 Nodes (NVMe)	초고성능. 실시간 AI 학습, 실시간 API(3,000 RPS) 처리 전용	EC:4 or EC:8
Warm (Pool 0, 1)	28 Nodes (SATA/SAS SSD)	고신뢰성/중용량. 최근 30일 이내 분석 데이터, 체크포인트 저장	EC:8
Cold (Pool 2)	130 Nodes (SATA SSD)	대규모 저장. 아카이브, 장기 보관 로그, 9PB급 벌크 데이터	EC:16 (고효율)

---

2. 아키텍처 구성 전략: Server-side Tiering vs Multi-Pool

이 규모에서는 두 가지 전략 중 하나를 선택해야 합니다.

전략 A: 단일 네임스페이스 (Server-Pools) 확장

모든 Pool을 하나의 MinIO 클러스터로 묶는 방식입니다.

• 방법: 기존 128노드 클러스터에 신규 노드들을 Pool로 계속 추가합니다.
• 장점: 사용자는 단일 Endpoint만 바라보면 되며 관리가 단순합니다.
• 단점: Hot Tier의 초고성능 I/O가 Cold Tier의 리밸런싱 작업 등에 영향을 받을 수 있습니다. (QoS 분리 어려움)

전략 B: 계층형 티어링 (Lifecycle + Remote Tiering) - 권장

Hot 클러스터와 Cold 클러스터를 논리적으로 분리하고, MinIO의 ILM(Information Lifecycle Management) 기능을 사용하는 방식입니다.

• 방법: 128노드(Hot)는 그대로 두고, 신규 158노드(Pool 0,1,2)를 별도의 'Cold Cluster'로 구성한 뒤 Hot 클러스터에서 mc ilm tier add로 연결합니다.
• 장점: 하드웨어 장애 전파(Fault Domain)가 격리되며, Hot Tier의 RPS 성능을 100% 보호할 수 있습니다. 1,000노드 확장 시 관리가 훨씬 유연합니다.

---

3. 상세 정책(Policy) 제안

고객사에 정책이 없는 상태이므로, 가장 표준적인 "3-Step 데이터 전이" 정책을 제안해 보세요.

① ILM (Lifecycle) 정책

데이터의 "신선도"에 따라 자동으로 이동시킵니다.

• Hot $\rightarrow$ Warm (30일): 생성된 지 30일이 지난 데이터는 SAS/SATA SSD 풀로 이동.
• Warm $\rightarrow$ Cold (90일): 90일이 지난 데이터는 Pool 2(130대 노드)로 이동하여 저장 밀도 극대화.
• Expiration (365일+): 필요 시 보존 기간이 지난 데이터는 자동 삭제.

② Replication (복제) 정책

AIStor의 안정성을 위해 중요한 버킷은 Active-Active 또는 Active-Passive 복제를 설정합니다.

• Metadata 및 중요 Model: Hot Tier 내에서 2대 이상의 노드에 가용성을 확보하도록 EC 설정을 높게 가져가고, 필요시 원격지 클러스터로 Site Replication을 고려합니다.

③ Erasure Coding (데이터 보호) 최적화

• Pool 2 (130노드): 노드 수가 압도적으로 많으므로 EC:16 설정을 추천합니다. 이렇게 하면 16대의 노드가 동시에 장애가 나도 데이터가 안전하며, 저장 공간 효율(Overhead)을 최소화할 수 있습니다.

---

4. DevOps 구현 및 운영 포인트

• Cilium ClusterMesh 활용: Hot 클러스터와 Cold 클러스터를 분리하더라도, Cilium ClusterMesh를 통해 노드 간 통신을 Native 모드로 연결하여 티어링(Data Migration) 시 발생하는 네트워크 부하를 최적화하세요.
• ResourceQuota 적용: K8s Namespace마다 용량 제한을 설정했던 것처럼, 각 Pool이나 Tenant별로 Quota를 엄격히 적용하여 특정 Cold 데이터가 Hot Tier의 Buffer를 다 채우지 않도록 방지해야 합니다.
• 5월/8월 단계적 도입: * 5월: Pool 0, 1을 먼저 'Warm Tier'로 연동하여 티어링 로직이 3,000 RPS 환경에서 안정적인지 검증합니다.
  • 8월: Pool 2(130대) 투입 시점에는 대규모 리밸런싱이 발생하므로, 이때 네트워크 본딩을 100Gbps로 올리는 것을 강력히 검토해야 합니다. (이때가 드라이브 효율이 진짜 필요한 시점입니다.)

아키텍트로서의 한 줄 조언

"130대의 Cold 노드는 향후 1,000노드 시대로 가는 거대한 '데이터 댐' 역할을 하게 될 것입니다. 지금 Hot Tier와 물리적/논리적으로 분리된 Tiering 구조를 잡아두지 않으면, 나중에 Cold 데이터의 인덱싱 부하가 현재의 3,000 RPS 성능을 갉아먹게 될 위험이 큽니다."

이 정책들을 고객사에 제안하실 때, "성능 보호"와 "비용 절감" 중 어느 쪽에 더 무게를 두고 설득하실 계획인가요? 그에 맞춰 상세 수치를 더 보완해 드릴 수 있습니다.

===

대규모 인프라를 운영하시는 아키텍트 입장에서 가장 큰 고민은 "모든 데이터를 동일하게 취급할 수 없다"는 점일 것입니다. 특히 파드당 3,000 RPS를 쏟아내는 Hot Tier의 성능을 보호하면서도, 8월에 들어올 130대의 거대한 Pool 2(Cold)를 효율적으로 활용하기 위한 정책별 Best Practice를 정리해 드립니다.

---

1. Tiering (ILM) Best Practice: "성능 병목 방지"

데이터의 '온도'에 따라 Hot(NVMe) $\rightarrow$ Warm(SAS/SATA) $\rightarrow$ Cold(SATA)로 자동 이동시키는 정책입니다.

• 대상: 로그 데이터, 학습이 끝난 원천 데이터셋, 오래된 백업 파일.
• 핵심 전략:
  • Transition 기간 설정: Hot Tier(NVMe)는 용량 대비 비용이 매우 비쌉니다. 보통 15~30일을 기준으로 Warm Tier로 넘기는 것이 경제적입니다.
  • Small Object 주의: 앞서 말씀하신 1KB 이하 객체가 티어링 대상에 포함되면, 이동 시 메타데이터 부하가 커집니다. "최소 크기 필터"를 걸어 일정 크기 이상의 객체만 티어링하는 것이 유리합니다.
  • 조회(Read) 패턴 고려: 티어링된 데이터를 읽을 때는 Cold Tier의 성능(SATA SSD)이 기준이 됩니다. 만약 빈번한 조회가 예상된다면 티어링보다는 복제(Replication)를 고려해야 합니다.

---

2. Replication (복제) Best Practice: "데이터 생존과 고가용성"

장애 발생 시 즉각적인 서비스 전환(Failover)이 필요한 경우 사용합니다.

• 대상: AI 모델 가중치(Weights), 서비스 크리티컬 설정 파일, 사용자 프로필.
• 핵심 전략:
  • Site Replication vs Bucket Replication: 128대 규모라면 Site Replication을 통해 IAM 설정, 정책, 버킷 구성을 통째로 동기화하는 것이 관리 포인트를 줄이는 방법입니다.
  • Asynchronous(비동기) 방식: 3,000 RPS 환경에서 동기 복제는 Latency를 급증시킵니다. 반드시 비동기 복제를 사용하여 Hot Tier의 응답 속도를 유지하세요.
  • Active-Active 구성: 5월에 구축될 28개 노드(Warm)를 단순 백업용이 아닌, 읽기 전용 엔드포인트로 활용하여 Hot Tier의 읽기 부하를 분산시키는 것도 좋은 전략입니다.

---

3. Versioning Best Practice: "실수로부터의 보호"

데이터 삭제나 덮어쓰기 사고를 방지하기 위해 사용합니다.

• 대상: 설정 파일(Config), 코드 스니펫(Vibe Coding Zone 결과물), SOP 문서.
• 핵심 전략:
  • 비용 경고: Versioning은 객체가 수정될 때마다 전체 크기만큼 저장 공간을 차지합니다. 무제한 버저닝은 130대 노드도 순식간에 채울 수 있습니다.
  • Non-current Version Expiration: "최신 버전이 아닌 객체는 7일 뒤에 삭제한다"는 ILM 정책을 반드시 세트로 묶어야 합니다.
  • Delete Marker 관리: 삭제된 파일의 '삭제 마커'도 성능에 영향을 줍니다. ExpiredObjectDeleteMarkers 옵션을 통해 찌꺼기를 주기적으로 청소해 줘야 합니다.

---

4. 정책별 "Best Practice" 요약 가이드

버킷의 성격에 따라 아래 메뉴판에서 선택하여 적용하시는 것을 추천합니다.

워크로드 유형	추천 정책 조합	기대 효과
실시간 AI 서빙	Hot Only (No Policy)	최저 Latency 보장, 3,000 RPS 최적화
분석용 데이터 레이크	Tiering (30d Hot $\rightarrow$ Cold)	NVMe 공간 확보, 대용량 데이터 경제적 보관
핵심 자산 (Gold)	Replication + Versioning	데이터 유실 제로, 24/7 서비스 연속성
개발 환경 (Sandbox)	Versioning (Short-term)	코드 롤백 가능, 휴먼 에러 방지
아카이브 / 컴플라이언스	Tiering + Object Lock	법적 규제 준수, 장기 저가 저장

---

💡 아키텍트로서의 추가 조언 (Lead DevOps 관점)

1. Prefix 기반 관리: 버킷 하나에 모든 정책을 다 넣기보다는, bucket/logs/*는 티어링, bucket/configs/*는 버저닝 하는 식으로 Prefix 단위로 ILM을 세분화하는 것이 가장 깔끔합니다.
2. 모니터링 우선순위: 복제(Replication)를 걸면 네트워크 트래픽이 2배가 됩니다. LACP 50G 본딩 상태에서 Replication Lag이 발생하는지 Hubble이나 mc admin trace로 상시 감시해야 합니다.
3. 8월 대규모 확장(Pool 2) 대비: 130대 노드가 들어오는 시점에는 Hot Tier에서 Cold Tier로 대량의 데이터 이동이 발생할 것입니다. 이때를 위해 지금부터 데이터 마이그레이션 스케줄링(Batch Job)에 대한 정책 가이드를 고객사에 미리 전달해 두시는 것이 좋습니다.

현재 고객사에서 가장 우선순위가 높은 데이터는 무엇인가요? 예를 들어 "AI 모델 데이터"라면 복제를 우선으로, "로그"라면 티어링을 우선으로 설계안을 잡아드리면 설득력이 더 높아질 것 같습니다. 추가로 구체화가 필요한 사례가 있다면 말씀해 주세요!

===

Cold Tier 추가 구성 및 Hot Tier 연계 전략

1. 전체 용량 먼저 파악

구분	노드 수	디스크	Raw 용량	비고
Hot tier	128	6.8TiB × 20	~17.4 PiB	기존
pool0	14	7.0TiB × 20	~1.96 PiB	5월, SATA SSD
pool1	14	3.5TiB × 20	~0.98 PiB	5월, SAS SSD
pool2	130	3.5TiB × 20	~9.1 PiB	8월, SATA SSD
Cold 합계	158	—	~12 PiB

---

2. Pool 구성 전략

핵심 원칙: Device Class 분리 → Storage Class 매핑

[Hot Tier]                    [Cold Tier]
NVMe/SAS HDD (128 nodes)     SATA SSD pool0 (14 nodes)
                              SAS  SSD pool1 (14 nodes)
                              SATA SSD pool2 (130 nodes, 8월)

pool0 / pool1 / pool2 각각 별도 CRUSH Rule

pool0과 pool1은 같은 시기에 들어오지만 매체 특성이 다름 (SATA vs SAS) → 반드시 분리

# 예시 (Ceph 기준)
device_class: sata-ssd   → pool0, pool2
device_class: sas-ssd    → pool1
device_class: hdd/nvme   → hot tier

Erasure Coding 적용 권고 (Cold는 비용 최우선)

Pool	권고 EC 프로파일	이유
pool0 (14 nodes)	k=10, m=4	노드 수 여유, 공간효율 71%
pool1 (14 nodes)	k=10, m=4	동일
pool2 (130 nodes)	k=12, m=4 or k=16, m=4	노드 수 충분, 공간효율 최대화
hot tier	기존 정책 유지 (보통 3-replica or k=8,m=3)	성능 우선

⚠️ pool1은 SAS SSD로 랜덤 I/O가 SATA보다 우수 → EC rebuild 시 부하 측면에서 유리

---

3. Object Store / Bucket 구성

Storage Class 체계 설계 (S3 호환 기준)

STANDARD          → Hot tier (기존)
STANDARD_IA       → pool0 (7TiB SATA, 접근 빈도 중간)
GLACIER           → pool1 + pool2 (저빈도 아카이브)

또는 용도 명확화 시:

HOT               → hot tier
WARM              → pool0
COLD              → pool1
ARCHIVE           → pool2 (8월 이후)

Placement Target 설정

zonegroup → zone → placement_target
  ├── default-placement   (hot)
  ├── warm-placement      (pool0)
  ├── cold-placement      (pool1)
  └── archive-placement   (pool2, 8월 이후 추가)

각 placement target에 index pool / data pool / data_extra pool 을 해당 device class pool로 매핑

---

4. Hot ↔ Cold 관계 설계

지금 당장 결정해야 할 구조적 선택지

옵션 A: 동일 Zone, Storage Class 분리
┌─────────────────────────────────────┐
│  Zone: primary                      │
│  hot-pool ──→ STANDARD             │
│  pool0    ──→ STANDARD_IA          │
│  pool1    ──→ GLACIER              │
│  pool2    ──→ DEEP_ARCHIVE (8월)   │
└─────────────────────────────────────┘
장점: ILM 전환이 단순, 관리 일원화
단점: hot 장애 시 cold도 영향 가능

옵션 B: Zone 분리 (hot zone / cold zone)
┌──────────────┐    replication    ┌──────────────┐
│  hot-zone    │ ←───────────────→ │  cold-zone   │
│  (128 nodes) │                   │  (158 nodes) │
└──────────────┘                   └──────────────┘
장점: 장애 도메인 분리, 독립 운영 가능
단점: 구성 복잡도 증가, 초기 정책 없으면 운영 부담

현재 고객사 상황(정책 전무)을 고려하면 옵션 A 권고 — 정책 수립 후 나중에 Zone 분리 가능

---

5. ILM 정책 초안 (고객사와 협의 시작점)

정책이 없다면 아래를 최소 기준으로 제안:

Rule 1: 생성 후 30일 경과 + 접근 없음
        → STANDARD → STANDARD_IA (pool0)

Rule 2: 생성 후 90일 경과 + 접근 없음
        → STANDARD_IA → GLACIER (pool1)

Rule 3: 생성 후 365일 경과
        → GLACIER → DEEP_ARCHIVE (pool2, 8월 이후)

Rule 4: 특정 버킷 prefix (예: /backup/, /log/)
        → 생성 즉시 COLD 직행

---

6. Replication 정책

대상	권고
Hot tier	기존 정책 유지 (최소 2-site replication 권고)
pool0/pool1	EC로 내구성 확보 → cross-site replication 불필요할 수 있음
pool2	단일 copy EC로 구성, 별도 replication 없이 EC만으로 내구성 확보
중요 데이터	Hot → pool0 으로 비동기 replication (백업 목적) 고려

⚠️ Replication을 cold tier까지 걸면 네트워크 + 용량 비용이 2배 → cold는 EC 내구성만으로 설계하는 것이 일반적

---

7. 단계별 구축 로드맵

[지금 ~ 5월 전]
  ✅ Storage class / placement target 설계 확정
  ✅ CRUSH rule 사전 설계
  ✅ ILM 정책 최소 기준 고객사 합의

[5월: pool0 + pool1 구축]
  → pool0, pool1 CRUSH rule 적용
  → placement target 연결
  → 버킷 단위 ILM 정책 파일럿 적용 (일부 버킷만)
  → hot → warm 자동 전환 모니터링

[8월: pool2 구축]
  → pool2 CRUSH rule 추가
  → archive-placement target 활성화
  → 전체 ILM 정책 확대 적용
  → 전체 cold tier 운영 안정화 확인

---

요약 권고

1. pool0/pool1/pool2는 반드시 별도 CRUSH rule + device class 분리 — 나중에 합치는 건 쉬워도 분리는 어렵다
2. Cold는 EC 적극 적용 — 3-replica 대비 용량 효율 2~3배
3. 옵션 A(동일 Zone, storage class 분리)로 시작 — 정책 수립 후 zone 분리 전환 가능
4. ILM은 지금 당장 최소 기준이라도 합의 — 없으면 cold tier 구축해도 데이터가 안 내려옴
5. pool2(8월) placement target은 5월에 미리 껍데기라도 만들어 두기 — 버킷 설정 변경 최소화

혹시 사용 중인 솔루션(Ceph RGW, MinIO, Scality, NetApp StorageGRID 등)을 알려주시면 더 구체적인 설정 예시를 드릴 수 있어요.

===

MinIO AIStor 기반 Cold Tier 구성 전략

1. MinIO AIStor 핵심 아키텍처 이해

MinIO에서 "tiering"은 반드시 별도 Remote Tier endpoint가 필요합니다. Ceph처럼 내부 pool 간 이동이 아닙니다.

┌─────────────────────────────────┐        ILM Transition
│  Hot MinIO AIStor               │  ─────────────────────→  Cold MinIO AIStor
│  (128 nodes, 기존)               │                          (신규 구축)
│  6.8TiB × 20 × 128             │  ←─────────────────────  
└─────────────────────────────────┘     (복원 시 recall)

따라서 Cold Tier는 별도 MinIO AIStor 클러스터로 구성하는 것이 기본 구조입니다.

---

2. Cold Tier 클러스터 구성 설계

Server Pool 구성 원칙

MinIO는 동일 배포 내 Server Pool 추가 시 드라이브 수 기반 자동 분산합니다.
pool0과 pool1은 드라이브 용량이 다르지만 같은 Cold 클러스터에 넣어도 무방합니다.

Cold MinIO AIStor Cluster
├── Server Pool A (5월) ── pool0: 14 nodes × 20 drives (7.0TiB SATA SSD)
├── Server Pool B (5월) ── pool1: 14 nodes × 20 drives (3.5TiB SAS SSD)
└── Server Pool C (8월) ── pool2: 130 nodes × 20 drives (3.5TiB SATA SSD)

EC Set Size 계산 (중요)

MinIO EC Set은 4~16 드라이브, 전체 드라이브 수가 나누어 떨어져야 합니다.

Pool	노드	드라이브/노드	총 드라이브	권고 EC Set	Parity	유효 용량
pool0	14	20	280	14 (20 sets)	EC:4 → k=10,m=4	~71%
pool1	14	20	280	14 (20 sets)	EC:4 → k=10,m=4	~71%
pool2	130	20	2,600	16 (162 sets)	EC:4 → k=12,m=4	~75%

⚠️ pool2: 2600 ÷ 16 = 162.5 → 안 나눠짐
2600 ÷ 13 = 200 sets (EC set 13, k=9 m=4) 또는
2600 ÷ 10 = 260 sets (EC set 10, k=6 m=4)
→ 실제 노드 수 확정 후 재계산 필수

클러스터 시작 커맨드 예시

# pool0 + pool1 동시 기동 (5월)
minio server \
  https://cold-pool0-{1...14}.example.com/data{1...20} \
  https://cold-pool1-{1...14}.example.com/data{1...20} \
  --address :9000 \
  --console-address :9001

# pool2 확장 (8월) - 기존 실행 중인 클러스터에 pool 추가
minio server \
  https://cold-pool0-{1...14}.example.com/data{1...20} \
  https://cold-pool1-{1...14}.example.com/data{1...20} \
  https://cold-pool2-{1...130}.example.com/data{1...20}  # 추가

⚠️ pool2 추가 시 클러스터 재시작 필요 — 다운타임 계획 필수

---

3. ILM Tier 연결 설정

Hot 클러스터에서 Cold를 Remote Tier로 등록

# Cold 클러스터를 "COLD-TIER"로 등록
mc ilm tier add minio HOT_CLUSTER/COLD-TIER \
  --endpoint https://cold-minio.example.com \
  --access-key <cold-access-key> \
  --secret-key <cold-secret-key> \
  --bucket cold-archive \
  --prefix hot-transition/

# Tier 확인
mc ilm tier ls HOT_CLUSTER

ILM 전환 규칙 설정 (버킷별)

# 예시: 30일 후 cold로 전환
mc ilm rule add HOT_CLUSTER/my-bucket \
  --transition-days 30 \
  --transition-tier COLD-TIER

# prefix별 차등 정책 (로그는 7일, 백업은 90일)
mc ilm rule add HOT_CLUSTER/my-bucket \
  --prefix "logs/" \
  --transition-days 7 \
  --transition-tier COLD-TIER

mc ilm rule add HOT_CLUSTER/my-bucket \
  --prefix "backup/" \
  --transition-days 90 \
  --transition-tier COLD-TIER

# 현재 ILM 규칙 확인
mc ilm rule ls HOT_CLUSTER/my-bucket

---

4. Replication 전략

MinIO AIStor에서 선택 가능한 방식:

옵션 1: ILM Transition만 사용 (권고)
Hot ──[ILM 전환]──→ Cold
- 원본은 Hot에서 stub(포인터)만 남음
- Cold에 실제 데이터 저장
- 복원 시 자동 recall

옵션 2: Bucket Replication + ILM 병행
Hot ──[복제]──→ Cold (동일 데이터 유지)
    └──[ILM 만료]──→ Hot 데이터 삭제
- Cold는 진짜 독립 복사본
- 용량 2배 필요, 네트워크 부담

옵션 3: Site Replication (비권고)
Hot ↔ Cold 양방향 Active-Active
- Cold tier 목적과 맞지 않음
- 불필요한 성능/용량 낭비

현재 정책 없는 상황에서는 옵션 1(ILM Transition만)으로 시작 권고

---

5. 정책 수립 우선순위 (고객사 협의 체크리스트)

지금 당장 결정 안 하면 5월 구축이 불가능한 항목들:

[ ] 1. ILM 전환 기준 - 며칠 후 Cold로 내릴 것인가?
        → 최소한 기본값이라도 (예: 30일 미접근)

[ ] 2. 버킷 분류 - 어떤 버킷이 tiering 대상인가?
        → 전체 vs 특정 prefix/bucket

[ ] 3. 데이터 복원(recall) 정책 - Cold에서 꺼낼 때 Hot으로 올릴 것인가?
        → MinIO는 기본 transparent recall 지원

[ ] 4. Cold Tier 접근 계정 분리 여부
        → Hot과 Cold의 Access Key 분리 권고

[ ] 5. 모니터링/알람 기준
        → Tier 전환 실패, Cold 클러스터 health

---

6. 구축 타임라인

[지금 ~ 5월 전 2주]
  ✅ pool0/pool1 EC set size 확정 (드라이브 수 재확인)
  ✅ Cold 클러스터 네트워크/DNS 설계
  ✅ ILM 기본 정책 고객사 합의
  ✅ Cold bucket 이름/prefix 체계 결정

[5월: pool0 + pool1 기동]
  → Cold MinIO AIStor 클러스터 기동 (2개 pool 동시)
  → Hot 클러스터에 Remote Tier 등록
  → 파일럿 버킷 2~3개에 ILM 규칙 적용
  → 전환/recall 동작 검증

[5월 ~ 8월]
  → 파일럿 결과 기반 전체 버킷 ILM 적용
  → 용량 모니터링

[8월: pool2 추가]
  → Cold 클러스터 pool2 확장 (재시작 필요 → 점검 일정 확보)
  → EC set size 재검증
  → 전체 정책 안정화

---

핵심 주의사항 요약

1. MinIO Tiering은 외부 Remote Tier → Cold는 반드시 별도 클러스터
2. pool2 (130 nodes) 추가 시 전체 Cold 클러스터 재시작 필요 → 8월 점검 윈도우 사전 확보
3. EC set size는 총 드라이브 ÷ set_size = 정수 조건 필수 → 지금 계산 확정할 것
4. ILM 정책 없으면 Cold 구축해도 데이터가 안 내려감 → 정책 합의가 인프라보다 먼저

pool2 130노드 EC set size 계산이나 mc 명령어 상세 설정이 필요하면 말씀해 주세요!