継続的なイノベーション: AWSブロックストレージの簡略史

 (allthingsdistributed.com)
2 ポイント 投稿者 GN⁺ 2024-08-23 | 1件のコメント | WhatsAppで共有
  • AWS EBSはEC2向けのネットワーク接続ブロックストレージとして出発し、共有HDDベースのサービスから、1日あたり140兆回超の処理をこなす分散SSDフリートへと成長した
  • 初期の性能限界は、HDDの120〜150 IOPSと平均6〜8msのレイテンシだけでなく、複数の顧客ワークロードが同じディスクを共有することで生じるnoisy neighbor問題にも起因していた
  • SSD導入により、2012年のProvisioned IOPSボリュームは最大1,000 IOPS、平均約2〜3msのレイテンシを提供したが、ボトルネックはネットワーク、ハイパーバイザー、ソフトウェアキューへと移った
  • EBSチームはすべてのIOパスを計測し、Xenキュー、Nitroオフロード、暗号化のハードウェア処理、TCPチューニング、SRD転送プロトコルに至るまで階層ごとに改善した
  • 性能向上は大規模な書き直しではなく、無停止マイグレーション、小規模チームによる独立した変更、継続的な測定とロールバック可能な段階的改善によって進められた

EC2向けブロックストレージから大規模SSDフリートへ

  • EBSは2008年8月20日、EC2ベータ公開から約2年後、EC2インスタンス向けにネットワーク接続ブロックストレージを提供しようというアイデアから始まった
  • 当時のチームには1〜2人のストレージ専門家と数人の分散システムエンジニアがおり、コンピュータシステムとネットワークの知識をもとにサービスを作り始めた
  • その後EBSは、共有HDD製品から、単一のEC2インスタンスに数十万IOPSを提供できるサービスへと変化した
    • 現在、単一インスタンスに提供可能なIOPSは、初期のHDDベース時代にAvailability Zone全体へ提供していた水準を上回る
    • EBS全体では、分散SSDフリートで1日あたり140兆回超の処理を実行している
  • 主なワークロードはEC2インスタンスのシステムディスクであり、物理サーバー内のハードディスクの役割をネットワークストレージとして提供する形に近い
  • 顧客は耐久性を重視する一方で、EC2体験と直結する性能と可用性も同じくらい重要だと考えている
    • io2 Block Expressボリュームとボリュームスナップショットは、高い耐久性を実現するための基本要素として提供される
    • EBSボリュームの性能と可用性は、EC2ベースのアプリケーション体験にほぼそのまま反映される

キューイングとHDDが生んだ初期の限界

  • コンピュータシステムでは、ストレージ要求はCPU、バス、デバイスの間にある複数のキューを経て処理される
  • ネットワークストレージでは、OSカーネル、ストレージアダプタ、ストレージファブリック、対象ストレージアダプタ、記憶媒体の間に複数のキューが生じる
  • 2008年にEBSが最初に作られたとき、ストレージ市場の中心はHDDであり、レイテンシは記憶媒体そのものに支配されていた
    • ハードディスクは機械装置であり、物理的な限界がある
    • 数十年にわたり、HDD性能は概ね毎秒120〜150処理、平均IOレイテンシ6〜8ms前後にとどまっていた
    • キューイングとドライブ内部のコマンド再順序化により、テールレイテンシは数百msにまで伸びることがある
  • 当時のEBSのエンドツーエンドレイテンシは数十ms単位だったため、ネットワークで追加される数十マイクロ秒は全体レイテンシの中では小さな割合だった
  • HDD性能は、キューに積まれた他の処理の影響を大きく受ける
    • 媒体上に散在する小さなランダム要求は、互いに近い大きな要求が複数ある場合より探索とアクセスに時間がかかる
    • 顧客を複数のディスクへ分散すると、最もホットなワークロードのピーク超過レイテンシは減ったが、不規則な挙動がより多くの顧客に広がった
  • あるワークロードが別のワークロードに影響を与えるnoisy neighborが、重要なビジネス問題となった
    • AWSは顧客体験の品質を高めるには、強い性能分離が必要だと考えた
    • ディスクスケジューリングアルゴリズムの変更や、より多くのスピンドルへのワークロード分散は、小さな段階的改善にとどまった

SSD導入後に明らかになった計測の重要性

  • 2011年ごろになるとSSDがより一般化し、AWSが検討できる容量でも提供され始めた
  • SSDはデータ探索のための物理アーム移動がなく、ランダム要求もシーケンシャル要求とほぼ同じ速さで処理でき、コントローラとNANDチップの間に複数のチャネルを持つ
  • EBSはまず、SSDベースの新しいストレージサーバータイプと、Provisioned IOPSという新しいボリュームタイプを作った
    • 新しいボリュームタイプの投入は決して小さな作業ではなく、それを活用できるワークロードも限られていた
    • HDDをSSDに置き換えれば、ほぼすべての問題が解決するという期待に反して、noisy neighbor問題が自動的に消えることはなかった
  • 2012年8月にリリースされたProvisioned IOPSは、最大1,000 IOPSを提供した
    • 従来のEBS standardボリュームより10倍高い
    • 平均レイテンシは約2〜3msで、5〜10倍改善した
    • 外れ値の制御も大きく向上した
  • この時点のEBSには基本的なテレメトリしかなく、何を直すべきか判断するには、より密な計測が必要だった
  • チームは、すべてのIOを複数の地点で追跡する仕組みを構築した
    • EBSクライアントイニシエータ
    • ネットワークスタック
    • ストレージ耐久性エンジン
    • OS
  • 顧客ワークロードの監視に加え、既知のワークロードで変更の正負両面の影響を継続確認するカナリアテストも作成した

ハードウェアとソフトウェアをまたいだ改善作業

  • 新しいテレメトリは、初期の投資対象を明確に示した
    • システム全体のキュー数を減らす必要があった
    • EC2で使われていたXenハイパーバイザーのIOパス複雑性を下げる余地があった
    • ネットワークソフトウェアの最適化が必要だった
    • 中核となる耐久性エンジンには、オンディスクデータ配置、キャッシュライン最適化、非同期プログラミングモデルの採用が必要だった
  • AWSのシステム性能問題は、ハードウェアとソフトウェアスタックの複数階層を同時にまたぐことが多い
  • EBSはストレージサーバーチームとクライアントチームを並行して動かし、EC2ハイパーバイザーエンジニアやAWS社内ネットワーク性能グループも参加した
  • 開発組織も、ソフトウェアシステムのようにdivide and conquer方式で分割された
    • モノリシックなストレージサーバー開発チームを、データ複製、耐久性、スナップショットhydrationのような領域別の小規模チームへ再編した
    • 各チームは厳格なテストを前提に独立して反復開発し、変更を反映できた
  • 2013年に作られた青写真は、現在のEBSの姿と同じではなかったが、進むべき方向を示した
    • 当時は、Amazonが将来的に独自SSDを作り、EBSの要件に合わせた技術スタックを持つことになるとは想定していなかった

XenからNitro、そしてSRDへ続くボトルネック除去

  • 2017年末まで、すべてのEC2インスタンスはXenハイパーバイザー上で動作していた
  • Xenのデバイスパスには、ゲストドメインと特権ドライバドメインであるdom0が情報を共有するring queueがあり、EBSクライアントはdom0のカーネルブロックデバイスとして動作していた
  • インスタンスからEC2ホストを出るまでに、IO要求は複数のキューを通過した
    • インスタンスのブロックデバイスキュー
    • Xen ring
    • dom0カーネルブロックデバイスキュー
    • EBSクライアントのネットワークキュー
  • EBSチームは各キューの影響を分離するため、複数のループバックデバイスを作成した
  • dom0デバイスドライバのレイテンシがほとんどなくても、複数のインスタンスが同時にIOを発生させると、システム全体の実効スループットが低下する現象が確認された
    • EC2はXenのデフォルトのブロックデバイスキュー数とキューエントリ数でリリースされていた
    • このデフォルト値は、過去のXen開発環境における制約の大きいストレージハードウェアを基準に設定されたものだった
    • ホスト全体に対するoutstanding IO要求は64個に制限されており、デバイスごとの制限ではなかった
  • 2013年には、ネットワーキング専用の最初のNitro offload cardの開発が進んでいた
    • VPCのソフトウェア定義ネットワーク処理を、Xen dom0カーネルから専用ハードウェアパイプラインへ移した
    • パケット処理のデータプレーンをハイパーバイザーから分離し、顧客インスタンスのCPUサイクルをネットワークトラフィック処理に使わずに済むようにした
  • 同じアプローチがEBSストレージにも適用された
    • より多くの処理をハードウェアへ移し、ハイパーバイザーのOSキューを減らした
    • 割り込みベースの処理をオフロードし、ハイパーバイザーが要求処理に使う時間を短縮した
    • 2枚目のNitroカードには、EBS暗号化ボリュームを性能影響なしに処理できるハードウェア機能も備わっていた
    • 暗号鍵素材をハイパーバイザーから分離し、顧客データをさらに保護した
  • EBSをNitroへ移行した後、ボトルネックはネットワークそのものへ移った
    • 最新のデータセンター向けTCPチューニングパラメータと輻輳制御アルゴリズムを見直した
    • ストレージサーバー要求に小さなランダム遅延を加えると、ネットワークの平滑化効果により平均レイテンシと外れ値が下がるケースもあった
    • こうしたチューニングは、システム性能と規模が増え続ける中で長続きせず、回帰を防ぐための計測と監視が継続的に必要だった
  • 2014年には、TCPより優れた方法を目指して**Scalable Reliable Datagram(SRD)**ベースの取り組みが始まった
  • SRD設計では、2つの観察が重要だった
    • 一般的なインターネットではなく、AWSデータセンターネットワーク設計に集中できること
    • ストレージでは、飛行中のIO要求の実行順序を再順序化できること
  • TCPの厳密なin-order deliveryのコストを避け、異なる要求を複数のネットワーク経路へ送り、到着時に実行できた
  • SRDはストレージだけでなくネットワーキングにも使われている
    • Elastic Network Adapter(ENA) Expressでは、SRDがゲストのTCPスタック性能を改善する
    • 複数のネットワーク経路を活用し、中間ネットワーク機器のオーバーフローやキューを減らして、より高いネットワーク利用率を実現できる

SSDキャッシュと無停止マイグレーション

  • EBSは、一部のボリュームと顧客だけがより良い性能を得る状態に満足せず、SSDの利点をより広く提供しようとした
  • 当時は、数千台のストレージサーバー上で数百万のnon-provisioned IOPS顧客ボリュームが稼働していた
    • その一部のボリュームは現在も存在している
    • すべてのハードウェアを廃棄して置き換える方式は高コストだった
  • サーバーシャーシには空きスペースがあったが、冷却気流を妨げない位置はマザーボードとファンの間しかなかった
  • SSDは小さく軽かったが、シャーシ内で動かないよう固定する必要があり、材料科学者の協力と試行錯誤の末、耐熱性のある工業用hook and loop fastening tapeが見つかった
  • 2013年の数か月間、EBSは数千台の各サーバーにSSD 1台を手作業で追加した
  • ソフトウェアには、新しい書き込みをSSDへstagingし、アプリケーションに完了を返した後、遅いHDDへ非同期flushする小さな変更が加えられた
  • この作業は顧客中断なしで進められた
    • EBSは当初から無停止メンテナンスイベントを考慮して設計されていた
    • EBSボリュームを新しいストレージサーバーへretargetし、空いたサーバーを更新または再構築できた
  • 顧客ボリュームを新しいストレージサーバーへ移せる能力は、その後も何度も役立った
    • オンディスクフォーマット向けにより効率的なデータ構造を導入する際に活用された
    • 古いハードウェアを新しいハードウェアに置き換える際にも使われた
  • 2008年のEBS公開初期数か月に作成されたボリュームのうち、現在もアクティブなものがある
    • こうしたボリュームは、何百台もの異なるサーバーと複数世代のハードウェアを経てきた可能性がある
    • そのワークロードに影響を与えることなく、フリートの更新と再構築が行われてきた

性能拡張に合わせたリーダーシップのあり方

  • EBSの規模は、技術面だけでなく組織面でも、従来の小規模企業やスタートアップ環境とは異なっていた
  • システム専門家がすべてのエスカレーション、コミットレビュー、設計変更レビューに関与すると、組織の性能ボトルネックになり得る
  • これを解決するため、コードだけでなく協業のやり方でも実験が行われた
  • 代表的な手法としてpeer debuggingが使われた
    • 複数のエンジニアがコードとターミナルを一緒に見ながら問題を追跡した
    • 重要なデータ構造更新に対するlockingの位置と方法が問題だった事例を見つけ出した
    • 通常は問題が表面化しなかったが、ときどき要求応答が遅くなっており、これを修正してjitterの一因を除去した
  • エンジニアが安全に実験できるよう権限を与え、障害物を減らしつつguardrailを維持するやり方が、より良い結果につながる場合があった

大規模な書き直しより継続的改善

  • EBSの改善は、1回の巨大な変更ではなく、時間をかけた段階的改善の連続として進められた
  • この方式により、顧客価値をより速く届けられ、顧客ワークロードの変化に応じて学んだことを反映しながら方向修正できた
  • EBSのレイテンシ体験は、IO処理あたり平均10ms超の水準から、最高性能のio2 Block Expressボリュームにおける一貫したサブミリ秒IOへと改善された
  • 新しいアーキテクチャを提供するためにサービスをオフラインにすることなく、この変化を達成した
  • 顧客は今後もさらに高い性能を求め続け、その要求がEBSのイノベーションと反復を継続的に駆動する力となっている

関連記事

1件のコメント

 
GN⁺ 2024-08-23
Hacker News のコメント

  • ここでこの記事を見られて本当にうれしい。大規模システムに少しでも関心があるなら、ぜひ読む価値がある。
    シーケンシャルなワークロードでは、現代的な磁気ディスクは読み書きで 100MB/s 以上を出せるが、完全にランダムな 4kB ワークロードでは 400kB/s まで落ちることがある。キューイングやスケジューリングで最悪の事態は避けられても、実際の性能はワークロードによって 100 倍以上変わるため、マルチテナントシステムにとっては非常に扱いにくい。特に読み取りには、「単に別の場所に書く」といった回避策がない。
    Marc から最も大きく学んだのは、何が壊れているのかを知るには、まず正しく見なければならないということだった。彼は遅延時間の可視化、たとえば記事にあるヒストグラム時系列のようなものを作り、その可視化を使ってストーリーを組み立て、チームがやるべきことの見方をまったく変えてしまった。ヒストグラムの各ピークにはそれぞれ固有の原因と最適化作業があり、性能データをさまざまな方法で深く見ることに投資しなければ見えない効率や機会が開ける。
    2013 年に数千台のサーバーそれぞれに SSD を 1 台ずつ追加したレトロフィットプロジェクトは、AWS の話の中で一番好きな事例だ。最初から無停止メンテナンスイベントを念頭に置き、EBS ボリュームを新しいストレージサーバーへ再割り当てし、空いたサーバーを更新または再構築できるようにしていたからこそ可能だった。分散システムはスケールアウトのためだけのものではなく、サーバー障害を自然に許容し、データを失わずに移動できるようにして、大規模運用まで可能にするという好例だ。

    • Marc が遅延時間の可視化を作り、それを使ってストーリーを組み立てたというくだりが興味深い。
      Google の Dick Lyon も Google のストレージサーバーで同じアプローチを取り、https://www.pdl.cmu.edu/SDI/2015/slides/DatacenterComputers.... の 62 枚目のスライド以降で、ブロックストレージの主要なボトルネックとして複数のキューとリソース競合を特定している。

  • 昔の記憶がよみがえる。Reddit は 2008 年に EBS の初期ユーザーの一つで、EBS ボリューム 5 個でソフトウェア RAID を組めば IOPS が増えると気づき、自分たちは賢いと思っていた。
    当時は各ボリュームの性能が非常にばらついていたので、7〜8 個立ち上げて読み書き負荷をかけ、最も性能の良い 5 個を選んで Linux のソフトウェア RAID にまとめていた。うまくいくと狙いどおり、単一ノードの 5 倍を超える IOPS が出ることもあったが、悪いときは本当にひどかった。
    ソフトウェア RAID では、ノードが 1 つ遅いと RAID 全体が最も遅いボリュームの速度で動くことを知らず、その結果、データベースが壊れているように見えた。原因が RAID だと突き止めるまで時間がかかり、悪いノードを外すのも難しかった。ソフトウェア RAID がその遅いボリュームへの書き込みを終えるまでは解放しようとしなかったからだ。
    新しい EBS ボリュームを入れてアレイを作り直す必要があったが、これも新しいボリュームの IOPS に詰まって具合が悪かった。その後、そのソフトウェア RAID は使わなくなり、Netflix では EBS をほとんど使わなかった。Reddit で犯した失敗を、聞く人すべてに話していたし、Netflix は私が加わる前からすでにローカルディスクのみを使用する方針で標準化していた。
    面白い余談として、AWS の大規模な EBS 障害のとき、私は Reddit で働いていて、データベースを直すために EBS の復旧を待ちながら Netflix を見ていた。Netflix の面接で「EBS 障害中もどうやって生き延びていたのですか？」と聞いたら、「ああ、うちは単に EBS を使っていないんです」と答えられた。

    • 私たちもその方式を使っていた。最終的にはネットワーク帯域幅の上限にぶつかり、当時のほとんどのインスタンスタイプでは、性能は毎秒約 160MB あたりで頭打ちになっていたと思う。

  • この記事は読んでよかった。
    興味深いのは、記事が扱っている時期に、AWS が EBS に起因するおよそ4 日間の障害に見舞われ、EC2、EBS、RDS が影響を受けたと記憶している点だ。この障害は AWS への信頼を大きく揺るがした。
    その結果、組織改編が行われ、EBS を独立サービスとしてはるかに深く投資するようになった。この時期は Apple が顧客になった時期とも重なり、Netflix、Zynga、Dropbox のようなスタートアップでの採用によって AWS 全体が急成長していた時期でもある。
    こうした技術的・運用的な話も面白いが、本番環境での技術革新は雑然としていて、現実のビジネス要件という背景の上で起きる。そういう話ももっと聞けるとうれしい。

    • あの出来事の後の 1 年は良い年だった。安定性に集中し、問題を減らし、多くの開発アイデアも方向転換した。
      しかし車輪はまた回り、機能開発へと戻っていった。その年は、そこにいた間でエスカレーションが最も少なかった年として、ずっと記憶している。

  • 「ストレージサーバーのリクエストに少量のランダムな遅延時間を追加すると、ネットワークを平坦化する効果によって平均遅延時間と外れ値がむしろ減った」という部分が気になる。なぜそうなるのか説明できるだろうか？

    • 同期したネットワークトラフィックは、インキャストやその他のバッファオーバーフローを引き起こすことがある。

  • 興味があれば、2009 年に Amazon S3 の内部構造について発表した講演 [0] がある。S3 チームの内部資料を基に作られたもので、ここにある多くの内容が EBS の開発方法にも影響を与えた。
    [0]: https://vimeo.com/7330740

  • 2013年にすべてのEBS機器へSSDを手作業で追加したという部分がよかった。写真を見るとSamsung SATA SSDにかなり似ているように見える
    https://www.allthingsdistributed.com/images/mo-manual-ssd.pn...
    記憶違いかもしれないが、DellのブレードにSSDを入れて使っていたのは、それよりずっと前だった気がする。2010〜2012年ごろはI/O性能が本当に大きな課題で、回転式ハードディスクからフラッシュメモリへ移行していた時期だった
    エラー処理やウェアレベリングもまったくない、生のフラッシュベースのデバイスで実験していた記憶がある。正気の沙汰ではなかったが、誰もが回転式ディスクからシリコンへ移ることで得られる莫大なI/O性能向上を切実に求めていた

    • それは少数のフランケンラックだけだった。扱いにくく性能もよくはなかったが、全員が研究を先行して始められるようにしてくれた
      ディスク速度の向上が速すぎて、6か月で最初のSKUは時代遅れになった。予定より数年早くそのラックを廃棄するとき、資産チームに自分で説明しなくて済んでよかった。新しく、より高密度で高速なモデルを入れるほうが、ラック位置の価値ははるかに高かった

  • 使い物になるオープンソースが出てくる前に、サービスとしてのストレージインフラを作っていたことを思い出す。Sun SAN、Fibre Channel、Solarisから離れ、LinuxとNFSを動かすSupermicroのストレージサーバー上のGlusterFSへ移行し、2007年に離れる前にはほぼ2PBまで増えていた
    それから、サーバーを稼働させたまま回転式ディスクの代わりにSSDを差し込み、mdraidをこっそり壊して作り直すのが単に合理的だった時代も思い出す。SATAがドライブのホットスワップをある程度サポートしていたからだ。回転式ディスクからSSDに替えたことで、プラットフォームで最も重要なシステムのIOPSは14倍増加した

  • キャリアの初期に、人員規模ではなく技術・運用規模が大きいインターネット企業で、システム全般を扱う仕事をしていた。短い時間で学んだ教訓の数は途方もなく多かった。その会社を離れた後、ほとんどの人はキャリアを通じてそうした問題にほとんど直面しないため、その教訓も学べないのだと知った
    だから専門資格制度があるべきだと思う。熟練エンジニアの下での見習いを求めれば、経験でしか学べない非常に価値ある知識と技術を短期間で身につけ、その後はるかに効果的に働ける。候補者を面接する立場から見ても、経験の証拠とメンターの推薦は非常に価値があるはずだ

    • 資格を取った後でも、顧客が必要としているものが単純なUI付きのCRUDサービスなら、それを作ることになる状況を想像すればいい。顧客が無資格の開発者を使えないなら、なおさらそうなるだろう

  • この一文がよかった
    「広く称賛されるフルスタックエンジニアという理想にも価値はあるが、深く複雑なシステムでは、スタック全体と各自の深い専門領域を横断して協業し、創造的に働ける専門家集団を作ることのほうが、より価値がある場合が多い」

  • 記事の最初の図は不正確か、かなり古い内容だ。現代のコンピューターでは、ほとんどのPCIeレーンは昔のように別個のPCHを経由せず、CPUのI/OハブまたはUncore領域へ直接接続されている
    これはI/Oスループットとレイテンシの両方にとって重要な進歩だ。それ以外は素晴らしい記事で、結局あらゆる場所がキューなのだという点をよく示している

    • その通りで、現代のコンピューターははるかに優れたアーキテクチャを持っている。話を構成するときは、私たちが始めた当時の姿を思い浮かべていた
      画像のキャプションで、その時代の構造であることを明確にしておく