S3という巨大なストレージシステムの構築と運用
(allthingsdistributed.com)- Amazon S3は2006年3月14日にリリースされたHTTP REST APIベースのオブジェクトストレージとして始まり、数百のマイクロサービスと複数の専任チームが連携して運用する大規模サービスへと成長した
- S3の規模はコードだけでは説明できず、ハードディスク・ファームウェア・データセンター・運用組織・顧客ワークロードが継続的にかみ合いながら変化するシステムである
- HDDは容量とコスト効率が大幅に向上した一方で、ランダムアクセス性能は機械的な限界に縛られており、S3は数百万台のディスクにおけるI/Oヒート管理とデータ配置を中核課題として扱う
- レプリケーションとReed-Solomonベースのイレイジャーコーディングは耐久性を高めるだけでなく、過負荷のディスクを避けてリクエストを迂回させることで、性能とtail latencyの管理にも貢献する
- S3の運用は、durability review、RustベースのShardStore、軽量な形式検証、チーム単位の**オーナーシップ（ownership）**によって、高速な開発と高い耐久性基準を両立するよう設計されている
S3を1つの巨大なサービスシステムとして見る
- S3はオブジェクトストレージサービスであり、HTTP REST API、フロントエンドフリート、ネームスペースサービス、ハードディスクベースのストレージフリート、バックグラウンドジョブフリートで構成される
- 大きな構成要素ごとにS3組織内の別領域やリーダー、複数のチームが存在し、さらに内側の構成要素も独自のフリートとチームを持つ形で運用されている
- 現在のS3は数百のマイクロサービスで構成され、チーム間の相互作用はAPIレベルの契約に近い
- モジュール性の設計を誤るとチーム間のやり取りも非効率で不自然になり、それを修正すること自体がソフトウェアとチームを一体で設計する過程に含まれる
ソフトウェアではなくサービス全体がシステムである
- S3の顧客が購入しているのはパッケージ化されたソフトウェアではなくサービス体験であり、継続的で予測可能な品質を期待している
- S3のシステム境界はコードだけにとどまらない
- ディスクの近くで動作するコード
- データセンターに新しいストレージラックを設置する技術者
- 性能をチューニングする顧客アプリケーション
- ハードウェア、財務、エンジニアリング組織
- S3はソフトウェア、ハードウェア、人が共に成長し変化し続ける生きたシステムに近い
- 単純なホワイトボード上のアーキテクチャ図は、各ボックス内部にある拡張されたサービスとその規模を隠してしまい、実際のシステムを過小評価させる
HDDの物理的限界がS3設計に与える影響
- S3は数百万台のハードディスクを使う非常に大きなシステムであり、HDDの特性は設計上の中心的な制約の1つである
- 1956年のIBM 350 disk storage unit以降、HDDは大きく進化してきた
- 現在言及されている最大のHDDはWestern Digital Ultrastar DC HC670 26TBである
- RAMAC以降、容量は720万倍に向上した
- 物理サイズは5,000分の1になった
- インフレ調整後のバイト単価は60億分の1まで低下した
- しかしseek timeの改善は150倍にとどまり、ランダム読み書き性能は秒間約120操作の水準にとどまっている
- この性能値はS3がリリースされた2006年時点でもほぼ同様で、それより10年前と比べても大差はなかった
- HDDは機械装置であるため、アームの移動とプラッタの回転を待つ必要があり、容量の増加ペースほどランダムアクセス性能は向上しない
- 業界ロードマップは今後10年以内に200TB HDDへ至る道筋を示しており、この規模では全データに均等なランダムアクセスを行うと仮定した場合、ディスクデータ2TBあたり毎秒1 I/Oしか許されない計算になる
- S3はまだ200TBドライブを使っていないが、そのドライブとそこへ至るまでのあらゆる容量のドライブを使うことになると見込まれている
ヒート管理: データ配置と性能
- S3におけるheatとは、ある時点で1台のディスクに入ってくるリクエスト数を意味する
- ヒート管理を誤ると特定のディスクにリクエストが集中してhotspotが生じ、そのディスクに依存するリクエスト全体の性能が悪化する
- hotspotはシステムを即座に停止させるよりも、まずリクエストキューを生み、顧客体験を悪化させる
- 忙しいディスクを待つリクエストが遅延する
- 遅延はメタデータ参照やイレイジャーコーディングなど依存するI/Oを通じてストレージスタック上位層へ増幅される
- 一部リクエストで高遅延、すなわちstragglerが発生する
- 個々のHDDのhotspotはtail latencyにつながり、放置すれば全体のリクエスト遅延にも影響する
- S3ではデータの書き込み時点で将来いつどのようにアクセスされるか分からないため、書き込み時のデータ配置決定は難しい
- 小規模ではI/O heatの予測と管理は非常に難しいが、S3の規模とマルチテナンシーでは別の性質が現れる
- 個別ワークロードは多くの時間でアイドル状態にありつつ突然ピークを見せることが多いが、数百万のワークロードを合算すると全体需要は平坦で予測可能になる
- 一定規模を超えると、単一の個別ワークロードが全体ピークに影響を与えることは難しい、あるいは不可能になる
レプリケーションとイレイジャーコーディングが耐久性と性能を同時に扱う
- ストレージシステムの冗長化方式は、ハードウェア障害からデータを保護するだけでなく、ヒート分散にも役立つ
- レプリケーションは複数のディスクにコピーを置くことでディスク障害に耐え、読み取りリクエストを複数コピーのどこからでも処理できるようにする
- レプリケーションは容量面ではコストが高いが、読み取りI/Oの観点では効率的である
- S3はすべてのデータにレプリケーションのオーバーヘッドを払わないよう、イレイジャーコーディングも使用している
- 例としてはReed-Solomonのようなアルゴリズムを使う
- オブジェクトをk個のidentity shardに分割する
- m個のparity shardを追加生成する
- 合計k+m個のshardのうちk個が利用可能ならオブジェクトを読み出せる
- このアプローチは同数の障害に耐えつつ、容量オーバーヘッドを削減する
データ配置戦略と顧客ワークロードの分離
- 冗長化方式は、必要な読み取り回数より多い断片にデータを分割し、それによって過負荷のディスクを避けてリクエストを送れるようにする
- S3は新しいオブジェクトをディスクフリート全体へ広く配置し、ヒートをさらに下げる
- 個々のオブジェクトは数十台のドライブにまたがって符号化され、異なるオブジェクトは異なるドライブ集合に配置される
- 各バケット内のオブジェクトを多数のディスクへ分散すると、2つの利点がある
- 顧客データが1台のディスク上で占める比率が極めて小さくなり、個別ワークロードが特定ディスクにhotspotを作りにくくなる
- 個別ワークロードが、独立システムとして構築するには難しく高価なレベルのディスク規模までburstできる
- ゲノム解析の顧客が数千のLambda関数で並列解析を実行するburstは、100万台を超える個別ディスクで処理できる
- 現在のS3には、数百万台のドライブにまたがって分散したバケットを持つ顧客が数万人いる
- S3の差別化要因は、ストレージシステム自体の規模だけでなく、顧客とワークロードが集約される規模がシステムの性質そのものを変え得る点にある
durability reviewとガードレール
- Amazonは、エンジニアとチームが速く、かつ安全に失敗できるようにすることを重視している
- S3は高い耐久性を持つストレージを提供しながら素早く動くために、durability reviewのプロセスを用いている
- durability reviewは統計的な11 9sモデルに含まれるメカニズムではないが、S3の運用では重要なものとして扱われている
- エンジニアリング変更が耐久性の状態に影響し得る場合、durability reviewを実施する
- このプロセスはセキュリティ研究のthreat modelの考え方を借りている
- 変更の要約を書く
- 包括的な脅威リストを作る
- 変更がそれらの脅威にどう耐えるかを整理する
- durability reviewには2つの役割がある
- 作成者とレビュアーに、守るべきリスクを批判的に考えさせる
- リスクと対策を分離し、それぞれを別個に議論できるようにする
- 対策を見つける際には、個別の詳細リスクごとに個別緩和策を付けるよりも、広いリスク群を防ぐ単純で強力なguardrailが好まれる
ShardStore、Rust、軽量な形式検証
- S3は数年前、ストレージスタック最下層、すなわち個々のディスク上のデータを管理する部分をゼロから書き直すプロジェクトを開始した
- 新しいストレージ層の名前はShardStoreである
- ShardStoreを再構築する際に採用したガードレールの1つが軽量な形式検証だった
- チームはバグをより早期に見つけるため、実装言語をRustへ移行した
- 型安全性を活用した
- 構造化された言語サポートを活用した
- オンディスク構造にも型安全性を拡張するライブラリを作成した
- 検証面では、ShardStoreロジックの単純化モデルをRustで書き、実際の本番ShardStore実装と同じリポジトリに置いた
- このモデルは、実際のオンディスクストレージ層とHDDの複雑さを取り除いた実行可能な仕様として機能する
- モデルのサイズは実システムの約1%だったが、120 IOPSのハードドライブ相手では非現実的なレベルのテストを可能にした
- この取り組みはSOSP論文 Using lightweight formal methods to validate a key-value storage node in Amazon S3 としても公開されている
- その後、ツールやproperty-based testingのような既存手法を用いて、実装の振る舞いが仕様と一致するかを検証した
- 重要なのは、形式検証の研究手法を一般のエンジニアが保守できるコードと毎コミット適用されるツールへと産業化した点である
- 検証のガードレールはチームに、より速く開発できるという自信を与え、新しいエンジニアが加わった後も維持されている
オーナーシップでチームと個人のスケーリング問題に対処する
- Amazonにおけるownershipとは、特定の仕事やサービスが成功するまで責任を持つ単一の個人またはチームを明確にする概念である
- S3で素早く動きながら高い品質基準を維持するには、チームがオーナーでなければならない
- 他システムとのAPI契約を所有する
- 耐久性、性能、可用性に責任を負う
- 想定外のバグが可用性に影響したら午前3時でも修正する
- バグ修正後には同じことが繰り返されないようシステムを改善する
- ownershipには大きな責任とともに信頼も必要である
- 個人やチームがサービスを所有するには、どう提供するかを自ら決められる余地が必要になる
- 大学院の研究プロジェクト経験でも、学生がそれを自分のアイデアだと感じ、自ら発展させられるときのほうが深くコミットする
- 非常にシニアなエンジニアの役割では、解決策を自ら配布するように提示するよりも、問題を明確に定義し、チームが解法を所有できるよう支援するほうが効果的である
- 複数の解法があり得る問題では、適切な解法を選ばせることが、誰かに解決策のオーナーシップを与える方法になる
S3から得られる結論
- S3の技術的スケールは、小規模システムを単に大きくしただけではなく、ワークロード・構造・運用方法そのものが根本的に異なる
- 「システム」にはソフトウェアだけでなく、サービス運用、運用組織、そのサービスと共に動作する顧客コードまで含まれる
- 組織もシステムの一部であるため、それ自体にスケーリング課題とイノベーションの機会がある
- 個人の役割で成功するには、解決策よりも問題を明確に表現し、強いエンジニアリングチームが解決策を実際に所有できるよう支援する必要がある
2件のコメント
Hacker News のコメント
AWS にいた頃に覚えている会話の一つに、10億分の1の事象でも S3 の規模では毎日起こる、というものがあった
普通ならあまりに確率が低く、心配する価値はないとして流すようなことでも、必ず考慮して対処しなければならない
ShardStore、特に形式検証やプロパティベーステストのようなアプローチを見るとうれしくなる。前世代のサービス群は、有機的成長の危険をよく示すほどバグが多かったが、少なくとも障害が「安全に」起きるよう設計されていてデータ損失は防いでおり、S3 のエンジニアたちはその点にこだわっていた
S3 だけの話でもない。例えば Prime Day 2022 では、DynamoDB が Amazon のワークロードだけで毎秒1億500万件以上に達した: https://aws.amazon.com/blogs/aws/amazon-prime-day-2022-aws-f...
記事で Andy は軽量な形式手法やチームの Rust 採用にも触れているが、極めて低確率の事象でさえ日常的になる規模では、正確性のために何層ものツールとプロセスへ投資する必要がある
目標だった 500k TPS まで上げれば、それは1分あたり30回だと説明し、「その週にオンコールに入りたいのか？」と聞いた。そのスタックでは「最高水準を守る」という言葉が、たいていの組織とはまったく違う意味になる
幸いアルゴリズムは良く、最近のハードウェアもはるかに安定している
初の大規模な暗号学的ハッシュ衝突が起きたときの余波を運良く見物できるなら、ポップコーン片手に眺める準備ができている、少し斜に構えた声も頭の中にある
ゲノミクスの仕事をしていて、この10年でペタバイト級のデータストアを数多く扱ってきた
AWS S3、GCP GCS、そしてコロケーション環境のハードウェア向けストレージシステム（Ceph、Gluster、名前は記憶から消してしまった HP のシステム）を使ってみて、こうしたシステムの運用にかかる努力を大いに尊敬するようになった
多数の他の顧客とディスク I/Oを共有する利点も過小評価しがたい。記事でいう「heat」という用語は初めて聞いたが、単一システムではこれを緩和するのは本当に難しい。私たちのコロケーションクラスターでは、大規模ジョブ間で I/O を適切に管理するために、バッチシステムを修正して I/O を RAM や CPU のように割り当て可能なリソースとして扱う必要があった。S3 と GCP は非常に高価だが、性能がその価格に見合うことがある
こういう記事こそ HN の最良の面だと思う
クラウドストレージの観点で最高の顧客は、データを非常に大量に保存するが、ほとんど読み出さない顧客だ。ハードディスクを借りるのに似ているが、各ディスクの一部だけを「コールド」データで埋めれば、同じディスクの I/O 容量全体をホットな処理に引き続き使える
どのドライブにどのデータを置くかを非常に慎重にバランスさせれば、データの大半が使われていなくても、すべてのドライブを使い続けられる。だから保存は比較的安く、読み出しは比較的高い傾向にある
S3 をサポートしていても、性能は出せるはずの水準よりはるかに遅いことが多い
難しいし、読み取り可用性が99.95%程度しかない点は申し訳ない
S3 が読み書きアクセスの委任のための単純な OAuth2 ベースのプロトコルを明示していたら、作れたものは多かったはず
アプリがユーザーに代わってデータへアクセスできる HTTP ベースのプロトコルが世の中には必要。Google Drive がこれに最も近いが、提供者が1社だけで、ほかにも問題がある[0]。remoteStorage が定着しなかったのは残念。Solid がうまくいくことを願っているが、自分には複雑すぎるように感じる。この問題に対する自分のアプローチは https://gemdrive.io/ だが、今はセルフホスティングスタックの別の部分に集中しているため、ほぼ止まっている
[0]: https://gdrivemusic.com/help
今きちんとやろうとすると非常に難しい。「この特定のバケットだけにアクセスできる AWS 認証情報を発行する」という問題を解くために CLI アプリを丸ごと1つ作ったが、ユーザーにこれをインストールして実行するよう案内したくはない: https://s3-credentials.readthedocs.io/en/stable/
実際には、ユーザーの S3 バケットであるローカルディレクトリをマウントしてくれる、クライアント側の依存関係が最小限のライブラリがあるとよい
競合がいつでも 敵対的相互運用性で攻め込んでこられるから
ユーザーデータ主権を作ろうとしていた、あるいは作っているプロジェクトがすべて妙な暗号資産方面に流れていったのは本当に残念
https://docs.aws.amazon.com/cognito/latest/developerguide/co...
追記: コメントを読み違えていたようだ。アプリがユーザーデータをクライアントに委任しようとしているのだと理解したが、実際にはユーザーが自分のデータをアプリに委任したいということらしい。別々のユースケース
IBM RAMAC の仕様に 保存容量 3.75MB、テラバイトあたり約9,200ドルとあるが、正しいはずがない
コストに保存容量を掛けると、ドライブ価格が3セントになってしまう
このサイト[1]では「平方インチあたり約2,000ビットを保存し、購入価格はメガバイトあたり約10,000ドル」だったとしている
だからおそらく仕様はメガバイトあたり9,200ドルであるべきだろう。そうするとドライブ価格は34,500ドルになり、よりもっともらしい
[1]: https://www.historyofinformation.com/detail.php?entryid=952
3,000万ビットで、パリティを除いて6個のデータビットだけを使った数字だった。ただ、月額3,000ドルでリースされていたため、物理ドライブを一括で買うのと同じような固定費はなかった。その意味では S3 モデルともかなり似ている
ほとんどの人が気づいていないのは、魔法はシステム自体を処理することではなく、認可がコストなしであるかのように見せることにある
分散システムにおける認可は非常に難しい。AWS の規模では、事実上魔法に近い。AWS には豊富な権限モデルがあり、権限変更はおそらく数兆件のリクエストを処理しながらも、インフラ全体にサブミリ秒の速度で伝播する
この部分と、課金用のロギング／精算が、AWS について文章で読んでみたい2つの魔法のような要素
S3 はほかのサービスとは異なる方法でアクセス制御を扱っており、権限がリソースに付いている。速度のためなのだと思う
バケット／キーのアクセス方式が特別である理由の1つは、IAM が登場した時点ですでにそのモデルが定着していたから
その後も維持されたのは、既存モデルを取り除くと多くの顧客設定を壊しかねず、難しい作業だからである可能性が高い
「会社で本当にシニアなエンジニアとして、当然ながら強い意見も技術的なアジェンダもある。だが、エンジニアたちとやり取りするときに、ただアイデアを配ろうとするだけでは、全員が成功するのは難しい。自分が所有していないアイデアに没入するのはずっと難しい。だからチームと働くときは、私の最高のアイデアが、私ではなく他の人たちから出たアイデアになるようにする、という戦略を取ってきた。解決策を売り込むよりも、問題を発展させ、それをとても上手に表現することに、意識的にはるかに多くの時間を使っている。問題の解き方はたいてい複数あり、正しい方法を選ぶということは、誰かにその解決策を所有させるということだ。」
「自分の役割で本当に成功するには、解決策ではなく問題を明確に表現することに集中し、強いエンジニアリングチームがその解決策を本当に所有できるよう支援する方法を見つける必要があるのだと学んだ。」
この部分が本当に良かった。ある程度 Ikea効果を思い起こさせる。誰かに自分のやっていることへ情熱を持ってもらうには、所有感を促す必要があり、良い方法はそれを「その人のアイデア」にすることだ。
結局、人々はそもそも「問題」が何なのかをしばしば違うように見ている。
幸い、すべての問題がそうというわけではない。だが、たとえばPythonの「パッケージング問題」の議論を見ると、実際には6つほどの異なる問題を人々が非常に違う形で説明していて、この現象がかなり悪い形で表れている。
Andy Warfieldが読んでいるなら、おそらく読んでいると思うが、質問がある。問題を発展させるとき、考えられる解決策をスケッチすることにはどれほど価値があるのか？ 問題を明確に表現すれば、いくつかの可能な解決策は自然に浮かぶはずだが、潜在的な所有者の思考を走り出させるために、それらの解決策を共有する価値はあるのか？ それとも問題だけに集中し、解決空間は完全に開いたままにしておくほうがよいのか？
さらに、このような非常にシニアな個人貢献者の運営の仕方について、もっと読むべき資料はあるだろうか？
私には「この平民め！ お前の問題に構っている時間はない。問題だけ持ってこられても、お前の仕事で私が昇進できないではないか」と言っているように聞こえる。
問題を解けるようになるには、まずその問題を理解し、存在を認められなければならない。
事前に認められた権威や専門性がない状況、つまり日常の問題の大半が現れる文脈では、長く、詳しく、慎重に整理した問題説明で双方向の会話チャネルを一人で占有すると、口だけ出して仕事はしない人のように見えたり、他の人たちと一緒に解決策を探したくない人のように見えたりしやすい。
Amazonの社員たちがS3の内部動作を公に話せるようになったのを見るのはうれしい。
Glacierがどう動いているのかも、もっと聞きたい。私の知る限り、基盤となる記憶媒体が何なのかは一度も公開されたことがなく、テープなのか、オフラインHDDなのか、カスタムHDDなのか、さまざまな憶測が出ていた。
ただし、同意しない人たちもいる。依然として未知数だ。
AWSがそれに関するすべてと、その全体の道のりを話してくれたらよいのに。本当に興味深い対象だ。
エンジニアが一人、酔ってぺらぺらしゃべるだけで済む話なのに。はるかに重大な分野では、マサチューセッツ州のある兵士がゲーマー仲間に格好よく見られようとしてDiscordに国家安全保障情報を流し、長い懲役刑を目前にしている。Glacierの詳細はもう出ていると思っていた。
「ハードディスクのヘッドを、747が時速75マイルで芝生の上を飛んでいる姿として想像してみてほしい。飛行機の底と芝の先端の間の空気の隙間は紙2枚分の厚さだ。ディスクのビットを芝の葉で測ると、トラック幅は芝4.6枚分の幅で、ビット長は芝1枚分だ。飛行機が芝の上を飛びながら芝の葉を数えると、地球を2万5千周するごとに芝の葉を1枚だけ見逃す。」
負荷分散の部分を見て、S3 KeyMap 時代と、初期実装からそれへ移行しようとしていた頃を思い出した。
学んだことは、最も熱いオブジェクト／パーティション／バケットを特定した後でも、単に移動して終わりにはできないということだった。すべてを整列させる必要があった。実際の解決策は、整列したうえでホストのパーティション負荷を四分位に分け、第2四分位のパーティションを最も負荷の低いホストへ移すことだった。
最も熱いバケット、つまり第1四分位を移そうとすると、残ったメンバーにさらに負荷がかかり、失敗し続けた。
もう一つの副作用として、エラー率が安定して約1%だった状態から、数日間エラーがない状態へ変わり、その結果、アラート基準をはるかに厳しく更新した。だいたい2009年頃のことだった。
私もUMの学術的バックグラウンドがあったが、博士課程の代わりにS3に参加した。韻も踏んでいる。
S3はストレージ以上のものであり、標準だ。
いくつかの場所でS3互換ストレージを、たいていは少し注意点つきで使えるのが良い。標準がどれほどオープンなのか、「S3 compatible」と言うためにAmazonへお金を払う必要があるのかは知らないが、かなり格好いい。
例として、iDriveのE2、Digital Ocean Object Storage、Cloudflare R2、Vultr Object Storage、Backblaze B2がある。
追記: 調べてみたところ、Azureには本当にないようだ :-/
Hacker Newsのコメント
ゲノミクス分野で働きながら、この10年間で多くのペタバイト級データストアを扱ってきた。
S3がOAuth2ベースのプロトコルを使って読み書きアクセスを委譲できたら、私たちが構築できるものは大きく広がる。
分散システムで認証を扱うのは非常に難しい。
Amazonの社員たちがS3の内部動作について公に話しているのを見るのはよいことだ。
ハードドライブヘッドを747機にたとえて説明する部分。
S3 KeyMap時代にさかのぼると、最もホットなオブジェクト/パーティション/バケットを特定した後でも、単純に移動させるだけでは解決しないことを学んだ。
S3は単なるストレージではなく、標準だ。