Google は、ストレージのニーズのほとんどを依然としてハードディスク ドライブに依存しているものの、自社製の自動データ階層化システムによってストレージ システムのパフォーマンスを「劇的に」向上させることができたと明らかにしました。
広告・検索大手の同社は、自社のユニバーサルストレージプラットフォーム「Colossus」の仕組みを説明する木曜日の投稿で、引き続き錆びを回転させることに愛着を持っていることを認めた。
Colossus は、YouTube、Gmail、Google のクラウド ストレージ サービス、その他のアプリケーションの基盤となります。
「ほとんどのデータセンターには、クラスター内で実行されるワークロードの数に関係なく、クラスターが 1 つあり、したがって Colossus ファイルシステムも 1 つあります」と投稿には記載されており、さらに「多くの Colossus ファイルシステムには、それぞれ 10 エクサバイトを超えるストレージを持つ 2 つの異なるファイルシステムを含む、複数エクサバイトのストレージがあります」と付け加えています。
Colossusは高速です。Googleの投稿によると、同社の最大規模のファイルシステムは、読み取りスループットが50TB/秒、書き込みスループットが25TB/秒を定期的に超えており、最も負荷の高いクラスターでは「読み取りと書き込みを合わせて6億IOPS以上」を実現しています。
毎日1.2エクサバイトのデータを世界中に転送したい？Effingoならお任せください
続きを読む
GoogleがColossusに関する公開情報を最後に投稿したのは2021年で、そのシステムは「フラッシュストレージとディスクストレージを組み合わせて使用」し、最も頻繁にアクセスされるデータをフラッシュディスクに配置することで「より効率的なサービス提供と低レイテンシ」を実現すると明らかにした。
Colossus は今でも、需要の高いデータをハードディスク (HDD) からソリッド ステート ディスク (SSD) に移動しており、新しい投稿では、この処理は「長年にわたって SSD がより手頃な価格になり、データ センターでの重要性が高まっているため、今日ではさらに重要になっています」と述べています。
「しかし、SSDのみのストレージは、SSDとHDDを組み合わせたストレージ群に比べて依然として大幅なコスト増を招きます」と投稿には記されている。「課題は、適切なデータ、つまりI/Oが最も多く発生するデータやレイテンシが最も低いデータをSSDに置き、残りのデータをHDDに保持することです。」
木曜日の投稿は、ストレージ技術リーダーの Larry Greenfield 氏とストレージ ソフトウェア エンジニアの Seth Pollen 氏によって執筆され、Google がソリッド ステート ディスク (別名フラッシュ ストレージ) とハード ディスク ドライブ間でデータを移動するために使用するツールについて説明しています。
2人は、Googleの社内ユーザーはファイルをフラッシュメモリに強制的に保存するか、ファイルのコピーを1つSSDに保存するハイブリッド方式を採用できると明らかにした。後者は、Googleがストレージデバイスを格納するために使用しているサーバーが常に利用可能とは限らないため、SSD上のファイルのコピー1つにアクセスできない可能性があり、社内ユーザーはHDDによるレイテンシの増加に対処しなければならないため、最適とは言えない。
したがって、どのメディアがデータに最適であるかに関するほとんどの決定は、「L4」と呼ばれる自動キャッシュ システムによって行われ、Greenfield 氏と Pollen 氏は「SSD に最適なデータを動的に選択する」と述べています。
- 毎日1.2エクサバイトのデータを世界中に転送したい？Effingoならお任せください
- アーカイブ ストレージが Google Cloud に登場: AWS と Azure に冷遇されることになるのか?
- Big RedとMicrosoftが、より主流のOracleユーザー向けにAzureデータベースサービスを展開
- アップルとグーグル、クラウド間のデータ転送を簡素化、コストの負担は大きいか
The Registerの投稿を読む限り、L4 は SSD にデータをキャッシュし、そのキャッシュ内のデータをリストするインデックスを構築します。
「つまり、アプリケーションがデータを読み込みたい場合、まずL4インデックスサーバーに問い合わせます。そのインデックスは、データがキャッシュ内にあるかどうかをクライアントに通知し、キャッシュ内にある場合、クライアントは1つまたは複数のSSDからデータを読み取ります」と両氏は記している。
データがキャッシュにない場合、L4 はそれを HDD から読み取り、SSD を使用するサーバーに移動します。
「L4はSSDにどの程度のデータを配置するかについて、多かれ少なかれ積極的になることがあります」とストレージ技術者は記している。「私たちは機械学習（ML）を活用したアルゴリズムを用いて、ワークロードごとに異なるポリシーを決定します。データの書き込み時、最初の読み取り後、あるいは短時間内に2回目の読み取りを行った後にのみL4キャッシュに挿入する、といった具合です。」
Google は、2022 年の USENIX カンファレンスでのプレゼンテーションで、これらの技術のいくつかを詳しく説明しました。
パフォーマンスは向上したが、問題は依然として残る
Greenfield 氏と Pollen 氏の投稿では、L4 のキャッシュ技術は「同じデータを頻繁に読み取るアプリケーションに適しており、IOPS とスループットが劇的に向上しました」と述べています。
また、Google は依然として新しいデータを HDD に書き込むため、それが「大きな弱点」となっていることも認めている。
「そして、L4 読み取りキャッシュが期待するほどリソースを節約できない重要なデータ クラスが他にもあることが判明しました。具体的には、書き込み、読み取り、削除が高速なデータ (大規模なバッチ処理ジョブの中間結果など) や、データベース トランザクション ログ、多数の小さな追加が行われるその他のファイルです。」
このようなワークロードは HDD にはあまり適しておらず、2 人は「それらを SSD に直接書き込んで、HDD を完全にスキップすることが望ましい」と感じています。
これらのシグナルは、新しいSSDハードウェアの購入を促進し、計画者に効率を最大化する方法を伝えます。
L4 は、アプリケーションがまだ使用していないため、SSD でパックされたキャッシュへの昇格が必要と想定できない新しいファイルのデータ配置も自動化します。
したがって、アプリケーションが新しいファイルを作成すると、ファイルの種類や、ファイルにデータが格納されているデータベース列に関するメタデータなどの情報が共有されます。
「L4はこれらの特徴を利用してファイルを『カテゴリ』に分類し、各カテゴリのI/Oパターンを経時的に観察します」とグリーンフィールド氏とポレン氏は記している。「これらのI/Oパターンに基づいて、『SSDに1時間配置する』、『SSDに2時間配置する』、『SSDには配置しない』といった様々な配置ポリシーのオンラインシミュレーションが実行されます。このシミュレーションに基づいて、L4は各カテゴリに最適なポリシーを選択します。」
これらの状況では、「利用可能な SSD 容量が増減した場合に L4 が選択する配置も予測します。」
「これにより、SSDの容量に応じてHDDからどれだけのI/Oをオフロードできるかを予測できます。これらのシグナルは、新しいSSDハードウェアの購入を促進し、アプリケーション間でSSD容量をシフトして効率を最大化する方法を計画者に提供します」と両氏は記しています。
SSD と HDD を最適に組み合わせる方法に取り組んでいるのは Google だけではありません。ストレージ ハードウェア ベンダーは、この組み合わせをうまく行うことを強みとしていますが、エクサバイト規模で動作させる必要はありません。
そのため、Googleが4月に開催されるGoogle Cloud Nextカンファレンスでストレージシステムに関する詳細情報を発表すれば、彼らもあなたも恩恵を受けることができるでしょう。ラスベガスのガブフェストに参加するなら、グリーンフィールド氏とポレン氏は「Google Cloudのストレージの最新情報」と「AIハイパーコンピュータ：ストレージインフラストラクチャのマスター」というセッションに注目することを勧めています。®
