コンテンツに移動
データベース

Key-Value ワークロードでの Spanner のコスト パフォーマンスをベンチマークする

2024年1月10日
Google Cloud Japan Team

※この投稿は米国時間 2023 年 12 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。

企業同士がしのぎを削っている今日、コストは重要な成功要因のひとつです。Spanner は、リレーショナル ワークロードと非リレーショナル ワークロードの両方に適した Google のフルマネージドのデータベース サービスで、グローバル レベルの強整合性と、事実上の無制限スケーリングで高性能を実現し、最大 99.999% の可用性 SLA を維持します。Spanner は膨大なワークロードに対応できる汎用性の高いデータベースで、世界で広く利用されている製品にも採用されています。また、先ごろ Spanner のコスト パフォーマンスが大幅に改善され、ノードあたりのスループットとストレージが向上し、より手頃な価格で利用できるようになりました。

このブログ投稿では、業界標準の Yahoo! Cloud Serving Benchmark(YCSB)ベンチマークを使用して、このようなワークロードのサブセットである Key-Value ワークロードのベンチマークを行う方法をご紹介します。YCSB は、異なるデータベース間で Key-Value ワークロードのパフォーマンスの評価と比較を行うオープンソースのベンチマーク スイートです。多くの場合、Spanner はリレーショナル ワークロードで使用されますが、Key-Value ワークロードも業界をリードする企業では一般的に使用されています。

結果の概要

最近行われたコスト パフォーマンスの改善が功を奏し、システム全体のコストを変えずにノードあたりのスループットが最大 50% 向上しました。リージョン構成で推奨される CPU 使用率で実行した場合、ミリ秒単位のレイテンシでこのスループットを提供します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1-spoiler_alert.max-2200x2200.png

このことを踏まえ、上述の結果を導き出すために使用した YCSB ベンチマークの設定について、さらに掘り下げていきましょう。

方法

Spanner で YCSB ベンチマークを使用し、以下のベンチマークを実行しました。

ワークロードの特性

ベンチマークで典型的な本番環境ワークロードを模倣します。そのために、次のような特性を選びました。

  • ステイルネスの読み取り: 「ステイル / スナップショット」読み取りではなく、「整合性のある / 強力な」読み取りに基づいて読み取りワークロードの比較を行います。
  • 読み取り / 書き込みの比率: 評価は 100% 読み取りのみのワークロードと、80 対 20 の比率での読み取り / 書き込みワークロードで行いました。
  • データの分散: より実世界に近いシナリオを表すジップ(Zipf)分布をベンチマークに使用しています。
  • データセットのサイズ: このベンチマークには、1TB のワークロード データセット サイズを使用しました。これにより、ほとんどのリクエストはメモリから提供されずに済みます。
  • インスタンスの構成: リージョン インスタンスの 3 ノード Spanner インスタンスを使用しました。
  • CPU 使用率: 今回は 2 つのベンチマークをご紹介します。1 つ目のセットは、レイテンシの影響を受けやすいワークロードを安全にフェイルオーバーするために推奨されている 65% の CPU 使用率で実行し、2 つ目のセットでは、Spanner のスループットを最大化するためにほぼ 100% の CPU 使用率で実行しました。CPU 使用率 100% 時のパフォーマンス値は、一般公開ドキュメントにも公開されています。
  • クライアント VM: クライアント VM のホストには、Spanner インスタンスと同じリージョンに配置される Google Compute Engine を使用しました。

コスト パフォーマンス指標

コストの見積もりを簡素化するため、「Dollars per kQPS-Hr.」という正規化された指標を採用します。端的に言うと、これは特定のワークロードに対して 1k QPS を維持するための 1 時間あたりの費用です。

料金

Spanner のコストはお客様がプロビジョニングするコンピューティングの量によって決まります。たとえば、us-east4 での単一ノードのリージョン インスタンスは 1 時間あたり 0.99 ドルです。今回ご紹介する結果では、Spanner ノードのコストに長期的な確約利用の割引(例: 確約利用割引)は一切ないものとします。これらはノードあたりのコストを下げる割引であるため、適用すると実際のコスト パフォーマンスを正確にとらえられないためです。Spanner の料金について詳しくは、公式料金ページをご覧ください。

また、QPS が「1,000」増加するたびにコストを測定するため、わかりやすいように料金計算からストレージ費用を除外しています。

結果

推奨 CPU 使用率でのベンチマーク

以下の結果は、ノードあたりのスループットが約 50% 向上したことによる、さまざまなワークロードで実現したコスト削減を示しています。

ベンチマーク 1: 100% 読み取り

YCSB 構成: recommended_utilization_benchmarks フォルダにある Workloadc.yaml 構成を使用しました。

Spanner の指標を導き出す: 1TB のデータをプリロードした 3 ノード Spanner インスタンスは、推奨される 65% の CPU 使用率で 37,500 QPS のスループットを生成しました。これは Spanner ノードあたり 12,500 QPS に相当します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2-benchmark1-100reads.max-1200x1200.png

Spanner で 1,000 QPS の読み取りを 1 時間維持するのにかかる費用は、わずか 7.9 セントになりました。

https://storage.googleapis.com/gweb-cloudblog-publish/images/3-Dollar_kqps_hr-chart.max-1200x1200.png

ベンチマーク 2: 80% 読み取りと 20% 書き込み

YCSB 構成: recommended_utilization_benchmarks フォルダにある ReadWrite_80_20.yaml 構成を使用しました。

Spanner の指標を導き出す: 1TB のデータをプリロードした 3 ノード Spanner インスタンスは、推奨される 65% の CPU 使用率で 15,600 QPS のスループットを生成しました。これは Spanner ノードあたり 5,200 QPS に相当します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/4-Benchmark2-80read-20Write.max-1200x1200.png

Spanner で 1,000 QPS の読み取りと書き込みを 80 対 20 の割合で 1 時間維持するのにかかる費用は、わずか 19 セントになりました。

https://storage.googleapis.com/gweb-cloudblog-publish/images/5-Dollar_kQPS_hr-chart.max-1200x1200.png

ほぼ 100% の CPU 使用率でのベンチマーク

ベンチマーク 1: 100% 読み取り

YCSB 構成: throughput_benchmarks フォルダにある Workloadc.yaml 構成を使用しました。

Spanner の指標を導き出す: 1TB のデータをプリロードした 3 ノード Spanner インスタンスは、ほぼ 100% の CPU 使用率で 67,500 QPS のスループットを生成しました。これは Spanner ノードあたり 22,500 QPS に相当します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/6-Benchmark1-100Reads.max-1200x1200.png

CPU 使用率が 100% に近い状態の Spanner で 1,000 QPS の読み取りを 1 時間維持するのにかかる費用は、わずか 4.4 セントになりました。

https://storage.googleapis.com/gweb-cloudblog-publish/images/7-Dollar_kQPS_hr-chart.max-1200x1200.png

ベンチマーク 2: 80% 読み取りと 20% 書き込み

YCSB 構成: throughput_benchmarks フォルダにある ReadWrite_80_20.yaml 構成を使用しました。

Spanner の指標を導き出す: 1TB のデータをプリロードした 3 ノード Spanner インスタンスは、ほぼ 100% の CPU 使用率で 35,400 QPS のスループットを生成しました。これは Spanner ノードあたり 11,800 QPS に相当します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/8-Benchmark2-80Read-20Write.max-1200x1200.png

CPU 使用率が 100% に近い状態の Spanner で 1,000 QPS の読み取りと書き込みを 80 対 20 の割合で 1 時間維持するのにかかる費用は、わずか 8.3 セントになりました。

https://storage.googleapis.com/gweb-cloudblog-publish/images/9-Dollar_kQPS_hr-chart.max-1200x1200.png

実際の結果は異なる場合があります

ベンチマークの結果は、リージョン構成によって若干異なる可能性があることにご留意ください。たとえば、推奨使用率のベンチマークでは、テストの QPS が固定されているため、CPU 使用率が推奨目標値である 65% からわずかに異なる場合があります。ただし、これによるレイテンシへの影響はありません。

CPU 使用率 100% のベンチマークは、Spanner のおおよその理論上の制限値を表しています。実際のスループットは、システムタスクなど多くの要因によって変化します。

まとめ

Google Cloud ではコスト効率の重要性を認識し、今後もパフォーマンスの向上に取り組んでまいります。私たちは、お客様に高い性能、ほぼ無限のスケーラビリティ、高可用性を実現するデータベースを提供したいと考えています。このたびの Spanner のコスト パフォーマンスの改善により、スループットの向上とコスト削減を実現していただけるはずです。これらの改善は、すべての Spanner のお客様にご利用いただけます。再プロビジョニングやユーザー操作の必要はなく、ダウンタイムの発生もありません。

Spanner の詳細とお客様がどのように Spanner を使用しているかについてご確認ください。または、90 日間無料で、あるいは月額わずか 65 ドルで、ビジネスの成長に合わせて拡張できる本番環境対応のインスタンスを実際にお試しください。

- シニア ソフトウェア エンジニア Suraj Pasuparthy

- スタッフ ソフトウェア エンジニア Lokesh Agarwal

投稿先