コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第153回　サーバーレスNoSQLデータベースサービス「Firestore」（パート1）

グーグルのクラウドを支えるテクノロジー

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第153回　サーバーレスNoSQLデータベースサービス「Firestore」（パート1） (中井悦司) 2023年6月

はじめに

　今回からは、2023年に公開された論文「Firestore: The NoSQL Serverless Database for the Application Developer」に基づいて、Google Cloudで提供されるNoSQLデータベースサービス「Firestore」のアーキテクチャーを解説します。

Firestoreの特徴

　Firestoreは、Google Cloudのサービスとして利用可能なNoSQLデータベースで、主にモバイルアプリケーションのバックエンドとして使用されます。専用のSDKを利用することで、バックエンドサービスだけではなく、ブラウザー、もしくは、モバイルデバイスで稼働するクライアントアプリケーションからもアクセスすることができて、データベースに格納されたデータの変更をリアルタイムにアプリケーションに通知する「リアルタイムクエリー」の機能が利用できます。
　論文執筆時点のデータでは、1ヶ月あたり、約400万個のプロダクションデータベースに対して、10億以上のクライアントからのアクセスがあります。データベースのサイズやアクセス数には大きなばらつきがあり、スケーラビリティを備えたマルチテナント型のサービスとして、さまざまなアクセスパターンに対応した設計がなされていることが想像できます。冒頭の論文では、次の4点がFirestoreの特徴として挙げられています。

・Ease of Use（容易な利用方法）
　Firestoreは、任意のキー・バリューペアの集合からなる「ドキュメント」をデータモデルとしたNoSQLデータベースで、事前のデータベース設計に時間をかけずにアプリケーションの開発をスタートすることができます。また、一般的なNoSQLデータベースとは異なり、強い整合性を持ったACIDトランザクションを実行することができます。強い整合性を提供しないNoSQLデータベースの場合、データの整合性を担保するための工夫をアプリケーション側で行う必要がありますが、そのような手間が不要になります。

・Fully Severless Operation and Rapid Scaling（サーバーレス環境と高速なスケーリング）
　Firestoreは完全なサーバーレス・サービスとして提供されており、データベースを初期化するだけで、すぐに利用できます。APIリクエストを受けるフロントエンドサーバー群があらかじめ用意されており、クライアントからのリクエストは適切なフロントエンドに自動的にルーティングされるので、データベースにアクセスするためのネットワーク経路を意識する必要もありません。Firestoreに格納したデータは、Googleのデータセンター内で稼働する分散データベース（Spanner）に保存されており、Firestoreの高速なオートスケーリングは、Spannerの高いスケーラビリティによって支えられています。

・Flexible, Efficient Real-time Queries（柔軟で効率的なリアルタイムクエリー）
　リアルタイムクエリーは、データベース上でのデータ変更をリアルタイムにクライアントに通知・反映する仕組みです。クライアントアプリケーションがリアルタイムクエリーを実行すると、クエリーの結果を格納したオブジェクトが得られますが、クエリー実行後、データベース上で該当のデータが変更されると、サーバーからの通知により、オブジェクトの内容が自動的に更新されます。更新イベントを受け取るコールバック関数を用意することで、更新後のデータをクライアントのUIに即座に反映するなどの実装が容易に行えます。

・Disconnected Operation（オフライン操作）
　Firestoreは、モバイルデバイス上のクライアントアプリケーションからアクセスできますが、モバイルデバイスはインターネットとの接続が途切れることもあります。クライアントアプリケーションは、クエリーで取得したデータをローカルキャッシュに保存しておき、オフライン状態の場合は、ローカルキャッシュのデータを利用することができます。さらに、ローカルキャッシュに対する書き込みも可能で、変更内容は、デバイスがオンラインになったタイミングで、データベースに反映されます。

Firestoreの歴史

　冒頭の論文では、Firestoreの歴史についても触れられています。Firestoreの前身となるのは、2008年に公開されたAppEngineのデータベースである「Datastore」です。当時のDatastoreは、第7回の記事で紹介したように、Megastoreと呼ばれるデータベースを基礎として実装されており、さらに、Megastoreは、Bigtableをバックエンドのデータストアとして利用していました。Datastoreは、Firestoreと同様のサーバーレスサービスで、高いスケーラビリティを有するものの、強い整合性は「Ancestorクエリー」に限定されており、同一のエンティティに対する連続した書き込み処理に性能上の制限があるなどの課題もありました。
　その後、2014年にGoogleは、Firebase, Inc.を買収すると、当時のFirebase社が提供していたリアルタイムデータベースをGoogleの独自サービスとして再実装するプロジェクトがスタートしました。この際、Googleのエンジニアは、Datastoreの高いスケーラビリティにリアルタイムデータベースの機能を融合した新しいデータベースシステムを実現することを決断して、現在のFirestoreが誕生しました。Firestoreの実装にあたっては、強い整合性を持ったトランザクション機能を実現するために、バックエンドのデータストアをMegastoreからSpannerに変更したということです。
　現在、Google Cloudで提供されるFirestoreは、「Nativeモード」と「Datastoreモード」が選択できるようになっており、Datastoreモードを選択した場合は、これまでのDatastoreと互換性を持ったAPIで利用することができますが、リアルタイムクエリーなどの機能は利用できません。一方、Nativeモードを選択した場合は、リアルタイムクエリーなど、Firestore独自の機能をすべて使用することができます。冒頭の論文は、NativeモードのFirestoreを前提とした内容になります。

次回予告

　2023年に公開された論文「Firestore: The NoSQL Serverless Database for the Application Developer」に基づいて、Google Cloudで提供されるNoSQLデータベースサービス「Firestore」の特徴を紹介しました。次回は、Firestoreのデータモデルと、バックエンドのアーキテクチャーの全体像を紹介します。

Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡