콜드 데이터 vs 핫 데이터 계층화(Tiering) 스토리지 아키텍처
핵심 인사이트 (3줄 요약)
- 본질: 데이터 계층화 (Data Tiering)는 데이터의 접근 빈도(Hot, Warm, Cold)와 비즈니스 가치 변화에 따라, 고성능-고비용 저장소(NVMe SSD)에서 저성능-저비용 저장소(HDD, Object Storage, Tape)로 데이터를 물리적으로 재배치하는 스토리지 수명 주기 최적화 아키텍처다.
- 가치: 대용량 빅데이터 환경에서 모든 데이터를 단일 고성능 스토리지에 유지할 때 발생하는 천문학적인 인프라 TCO (Total Cost of Ownership)를 최대 80% 이상 절감하면서도, 최신 데이터에 대한 쿼리 레이턴시 (Latency)를 보장한다.
- 융합: 이 패턴은 단순한 파일 백업을 넘어 클라우드 네이티브 환경의 S3 수명 주기 정책, Elasticsearch의 ILM (Index Lifecycle Management), 그리고 클라우드 데이터 웨어하우스(Snowflake, Redshift)의 스토리지-컴퓨팅 분리 아키텍처와 결합하여 데이터 레이크 (Data Lake) 생태계의 핵심 기반으로 작동한다.
Ⅰ. 개요 및 필요성 (Context & Necessity)
-
개념: 데이터 계층화 (Tiering) 시스템은 데이터가 생성된 시점부터 폐기될 때까지의 수명 주기를 '온도(Temperature)'라는 메타포로 분류하여, 각 온도에 가장 적합한 I/O 성능과 비용 구조를 가진 스토리지 계층(Tier)으로 데이터를 자동 또는 반자동으로 마이그레이션 (Migration)하는 데이터 관리 전략이다.
-
필요성: 오늘날 IT 시스템은 로그, 센서 메트릭, 트랜잭션 기록 등 하루에도 수 테라바이트(TB)의 데이터를 쏟아낸다. 데이터의 가치는 생성 직후 가장 높으며 시간이 지날수록 급격히 하락하는 '가치 반감기' 특성을 띤다. 예를 들어 어제 발생한 결제 내역은 오늘 고객 응대나 환불 처리를 위해 수천 번 조회되지만(Hot), 5년 전 결제 내역은 법적 컴플라이언스(보관 의무) 외에는 거의 조회될 확률이 0에 가깝다(Cold). 이를 모두 밀리초(ms) 단위 응답을 보장하는 고가의 블록 스토리지 (Block Storage)에 유지하면 스토리지가 가득 차 장애가 발생하거나 IT 예산이 파탄 난다. 반대로 모두 저렴한 아카이브(Archive) 스토리지에 두면 실시간 서비스가 불가능해진다. 이 모순을 해결하는 유일한 방법이 물리적 계층 분리다.
-
등장 배경 및 발전 과정:
- 초기 HSM (Hierarchical Storage Management): 1990년대 메인프레임 환경에서 고가의 자기 디스크와 저렴한 자기 테이프 간에 파일을 옮기던 것이 시초다.
- 빅데이터 및 NoSQL의 폭발: 하둡(Hadoop)과 엘라스틱서치(Elasticsearch) 클러스터 규모가 페타바이트(PB) 단위로 커지면서, 핫/웜/콜드 노드(Node)를 분리하는 아키텍처 패턴이 정립되었다.
- 클라우드 객체 스토리지의 성숙: AWS S3 (Standard, IA, Glacier)와 같은 클라우드 스토리지 클래스가 세분화되고, 수명 주기 정책 (Lifecycle Rule)을 통한 투명한(Transparent) 마이그레이션이 대중화되었다.
다음 다이어그램은 모든 데이터를 단일 계층에 저장할 때의 문제점과 이를 해결하는 계층화 아키텍처의 패러다임 변화를 대조하여 보여준다.
┌───────────────────────────────────────────────────────────────┐
│ 단일 스토리지 구조 vs 데이터 계층화(Tiering) 아키텍처 │
├───────────────────────────────────────────────────────────────┤
│ │
│ [기존: 단일 고성능 스토리지 아키텍처] │
│ │
│ (응답 1ms / 비용 100) ┌─────────────────────────┐ │
│ 고가의 NVMe SSD │ 1일 전 (Hot) : 1TB │ │
│ │ 1달 전 (Warm) : 30TB │ ◀ 예산낭비! │
│ │ 5년 전 (Cold) : 500TB│ ◀ 용량포화! │
│ └─────────────────────────┘ │
│ │
│ [개선: 온도 기반 데이터 계층화 아키텍처 (Data Tiering)] │
│ │
│ ┌──────────────┐ 자동 이동 (정책) ┌──────────────┐ │
│ │ Hot Tier │ ──────────────────────▶ │ Warm Tier │ │
│ │ (NVMe / RAM) │ 30일 경과 │ (HDD / S3-IA)│ │
│ │ 1일~30일 데이터│ │ 1달~1년 데이터 │ │
│ │ 응답: < 1ms │ │ 응답: ~100ms │ │
│ │ 비용: $$$$ │ │ 비용: $$ │ │
│ └──────────────┘ └──────┬───────┘ │
│ │ │
│ 자동 아카이빙 │ │
│ 1년 경과 │ │
│ ▼ │
│ ┌──────────────┐│
│ │ Cold Tier ││
│ ★ 핵심: 데이터의 조회 확률(가치)과 물리적 저장 │(Glacier/Tape)││
│ 매체의 비용 곡선을 완벽히 일치시킴! │ 1년 이상 데이터││
│ │ 응답: 수 시간 ││
│ │ 비용: $ ││
│ └──────────────┘│
└───────────────────────────────────────────────────────────────┘
[다이어그램 해설] 단일 스토리지 구조에서는 과거 데이터가 누적됨에 따라 고가의 스토리지 용량이 기하급수적으로 고갈되며, I/O 경합(Contention)이 발생해 정작 빠른 응답이 필요한 최신 데이터의 조회 성능까지 동반 하락한다. 반면 계층화 아키텍처는 데이터를 온도(Hot, Warm, Cold)에 따라 세그먼트화한다. Hot Tier는 IOPS(Input/Output Operations Per Second)가 가장 높은 NVMe SSD로 구성되어 실시간 트랜잭션을 처리한다. 데이터가 일정 기한(예: 30일)을 넘기면 백그라운드 프로세스나 스토리지 정책에 의해 상대적으로 저렴하고 용량이 큰 Warm Tier(HDD 기반 또는 클라우드 객체 스토리지)로 이동한다. 법적 보관 목적의 데이터(예: 1년 이상)는 Cold Tier(아카이브/테이프 스토리지)로 이동하며, 이 계층은 기가바이트당 비용이 극히 낮지만 데이터를 다시 읽어오기 위해 수 분에서 수 시간이 소요되는 특성을 가진다.
- 📢 섹션 요약 비유: 자주 입는 외투는 침대 옆 옷걸이(Hot)에 걸어 1초 만에 입고, 지난 계절 옷은 옷장 안(Warm)에 두며, 작년에 입고 작아진 옷은 지하실 박스(Cold)에 테이프로 밀봉해 보관함으로써 한정된 내 방(예산) 공간을 가장 넓게 쓰는 이치와 같습니다.
Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)
계층별 구성 요소 및 특성 매트릭스
데이터 계층화 시스템은 스토리지 미디어, 네트워크 계층, 그리고 데이터를 마이그레이션하는 정책 엔진으로 구성된다.
| 계층 (Tier) | 데이터 특성 | 권장 스토리지 미디어 | I/O 프로파일 특성 | 실무 활용 비유 |
|---|---|---|---|---|
| Hot Tier | 실시간 쓰기/조회, 높은 빈도, 최근 생성 | NVMe SSD, 인메모리 (Redis), AWS EBS (io2) | Random Read/Write 집중, 높은 IOPS구 | 수술실 응급 트레이 |
| Warm Tier | 가끔 조회되는 분석용 데이터, 배치 처리 대상 | Enterprise SATA HDD, AWS S3 Standard-IA | Sequential Read 중심, 높은 Throughput | 병원 기록실 일반 캐비닛 |
| Cold Tier | 규제 준수(Compliance), 거의 조회되지 않음 | Magnetic Tape (LTO), AWS S3 Glacier, Deep Archive | Write Once Read Rarely, 긴 복원 레이턴시 | 지하 문서 보존소 (밀봉) |
| 정책 엔진 | 각 계층 간 데이터 이동 룰 | 클라우드 Lifecycle Rule, ILM (Index Lifecycle Mgt) | 메타데이터 기반 TTL (Time to Live) 평가 | 문서 이관 관리자 |
심층 메커니즘: Elasticsearch의 ILM (Index Lifecycle Management) 구조
가장 대표적인 데이터 계층화 적용 사례는 로그 분석에 널리 쓰이는 Elasticsearch 클러스터의 ILM 아키텍처다.
┌──────────────────────────────────────────────────────────────────┐
│ Elasticsearch ILM 기반 Hot-Warm-Cold 아키텍처 구조도 │
├──────────────────────────────────────────────────────────────────┤
│ │
│ [ 데이터 수집 파이프라인 (Logstash / Beats) ] │
│ │ │
│ ▼ (새로운 로그 인입) │
│ │
│ ┌─────────────────[ Hot Nodes (고성능 군) ]──────────────────┐ │
│ │ 🔹 역할: 활발한 인덱싱(쓰기) 및 실시간 검색 │ │
│ │ 🔹 하드웨어: NVMe SSD, 고성능 CPU, 넉넉한 JVM Heap │ │
│ │ 🔹 상태: Index-000001 (Active) │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │ │
│ │ (Rollover 조건 충족: 50GB 도달 또는 7일 경과) │
│ ▼ 자동 마이그레이션 │
│ │
│ ┌─────────────────[ Warm Nodes (대용량 군) ]─────────────────┐ │
│ │ 🔹 역할: 읽기 전용 쿼리, 시계열 분석, 인덱스 병합(Shrink/Merge) │ │
│ │ 🔹 하드웨어: 고용량 HDD, 중간 수준 CPU │ │
│ │ 🔹 상태: Index-000001 (Read-only, 최적화 완료) │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │ │
│ │ (시간 경과: 30일 경과) │
│ ▼ 자동 아카이빙 │
│ │
│ ┌─────────────────[ Cold Nodes (저비용 군) ]─────────────────┐ │
│ │ 🔹 역할: 희귀한 과거 데이터 보관, 스냅샷(Snapshot) 생성 │ │
│ │ 🔹 하드웨어: 저렴한 네트워크 스토리지, 최소한의 메모리 │ │
│ │ 🔹 상태: Index-000001 (Frozen, 메모리 상주 최소화) │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ (Delete Phase: 365일 경과) │
│ [ 데이터 영구 삭제 ] │
└──────────────────────────────────────────────────────────────────┘
[다이어그램 해설] 이 아키텍처는 노드 레벨에서 물리적인 하드웨어 스펙을 분리하고, 데이터를 생명 주기에 따라 자동으로 이동시키는 구조를 명확히 보여준다. 새로 유입되는 대량의 로그는 오직 Hot Nodes에만 기록된다. 이 노드는 초당 수만 건의 쓰기 작업(Indexing)을 견뎌야 하므로 비싼 SSD를 장착한다. 인덱스 크기가 50GB를 넘거나 7일이 지나면(Rollover), 정책 엔진은 이 인덱스를 더 이상 쓰기가 발생하지 않는 상태(Read-only)로 잠그고 Warm Nodes로 옮긴다. 이 과정에서 세그먼트를 병합(Merge)하여 검색 효율을 극대화한다. 30일이 지나면 이 데이터는 Cold Nodes로 이동하며, 메모리(JVM Heap)를 거의 차지하지 않도록 동결(Frozen) 처리된다. 만약 사용자가 과거 데이터를 검색하면 응답 시간은 느리지만 시스템 안정성에는 영향을 주지 않는다. 마지막으로 보관 의무 기간인 1년이 지나면 디스크에서 완전히 삭제된다. 이 전체 파이프라인이 개발자의 수동 개입 없이 JSON 기반의 ILM 정책에 의해 자율적으로(Autonomous) 구동된다.
- 📢 섹션 요약 비유: 물류 센터에서 갓 도착한 택배(Hot)는 상하차 레일 바로 옆에 두고 즉시 출고하고, 일주일째 안 찾아가는 물건(Warm)은 일반 창고로 빼며, 반송 대기 물건(Cold)은 야외 컨테이너에 밀어 넣어 핵심 작업 공간의 정체를 막는 자동화 컨베이어 벨트와 같습니다.
Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)
클라우드 환경 스토리지 계층 비교 (AWS S3 기준)
단순히 "싸다/비싸다"를 넘어, 각 계층의 API 호출 비용과 최소 보관 기간의 트레이드오프를 계산해야 한다.
| 스토리지 클래스 | 주요 활용 (Tier) | 저장 비용 (GB당) | 검색/추출 비용 | 최소 보관/크기 조건 | 레이턴시 |
|---|---|---|---|---|---|
| S3 Standard | Hot Data | 높음 | 낮음 | 없음 | 밀리초 (ms) |
| S3 Standard-IA | Warm Data | 중간 (Standard 대비 ~50%) | 높음 (GB당 추출비 부과) | 30일 / 128KB | 밀리초 (ms) |
| S3 Glacier Flexible | Cold Data | 낮음 (Standard 대비 ~10%) | 중간 | 90일 | 수 분 ~ 12시간 |
| S3 Glacier Deep Archive | Deep Cold Data | 매우 낮음 (가장 저렴) | 중간 | 180일 | 12시간 ~ 48시간 |
이 비교 매트릭스에서 가장 주의해야 할 함정은 S3 Standard-IA (Warm Tier)의 추출 비용이다. 저장 비용이 싸다고 해서 조회가 자주 일어나는 핫 데이터를 IA로 넘기면, GB당 부과되는 데이터 검색 요금 폭탄(Data Retrieval Charge)을 맞고 오히려 총비용이 증가하는 역전 현상이 발생한다.
데이터 레이크 및 아키텍처 융합 관점
-
컴퓨팅-스토리지 분리 (Separation of Storage and Compute): Snowflake나 BigQuery 같은 최신 클라우드 DW는 로컬 디스크에 데이터를 영구 저장하지 않는다. 마이크로 파티션 단위로 쪼개진 데이터를 S3(객체 스토리지)에 저장하고, 쿼리가 들어올 때만 임시로 로컬 NVMe SSD(Hot Cache)로 끌고 와서 처리한다. 이는 사실상 쿼리 엔진 내부적으로 마이크로 티어링(Micro-tiering)을 동적으로 수행하는 융합 아키텍처다.
-
📢 섹션 요약 비유: 주차장 요금과 같습니다. 강남 한복판 주차장(Hot)은 1시간에 5천 원이지만 차를 바로 뺄 수 있고, 외곽 공영 주차장(Warm)은 하루 종일 1만 원이지만 차를 가지러 가는 데 왕복 택시비(추출 비용)가 듭니다. 용도에 맞게 대지 않으면 배보다 배꼽이 커집니다.
Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)
실무 시나리오 및 의사결정
-
시나리오 — 클라우드 비용 최적화를 위한 지능형 계층화 적용: 한 미디어 회사가 5PB 규모의 비디오 원본 파일과 사용자 로그를 AWS S3에 쌓아두고 있다. 어떤 비디오가 언제 떡상하여(Viral) 다시 핫 데이터가 될지 예측하기 어렵다. 수명 주기 정책(30일 후 IA 이동)을 일괄 적용했다가, 예전 비디오가 갑자기 인기를 끌며 IA 추출 비용이 수천만 원 청구되었다.
- 의사결정: 데이터의 온도를 예측하기 힘든 워크로드이므로, 단순 날짜 기반의 정적 룰 대신 S3 Intelligent-Tiering 클래스를 도입한다. 이는 클라우드 벤더의 머신러닝 엔진이 오브젝트 단위로 접근 패턴을 모니터링하여, 30일 연속 접근이 없으면 Infrequent Access 계층으로 내리고, 다시 접근이 발생하면 즉시 Frequent Access 계층으로 올리며 추출 비용을 면제해 주는 동적 티어링(Dynamic Tiering) 전략이다. 약간의 모니터링 요금이 추가되지만 변동성이 큰 워크로드에서는 TCO 최적화의 정답이다.
-
시나리오 — 온프레미스 RDBMS의 파티셔닝 기반 계층화 (Data Aging): 전통적인 오라클(Oracle) DB 환경에서 10년 치 거래 원장(10TB)이 단일 테이블에 있어 백업(RMAN) 및 인덱스 재생성 작업에 주말 내내 시간이 소요된다.
- 의사결정: 테이블을 날짜(YYYYMM) 기준의 **레인지 파티셔닝 (Range Partitioning)**으로 쪼갠다. 당해 연도 파티션은 고성능 SSD로 구성된 테이블스페이스에 매핑(Hot Tier)하고, 작년 이전 파티션들은 느린 SATA 스토리지 테이블스페이스에 매핑(Cold Tier)한 뒤 읽기 전용(Read-only)으로 전환한다. 이를 통해 백업 대상을 Hot 파티션으로만 한정 지어 백업 시간을 획기적으로 단축(Data Aging 기법)한다.
계층화 아키텍처 도입 의사결정 트리
┌───────────────────────────────────────────────────────────────────┐
│ 데이터 계층화 (Tiering) 전략 수립 의사결정 트리 │
├───────────────────────────────────────────────────────────────────┤
│ │
│ [데이터 접근 패턴 프로파일링] │
│ │ │
│ ▼ │
│ 데이터의 조회 빈도가 시간이 지남에 따라 명확히 하락하는가? │
│ ├─ 아니오 ──▶ [단일 스토리지 계층 유지 및 압축률 튜닝 집중]│
│ │ │
│ └─ 예 │
│ │ │
│ ▼ │
│ 과거 데이터에 대한 조회 패턴을 미리 예측할 수 있는가? │
│ ├─ 아니오 ──▶ [지능형 티어링(Intelligent-Tiering) 적용] │
│ │ (ML 기반 동적 계층 이동) │
│ │ │
│ └─ 예 (예: 30일 지나면 절대 안 봄) │
│ │ │
│ ▼ │
│ Cold Data를 복원할 때 허용되는 대기 시간(RTO)은 얼마인가? │
│ ├─ 수 분 내 ──▶ [Warm Tier (S3-IA, 저가형 HDD) 유지] │
│ └─ 수 시간 ───▶ [Deep Archive (Glacier, Tape) 이동] │
│ │
│ 판단 포인트: "저장 비용 절감액이 검색 오버헤드 비용보다 압도적으로 큰가?"│
└───────────────────────────────────────────────────────────────────┘
[다이어그램 해설] 아키텍트가 가장 흔하게 저지르는 안티패턴은 '보관 비용'만 계산하고 '추출(복원) 비용'과 '네트워크 대기 시간'을 무시하는 것이다. Cold 스토리지에 데이터를 묻어버리는 것은 쉽지만, 갑작스러운 감사(Audit) 요건으로 5년 치 로그를 수 시간 안에 복원해야 할 때 Glacier 스토리지 구조에서는 엄청난 지연과 급행 복원 요금(Expedited Retrieval)이 발생한다. 따라서 계층 간 이동 정책을 짤 때는 반드시 비즈니스 부서와 SLA (Service Level Agreement) 및 RTO (Recovery Time Objective)를 사전 합의한 후, 그 기준에 맞는 스토리지 클래스를 매핑해야 한다.
- 📢 섹션 요약 비유: 냉장고(Hot), 김치냉장고(Warm), 냉동실(Cold) 구조와 같습니다. 당장 저녁에 먹을 고기를 냉동실에 얼려버리면 해동하느라 밥때를 놓치듯, 데이터의 유통기한과 활용 시점을 정확히 파악해야 완벽한 티어링이 완성됩니다.
Ⅴ. 기대효과 및 결론
정량/정성 기대효과
| 구분 | 단일 고성능 스토리지 유지 시 | 데이터 계층화 (Tiering) 적용 시 | 개선 효과 |
|---|---|---|---|
| 정량 | 매년 스토리지 증설 비용 기하급수적 증가 | 오래된 데이터를 저가형 스토리지로 마이그레이션 | 전체 스토리지 TCO 50~80% 절감 |
| 정량 | 대용량 풀 스캔 시 인덱스와 버퍼 캐시 오염 | 활성 데이터(Hot)만 메모리/SSD에 상주 | 핵심 쿼리 레이턴시 안정성 유지 및 향상 |
| 정성 | 백업/복구 창(Backup Window) 부족 야기 | 읽기 전용 상태인 Cold 데이터는 백업 대상에서 제외 | 백업/복구 소요 시간 획기적 단축 |
미래 전망
- AI 기반 자율 스토리지 (Autonomous Storage): 정적인 룰(예: 30일 경과 시 이동)을 넘어, 생성형 AI와 강화학습이 결합하여 쿼리 패턴의 계절성(Seasonality)과 요일별 특성을 스스로 학습한 뒤, 데이터 블록 단위로 핫/콜드 계층을 실시간 재배치하는 진정한 소프트웨어 정의 스토리지(SDS) 생태계가 만개할 것이다.
- DNA 스토리지 및 광학 매체: 테이프(Tape)를 넘어 수천 년간 데이터를 보존할 수 있고 전력 소모가 0에 가까운 차세대 Deep Cold 매체(예: 합성 DNA 스토리지, Microsoft Project Silica)가 실증 단계에 진입하며 콜드 아카이빙 패러다임을 바꿀 것이다.
참고 표준
- SNIA (Storage Networking Industry Association): 계층형 스토리지 및 데이터 관리 프레임워크 표준
- 데이터 보안 규제 (GDPR, ISMS): 개인정보 파기 및 장기 보관 의무에 대한 물리적 매체 분리 권고안
모든 데이터가 동등하게 태어나지만, 시간이 지남에 따라 그 가치는 극단적으로 불평등해진다. 데이터 계층화(Tiering) 아키텍처는 이 불평등함을 인프라 비용 구조에 완벽하게 일치시키는 데이터 엔지니어링의 미학이다. 무한히 팽창하는 데이터 레이크 환경에서, 데이터를 무작정 쌓아두는 '데이터 늪(Data Swamp)'을 방지하고 시스템의 민첩성과 경제성을 유지하기 위해 티어링 기술은 시스템 아키텍트가 반드시 설계 초기부터 고려해야 할 영순위 전략이다.
- 📢 섹션 요약 비유: 가장 비싼 땅(강남)에는 가장 수익성 높은 매장(Hot Data)을 세우고, 창고(Cold Data)는 땅값이 싼 외곽으로 빼는 도시 계획과 같습니다. 데이터를 똑똑하게 분산 수용해야 IT 인프라라는 도시가 교통체증 없이 원활하게 굴러갈 수 있습니다.
📌 관련 개념 맵 (Knowledge Graph)
| 개념 명칭 | 관계 및 시너지 설명 |
|---|---|
| 파티셔닝 (Partitioning) | 테이블을 날짜 등의 기준으로 분할하여, 각 파티션을 각기 다른 물리적 스토리지 계층에 맵핑하는 티어링의 논리적 기반이다. |
| 객체 스토리지 (Object Storage) | 블록 스토리지보다 유연하고 무한 확장이 가능하여, Warm/Cold 티어의 주력 백엔드로 활용되는 핵심 스토리지 구조다. |
| Elasticsearch ILM | 시계열 데이터(로그)를 Hot, Warm, Cold 노드로 자동 이전하고 병합/삭제하는 엘라스틱 스택의 자동화 수명 주기 관리 체계다. |
| 옵티마이저 (Optimizer) | RDBMS에서 파티션 프루닝(Pruning)을 통해 콜드 티어에 있는 데이터 스캔을 회피하고 핫 데이터만 빠르게 조회하도록 돕는다. |
| 백업 및 복구 (RTO/RPO) | 티어링은 백업 크기를 핫 데이터로 한정 지어 복구 시간을 줄이는 반면, 콜드 데이터의 복원 시 RTO 지연이라는 상충 관계를 갖는다. |
👶 어린이를 위한 3줄 비유 설명
- 매일 가지고 노는 로봇 장난감(Hot Data)은 손에 닿는 책상 위에 두고, 가끔 노는 블록(Warm Data)은 장난감 상자에, 애기 때 보던 동화책(Cold Data)은 다락방에 올려두죠?
- 컴퓨터 세상에서도 매일 찾는 정보는 제일 비싸고 빠른 서랍(SSD)에 두고, 잘 안 찾는 정보는 아주 싸고 느린 깊은 창고(Glacier)로 자동으로 옮겨요.
- 이렇게 정리를 잘 해두어야, 내 방(비싼 저장 공간)이 터질 듯이 가득 차지 않고 내가 원하는 장난감을 1초 만에 바로 찾을 수 있답니다!