[심층분석] 느린 HDD 수천만 대로 초당 1페타바이트를 서빙하는 AWS S3의 비밀

왜 지금 이 이야기인가

AWS S3는 2006년 출시 이후 사실상 "인터넷의 파일 시스템"으로 자리 잡았다. 그런데 최근 공개된 내부 아키텍처 분석이 개발자 커뮤니티를 뜨겁게 달구고 있다. 초당 1페타바이트(PB/s)의 트래픽, 초당 1억 5천만 건의 요청, 400조 개 이상의 객체 — 이 천문학적 규모의 시스템이 최신 SSD가 아닌 구식 HDD 수천만 대 위에서 돌아간다는 사실이 많은 엔지니어에게 충격을 주고 있기 때문이다. Reddit에서 338점과 74개의 댓글을 기록하며 활발한 토론이 이어졌다.

클라우드 비용 최적화가 업계 화두인 지금, S3가 어떻게 "싸고 느린" 하드웨어로 "비싸고 빠른" 서비스를 만들어냈는지 그 엔지니어링을 뜯어볼 가치가 충분하다.

핵심 기술 분석: 느린 디스크를 빠르게 만드는 법

HDD의 근본적 한계

HDD는 물리적 기계 장치다. 플래터(원판)가 분당 7,200회 회전하고, 액추에이터 암이 정확한 위치로 이동해야 데이터를 읽을 수 있다.

• 탐색 시간(seek time): 평균 ~8-9ms
• 회전 지연(rotational latency): 평균 ~4ms
• IOPS: 지난 30년간 약 120 IOPS에서 정체

용량은 720만 배 늘었지만 IOPS는 제자리이므로, 바이트당 접근 속도는 오히려 점점 느려지고 있다. 그런데도 S3가 HDD를 고수하는 이유는 단 하나, 가격이다. HDD는 바이트당 비용이 SSD 대비 5~10배 저렴하며, 지난 수십 년간 가격이 약 60억 배 하락했다.

S3의 아키텍처 전략

S3가 이 한계를 극복하는 핵심 전략은 대규모 병렬화와 계층적 캐싱이다.

1. 극단적 샤딩(Sharding): 수천만 대의 디스크에 데이터를 분산 저장한다. 개별 HDD가 120 IOPS밖에 못 내더라도, 1,000만 대를 병렬로 운용하면 이론상 12억 IOPS에 도달한다. 핵심은 단일 디스크의 성능을 높이는 것이 아니라, 디스크의 수를 늘리는 것이다.

2. 순차 I/O 최적화: HDD는 랜덤 I/O에 약하지만 순차 읽기/쓰기는 상당히 빠르다. S3는 내부적으로 객체를 큰 청크 단위로 순차 기록하도록 설계해 HDD의 강점을 최대한 활용한다.

3. 멀티 테넌트 스케줄링: 수백만 고객의 요청을 지능적으로 스케줄링하여 디스크 헤드의 불필요한 이동을 최소화한다. 같은 영역의 데이터 요청을 묶어 처리하면 seek time을 대폭 줄일 수 있다.

4. 메타데이터와 핫 데이터 분리: 자주 접근하는 인덱스와 메타데이터는 SSD나 메모리에 캐싱하고, 실제 대용량 객체 본문만 HDD에서 서빙하는 계층 구조를 채택한다.

업계 맥락: 왜 다들 이 방식을 못 따라하는가

구글 Cloud Storage, Azure Blob Storage 등 경쟁 서비스도 유사한 접근을 취하지만, S3의 차별점은 20년간 축적된 운영 노하우와 규모의 경제에 있다. 400조 객체라는 스케일에서는 아주 작은 비율의 장애도 수십억 건의 영향을 미치기 때문에, 내구성(eleven 9s — 99.999999999%)을 보장하는 복제 및 복구 시스템이 핵심 경쟁력이 된다.

최근 QLC SSD와 CXL 메모리 풀링 같은 기술이 부상하면서 스토리지 계층 구조에 변화가 예고되고 있지만, 엑사바이트급 콜드 데이터 저장에서는 여전히 HDD의 경제성을 대체하기 어렵다. Backblaze의 연간 HDD 신뢰성 보고서를 보면, 최신 대용량 HDD(20TB+)의 연간 고장률이 1% 내외로 충분히 관리 가능한 수준이다.

한국 개발자에게 미치는 영향

• 스토리지 클래스 선택의 중요성: S3 Glacier, Intelligent-Tiering 등의 가격 차이가 바로 이 HDD 기반 아키텍처에서 비롯된다. 데이터 접근 패턴을 분석해 적절한 스토리지 클래스를 선택하면 비용을 50% 이상 절감할 수 있다.
• 설계 원칙의 적용: "느린 컴포넌트를 대량 병렬화로 극복한다"는 S3의 철학은 자체 시스템 설계에도 적용 가능하다. 예를 들어, 느린 외부 API 호출을 병렬 배치 처리하거나, 저비용 인스턴스를 대량 투입하는 전략이 이에 해당한다.
• 순차 I/O 친화적 설계: 로그 수집, 데이터 파이프라인 등을 설계할 때 순차 쓰기 패턴을 유지하면 S3 PUT 성능이 크게 향상된다. 작은 파일을 수만 개 올리는 것보다 묶어서 큰 파일로 올리는 것이 훨씬 효율적이다.

마무리

AWS S3의 사례는 "최신·최고 하드웨어가 아니어도 아키텍처로 극복할 수 있다"는 시스템 엔지니어링의 정수를 보여준다. 30년간 120 IOPS에 머문 HDD를 수천만 대 엮어 초당 1PB를 서빙하는 것은, 결국 소프트웨어와 분산 시스템 설계의 승리다.

토론 질문: 여러분이 설계하는 시스템에서 "비싼 하드웨어 업그레이드" 대신 "아키텍처 개선"으로 해결한 경험이 있다면 공유해주세요. 혹은, HDD 기반 S3가 앞으로도 SSD 전환 없이 버틸 수 있을까요?