▲

AWS S3가 느린 HDD 위에서 초당 1페타바이트를 처리하는 방식

 (bigdata.2minutestreaming.com)
5P by GN⁺ 9시간전 | ★ favorite | 댓글 1개
  • AWS S3는 대규모 멀티테넌트 객체 스토리지 서비스로, 높은 가용성과 내구성을 낮은 비용에 제공
  • 구식이고 느린(≈120 IOPS) HDD를 활용하지만, 초저가·대용량 저장 매체의 경제성을 극대화함
  • S3는 내부 저장계층(ShardStore)을 로그 구조(LSM) 로 설계해 쓰기 경로를 순차 I/O에 맞추고, 읽기 경로는 Erasure 코딩(5-of-9) 과 대규모 병렬화로 성능문제를 상쇄함
  • 클라이언트·프런트엔드·스토리지 전 구간에서 멀티파트 업로드, 바이트 범위 GET, 커넥션 풀, 헤지 요청 등으로 테일 지연을 줄이고 처리량을 합산함
  • 무작위 분산 배치와 Power of Two Random Choices, 지속 리밸런싱, 규모가 커질수록 부하가 평탄화되는 데코릴레이션으로 핫스팟을 피하며, 결과적으로 >1 PB/s 급 처리량을 실현함

AWS S3의 대규모 스토리지 아키텍처

  • 누구나 AWS S3가 무엇인지는 알지만, S3가 얼마나 거대한 규모로 동작하는지와 이를 위해 어떤 혁신이 있었는지 아는 사람은 적음
  • S3는 확장 가능한 멀티테넌트 오브젝트 스토리지 서비스이며, API를 통해 오브젝트를 저장 및 조회할 수 있고, 매우 높은 가용성과 내구성을 상대적으로 저렴한 비용으로 제공함

  • S3의 규모

    • 400조 개 이상의 오브젝트 저장
    • 초당 1억 5천만 건의 요청 처리
    • 피크 시 초당 1PB 이상 트래픽 지원
    • 수천만 개의 하드 디스크 운영
  • 높은 가용성과 내구성(“11 nines” 설계 목표), 상대적으로 낮은 비용을 사용자 경험의 전제로 제시
    • 데이터 애널리틱스·머신러닝 데이터레이크의 기본 저장 레이어로까지 확장됨
  • 설계 목표는 비용 효율을 유지하면서 무작위 접근 패턴과 대규모 동시성을 감당하는 것
    • S3는 테넌트마다 임의의 크기/오프셋으로 접근하는 집합적 랜덤 액세스 워크로드를 전제로 함

기반 기술: 하드 드라이브(HDD)

  • S3의 놀라운 확장성과 퍼포먼스는 전통적인 저장 매체인 HDD가 기반임
  • HDD는 오래된 기술로 내구성은 높지만 물리적 이동에 의해 IOPS(초당 입출력)과 지연에서 한계가 존재함
    • 초당 회전(예: 7200 RPM) 과 액추에이터 시킹이라는 기계적 운동이 필수이므로 지연 시간이 구조적으로 크고 불가피함
    • 평균 반플래터 시킹 ≈4 ms, 평균 반회전 ≈4 ms, 0.5 MB 전송 ≈2.5 ms → 랜덤 0.5 MB 읽기 평균 ≈11 ms, 단일 디스크 랜덤 처리량 ≈45 MB/s 수준
  • SSD와는 달리,용량↑·가격↓ 의 장기 곡선으로 “초저가/대용량” 경제성을 확보하여 여전히 대규모 스토리지에 활용되고 있음
    • 가격: 바이트당 60억 배 하락 (물가 반영 기준)
    • 용량: 720만 배 증가
    • 크기: 5천 배 감소
    • 무게: 1,235배 감소
  • 그러나 30년째 IOPS는 약 120 수준에 정체되어 있으며, 랜덤 접근 성능과 지연은 크게 개선되지 않음
  • SSD는 랜덤 I/O에 유리하지만 페타·엑사 스케일 저장에선 총소유비용(TCO) 측면에서 불리함

순차 I/O에 최적화된 쓰기 경로

  • HDD는 순차 접근에 최적화되어 있으며, 연속된 바이트를 읽고 쓰면 디스크 플래터가 자연스럽게 돌아가면서 빠르게 데이터 처리 가능
  • 로그 기반 데이터 구조(log-structured)는 이런 순차 특성을 활용함
    • S3 내부 저장계층인 ShardStore는 로그 구조 LSM을 채택하여 쓰기를 디스크 순차 append로 처리하는 전략임
    • 유사하게 배치 처리로 디스크 순차 처리량을 극대화할 수 있음

랜덤 읽기 경로를 위한 병렬화와 Erasure Coding

  • 읽기는 사용자 요청에 따라 임의(랜덤) 위치 점프가 발생하므로 물리적인 한계를 그대로 맞닥뜨림(랜덤 I/O의 평균 지연은 약 11ms)
    • HDD 한 개에서 랜덤 I/O로 최대 초당 45MB 처리 가능
    • 그래서 대량의 데이터 저장에는 HDD가 가성비가 뛰어나지만, 무작위 액세스 성능이 떨어짐
  • S3는 이 물리적 한계를 극복하기 위해 데이터를 다수 디스크에 샤딩하고 동시에 읽어 합산 처리량을 끌어올리는 대규모 병렬화를 채택함
    • 데이터를 수많은 HDD에 분산 저장, 각 디스크의 입력/출력을 병렬로 사용해 전체 처리량을 크게 높임
    • 예를 들어 1TB 파일을 2만 개의 HDD에 분할 저장하면, 전체 디스크의 처리량을 합산하여 TB/s급 읽기 가능

에러수정코딩(Erasure Coding)

  • 스토리지 시스템에서는 중복성 보장이 필수임
  • S3는 Erasure Coding(EC) 을 사용하여 데이터를 K개의 조각과 M개의 패리티 조각으로 분할
    • 총 K+M개 중 임의의 K개만 있으면 복원 가능
  • S3는 9분할(5개 데이터 샤드, 4개 패리티 샤드) 구조를 활용한 Erasure Coding(5-of-9) 으로 균형점을 확보
    • 5개 데이터 + 4개 패리티 = 9조각
    • 최대 4개 샤드 손실까지 복원 가능하여, 아무 5조각만 있으면 원본 복구 가능한 내결함성 제공
    • 저장 오버헤드는 ≈1.8배로, 3중 복제(3x) 대비 용량 효율적
    • 동시에 5개의 병렬 읽기 경로를 확보해 샤드 병렬화와 스트래글러 회피에 유리함
  • S3는 이 물리적 한계를 극복하며, 대규모 데이터에 대한 무작위 액세스를 제공함

병렬 처리 구조

  • S3는 3가지 주요 병렬화 방식을 사용
    • 1. 사용자는 데이터를 여러 청크로 나누어 업로드 및 다운로드
    • 2. 클라이언트는 여러 프론트엔드 서버에 동시 요청
    • 3. 서버는 여러 스토리지 서버에 오브젝트를 분산 저장

  • 1. 프론트엔드 서버 단위 병렬 처리

    • 내부 HTTP 커넥션 풀을 활용해 분산된 여러 엔드포인트에 동시에 연결
    • 특정 인프라 노드나 캐시에서 과부하 방지

  • 2. 하드 드라이브 간 병렬 처리

    • EC 기반으로 데이터를 여러 HDD에 소규모 샤드로 분산 저장

  • 3. PUT/GET 요청 병렬 처리

    • 클라이언트가 데이터를 여러 부분으로 쪼개서 병렬 업로드
    • PUT: 멀티파트 업로드로 신규 병렬 처리 극대화
    • GET: 바이트 레인지 GET 지원(객체 내 일부 범위만 읽기 가능)
  • 병렬로 분산 처리하면 초당 1GB 업로드 등도 어려움 없이 달성 가능

핫스팟(Hot Spot) 방지

  • S3는 수천만 대의 드라이브와 초당 수억 요청, 수억 샤드의 병렬 운영 환경
  • 특정 디스크나 노드에 부하가 몰릴 경우 시스템 전체 성능 저하 위험 발생
  • 이를 막기 위한 핵심 전략:
    • 1. 데이터 저장 위치 무작위 분산
    • 2. 지속적 리밸런싱
    • 3. 시스템 규모 확장

  • 1. 셔플 샤딩 & Power of Two

    • 최초 데이터 저장 위치를 무작위로 분산함
    • ‘Power of Two Random Choices’ 알고리듬 적용:
      • 무작위 2개의 노드 중 부하가 적은 쪽 선택 시 효과적 로드 밸런싱 가능

  • 2. 리밸런싱

    • 데이터 온도: 신규 데이터가 더 뜨거움(자주 접근됨) 이라는 특성을 이용해 주기적 리밸런싱으로 공간과 I/O를 재분배
      • 데이터가 오래될수록 접근 빈도 감소, 스토리지 전체의 I/O 여력 증가
    • S3는 콜드 데이터를 재분산하여 공간과 자원 활용 극대화
    • 신규 랙 도입 시(예: 20 PB/랙, 1000×20 TB) 빈 용량에 능동적 분산이 필요

  • 3. Chill@Scale

    • 규모의 효과: 워크로드가 독립적일수록 버스트 동시성이 줄어 집계 부하가 평탄화되는 데코릴레이션이 발생함
    • 시스템이 클수록 피크/평균 격차 축소, 예측 가능성 향상이라는 이점을 얻음
    • 즉, 사용량이 급증-휴면을 반복하더라도 대규모에서는 서로 상쇄되어 예측 가능한 부하 유지 가능

운영·신뢰성 문화와 기타 기법

  • DNS 레벨 shuffle sharding으로 네임 리졸버 차원에서 테넌트 간 격리와 균등 분산 추구
  • 소프트웨어 롤아웃도 EC처럼 점진적·무중단 방식으로 수행, ShardStore 전환도 서비스 영향 없이 진행
  • 내구성 문화: 지속적 결함 탐지, chain of custody, 내구성 위협 모델링, 형식 검증 등 프로세스 기반 신뢰성 확보

왜 중요한가: S3를 기반으로 한 데이터 인프라 트렌드

  • Stateless 아키텍처 확산으로 애플리케이션 노드는 상태를 비우고 영속성·복제·부하분산을 S3에 위임하는 패턴이 확대됨
    • 예: Kafka Diskless(KIP-1150), SlateDB, Turbopuffer, Lucene on S3, ClickHouse/OpenSearch/Elastic의 오브젝트 스토리지 통합 등
  • 장점은 탄력적 스케일링·운영 단순화·비용 절감이며, 단점은 지연 증가 가능성으로 워크로드별 레이턴시·비용·내구성의 3요소 트레이드오프를 설계해야 함

요약

  • AWS S3는 대규모 멀티테넌트 스토리지 서비스로, 느린 저장 매체의 한계를 대규모 병렬성, 로드 밸런싱, 데이터 샤딩 기술로 극복
  • 에러수정코딩, 무작위 분산, 지속적 리밸런싱, 헤지 요청 등으로 안정성과 성능을 확보
  • 초기에는 백업·미디어 중심이었으나, 데이터 분석 및 머신러닝 등 빅데이터 인프라의 메인 스토리지로 발전함
  • S3 기반 아키텍처는 스테이트리스 확장성을 확보하며, 내구성·복제·로드 밸런싱 문제를 효과적으로 AWS 측에 위임 가능
  • 이는 클라우드 비용 절감 및 관리 효율까지 제공함
▲
GN⁺ 9시간전  [-]
Hacker News 의견

  • 몇 가지 사실 오류가 있지만 기사 흐름에 큰 영향을 주지는 않음. 예시로 S3가 5:9 샤딩 방식을 쓴다는 주장인데 실제로 S3는 다양한 샤딩 스킴을 사용하고, 내가 알기로는 5:9는 그중 하나가 아님. 1 논리 바이트당 1.8 물리 바이트라는 비율은 HDD 비용 관점에서 정말 안 좋은 수치임. 실제로 그 비율을 더 낮추는 방법도 있고, 병렬성이 넓어지며 가용성이 더 좋아짐. 예를 들어 AZ 전체가 다운되었을 때 객체가 GET 불가 상태가 되기까지 몇 개 샤드를 잃을 수 있는지 생각할 필요 있음

    • 이 유튜브 영상 42:20 지점에서 S3가 해당 샤딩 스킴을 사용한다고 이해했음. 혹시 더 알고 있다면 궁금함

    • 1.8배 비율을 낮추면서 동시에 가용성을 올린다는 게 직관적으로 어려워 보임. 복제본이 적으면 AZ 장애 시 데이터 손실 위험이 커지지 않겠음? AWS는 3개 AZ에 완전히 독립된 복제본을 제공한다고 알고 있었음. 그리고 16MB 청크 하나를 읽으려면 실제로 5개의 다른 하드 드라이브에서 4MB씩 읽어야 더 빠르다는 설명이 아직도 신기함

    • VAST data는 146+4 스킴을 사용함. (링크)

  • 이 글을 즐겁게 읽었는데, 제목 질문의 정답은 너무 분명함: 병렬성임

    • 평소에는 스토리지 I/O 속도를 그렇게 대규모로 생각해본 적이 거의 없음. 예전에 하드디스크를 더 빠르게 쓰려고 RAID0를 썼지만 오래전 이야기임. 처음엔 캐싱이나 계층화 같은 흥미로운 방식을 쓸 줄 알았음. 읽고 나서야 병렬성이 당연한 해답이구나 느꼈지만, S3의 세부 구현이나 오류 수정 방식까지는 생각 못했음. 병렬성이라는 단어가 핵심이지만, 자세한 내용에 큰 인사이트가 있었음. minio도 비슷한 확장성 이야기를 가지고 있을 거라고 봄: 역시 병렬성임

    • 기사 제목이 S3 전체의 피크 처리량에만 초점을 둬서 약간 헷갈린다고 생각함. 진짜 흥미로운 질문은 "어떻게 HDD의 최대 처리량을 넘는 GET 처리량이 가능한가"라고 생각함. 단순 복제라면 여러 HDD를 지정해 GET을 병렬로 하면 S3 전체 입장에선 처리량이 높아지지만, 결국 개별 HDD 처리량 * GET 요청 수에 묶이게 됨. 그런데 S3는 이런 한계가 없다는 점이 비밀이고 흥미로운 지점임

    • 수백만 개 하드디스크를 합치면 엄청난 IO 대역폭이 생김

    • "달에 가는 방법은 분명하다: 여행이다" 같은 논리로 들림

  • full-platter seek time: ~8ms; half-platter seek time (avg): ~4ms
    평균적으로 [0,1] 구간에 두 점이 균일 분포하면 그 거리의 기대값은 0.5가 아니라 1/3임. 만약 풀 플래터 seek 시간이 8ms면, 평균 seek 시간은 2.666ms임

    • 최신 드라이브에서 풀 시크는 8ms보다 25ms에 더 가까움. 직접 테스트하려면 하드디스크와 루트권한이 있다면 fio에서 --readonly 옵션 주고 디스크 양 끝에서 번갈아 읽기를 넣으면 됨. 최신 드라이브에서 왜 1/3 숫자가 정확하지 않은지 설명하는 좋은 논문(여기)도 있음. 디스크 드라이브 메카닉이나 성능에 더 궁금한 점 있으면 답변 가능함

    • 트랙 사이를 움직일 때 헤드 가속이 발생함. 각 거리가 짧을수록 최고 속도가 낮고 일정한 지연(정착 시간 등)도 있어서 실제로 평균 4ms가 될 수 있음

    • 플래터가 원형이기 때문에 균일 분포 [0, 1]이 아니라 [0, 2파이]인 단위원 분포를 써야 하고, 플래터가 한쪽 방향으로만 도니 거리는 항상 시계 방향으로만 계산해야 함.
      문제를 단순화해서 시작점 0도, 목표점이 임의의 지점에 있으면 평균 거리는? 0-180도와 180-360도가 아크 길이 같으니 평균 거리는 180도가 됨. 즉, half-platter seek는 full-platter seek의 정확히 절반임

  • S3가 HDD를 여전히 기본 서비스로 쓰는지 가격을 보고 IOPS 기준으로 환산하면 가늠할 수 있음. S3의 GET/PUT 요청 단가가 충분히 비싸서 AWS는 고성능 테넌트를 위해 디스크 공간을 놀리면서 쓸 여력이 있긴 함. 하지만 아주 조금 더 비싼 수준 그 이상은 아님

  • S3의 일부가 SSD로 운영되는지 궁금함. 표준 S3도 SSD 기반일 거라 생각했고 느린 티어만 HDD나 느린 시스템을 쓸 줄로 알았음

    • S3의 KeyMap Index가 SSD를 사용함. 현재 시점에서 SSD가 뜨거운 객체 캐시나 새로운 one zone 상품의 일부분에 이미 들어가 있을 것 같음

    • 실제 저장 데이터는 거의 HDD에 있을 확률이 높음. 하지만 메타데이터, 인덱스 등은 훨씬 더 빠른 플래시 스토리지를 쓸 거라 생각함. 작은 규모 Ceph 클러스터의 MDS 서버들도 보통 그렇고, S3는 훨씬 규모가 큼

    • 위에서 한 번 언급했던 내용이지만, 표준 티어 기준 요청 단가가 높아 IOPS/TB 비율이 높은 고객이 있어도 디스크 일부 용량을 놀리는 수준까진 비용 효율이 맞음. 하지만 그것보다 비싸지면 이득이 아님. 최신 HDD는 약 30TB를 저장하며, AWS가 실제 얼마에 사는지 몰라도 대략 300~500달러 선으로 추정함. 30TB SSD와 비교하면 훨씬 쌈. 또한 이러한 HDD를 고밀도 시스템(예: 4U에 100개 드라이브)으로 장착할 수도 있는데, 전체 원가의 25% 정도만 추가하면 됨. 반면 대량 SSD를 지원하는 하드웨어 박스는 슬롯당 비용이 훨씬 비쌈

    • S3 Express One Zone 정도는 SSD 기반일 걸로 추정함. 다만 Amazon이 이를 공개적으로 밝히진 않은 듯함

    • 메타데이터는 확실히 SSD에 저장할 걸로 예상함. 자주 읽히는 핫 객체는 SSD에 캐싱할 가능성도 있음

  • HDD 가격이 계속 떨어져도 S3 요금이 최소 8년간 같았다는 점이 신기함. 가격 인하 경쟁이 부족해 계속 높은 요금 체계를 유지하고 있음. 이것이 AWS에 얼마나 큰 수익을 가져다주는지 상상해볼 만함

    • AWS 가격 정책은 모든 서비스에서 비슷함. 예를 들어 EC2의 m7a.medium 인스턴스는 온디맨드 기준 월 50달러, 1년 리저브 시 35달러임. 비슷한 스펙의 타 회사 서비스와 비교해도 경쟁력이 크게 떨어짐

    • 인플레이션 영향도 있으므로, 명목 요금이 동일해도 실질적으로 가격이 하락한 셈임. 그러나 인플레이션이 기술 진보 속도보다 훨씬 느리게 반영된다는 점 동의함

    • 비용 절감이 인센티브의 목표가 아니라는 생각임. Splunk나 CrowdStrike처럼 AWS에 거대한 데이터를 저장하는 업체를 보면 반복적인 데이터가 매우 많고, 이를 그대로 고객에게 요금 청구하고 데이터 중복 제거만 간단하게 적용함. 비용을 줄이면 오히려 쓸데없는 사용량이 더 늘어날 인센티브가 만들어짐

    • HDD 가격 하락 폭이 실제로 큰지 궁금함. 최근 수년 간 하드디스크의 GB당 가격 하락 속도는 많이 느려져서 앞으로는 SSD가 곧 따라잡을 전망임

  • S3에 대해 더 흥미로운 글로 "Building and operating a pretty big storage system called S3"을 추천함

  • rustfs는 실제 성능이 어떤지 궁금함

  • 수천만 개 HDD가 사용된다는 언급을 보며, 엔터프라이즈 HDD가 10~20TB급 용량이라면 AWS S3 전체 용량은 수백 Exabyte급이라고 추정할 수 있음. 아마 지구상에서 가장 큰 스토리지 시스템일 가능성이 높음

    • 2013년 이래 하드웨어가 업그레이드 됐다면 유타의 특정 데이터센터가 그 용량을 넘길 수 있음 (관련기사)

    • 현재 엔터프라이즈 HDD는 30TB, 곧 50TB까지도 가능해질 전망임

  • HDD에 최적화되어 비슷한 성능을 내는 오픈소스 서비스를 알고 싶음. 주요 프로젝트(MinIO, Swift, Ceph+RadosGW, SeaweedFS)는 모두 플래시 전용 배포를 권장함. 최근 Garage라는 프로젝트를 살펴보고 있는데 EC를 쓰지 않는 등 설계가 꽤 다름

    • Ceph+RadosGW도 HDD와 충분히 잘 동작함. 단, 인덱스 풀은 SSD를 써야 하고, HDD 풀에서 기대할 수 있는 IOPS 숫자에 대한 현실적인 판단이 필요함. 클라이언트 쪽에서의 IOPS가 실제로는 여러 배수로 곱해지기 때문에, S3도 이 문제를 수많은 HDD로 해결함. 4MB 스트리밍 대용량 스토리지에는 큰 문제가 아니지만, 작은 키를 많이 랜덤하게 읽고 쓰거나 한 키로 분산 접근이 많으면 백엔드 성능이 중요함

    • Lustre/ZFS도 유사한 속도를 구현할 수 있음. 하지만 고IOPS가 필요하다면 Lustre의 경우 MDS에 플래시, ZFS는 전용 로그 SSD가 필요함

    • 이들 서비스 모두 대형 데이터센터급 드라이브가 많아야 동일 성능이 나옴. 극소수 구축건만 이런 스케일을 처리할 수 있음. 이 때문에 플래시는 공간/비용 측면에서 빠른 접근에 더 효율적임

    • SeaweedFS는 최근 몇 년간 많이 발전해서 RDMA 지원 및 EC도 도입함

    • 예전 직장에서 SwiftStack을 기반으로 오브젝트 스토리지를 운영했고, 메타데이터는 SSD에, 객체 데이터는 일반 HDD에 저장했음. 충분히 잘 동작했음

답변달기