このページでは、Cloud Run サービスの負荷テストを行い、本番環境での使用が正常にスケーリングできるかどうかを調べ、スケーリングを妨げるボトルネックを特定するためのベスト プラクティスについて説明します。
負荷テストの前に実施するテスト
負荷テストに進む前に、開発環境や小規模なテスト環境で同時実行の問題を特定して対処します。負荷テストを実施する前にコンテナの同時実行数を測定し、Cloud Run サービスが確実に稼働していることを確認します。
手動でスケーリングした環境でコンテナ数を少しずつ増やしてテストを行います。Cloud Run の手動スケーリングは、スケーリング値にインスタンスの最大数を設定することで概算できます。
コンテナ イメージを最近ビルドしたか、コンテナ イメージを最近変更したばかりの場合は、負荷テストを実施する前に単独でテストを行ってください。
また、大規模な負荷テストを実施する前に、過度のレイテンシや CPU 使用率などのパフォーマンス上の問題を確認しておく必要があります。
max instances を適切に使用する
Cloud Run では、サービスのスケーリングを制限する最大インスタンスが適用されます。インスタンスのデフォルトの最大数は 100 です。負荷テストがこのデフォルト値を超えることが予想される場合は、Google のアカウント担当者と連携して、新しい最大値を設定してください。アカウント担当者がわからない場合は、Google Cloud セールスにお問い合わせください。
選択できるインスタンスの最大数は、CPU の上限、メモリの上限、デプロイ先のリージョンによって異なります。
これらの上限は割り当て上限によって管理されていますが、この割り当て上限の引き上げを依頼することもできます。
リージョン us-central1 での負荷テスト
Google Cloud リージョン us-central1 には十分な割り当て上限が設定されているため、us-central1 で負荷テストを行うことをおすすめします。割り当ての上限に近付くことが予想される場合は、アカウント チームと協力して、テスト時間とスケールの詳細を記載したサポートケースを送信してください。
適切な CPU 使用率とサービス初期化プロファイルをテストする
サービスのテスト バージョンを Cloud Run にデプロイして直接テストを実施するのが理想的ですが、サービスのテスト バージョンをデプロイできない場合もあります。たとえば、Cloud Run サービスが、テスト環境で再現の難しい複雑なエコシステムの一部になっていることがあります。
このような場合は、CPU 使用量と初期化時間を比較できるシンプルなサービスでシミュレーションすることで、サービスのおおよそのパフォーマンスを把握できます。迅速なスケーリングには初期化時間が特に重要です。ただし、シンプルすぎるテストも問題です。たとえば、受信したリクエストを処理せずに返す単純な hello world サービスを使用したテストは避けてください。
テストハーネスを使用して負荷を生成する
JMeter などのテストハーネスを使用すると、制御下でトラフィックを急増させ、テスト負荷を生成できます。JMeter テストで JMeter スレッド グループの数とリクエスト間の遅延を使用して、負荷を高めることができます。
シンプルな HTTP リクエストを送信したり、JMeter を使用してブラウザ セッションを記録することもできます。Cloud Run では、デベロッパー認証を使用して、インターネットにアクセスせずにサービスをテストできます。これにより、JMeter などのテストハーネスからアクセスして、プロジェクトの Virtual Private Cloud に接続されている Compute Engine 仮想マシンで実行できるようになります。
レートと同時実行を制御できないツールで負荷を生成しないでください。Pub/Sub は、トラフィックのレートとクライアント数を制御できないため、負荷を生成するツールとしては適切ではありません。レートと同時実行がわからないと、テスト対象が明確になりません。
エクスポートされたログで詳細なログ分析を行う
トラフィックの急激な増加に対する Cloud Run サービスのレスポンスを把握するには、イベントを秒単位で分析する必要があります。モニタリング データの粒度では不十分なため、ログ分析が必要になります。ログを分析することで、レイテンシが長いリクエストの理由を調査することもできます。
ログを書き込むときに、Cloud Logging クライアント ライブラリを使用せずに stdout に直接書き込むことで、ロギングのパフォーマンスを向上させることができます。
テストを開始する前にログ エクスポートを設定するには、宛先の BigQuery と一致フィルタを含むログシンクを作成します。
resource.type="cloud_run_revision"
resource.labels.service_name="[your app]"
想定外のコールド スタートを避ける
ユーザーによるコールド スタートを最小限に抑えるには、インスタンスの最小数を 1 以上に設定します。
サービスが線形にスケールアウトされるようにする
さまざまな負荷でテストを繰り返して、Cloud Run サービスが負荷に応じて直線的にスケールアウトし、本番環境で想定される負荷よりも少ない負荷でボトルネックに達することがないことを確認します。
Colab で結果の分析と可視化を行う
モニタリングの概要のグラフを使用して結果の概要を把握すると、エクスポートしたログを使用した詳細なログ分析を補完できます。
モニタリング グラフは、次のことを調べる場合に役立ちます。
- 新しいインスタンスの作成と初期化がどの程度の速さで行われているか（秒単位）
- 異なるインスタンスへのリクエストがどの程度均等に分散されているか
- さまざまなパーセンタイルでのレイテンシを定常値までどれだけ迅速に引き下げられるか
BigQuery 用の Google Cloud コンソール ユーザー インターフェースを使用すると、エクスポートされたログスキーマをイントロスペクトして、結果をプレビューできます。BigQuery、Pandas、Matplotlab とすぐに統合できる Colab でクエリを実行し、結果をプロットします。Colab は、Seaborn などのリッチデータ可視化ツールとも簡単に統合できます。
ボトルネックを検出する
負荷テストは、非効率なコードとスケーリングのボトルネックの両方を見つけるのに役立ちます。非効率なコードがあると、より多くのトラフィックを処理する必要があるため、コスト増につながりますが、必ずしもスケーリングが妨げられるわけではありません。たとえば、テーブルレベルでロックされたデータベース変換に依存している場合は、一度に 1 つのトランザクションしか実行できないため、Cloud Run サービスのスケーリングを妨げるボトルネックになる可能性があります。
クライアント側のパフォーマンスを確認する
JMeter でキャプチャされたログ（クライアントで測定されたレイテンシを含む）に対してクエリを実行できます。ただし、JMeter などのサーバーテスト ツールは、ブラウザやモバイル クライアントと同じではないため、Selenium Webdriver などのブラウザベースのフレームワークや、モバイル クライアントのテスト用フレームワークでテストを実施することもできます。TLS 接続の初期化で、外れ値によって結果に歪みが生じる可能性があるため、過度の最大レイテンシには注意してください。
ベスト プラクティスの概要
負荷テストを実行して、Cloud Run への移行が適切な選択であり、サービスが想定される最大トラフィックにスケーリング可能かどうかを判断します。JMeter などのハーネスを使用してテストを実施します。詳細な分析を行うため、ログを BigQuery にエクスポートします。