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

 (allthingsdistributed.com)
2 ポイント 投稿者 GN⁺ 2024-08-23 | 1件のコメント | WhatsAppで共有

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

  • 紹介

    • Marc OlsonはElastic Block Store（EBS）チームで10年以上働いてきた。
    • EBSは単純なブロックストレージサービスから、1日に140兆件を超える処理をこなす大規模なネットワークストレージシステムへと進化した。
    • この記事では、EBSの進化の過程と重要な教訓を共有する。

  • EBSの初期の歴史

    • EBSは2008年8月20日にリリースされ、EC2インスタンス向けのネットワーク接続ブロックストレージを提供するというシンプルなアイデアから始まった。
    • 当初は共有ハードディスクドライブ（HDD）を使用していたが、現在では単一のEC2インスタンスに数十万IOPSを提供できる。
    • EBSは現在、分散SSDフリートを通じて1日に140兆件を超える処理を実行している。

  • 待ち行列理論

    • コンピュータシステムがストレージと相互作用する方法は、基本的に変わっていない。
    • CPUはリクエストをキューに入れ、ストレージデバイスはCPUメモリからデータを取得して耐久性のある媒体に保存するか、逆にデータをCPUメモリへ転送する。
    • 待ち行列理論は、このプロセスを理解するうえで重要な役割を果たす。

  • HDDからSSDへの移行

    • 初期のEBSはHDDを使用しており、これは物理的な限界によって性能が制約されていた。
    • SSDの登場により、ランダムリクエストもほぼシーケンシャルリクエストと同じくらい高速に処理できるようになった。
    • 2012年には、SSDを使った新しいストレージサーバータイプと、Provisioned IOPSという新しいEBSボリュームタイプをリリースした。

  • 計測と管理

    • 2012年当時、EBSには基本的なテレメトリしかなかった。
    • システム性能を改善するには、何が問題なのかを突き止め、それを優先順位に従って解決する必要があった。
    • 複数のサブシステムでIOを計測する仕組みを構築し、継続的な監視によって変化を検知した。

  • 組織の分割統治

    • EBSストレージサーバーチームを、データレプリケーション、耐久性、スナップショットのハイドレーションなど特定領域に集中する小規模チームへ再編した。
    • 各チームは独立して変更を反復し、コミットできた。

  • 前提への挑戦

    • Xenハイパーバイザーのデフォルト設定が性能を制限していたことを発見した。
    • Nitroオフロードカードを使って、ネットワークおよびストレージ処理をハードウェアにオフロードした。

  • ネットワークチューニングの実験

    • EBSをNitroへ移行する際、ネットワーク自体のオーバーヘッドが増加した。
    • TCPの代わりにSRD（Scalable Relatable Diagram）プロトコルを開発し、ネットワーク性能を改善した。

  • 制約条件がイノベーションを促進する

    • すべての顧客にSSDの利点を提供するため、既存ハードウェアを置き換えずにSSDを追加した。
    • SSDをサーバーに手作業で追加し、新しい書き込みをSSDに保存した後、非同期にHDDへフラッシュした。

  • 性能拡張を振り返って

    • 個人的な成長の物語: 小さな会社の文化から大規模組織への移行。
    • 同僚とのデバッグセッションを通じて問題を解決し、チームの効率を高めた。

  • 結論

    • EBSは単一の大規模な変更ではなく、一連の段階的な改善を通じて進化してきた。
    • 顧客の要求は今後も増え続け、それがイノベーションと反復を続ける動機となる。

# GN⁺の要約

  • この記事は、AWSのEBSがどのように進化してきたのかについて、内部関係者の視点を提供する。
  • 待ち行列理論、SSD導入、ネットワークチューニングなど、さまざまな技術的課題と解決策を扱っている。
  • 性能改善のための継続的な計測と管理の重要性を強調している。
  • 類似機能を持つ製品としては、Google Cloud Persistent DiskやMicrosoft Azure Disk Storageがある。

関連記事

1件のコメント

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

  • 大規模システムに関心があるなら、この記事は読む価値がある

    • ハードドライブの性能は、キュー内の他のトランザクションによって左右される
    • ランダムな4kBワークロードでは性能が大きく低下することがある
    • キューイングとスケジューリングは役に立つが、実際の性能はワークロード次第で100倍以上異なることがある
    • マルチテナントシステムでは、特に読み取り処理で難しさがある

  • 問題を解決するには、何がうまくいっていないのかを知る必要がある

    • Marcから学んだ最大の教訓は、可視化によってチームの視点を変えることだった
    • 性能データをさまざまな方法で分析すると、見えていなかった効率性や機会を発見できる

  • 2013年にEBSサーバーへSSDを導入したプロジェクトは、AWSの興味深い話のひとつだ

    • システムは最初から、破壊を伴わないメンテナンスイベントを念頭に置いて設計されていた
    • 分散システムを構築すれば、大規模運用が可能になる

  • AWSで約4日間続いた障害はEBSが原因で発生し、AWSへの信頼を揺るがした

    • これによりEBSへの投資が増えた
    • Appleが顧客になろうとしていた時期とも重なっていた

  • Redditは2008年にEBSの初期ユーザーのひとつだった

    • ソフトウェアRAIDを使ってIOPSを増やそうとしたが、性能は一貫していなかった
    • RAIDの問題を解決するのに時間がかかった
    • NetflixはEBSを使っていなかった

  • ランダムな遅延を加えると、平均遅延と外れ値の両方が減少する効果がある

  • 大規模インターネット企業で働きながら、多くの教訓を得た

    • 徒弟制度のような過程を通じて、重要な知識と技術を素早く習得できる
    • 面接では、経験とメンターの推薦が非常に役立つ

  • 2013年にすべてのEBSユニットへSSDを手動で取り付けたという部分が興味深かった

    • 2010年から2012年にかけて、I/O性能は重要な課題だった

  • 2009年にAmazon S3の内部について講演した

    • この講演はEBS開発に影響を与えた

  • クラウドの初期には汎用ハードウェアを使っていたが、今では個々のサービスに特化したハードウェアを使っている

    • AWSはGraviton、Inferentia、Traniumチップを使っている
    • GoogleはTPUとTitanセキュリティカードを使っている
    • AzureはFPGAとSphereを使っている

  • 最初の図は誤っているか古くなっている

    • 現代のコンピュータでは、ほとんどのPCIeレーンがCPUに直接接続されている
    • これはI/Oスループットとレイテンシにとって重要な進歩だ

  • 新しいEC2インスタンスに高速な256GBデータセットディレクトリを提供する最良の方法を探している

    • EBSボリュームを使っているが、更新が煩雑だ
    • EFSは遅すぎる
    • インスタンスストレージSSDは一時的だ
    • FSx Lustreはまだ試していない