コラム

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

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

CTC 教育サービス

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

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

はじめに

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

データベースのサイズとアクセス数

　第153回の記事では、論文執筆時点のデータとして、1ヶ月あたり、約400万個のプロダクションデータベースに対して、10億以上のクライアントからのアクセスがあることを紹介しました。特に、データベースのサイズやアクセス数には大きなばらつきがあると説明しましたが、図1は、これを示す実データになります。

fig01

図1 Firestoreで利用されるデータベースのサイズとアクセス数の分布（論文より抜粋）

　これは、過去28日間に実際にアクセスがあったすべてのデータベースに対して、データベースのサイズ、アクセス頻度（QPS）、リアルタイムクエリーの実行数の分布を示したものです。中央値を基準にした相対値になりますが、たとえば、データベースのサイズについては、中央値に対して、10^9以上もの大きさのデータベースが存在することなどがわかります。これまでに説明したように、Firestoreに保存したデータは、分散データベースのSpannerに保存されており、数千ノードの規模で分散保存することができます。このため、ペタバイトクラスのデータベースであっても性能に大きな影響を与えることなく利用できます。
　アクセス頻度（QPS）についても同様の大きなばらつきがありますが、ここでは、アクセス頻度の高い一部のデータベースが、他のデータベースの処理速度に悪影響を及ぼさないことが重要になります。そのため、Firestoreには、データベースごとにCPUの使用時間を公平に割り当てるなどの仕組みが用意されています。図2は、ベンチマーク用のテスト環境で、2つのワークロードを同時に稼働した場合に、CPU使用時間を公平に割り当てる仕組み（フェアCPUスケジューリング）をOn/Offした際に性能がどのように変化するかを示したものです。

fig02

図2 CPUスケジューリングの違いによる性能比較（論文より抜粋）

　ワークロードの1つは100QPSの単純なアクセスを繰り返すもので、もうひとつは、あえて不適切なインデックスを設定して、多くのCPU処理時間を要するアクセスを0QPSから500QPSまで増加させていきます。このベンチマーク環境では、500QPSが処理性能の最大値となります。オレンジ色と青色のグラフは、それぞれ、1つ目のワークロードについて、フェアCPUスケジューリングをOnにした場合とOffにした場合のレイテンシーの変化を表します。左右のグラフは、それぞれ、50パーセンタイルと99パーセンタイルの値を示しますが、いずれの場合も、フェアCPUスケジューリングがOffの場合（青色のグラフ）、あるタイミングで、1つ目のワークロードのレイテンシーが10,000倍近くまで増加しています。これは、CPUの処理時間が2つ目のワークロードに占有されたためと想像されます。フェアCPUスケジューリングをOnにすることで（オレンジ色のグラフ）、このような影響が抑えられていることがわかります。

アクセス頻度に対するスケーラビリティ

　図3は、アクセス頻度に対するスケーラビリティを検証するベンチマークの結果です。ここでは、YCSB-A、YCSB-Bと呼ばれる2種類のベンチマークを用いており、YCSB-Aは、ReadとWriteの比率が50:50で、YCSB-Bは、ReadとWriteの比率が95:5になります。それぞれ、QPSの増加に伴って、書き込み処理のレイテンシー（中央値）がどのように変化するかを示したものになります。

fig03

図3 アクセス頻度に対するスケーラビリティのベンチマーク結果（論文より抜粋）

　YCSB-Bについては、QPSの変化に伴うレイテンシーの変化はほとんどなく、Firestoreのスケーラビリティを示す結果になっています。一方、Writeの比率が高いYCSB-Aでは、QPSの増加に伴って、レイテンシーが増加する傾向があります。この点について、論文の中では、YCSBのベンチマークは、QPSの増加が速いことを理由としてあげています。Firestoreのデータを格納するSpannerは、データ量やアクセス数の変化に応じて、ノード数を自動的に増減するオートスケーリングの機能を備えていますが、変化が激しすぎるとオートスケーリングの効果が得られるまでに少し時間がかかる場合があります。このため、高いQPSでFirestoreを使用する場合は、最初から高い負荷をかけるのではんなく、一定の速さで負荷をあげていくことが推奨されています。

データ構造による性能の違い

　最後に、図4はFirestoreに保存するデータの構造によって、書き込み性能がどのように変化するかを調べたものです。

fig04

図4 データ構造による性能の違い（論文より抜粋）

　Firestoreに保存するドキュメントは、複数のフィールド（キー・バリューペア）の集合なので、ドキュメントのデータサイズが大きくなるのは、1つのバリューのサイズが大きくなる場合と、ドキュメントに含まれるフィールドの数が増える場合の2種類のパターンがあります。左のグラフは、1つのフィールドだけを持つドキュメントを追加しつづけた場合の書き込みのレイテンシーを示しており、バリューの値を10Kバイトから1Mバイトまで増加させた時の変化を示します。青色のグラフは中央値でオレンジ色のグラフは99パーセンタイルの値を示します。一方、右のグラフは、一定サイズのバリューを持つ多数のフィールドからなるドキュメントを追加しつづけた場合で、ドキュメントに含まれるフィールド数を1から500まで変化させています。左右のグラフを比較すると、書き込み処理のレイテンシーは、ドキュメントに含まれるフィールド数にはほとんど影響されず、1つのフィールドに格納されたバリューのサイズに依存することがわかります。

次回予告

　2023年に公開された論文「Firestore: The NoSQL Serverless Database for the Application Developer」に基づいて、Google Cloudで提供されるNoSQLデータベースサービス「Firestore」について、その処理性能に関するベンチマークデータを紹介しました。
　次回は、新しい話題として、サーバー内部のネットワーク処理速度に関する論文を紹介したいと思います。