グレンジ 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 splits と load-dased splits がありますが、
実際にどのタイミングでテーブルが分割されるかの保証はないとされています。
ただし、負荷試験の方法としては、
超実践 Cloud Spanner 設計講座 slide 20
Cloud Spanner の負荷試験を行う場合に、5分ではなく20〜30分の負荷試験をオススメします。その理由は、データの容量が多くなることにより、Split がより多く発生して、データが正常に全ノード間に分散されるからです。
とされているので、こちらに沿って検証していきます。
また、超実践 Cloud Spanner 設計講座 slide 20 にある
Google Cloud metrics #spannerの api/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回目
- データベースを新規作成
- テーブル作成
- 負荷試験実施
負荷試験実施後、
Stackdriver Monitoring で Cloud Spanner の Metric を確認します。
左図が 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 を確認します。
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 を確認します。
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 がウォームアップの一つの指標として参考になれば幸いです。