LoginSignup
4

More than 3 years have passed since last update.

ほんま正直、Cloud Spannerのウォームアップの指標、真剣に検証しました。そこに関して何の嘘もありません。包み隠さず全て話します。

Posted at

グレンジ Advent Calendar 2019 をやるんですね、
正直、めちゃくちゃ悩みました。そしてほんまに真剣に、真剣に検証を重ねて気づいたんです。
Cloud Spanner、感動しました。そこに関して何の嘘もありません。
その強さ、がどこから来たのか…

包み隠さず全て話します。

Cloud Spanner ウォームアップの重要性

ノード

Cloud Spanner は、全体の CPU 使用率を 65% 以下 に抑えるため、十分な数の Cloud Spanner ノードのプロビジョニングが必要になります。
コールド状態の Cloud Spanner は、事前にウォームアップしておかないと、リリースに必要なノードが提供されません。

データベースのスプリット

スプリットは、Cloud Spanner でのデータの単位です。
Cloud Spanner は複数のノードをフル活用するためにテーブルを自動的に Split に分割します。

スプリットは、以下の条件で分割されます。

  • Size-dased splits
    • データサイズによる分割
    • 数GB程度でテーブルをスプリット
  • load-dased splits
    • 負荷による分割
    • 分散できる負荷でスプリット

十分なスプリットが作成されることで Cloud Spanner の全ノードが活用され、
Cloud Spanner の最大のパフォーマンスを得られます。

負荷試験、リリース前には、Cloud Spanner をウォームアップし、十分なスプリットを作成する必要があります。

Cloud Spanner ウォームアップの指標

スプリットの条件は、 Size-dased splitsload-dased splits がありますが、
実際にどのタイミングでテーブルが分割されるかの保証はないとされています。

ただし、負荷試験の方法としては、
超実践 Cloud Spanner 設計講座 slide 20

Cloud Spanner の負荷試験を行う場合に、5分ではなく20〜30分の負荷試験をオススメします。その理由は、データの容量が多くなることにより、Split がより多く発生して、データが正常に全ノード間に分散されるからです。

とされているので、こちらに沿って検証していきます。

また、超実践 Cloud Spanner 設計講座 slide 20 にある
Google Cloud metrics #spannerapi/api_request_count に注目します。

Cloud Spanner ウォームアップの検証

負荷試験ツールは locust を使用します。

負荷試験の条件は以下です。

  • 負荷試験の一回の実施時間は30分
  • 秒間 2000〜30000 requests
  • Cloud Spanner ノード数は同一

参考にする Cloud Spanner の Metric は、

  • API request rate
    • api/api_request_count
  • Request latencies
    • api/request_latencies

負荷試験シナリオ構成

  • 負荷試験のシナリオの前半に高負荷のAPIが実行されます
  • 負荷試験のシナリオはランダムに実行されます

負荷試験 1回目

  1. データベースを新規作成
  2. テーブル作成
  3. 負荷試験実施

負荷試験実施後、
Stackdriver Monitoring で Cloud Spanner の Metric を確認します。

image.png

左図が API request rate、右図が Request latencies p99 です。

API request rate のグラフをみると、5:27 ごろまで安定せず、5:30 を超えたあたりから安定しました。
5:27 ごろまでは、超実践 Cloud Spanner 設計講座 slide 20 の通り、スプリットを作成していて、5:30を超えるとスプリットの作成が終わり、安定しているようにみえます。

Request latencies p99 のグラフでも 5:27 ごろまでのレイテンシは安定せず、5:30 を超えたあたりから安定してきました。
5:27 ごろまでのExecuteStreamingSql、Commitは数秒かかるものがありましたが、
5:30 を超えたあたりから ExecuteStreamingSql が 30 ms、Commit が 10〜13 ms と安定しました。

負荷試験 2回目

Stackdriver Monitoring で Cloud Spanner の Metric を確認します。

image.png

API request rate のグラフを 1回目と比較をすると前半(6:15 ごろまで)のグラフが1回目と比較すると、緩やかであることがわかります。

Request latencies p99 のグラフについては、
Request latencies p99 のグラフでも 6:15 ごろまでのレイテンシは安定しませんが、1回目で数秒かかっていたのが、数ミリ秒になっているのが確認できます。
その後は、ExecuteStreamingSql が 30 ms、Commit が 10〜15 ms と安定しました。

負荷試験 3回目

Stackdriver Monitoring で Cloud Spanner の Metric を確認します。

image.png

API request rate のグラフは、2回目と大差ないことが確認できます。
Request latencies p99 のグラフは、ExecuteStreamingSql が 30 ms、Commit が 10〜13 ms と安定しています。

負荷試験の結果から

負荷試験 1回目の API request rate のグラフ に着目すると、安定したグラフになってから、
Request latencies p99 が 1回目、2回目、3回目とほぼ大差ないレイテンシになっています。
1回目の API request rate のグラフが安定したころから Cloud Spanner のウォームアップが完了したと考えても問題なさそうに思います。

負荷試験の2回目と、3回目の Request latencies p99 のグラフに差異が見られますが、
アプリケーションのp99のレイテンシを比較したところ大きな差異が見られなかったので、負荷試験シナリオのランダム性の偏りによるものと考えます。

Cloud Spanner ウォームアップの指標

Cloud Spanner ウォームアップの仕方は各社様々あると思いますが、
Stackdriver Monitoring で確認できる、 Cloud Spanner の Metric API request rate がウォームアップの一つの指標として参考になれば幸いです。:rose:

参考

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4