AWS S3が低速なHDD上で毎秒1ペタバイトを処理する仕組み

 (bigdata.2minutestreaming.com)
19 ポイント 投稿者 GN⁺ 2025-09-27 | 2件のコメント | WhatsAppで共有
  • AWS S3は大規模マルチテナントのオブジェクトストレージサービスで、高い可用性と耐久性を低コストで提供
  • 旧式で低速な（≈120 IOPS）HDDを活用しつつ、超低コスト・大容量の保存媒体としての経済性を最大化
  • S3は内部ストレージ層（ShardStore）をログ構造（LSM）で設計し、書き込み経路をシーケンシャルI/Oに最適化、読み取り経路はErasure Coding（5-of-9）と大規模並列化で性能問題を相殺
  • クライアント・フロントエンド・ストレージの全区間で、マルチパートアップロード、バイトレンジGET、コネクションプール、ヘッジリクエストなどによりテールレイテンシを削減し、スループットを合算
  • ランダム分散配置とPower of Two Random Choices、継続的リバランシング、規模が大きいほど負荷が平準化されるデコリレーションによってホットスポットを回避し、結果として**>1 PB/s**級のスループットを実現

AWS S3の大規模ストレージアーキテクチャ

  • AWS S3が何かは誰もが知っているが、S3がどれほど巨大な規模で動作しているのか、またそのためにどのような革新があったのかを知る人は少ない
  • S3はスケーラブルなマルチテナント型オブジェクトストレージサービスであり、APIを通じてオブジェクトの保存と取得ができ、非常に高い可用性と耐久性を比較的低いコストで提供する

  • S3の規模

    • 400兆個を超えるオブジェクトを保存
    • 毎秒1億5,000万件のリクエストを処理
    • ピーク時には毎秒1PB超のトラフィックをサポート
    • 数千万台のハードディスクを運用
  • 高い可用性と耐久性（「11 nines」を設計目標）、そして比較的低いコストをユーザー体験の前提として提示
    • データアナリティクスや機械学習のデータレイクにおける基本ストレージレイヤーにまで拡大
  • 設計目標は、コスト効率を維持しながらランダムアクセスパターンと大規模な同時実行性に対応すること
    • S3は、テナントごとに任意のサイズ・オフセットでアクセスする集合的なランダムアクセスワークロードを前提としている

基盤技術: ハードディスクドライブ（HDD）

  • S3の驚異的な拡張性とパフォーマンスは、従来型の保存媒体であるHDDを基盤としている
  • HDDは古い技術で、耐久性は高いが物理的な移動によりIOPS（1秒あたりの入出力回数）やレイテンシに限界がある
    • 毎分回転数（例: 7200 RPM）とアクチュエータのシークという機械的運動が不可欠であるため、遅延時間は構造的に大きく、避けられない
    • 平均ハーフプラッターシーク ≈4 ms、平均ハーフローテーション**≈4 ms**、0.5 MB転送**≈2.5 ms** → ランダム0.5 MB読み取りの平均**≈11 ms**、単一ディスクのランダムスループットは**≈45 MB/s**程度
  • SSDとは異なり、**容量↑・価格↓という長期曲線によって「超低コスト/大容量」**の経済性を確保し、依然として大規模ストレージで活用されている
    • 価格: バイト単価が60億分の1まで低下（物価補正ベース）
    • 容量: 720万倍に増加
    • サイズ: 5,000分の1に縮小
    • 重量: 1,235分の1に減少
  • しかしこの30年間、IOPSは約120前後で停滞しており、ランダムアクセス性能とレイテンシは大きく改善していない
  • SSDはランダムI/Oに有利だが、ペタ・エクサスケールの保存では総所有コスト（TCO）の面で不利

シーケンシャルI/Oに最適化された書き込み経路

  • HDDはシーケンシャルアクセスに最適化されており、連続したバイトを読み書きすればディスクプラッターが自然に回転しながら高速にデータ処理できる
  • ログベースのデータ構造（log-structured）は、このシーケンシャル特性を活用する
    • S3の内部ストレージ層であるShardStoreはログ構造LSMを採用し、書き込みをディスクへのシーケンシャルappendとして処理する戦略を取っている
    • 同様にバッチ処理によってディスクのシーケンシャルスループットを最大化できる

ランダム読み取り経路のための並列化とErasure Coding

  • 読み取りでは、ユーザー要求に応じて任意（ランダム）位置へのジャンプが発生するため、物理的な限界にそのまま直面する（ランダムI/Oの平均レイテンシは約11ms）
    • HDD 1台でランダム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のアップロードなども難なく達成できる

ホットスポットの防止

  • 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は大規模マルチテナントストレージサービスであり、低速な保存媒体の限界を大規模並列性、ロードバランシング、データシャーディング技術で克服
  • Erasure Coding、ランダム分散、継続的リバランシング、ヘッジリクエストなどにより安定性と性能を確保
  • 当初はバックアップ・メディア中心だったが、データ分析や機械学習などビッグデータインフラのメインストレージへと発展
  • S3ベースのアーキテクチャはステートレスな拡張性を確保し、耐久性・複製・ロードバランシングの問題を効果的にAWS側へ委譲できる
  • これはクラウドコスト削減と管理効率の向上にもつながる

関連記事

2件のコメント

 
shakespeares 2025-10-05

技術が優れていなければ、利益は出なさそうですね。
 
GN⁺ 2025-09-27
Hacker Newsの意見

  • いくつか事実関係の誤りはあるが、記事全体の流れに大きな影響はない。たとえば、S3が5:9のシャーディング方式を使っているという主張だが、実際のS3はさまざまなシャーディングスキームを使っており、私の知る限り5:9はその一つではない。論理1バイトあたり物理1.8バイトという比率は、HDDコストの観点ではかなり悪い数値だ。実際にはその比率をもっと下げる方法もあり、並列性はさらに広がり、可用性も高くなる。たとえば、AZ全体がダウンしたときに、オブジェクトがGET不能になるまで何個のシャードを失えるかを考える必要がある

    • このYouTube動画の42:20あたりで、S3がそのシャーディングスキームを使っていると理解した。もしもっと詳しければ教えてほしい

    • 1.8倍の比率を下げながら同時に可用性を上げる、というのが直感的には少し理解しづらい。レプリカが少なければ、AZ障害時のデータ損失リスクは大きくならないだろうか？ AWSは3つのAZに完全に独立したレプリカを提供していると思っていた。それに、16MBのチャンクを1つ読むのに、実際には5台の異なるハードドライブから4MBずつ読んだほうが速い、という説明もまだ不思議に感じる

    • VAST dataは146+4スキームを使っている。(リンク)

  • この記事は楽しく読めたが、タイトルの問いに対する答えはあまりに明白だ。つまり、並列性だ

    • 普段、ストレージI/O速度をそこまで大規模に考えることはほとんどない。昔、ハードディスクをもっと速く使いたくてRAID0を使っていたことはあるが、ずいぶん前の話だ。最初はキャッシュや階層化のような面白い仕組みを使っているのかと思っていた。読み終えてから、並列性こそが当然の答えなのだと感じたが、S3の細かな実装やエラー訂正のやり方までは考えていなかった。キーワードは並列性だが、詳細には大きな示唆があった。minioも似たようなスケーラビリティの話をしているはずだ。やはり答えは並列性だ

    • 記事のタイトルがS3全体のピークスループットだけに焦点を当てているので、やや紛らわしいと思う。本当に面白い問いは「どうやってHDDの最大スループットを超えるGETスループットが可能なのか」だと思う。単純なレプリケーションなら、複数のHDDを割り当ててGETを並列化すれば、S3全体としてのスループットは上がるが、結局は個々のHDDのスループット × GETリクエスト数に縛られる。ところがS3にはこの制約がない。その点が秘密であり、面白いところだ

    • 数百万台のハードディスクを束ねれば、とてつもないI/O帯域になる

    • 「月に行く方法は明らかだ。旅をすることだ」と言っているような論理に聞こえる

  • full-platter seek time: ~8ms; half-platter seek time (avg): ~4ms
    平均的に[0,1]区間上の2点が一様分布するとき、その距離の期待値は0.5ではなく1/3だ。もしフルプラッターseek時間が8msなら、平均seek時間は2.666msになる

    • 最近のドライブでは、フルシークは8msより25msに近い。自分で試すなら、ハードディスクとroot権限がある環境で、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全体の容量は数百エクサバイト級と推定できる。おそらく地球上で最大のストレージシステムだろう

    • 2013年以降にハードウェアがアップグレードされているなら、ユタ州のあるデータセンターがその容量を上回っている可能性はある (関連記事)

    • 現在のエンタープライズHDDは30TB級で、近いうちに50TB級も可能になる見込みだ

  • HDD向けに最適化され、同様の性能を出せるオープンソースサービスを知りたい。主要プロジェクト（MinIO、Swift、Ceph+RadosGW、SeaweedFS）はどれもフラッシュ専用デプロイを推奨している。最近Garageというプロジェクトを見ているが、ECを使わないなど設計がかなり異なる

    • Ceph+RadosGWもHDDで十分うまく動く。ただし、インデックスプールにはSSDを使うべきで、HDDプールで期待できるIOPSについて現実的な見積もりが必要だ。クライアント側のIOPSは実際には何倍にも増幅されるので、S3もこの問題を大量のHDDで解決している。4MBストリーミングの大容量ストレージなら大きな問題ではないが、小さなキーを大量にランダム読み書きしたり、1つのキーに分散アクセスが集中したりする場合は、バックエンド性能が重要になる

    • Lustre/ZFSでも似たような速度は実現できる。ただし、高IOPSが必要なら、LustreではMDSにフラッシュ、ZFSでは専用のログ用SSDが必要になる

    • これらのサービスはいずれも、大規模データセンター級のドライブ台数があって初めて同等の性能が出る。これほどのスケールを扱える導入はごくわずかだ。そのため、フラッシュのほうがスペース/コスト面で高速アクセスにより効率的だ

    • SeaweedFSはここ数年で大きく進化しており、RDMAサポートやECも導入している

    • 前職ではSwiftStackベースのオブジェクトストレージを運用していて、メタデータはSSDに、オブジェクトデータは通常のHDDに保存していた。十分うまく動いていた