S3と呼ばれるかなり大規模なストレージシステムの構築と運用

 (allthingsdistributed.com)
4 ポイント 投稿者 GN⁺ 2023-07-28 | 1件のコメント | WhatsAppで共有

S3の構築と運用

  • S3はAmazon Simple Storage Serviceの略であり、大規模なストレージシステムを意味する。
  • Andy WarfieldはS3で働き、システムに対する幅広い理解を得た。
  • S3は、顧客の性能体験からハードディスクのメカニクスまで、さまざまな領域をまたぐサービスである。

17年前、遠い大学キャンパスで...

  • S3は2006年3月14日にリリースされ、今年で17周年を迎える。
  • Warfieldはケンブリッジ大学で博士号を取得した後、Xenプロジェクトに参加し、その後XenSourceというスタートアップを創業した。
  • XenSourceは成長してCitrixに買収され、Warfieldは事業の成長とチーム運営について多くを学んだ。

S3の動作方式

  • WarfieldはAmazonに加わった後、S3の初期エンジニアの一人であるSeth MarkleからS3の動作原理を学んだ。
  • S3はHTTP REST APIを持つオブジェクトストレージサービスであり、フロントエンド、ネームスペースサービス、ハードディスクを備えたストレージフリート、バックグラウンド処理を実行するフリートで構成される。
  • S3は数百のマイクロサービスで構成されており、各チーム間の相互作用はAPIレベルの契約によって成り立っている。

初期の観察

  • S3はソフトウェアを超えて、ハードウェアと人を含む継続的に進化するエコシステムである。
  • S3の規模は、各構成要素がスケールアウトされたサービス群で構成されているため、システム全体の規模を理解するには時間がかかる。

技術的な規模: ストレージの物理学

  • S3は数百万台のハードディスクを使用する非常に大きなシステムである。
  • ハードドライブは技術と革新の驚異を体現しており、コスト効率にも優れている。

熱管理: データ配置と性能

  • S3では「熱管理」という問題を解決するため、I/Oリクエストを多数のハードドライブに均等に分散させる最適化が行われている。

レプリケーション: データ配置と耐久性

  • S3はデータの耐久性を保証し、熱を管理するために、レプリケーションやイレイジャーコーディングのような冗長化スキームを使用している。

規模の影響: データ配置戦略

  • データを可能な限り多くのディスクに広く配置することで、顧客データが各ディスク上で占める割合を非常に小さくし、ワークロード分離を実現している。

人的要素

  • S3の複雑さは、技術的要素だけでなく人的要素にも起因している。
  • Amazonは、エンジニアとチームが迅速かつ安全に失敗し、高い耐久性を持つストレージの提供に集中することを奨励している。

自分自身のスケールアップ: 「オーナーシップ」で始まり終わる難題の解決

  • WarfieldはAmazonで個人としてのスケールアップを経験し、ソフトウェア、人、ビジネスの規模について学んだ。
  • Amazonでは「オーナーシップ」を重視しており、これは組織構造とエンジニアリングアプローチを理解する助けとなっている。

GN⁺の意見

  • S3は単なるストレージサービスを超え、ハードウェア、ソフトウェア、人的要素が結びついた複雑なエコシステムである。
  • この記事は、S3の規模と複雑さを理解したい初級ソフトウェアエンジニアに洞察を与える。
  • Amazonの「オーナーシップ」文化は、チームと個人がより大きな責任感を持ってイノベーションを追求するよう動機づける重要な要素である。

関連記事

1件のコメント

 
GN⁺ 2023-07-28
Hacker Newsのコメント

  • エラー率が10^15リクエストあたり1回というのは、現実世界では実際によく起こることであり、S3では考慮すべき事項だ。

    • AWSで働いていたとき、S3の規模では10億分の1の事象が毎日発生しており、普段は心配する必要がないほど低確率の事象であっても考慮して対処しなければならないことを覚えている。
    • ShardStoreについて読めてうれしい。特に形式検証やプロパティベーステストなどが印象的だ。前世代のサービスはバグが多いことで有名だったが、少なくとも安全に失敗してデータ損失を防ぐことに執着していたS3エンジニアたちのおかげで、よく設計されていた。

  • ゲノミクス分野で働きながら、この10年間で多くのペタバイト級データストアを扱ってきた。

    • AWS S3、GCP GCS、Ceph、Gluster、HPのシステムなど、さまざまなストレージシステムを使ってきた経験から、こうしたシステムを運用するのに必要な努力を高く評価している。
    • 数多くの別の顧客とディスクIOPSを共有することの利点は非常に大きく、単一システムでこれを緩和するのはとても難しい。
    • コロケーションされたハードウェアクラスタでは、大規模ジョブでIOをRAMやCPUのような割り当て可能資源として扱うために、バッチシステムをカスタマイズする必要があった。
    • S3とGCPは高価だが、その性能にはそれだけの価値がある。

  • S3がOAuth2ベースのプロトコルを使って読み書きアクセスを委譲できたら、私たちが構築できるものは大きく広がる。

    • ユーザーの代わりにアプリがデータへアクセスできるHTTPベースのプロトコルが必要だ。
    • Google Driveがこれに最も近いが、単一プロバイダーの問題があり、remoteStorageが普及しなかったのは残念だ。
    • Solidには成功してほしいが、複雑に感じる。
    • この問題に対する自分なりの解決策はgemdrive.ioだが、今はセルフホストスタックの別の部分に集中している。

  • IBM RAMACハードドライブの1956年仕様についての説明。

    • ストレージ容量3.75 MB、コストがテラバイトあたり約$9,200という仕様は正確ではないかもしれない。
    • 別のサイトでは購入価格はメガバイトあたり約$10,000であり、仕様はメガバイトあたり$9,200であるべきだと示唆している。

  • 分散システムで認証を扱うのは非常に難しい。

    • AWS規模での認証は魔法のようなもので、AWSは豊富な権限モデルを持ち、認証変更がインフラ全体へサブミリ秒の速度で伝播する。
    • S3は他のサービスとは異なり、権限がリソース側にあるのは速度のためかもしれない。

  • 技術的なアジェンダを持つ非常に経験豊富なエンジニアとして、アイデアを出すことよりも、問題を掘り下げて明確に説明することにより多くの時間を費やしている。

    • 成功する役割を果たすには、問題を明確にし、解決策を支援することに集中しつつ、強力なエンジニアリングチームがその解決策をオーナーシップを持って進められるよう支援する方法を見つける。

  • Amazonの社員たちがS3の内部動作について公に話しているのを見るのはよいことだ。

    • Glacierがどう動いているのかもっと聞きたい。使われている記憶媒体についてはまだ公開されておらず、多くの憶測がある。

  • ハードドライブヘッドを747機にたとえて説明する部分。

    • 飛行機が地球を25,000周する間に、たった1回のミスで草の葉1本を外すような精密さだ。

  • S3 KeyMap時代にさかのぼると、最もホットなオブジェクト/パーティション/バケットを特定した後でも、単純に移動させるだけでは解決しないことを学んだ。

    • 実際の解決策は、ホストのパーティション負荷を四分位に分け、第2四分位のパーティションを最も負荷の低いホストへ移すことだった。
    • その結果、エラー率は安定的な約1%からエラーゼロの日が出る状態へと変わり、アラートをはるかに厳しく更新した。

  • S3は単なるストレージではなく、標準だ。

    • いくつかの場所でS3互換ストレージが提供されており、その標準がどれほどオープンなのか、また「S3互換」と言うためにAmazonへ支払いが必要なのかはわからないが、これはとてもクールなことだ。