Spanner の強整合性を Cloud Storage でも提供 ―― オブジェクトの一覧表示で一貫した整合性を保持
Google Cloud Japan Team
Google Cloud Storage の誇るべき特徴の 1 つは、オブジェクトの一覧表示に関するすべてのオペレーションで整合性が保たれていることです。Cloud Storage バケットの置かれている位置が同一リージョンかマルチリージョンかにかかわらず、一覧表示のオペレーションには強整合性があるのです。プロジェクト内のバケットの一覧表示でも、バケット内のオブジェクトの一覧表示でもそうです。Cloud Storage のバケットやオブジェクトを作り、すぐにリソースの一覧を表示せよと要求しても、それにきちんと応えてくれます。
では、なぜこれが重要なのでしょうか。データや分析のワークロードを実行する際には、一覧表示の強整合性には大きな意味があります。その理由について、Spotify のエンジニアである Twan Wolthof 氏は次のように述べています。
一覧表示に強整合性がなければ、ファイルを見落とす可能性が出てきます。製品開発中に読み込んだデータの整合性に信頼が置けなくなります。整合性のない一覧表示が原因で、目に見えない問題が起きることさえあります。たとえば、Spotify の処理ツールが部分的なデータの読み込みに成功し、一見有効な出力を生成する可能性があるのです。こういった問題は、依存関係のツリー全体であっという間に拡散していきます。こういうことが起きた場合、運が良ければ問題に気づき、依存関係ツリー内で生成されたすべてのデータセットを再計算することになります。最悪なら、エラーに気づかず、間違ったレポートや統計情報を作ってしまいます。私たちが実行しているデータ パイプラインがいかに膨大かを考えると、そのような可能性がわずかでもあれば大変なことです。一覧表示の強整合性がクラウド ストレージ製品で欠如していることは、Spotify のデータ処理にとって大きな阻害要因でした。
すべてのクラウド ストレージ サービスが “list-after-write”（書き込み後の一覧表示）の整合性を提供しているわけではありません。そのため、ごく一般的なユース ケースにおいて、これが問題になることがあります。
ユーザーがクラウド ストレージ バケットにオブジェクトをアップロードすると、そのオブジェクトがバケットのコンテンツ一覧に表示されるまで、通常は予測不能で制限のない時間がかかります。これは、結果整合性という弱い整合性モデルです。実際問題として、ユーザーが新しいオブジェクトをアップロードし、それを他のコンピュータのブラウザで見ようとしても、アップロードしたファイルが表示されないことがあるのです。複数のコンピュート ノードに分散されたワークロードでも同じような問題が起きます。
それに対し、すべてのオブジェクトに対して一覧表示の強整合性を提供している Cloud Storage の場合は、この種の問題は起きません。再び Spotify の Wolthof 氏の話に耳を傾けてみましょう。
NFS ベースのグローバルな整合性キャッシュの利用、Netflix の S3mper の導入、データとともに格納されるマニフェスト ファイルの永続化リストなど、私たちは問題回避に向けてさまざまな方法を検討しました。しかしどの方法も、単一障害点を導入するか、独自ソリューションの開発とツールの調整に膨大なリソースが必要になるという問題があり、最適とは言い難いものでした。一方、Cloud Storage は一覧表示で強い整合性を提供してくれるので、既存のデータ処理スタックをそのまま使い続けることができます。データ処理スタックに変更を加えたり、データの破損を心配したりする必要はないのです。Cloud Storage における一覧表示の強整合性は、Spotify のデータ処理の根幹を支える機能です。私たちは Hadoop Distributed File System の上に構築された Hadoop ベースのデータ処理スタックを使っており、これはファイル システム的な保証が前提条件になるということを意味します。私たちのビジネスで整合性はきわめて重要であり、これがなければさまざまな問題が生じます。
Spanner : Cloud Storage が強整合性を提供できる理由
Cloud Storage は昨年まで、バケットやオブジェクトに関する情報（メタデータ）を、Megastore と呼ばれる、Google の社内テクノロジーをベースとする一連のストレージ システムに格納していました。Megastore のおかげで Cloud Storage は、“read-after-write”（書き込み後の読み込み）の整合性といった重要な機能を迅速かつ大規模に提供できるようになりました。しかし、list-after-write については、他の多くのオブジェクト ストレージ サービスと同様に、結果整合性しか提供していませんでした。昨年、私たち Google はすべての Cloud Storage メタデータを Spanner に移しました。Spanner は、グローバルな分散環境で強整合性を提供する Google のリレーショナル データベースです。Spanner の特徴は、強い整合性を保証し、高い可用性を提供しつつ、水平スケーリングが可能なことです。Google Cloud のお客様は、これと同じテクノロジーを Google Cloud Spanner という形で利用できます。
Spanner への移行により、Cloud Storage は一覧表示の強整合性をはじめとする重要な機能を手に入れたのです。
一覧表示の強整合性は、たとえば MapReduce や Hadoop のタスクでも大きな意味があります。そうしたタスクでは、多数のワーカーが別々の作業を行い、その結果を別のプロセッサが収集して処理する必要がありますが、一覧表示の強整合性が保たれていれば、ワーカーは個別に処理結果をバケットにアップロードできます。収集ジョブが常に例外なくすべてのワーカーの処理結果を照合できるからです。これは、強整合性（外部整合性）によってアプリケーション開発の効率が向上する 1 つの例です。
まとめ
Cloud Storage は、あらゆるリージョンのあらゆるバケット タイプに対する以下のオペレーションで強整合性を提供します。- read-after-write : 書き込み完了後のオブジェクトの読み込みには、書き込みの内容が反映されます（新オブジェクトの書き込みと既存オブジェクトの上書きの両方を含む）。
- read-after-metadata-update : メタデータ更新後のオブジェクトのメタデータの読み込みには、更新の内容が反映されます。
- read-after-delete : 削除直後のオブジェクトの読み込みは 404 エラーとなります。
- list-after-write : バケットやオブジェクトの一覧表示には、過去に行った変更が常に反映されます。
- 権限付与後のリソース アクセス : オブジェクトの読み込み権限を新規ユーザーに付与すると、そのユーザーはすぐにオブジェクトを読み込むことができます。
- 一部の操作もしくは権限変更の場合は制限付きの整合性が提供されます。パブリック キャッシュされたオブジェクトの読み込みなど、キャッシュ パフォーマンスを最大化するために設計された機能では強整合性に制限があります。詳しくはこちらを参照してください。
Cloud Storage メタデータを Spanner にホスティングすることで得られる強整合性を皆さんに提供できることを、私たちはうれしく思います。Cloud Storage の整合性モデルの詳細はこちらのドキュメントをご覧ください。
* この投稿は米国時間 2 月 23 日、Google Cloud Storage の Software Engineer である Zhihong Yao によって投稿されたもの（投稿はこちら）の抄訳です。
- By Zhihong Yao, Software Engineer, Google Cloud Storage
