Google Cloudブログの先日の記事で、GoogleがColossusのアーキテクチャの一部を公開した。ColossusはGoogleのスケーラブルなストレージシステムを支えるもので、Google Cloudサービスに加えて、YouTubeやGoogle DriveやGmailなど、Google自身が世界規模で公開するサービスにおいても使用されている。
Colossusは独立した5つのコンポーネント — クライアントライブラリ、キュレータ(curator)、メタデータ・データベース、"D"ファイルサービス、カストディアン(custodian) — で構成されている。下の図は、これらコンポーネントの関係を示したものだ。
Colossusクライアントライブラリは、プラットフォームへのエントリポイントとして、さまざまなクライアントアプリケーションが使用するもので、ソフトウェアRAIDなどの機能を実装するとともに、それぞれのワークロードに合わせたパフォーマンスとコストのトレードオフの詳細なチューニングが可能になっている。
次のColossusキュレータは、Colossus Control Planeの大半を形成するもので、ファイル生成などのコントロール操作を担当し、水平スケーリングを可能としている。キュレータはメタデータを、Googleの高性能NoSQLデータベースであるBigTableに格納する。メタデータをBigTableに保存することで、Colossusは、前世代の最大のクラスタより100倍以上のスケールアップが可能になっている。
データ自体は、クライアントアプリケーションと、ネットワークにアタッチされたディスクである"D"ファイルサーバの間で直接転送される。カストディアンも同じくファイルサーバ上で動作し、"データの堅牢性と可用性、および全体的な効率性を維持し、ディスクスペースのバランス維持やRAIDの再構成といったタスクをハンドリングするという、重要な役割"を果たしている。
記事を書いたDean Hilderbrand氏とDenis Serenyi氏は、Colossusの実際の動作について、次のように説明している。
Colossusでは、単一のクラスタをエクサバイト単位のストレージ、数万台のマシンにまで拡張することが可能です。以下の例のように、Compute Engine VM、YouTube servingノード、Ads MapReduceノードからCloud Storageにアクセスするインスタンスがあれば、これらすべてが基盤として同じファイルシステムを共有した上で、リクエストを実行することができます。ここで重要な役割を果たしているのが、Colossusコントロールプレーンが管理する共有ストレージプールで、それぞれに対して、あたかも独立したファイルシステムを所有しているかのように見せているのです。
Colossusは、Googleのストレージサービスの実装で使用されている、3つのビルディングブロックのひとつを形成している。他の2つは、グローバルな一貫性を持ったスケーラブルなリレーショナルデータベースのSpannerと、各々が数万台のマシンで構成される多数のクラスタにわたって、数千のさまざまなアプリケーションの要求する数十万のジョブを実行する能力を備えた、スケーラブルなクラスタマネージャのBorgである。Borgは多くの場合において、Kubernetesの開発に大きな影響を与えた概念上の前身であると言われている。