💡 핵심 인사이트 콜드/핫 데이터 계층화(Cold/Hot Data Tiering)는 **"데이터를 사용 빈도(접근 빈도)에 따라 핫(고성능/고비용), 워름(중간), 콜드(저성능/저비용) 스토리지로自動分级配置하는 데이터 라이프사이클 관리 기법"**입니다. 모든 데이터를 SSD에 저장하면 성능은 뛰어나지만 비용이 하늘을 찌르고, 모두 HDD에 저장하면 비용은 싸지만 성능이 바닥을 찍습니다. Tiering은 **"자주 쓰는 데이터는 빠른 스토리지에, 그렇지 않은 데이터는 느린 스토리지에 自动 배치"**하여 비용과 성능의黄金比例을実現します。

Ⅰ. 데이터의 수명 주기와 접근 패턴

[데이터 접근 패턴의 시간적 변화]

  접근頻度
     ▲
     │★★★★★  ← 생애 초기: 접근 빈도 높음 (핫)
     │★★★★☆
     │★★★☆☆
     │★★☆☆☆  ← 생애中期: 접근 빈도 감소 (워름)
     │★☆☆☆☆
     │☆☆☆☆☆  ← 생애 말기: 거의 접근 안 함 (콜드)
     └──────────────► 시간 →
     생성   30일   3개월  1년   3년

  예시:
  - 신상품 출시 데이터: 첫 달 수만 회/일 접근 → 1년 후 年数 회 접근
  - 과거 거래 내역: 계약 시 다수 접근 → 계약 종료 후 거의 미접근
  - Regulatory 보존 데이터: 특정 기간만 접근 → 이후 거의零 접근

계층화하지 않으면 발생하는問題:

1. 비용 비효율: 사용 빈도低的 데이터에도 고비용 스토리지 사용
2. 성능 저하: 핫 데이터가 콜드 데이터와 스토리지 경합
3. 관리 복잡: "어떤 데이터가 어느 스토어에 있는지" 파악困難

II. 스토리지 티어 구성과 접근 방식

[3-Tier 스토리지 아키텍처]

  ┌──────────────────────────────────────────────────────────────┐
  │                     데이터 lake / DW                         │
  │                                                              │
  │  ┌────────────────┐ ┌────────────────┐ ┌────────────────┐  │
  │  │   Hot Tier     │ │   Warm Tier    │ │   Cold Tier    │  │
  │  │  (고성능 SSD)  │ │  (일반 SSD/HDD) │ │  (오브젝트     │  │
  │  │                │ │                │ │   스토리지)     │  │
  │  │  NVMe SSD      │ │  SSD 또는      │ │                │  │
  │  │  0.1ms 지연    │ │  HDD (멀티弟弟) │ │  S3 Glacier    │  │
  │  │  GB당 고가     │ │  10ms 지연     │ │  Azure Archive │  │
  │  │                │ │  GB당 중간가    │ │  GCS Coldline  │  │
  │  │  실시간 분석    │ │  주별 배치 분석 │ │  수십 ms~수분  │  │
  │  │  (현행 거래)   │ │  (최근 데이터)  │ │  월1회 접근    │  │
  │  │                │ │                │ │  (보존/감사용)  │  │
  │  └────────────────┘ └────────────────┘ └────────────────┘  │
  │                                                              │
  │  티어링 정책 (Tiering Policy)                                 │
  │  - 0~30일: Hot 自动 배치                                    │
  │  - 30~90일: Warm 自动 이동                                  │
  │  - 90일~: Cold 아카이브                                      │
  │                                                              │
  └──────────────────────────────────────────────────────────────┘

각 티어의 상세 사양

III. 티어링 자동화 구현

Snowflake의自動 티어링

-- Snowflake: 테이블 크기에 따른 자동 티어링
CREATE TABLE transactions (
    transaction_id BIGINT,
    amount DECIMAL(10,2),
    created_at TIMESTAMP
)
-- data_retention_time_in_days: 90일
-- 90일 이내는 Hot/Warm Tier
-- 90일 이후: Snowflake 자동 archieve (Cold Tier)
DATA_RETENTION_TIME_IN_DAYS = 90;

Apache Hive / HDFS 계층화

<!-- hive-site.xml: 스토리지 정책 설정 -->
<property>
  <name>hive.exec.dynamic.partition.mode</name>
  <value>nonstrict</value>
</property>

<!-- HDFS tiers 설정 -->
<property>
  <name>dfs.storage.policy.enabled</name>
  <value>true</value>
</property>

<!--
  SSD 스토리지: hot-storage-pool
  HDD 스토리지: warm-storage-pool
 Archive 스토리지: cold-storage-pool
-->

###Tier migration 정책

[Tier Migration 정책 설계]

  1. 시간 기반 (Time-based) ★가장 일반적
  ┌──────────────────────────────────────────┐
  │  0일   → Hot (NVMe SSD)                 │
  │  7일   → Warm (SSD)                     │
  │  30일  → Cold (오브젝트 스토어)           │
  │  365일 → Archive (Glacier, 深層 保存)     │
  └──────────────────────────────────────────┘

  2. 접근 기반 (Access-based)
  ┌──────────────────────────────────────────┐
  │  마지막 접근 > 30일 없음 → Warm으로 이동  │
  │  마지막 접근 > 90일 없음 → Cold으로 이동  │
  └──────────────────────────────────────────┘

  3. 사이즈 기반 (Size-based)
  ┌──────────────────────────────────────────┐
  │  테이블 크기 < 1GB → Hot (오버헤드防止)   │
  │  테이블 크기 > 100GB → Cold 고려         │
  └──────────────────────────────────────────┘

  4. 커스텀 정책
  ┌──────────────────────────────────────────┐
  │  Regulatiory 보존 테이블 → 절대 Cold 불가  │
  │  PII 포함 테이블 → 접근頻道と無関係 Cold 불가 │
  └──────────────────────────────────────────┘

IV. 비용 절감 효과 분석

[스토리지 비용 비교: Tiering vs 전부 Hot 저장]

  시나리오:
  - 전체 데이터: 100TB
  - 핫: 10TB, 워름: 30TB, 콜드: 60TB 분포
  - 1년 경과 후

  전부 Hot (NVMe SSD $0.05/GB):
  비용 = 100TB × $0.05 × 12개월 = $60,000/년

  Tiering 적용:
  ┌──────────────────────────────────────────┐
  │  Hot: 10TB × $0.05 × 12 = $6,000        │
  │  Warm: 30TB × $0.02 × 12 = $7,200       │
  │  Cold: 60TB × $0.004 × 12 = $2,880      │
  │  총계: $16,080/년                         │
  └──────────────────────────────────────────┘

  비용 절감: $60,000 → $16,080 = 약 73% 절감!

Ⅴ. 티어링 도입 시 고려사항と 📢 비유

데이터 지역성(Locality) 문제:

• 조인이 빈번한 테이블은 동일 티어에 배치해야 성능 저하 없음
• "콜드 테이블과 핫 테이블을 조인하면 콜드가 핫을 끌어내린다"

데이터 이동 비용:

• 핫→콜드 이동 시 네트워크 이월 비용 발생 (S3 egress 요금)
• 이동 중에 해당 데이터에 접근하면? → 이중 쓰기 또는プロキシ 필요

접근 지연이 업무에 영향을 주는가?:

• 실시간 대시보드: 핫 이어야 함
• 주간 보고서: 워름으로 충분
• 연 1회 감사報告: 콜드 가능

📢 섹션 요약 비유: 콜드/핫 티어링은 **"옷장을季節別に管理하는 것"**과 같습니다. 여름에 겨울옷을 옷장 앞쪽에 걸어두면 불편하죠. 그래서 "자주 쓰는 옷은 잘 보이는 곳에, 덜 쓰는 옷은 行ková에 넣고, 안 쓰는 옷은 수납 공간的最상층에 올려두는" 것이 자연스럽습니다. 데이터도 같습니다: "요즘 자주 보는 데이터(현행 거래)는 SSD라는 잘 닿는 行ková에,一ヶ月前の 데이터는 HDD라는 조금 먼 선반에, 1년 넘은 것은 Glacier라는 다락방에" 올려두는 것입니다. 중요한 것은 "옷장을管理하는咪도 정하고, 그 전략을自動으로実行하는" 것이 핵심입니다.漫然히全部 같은 옷장에 넣으면 비용만 나가고, 옷을 찾을 때마다 열이 식어버립니다.