클라우드의 스토리지 탐구 - (1) 티어링
이 글은 시리즈의 1편입니다. 3부작으로 생각하고는 있는데... 확정 된 부분은 아닙니다.
스토리지 티어링을 이야기하면, 많은 사람들이 이걸 그냥 "저장소를 싸게 바꾸는 기능" 정도로 이해한다. Hot은 비싸고 빠르고, Cold는 싸고 느리고, 그러니 안 쓰는 데이터는 Cold로 내리면 비용이 절감된다 — 딱 이 수준에서 멈춘다.
그런데 이 "싸질수록 느려진다" 라는 직관은 절반만 맞다. 정확히 말하면, 스토리지 티어링은 싸질수록 느려지는 게 아니라 싸질수록 읽기 비용·복구 지연·최소 보관 기간 제약이 커지는 쪽에 가깝다. 이 차이를 이해하지 못하면, "Cold로 내렸더니 오히려 청구 금액이 늘었다" 같은 황당한 일을 겪게 된다.
메모리 계층에 대해 기억하는가? 사실 CS에서는 슥 보고 넘어가지만, 이것을 파고들어보면, 의외로 할 이야기가 많다. 본격적인 클라우드의 스토리지를 바라보기 전, 스토리지 계층 구조부터 먼저 생각해보자.
스토리지 계층구조 다시 살펴보기
컴퓨터 구조를 공부했다면 이 그림이 익숙할 것이다.
위로 갈수록 빠르지만 비싸고 작고, 아래로 갈수록 느리지만 싸고 크다. 그리고 이 계층이 성립하는 단 하나의 이유는, 데이터 접근에 지역성(locality) 이 존재하기 때문이다. 자주 쓰는 건 위쪽 비싼 자리에, 안 쓰는 건 아래쪽 싼 자리에 넣는다 — 이 원칙은 CPU 캐시에서나, S3 스토리지 클래스에서나 완전히 동일하다.
즉, 스토리지 티어링은 새로운 개념이 아니라 바이트당 비용 vs 접근 지연 이라는 오래된 이야기를 디스크 너머 클라우드까지 늘린 것일 뿐이다. 그렇게 보면, "왜 싸질수록 이런저런 제약이 붙는가" 도 자연스럽게 설명된다.
레이턴시 - 읽는데 왜 오래 걸리지?
멀리갈 필요 없이, 매체의 물리적 특성 때문이다.
- SSD/NVMe: 기계적 이동 부품이 없다. 셀에 전기적으로 접근하므로 random access 지연이 µs 단위로 균일하다.
- HDD: 헤드를 옮기는 seek time + 플래터가 도는 rotational latency가 붙는다. 그래서 순차 접 근은 빠르지만 random 접근은 급격히 느려진다. (나중에 EBS 타입을 언급할 때 다시 등장하니, 기억하도록 하자.)
- 콜드 아카이브: Glacier 류의 "복구 지연" 은 인위적인 제약이 아니라, 비용을 극단적으로 낮추려고 매체를 평소엔 오프라인/저전력 상태로 둔 결과 다. 테이프든, 전원을 내려둔 디스크든, 읽으려면 일단 매체를 다시 "깨워서" 온라인으로 올려야 한다. 그래서 분~시간 단위의 restore가 필요한 것이다.
그러니까 "Cold는 느리다" 가 아니라, "Cold는 평소에 잠들어 있어서, 깨우는 데 시간이 든다" 가 정확한 표현이다.
왜 retrieval fee와 최소 객체 크기 제한이 있지?
- retrieval fee (읽기 비용): 싼 티어는 "거의 안 읽는다" 는 가정 위에서 저장 단가를 후려친 것이다. 따라서 자주 읽으면 그 가정이 깨지므로, 읽을 때 비용을 물려서 자주 읽을 거면 위 티어를 쓰라 는 신호를 준다.
- 최소 객체 크기 / 메타데이터 오버헤드: 오브젝트 스토리지는 객체마다 위치·체크섬·암호화 키 같은 메타데이터를 별도로 들고 있다. 객체가 128KB보다 작아지면 데이터보다 메타데이터 관리 비용이 더 커지는 구간이 생긴다. 그래서 작은 객체에 최소 과금 단위를 두거나, 콜드 티어 전환 시 객체당 오버헤드를 매긴다. 작은 파일 수억 개를 무작정 콜드로 보내면 안 되는 이유가 여기 있다.
- 운영체제를 공부했다면, 내부 단편화에 대해 들어봤을 것이다. 그림이 그려지지 않는가?
정리하면, 단순히 느리다, 빠르다를 넘어 매체의 물리와 메타데이터 구조에서 나오는 필연 이라고 생각하자.
11-nines?
그런데 지금까지는 "비용은 접근 지연이다" 라는 이야기만 했는데, 한 가지 포인트가 더 있다. 바로 내구성(durability)과 가용성(availability) 이다.
비슷해보이지만, 엄밀히 다른 개념이니 한 번만 다시 보고 넘어가자.
- 내구성 (durability): 한 번 저장한 데이터가 유실되지 않을 확률. "10년 뒤에도 그 비트가 그대로 있는가."
- 가용성 (availability): 지금 이 순간 그 데이터에 접근할 수 있는 확률. "장애가 나는 중에도 읽히는가."
S3가 흔히 자랑하는 "11 nines" (99.999999999%) 는 내구성 이야기다. 객체 1천만 개를 저장하면 평균적으로 1만 년에 1개 잃을까 말까 한 수준이라는 소리다.
그런데 디스크는 늘 깨지는데 어떻게 이게 가능할까?
replication vs erasure coding
db를 공부했다면 너무 쉽게 답을 내놓을 수 있을 것이다. 바로 replica 를 따는 것이다. 스토리지에서도 마찬가지로 Replication 을 생각해 볼 수 있다. 같은 데이터를 3벌 복사해 서로 다른 디스크/랙/AZ에 둔다. 하나 깨져도 나머지로 복구하면 되니까. 직관적이지만 한가지 치명적인 문제가 있다면, 저장 공간이 3배 (200% 오버헤드) 든다.
그래서 대규모 오브젝트 스토리지는 보통 erasure coding(EC) 을 쓴다. 데이터를 k 개 조각으로 나누고, 거기에 m 개의 패리티 조각을 더 만든다. (Reed-Solomon 등.) 그러면 k+m 개 조각 중 임의의 m 개가 날아가도 원본을 복구 할 수 있다. 예를 들어 10+4 구성이면 14개 중 4개가 깨져도 멀쩡한데, 저장 오버헤드는 40%에 불과하다. RAID의 패리티를 떠올리면 정확히 같은 원리다.
(여기서도 트레이드오프가 있다. EC는 조각을 나누고 패리티를 붙이는 자체에 고정 비용이 있어서, 작은 객체엔 비효율적 이다. 또 그놈의 작은 객체 문제다...)
AZ는 가용성의 단위다
그럼 One Zone 이 붙은 클래스는 왜 더 싼가? 여기서 AZ(Availability Zone)가 등장한다. AZ는 물리적으로 분리된 데이터센터(전원·냉각·네트워크가 독립)이고, 클라우드의 가용성은 보통 이 AZ 단위로 설계된다.
- S3 Standard / Standard-IA: 데이터를 여러 AZ에 분산 저장한다. AZ 하나가 통째로 날아가도(화재, 정전...) 데이터가 살아있다.
- One Zone-IA / Express One Zone: 이름 그대로 단일 AZ 에만 저장한다. 그래서 더 싸다.
즉 One Zone이 싼 이유는 "성능을 깎아서" 가 아니라 AZ 장애에 대한 내성을 포기해서 다. 그 AZ가 사라지면 데이터도 같이 사라진다. 그래서 One Zone은 "원본이 어딘가 따로 있어서 언제든 재생성 가능한 데이터" (예: 원천 데이터를 가공한 캐시성 결과물) 에만 써야 한다.
정리하면, 스토리지를 고를 때 우리는 사실 비용 / 접근 지연 / 내구성·가용성 이라는 최소 3개 축 위에 점을 찍는 것이다.
결국 싼 스토리지라면, 무언가 하나를 희생한다는 이야기라고 할 수 있다.
이제 이 원칙들이 AWS에서 어떻게 구현됐는지 케이스로 보자.
Case Study 1: AWS의 스토리지 계층
흔히 우리는 스토리지를 말할 때 Hot/Warm/Cold/Archive로 4분류를 하는데, 이건 개념적인 틀 이지 AWS의 공식 제품 라인이 아니다. 그리고 이 틀 안에 S3 계열과 EBS 계열이 섞여 있는데, 이 둘은 성격이 완전히 다른 물건이다.
- S3의 Storage Class 는 객체 저장 비용과 접근 빈도 를 최적화하는 선택지다. → 위에서 언급한 계층 구조에서, 오브젝트 스토리지와 콜드 스토리지 쪽이라고 할 수 있다.
- EBS의 volume type 은 블록 디바이스의 성능/비용 을 고르는 선택지다. → S3랑은 다른 개념이라고 봐야하는 것이다.
같은 "티어" 라는 단어를 써도, 전자는 "얼마나 자주 꺼낼 거냐", 후자는 "초당 몇 번의 I/O를 견뎌야 하냐" 의 문제다. 분리해서 보자.
S3 Storage Class
S3는 객체마다 Storage Class를 가질 수 있고, 아무것도 지정하지 않으면 기본은 S3 Standard 다.
| 계층 | AWS Storage Class | 성격 |
|---|---|---|
| Frequent | S3 Standard | 자주 접근, 밀리초 단위 접근 |
| Low-latency object | S3 Express One Zone | 단일 AZ, 낮은 지연의 object storage |
| Auto-tier | S3 Intelligent-Tiering | 접근 패턴이 불명확할 때 자동 티어링 |
| Infrequent | S3 Standard-IA | 드물게 접근하지만 즉시 읽어야 하는 데이터 |
| Infrequent / cheaper | S3 One Zone-IA | 단일 AZ, 재생성 가능한 데이터에 적합 |
| Cold | S3 Glacier Instant Retrieval | 거의 안 읽지만 즉시 읽기는 필요 |
| Archive | S3 Glacier Flexible Retrieval | 분 ~ 시간 단위 복구 허용 |
| Deep Archive | S3 Glacier Deep Archive | 장기 보관, 긴 복구 시간 허용 |
앞 절의 "retrieval fee" 가 그대로 등장한다. Standard-IA 와 One Zone-IA 는 밀리초 접근이 가능하지만,
- 읽을 때마다 retrieval fee 가 GB당 붙고,
- 128KB 미만의 작은 객체도 128KB로 과금 되며 (위에서 말한 메타데이터 오버헤드),
- 30일 최소 보관 기간 이 있다.
즉, 자주 읽거나 작은 객체가 많은 데이터를 무작정 IA로 내리면 오히려 비용이 늘어날 수 있다. 작은 데이터가 많다면? 자주 조회한다면?
Glacier 계열은 "그냥 싼 S3" 가 아니다
S3 Glacier Flexible Retrieval 이나 Deep Archive 에 들어간 객체는 실시간으로 바로 읽을 수 없다. 먼저 restore 요청을 해서 임시 복사본을 만들어야 한다. (이게 바로 앞에서 말한 "잠든 매체를 깨우는" 과정이다. Glacier Instant Retrieval 만은 예외적으로 밀리초로 바로 읽힌다.)
복구 시간은 티어별로 천차만별이다.
| 계층 | 복구 특성 |
|---|---|
| Glacier Instant Retrieval | 밀리초 접근 |
| Glacier Flexible Retrieval - Expedited | 보통 1~5분 (250MB 미만 객체 기준) |
| Glacier Flexible Retrieval - Standard | 보통 3~5시간 |
| Glacier Flexible Retrieval - Bulk | 보통 5~12시간 |
| Glacier Deep Archive - Standard | 보통 12시간 이내 |
| Glacier Deep Archive - Bulk | 보통 48시간 이내 |
여기에 최소 보관 기간이 더해진다. Glacier Instant / Flexible Retrieval은 90일, Deep Archive는 180일 이다. 이 기간 전에 삭제·전환하면 조기 삭제 비용이 발생하고, 전환 시 객체당 메타데이터 오버헤드도 붙는다. 그래서 작은 객체를 무작정 Glacier로 보내는 것 도 좋은 선택이 아니다.
결론적으로 Glacier는 "싸지만 느린 S3" 가 아니라 복구라는 절차를 거쳐야 다시 쓸 수 있는 보관소 다. 다시 말하면 복구 작업을 하면 할 수록 청구서에는 높은 금액이 뜰 것이다.
Intelligent-Tiering - 자동화는 또 돈...
접근 패턴을 모를 때 유용한 게 S3 Intelligent-Tiering 이다. 객체가 30일 동안 접근되지 않으면 Infrequent Access tier로, 90일 동안이면 Archive Instant Access tier로 자동으로 내려간다. (옵션을 켜면 Deep Archive까지 내려간다.)
사람이 "이 데이터는 30일 뒤부터 cold다" 라고 미리 정하는 게 Lifecycle 정책 이라면, Intelligent-Tiering은 실제 접근 패턴을 보고 S3가 알아서 비용을 최적화하는 방식이다.
다만 객체당 모니터링 비용이 따로 붙고, 128KB 미만 객체는 애초에 auto-tiering 대상이 아니라 Frequent Access tier에 남는다. 작은 객체가 수억 개면 모니터링 비용도 괴랄해질 것이다.
EBS volume type - HDD 를 다시 살펴보자.
이제 블록 스토리지인 EBS다. HDD 의 특징이었던 Random Access 에 약하고, Sequential 에 강한 특징은 여기서 그대로 적용된다.
| 계층 | EBS 타입 | 매체 | 성격 |
|---|---|---|---|
| General SSD | gp3 | SSD | 일반적인 트랜잭션 워크로드 |
| Provisioned IOPS SSD | io2 Block Express | SSD | 높은 IOPS, 낮은 latency, I/O intensive DB |
| Throughput HDD | st1 | HDD | big data, log processing, 대용량 순차 처리 |
| Cold HDD | sc1 | HDD | 낮은 비용, 드물게 접근하는 throughput-oriented 데이터 |
- SSD 계열(gp3, io2) 은 작은 I/O가 많은 transactional workload, 즉 IOPS(random 접근) 가 중요할 때 쓴다.
- HDD 계열(st1, sc1) 은 대용량 streaming workload, 즉 throughput(순차 접근) 이 중요할 때 쓴다.
왜냐고 묻는다면 당연히 HDD의 seek/rotational latency 때문에 random I/O가 비싸고 sequential I/O가 싸다는 것.
구체적 성능 한계는 이렇다. gp3는 baseline 3,000 IOPS / 125 MiB/s에서 볼륨당 최대 16,000 IOPS / 1,000 MiB/s 까지, io2 Block Express는 볼륨당 최대 256,000 IOPS / 4,000 MiB/s 까지다.
그러다보니 HDD인 st1/sc1을 "Warm/Cold tier니까" 라는 이유만으로 고르면 안 된다. 작은 random I/O가 많은 워크로드(예: 검색 인덱스)에는 오히려 독이다. 2-3부에서 Opensearch 이야기를 하면서 좀 더 자세히 다뤄보자.
Case Study 2: Do The Math - 직접 계산기를 뚜드려보자.
앞에서 청구서 이야기를 했으니, 진짜로 계산기를 뚜드려보자. 1TB(≈1,000GB)의 로그 를 한 달간 저장한다고 하고, 세 가지 클래스를 비교한다.
다만, 실제 가격은 리전·시점마다 다르고 자주 바뀐다. 아래 숫자는 정확한 금액이 아니라 구조를 보여주기 위한 대표값 이며, 실제 산정은 AWS Pricing Calculator로 해야 한다. 여기서 봐야 할 건 액수가 아니라 얼마나 빠르게 오르는지 다.
대표 단가를 이렇게 잡자. (GB-월 기준, 그리고 retrieval은 GB당 읽기 비용.)
| 클래스 | 저장 단가 | 읽기(retrieval) 단가 |
|---|---|---|
| S3 Standard | $0.023 | $0 (per-GB retrieval 없음) |
| S3 Standard-IA | $0.0125 | $0.01 |
| S3 Glacier Flexible Retrieval | $0.0036 | $0.01 (+ restore 요청비 · 3~5시간 대기) |
저장만 보면 당연히 Glacier가 압도적으로 싸다. 그런데 여기에 "한 달에 이 1TB 전체를 몇 번이나 읽느냐(N)" 를 넣으면 그림이 뒤집힌다.
| 월 전체 읽기 횟수 N | S3 Standard | Standard-IA | Glacier FR |
|---|---|---|---|
| 0회 | $23.0 | $12.5 | $3.6 |
| 1회 | $23.0 | $22.5 | $13.6 |
| 2회 | $23.0 | $32.5 | $23.6 |
| 3회 | $23.0 | $42.5 | $33.6 |
보다시피, 전체를 한 달에 한 번꼴로만 읽어도 Standard-IA는 이미 Standard보다 비싸진다. 크로스오버 지점을 계산하면 IA는 약 1.05회, Glacier는 약 1.9회다. 즉 IA/Glacier가 이득인 구간은 "전체를 한 달에 한 번도 안 읽다시피 하는" 아주 좁은 영역뿐이다. 게다가 Glacier는 거기에 3~5시간 복구 대기와 90일 최소 보관까지 얹힌다.
이게 retrieval fee가 admission control이라고 했던 말의 정량적 실체다. AWS는 은근 슬쩍 가격을 통해 "자주 읽을 거면 위 티어 쓰라" 고 유혹하고 있따.
작은 객체 - 더 파멸적!
여기에 1편 앞에서 본 최소 객체 크기 과금(128KB) 을 얹어보자. 로그를 10KB짜리 객체 하나하나로 IA에 올린다고 해보자.
- 10KB 객체도 IA에선 128KB로 과금 된다. → 실제 저장량이 약 12.8배로 부풀어 오른다.
- 1TB가 10KB 객체 약 1억 개라면, 과금 기준으로는 약 12.8TB 어치 저장료가 나간다.
IA로 내려서 아낀 저장 단가가, 작은 객체 페널티 한 방에 통째로 날아간다. (그래서 로그는 객체 하나하나 올리는 게 아니라, 묶어서 큰 파일(Parquet 등)로 만들어 올리는 것이다. 이건 다음 Case Study로 이어진다.)
Case Study 3: 로그 플랫폼에 대입하면
이 시리즈가 결국 OpenSearch / 로그 플랫폼을 염두에 둔 글이다 보니, 위 원칙을 로그 데이터의 생애주기에 대입해보면 그림이 선명해진다.
핵심은, 같은 "로그" 라는 데이터라도 시간이 지나며 접근 패턴(지역성)이 바뀌고, 따라서 적합한 티어도 바뀐다 는 것이다. 최근 로그는 자주·랜덤하게·빠르게 검색해야 하니 비싼 block storage에, 오래된 로그는 가끔 분석/감사용으로만 꺼내니 object storage에, 더 오래되면 "검색" 이 아니라 "보관" 의 영역이니 Glacier로. 메모리 계층에서 cache line이 evict되어 RAM으로, 다시 디스크로 내려가는 것과 정확히 같은 운동이다.
결론
간단하게 정리하면...
클라우드 스토리지 계층 구조는 단순히 "저장소를 싸게 바꾸는 기능" 이 아니다. 비용 / 접근 지연 / 내구성·가용성 이라는 축 위에서, 데이터의 접근 빈도, 복구 지연 허용치, IOPS 요구사항, 객체 크기, 최소 보관 기간, retrieval fee 를 함께 고려해 Hot / Warm / Cold / Archive로 배치하는, 메모리 계층의 클라우드 버전 이다.
다음 2편에서는, 이 티어링을 Kubernetes 위에 올릴 때 어떤 일이 벌어지는지 살펴보고, 좀 더 많은 이야기를 해보자.