負荷テストタイプ

以下のテストタイプは、このガイドで前述した基本的な質問に基づいています。

アプリケーションはどのくらいの負荷に耐えられますか?

アプリケーションが耐えられる負荷を判断するテストをセットアップするときは、まず 1 秒あたりのリクエスト数 (req/s)、応答時間 (秒)、または同時ユーザー数のどれを測定するかを決定します。いずれの場合も、アプリケーションのどの部分をテストするかを決定します。

• サイトの閲覧は、複数のページやエンドポイントにアクセスしたり、リクエストごとに異なるパラメータを使用して単一のエンドポイントにデータをリクエストしたりすることで発生する負荷です。多くの場合、「Tools to use」のセクションで説明している基本的なツールを使用してテストを実行できます。キャッシュはアプリケーションの重要なコンポーネントであることが多いため、テストにキャッシュレイヤーを含めるかどうかを決定します。

• リクエストが相互に依存し、リクエスト間でデータを転送するチェックアウトなどのトランザクションワークフローをテストするには、より複雑なツールが必要です。また、マルチステップトランザクションではリクエストの測定値の関連性が限られているため、ツールによる個別のデータポイントとして出力する必要がある、トランザクション全体をカウントする方がより正確です。Apache JMeter および k6 ツールでは、これらのデータポイントを提供するように設定できます。

ターゲットシステムのパフォーマンスとエラー率の許容しきい値を定義します。システムによっては、イベントが正常に処理されている限り、応答時間を気にしなくて良い場合もあります。ユーザーインタラクションを伴うアプリケーションなど、多くのアプリケーションではエンドユーザーが許容できる範囲に制限を定義します。

多くの場合、段階的にテストを実行することが有用です。負荷は、定義したしきい値に達するまでステップごとに増加します。テストを繰り返す場合は、前のテストから学び、ステップを改善して実行するステップ数を減らすことで、有効な結果を得ることができます。

アプリケーションは X 負荷を処理できますか?

前のテストと同様に、このテストの負荷は、テストするアプリケーションの性質に応じて、1 秒あたりのリクエスト数または同時ユーザーとして定義できます。このテストは、前のテストを簡略化したものです。このテストの場合、特定のワークロードを送信し、システムがそれを処理できる必要があります。必要な負荷量の指定をサポートするテストツールを選択することが重要です。

テストを実行する時間も関係する場合があります。一部の影響は、長時間にわたるテストを実行した場合にのみ観察できます。例えば、バックプレッシャーによってキューが過負荷になる場合です。本番稼働用システムを複製して有効な結論を導き出したい場合、テストの実行に必要な時間が、テストシステムのサイズ設定に影響する可能性があります。

アプリケーションは自動的にスケールアップとスケールダウンを行いますか?

伸縮性はクラウドの主要なセールスポイントであり、コスト削減の主要因でもあります。伸縮性のメリットを確実に得られるように、アプリケーションが適切にスケーリングされているかをテストすることは、クラウドジャーニーの一環です。

スケールアップとスケールダウンに使用されるキーメトリクスを特定する必要があります。通常、これはターゲットシステムの CPU 負荷です。CPU 負荷を発生させるエンドポイントをターゲットとして使用できます。

このテストは表現可能性を必要としないため、副作用のないエンドポイントをターゲットにすることでメリットを得られます。蓄積される可能性のあるデータを保持するフローや、後続のプロセスを開始して不要なコストを発生させたり、負荷をブロックしたりするフローは開始しないようにします。

テストは段階的に行い、負荷を徐々に増やしていきます。各ステップでメトリクスがスケーリングを開始できるように、間隔を十分に長くする必要があります。例えば、5 分間で CPU 負荷が 70% を超えることをルールとして定めている場合は、スケーリングイベントが開始され実行されるまでの時間を確保するために、ステップを 5 分より長くする必要があります。また、スケーリングが機能し、作成した負荷状況が修正されたことを確認する必要もあります。

複数のサーバーでスケーリングテストを開始することを検討してください。小規模な環境では、スケールアップに時間がかかり、負荷に対応するために複数のサイクルが必要になる可能性があります。また、EC2 自動スケーリングクラスターのサイズは 2 倍にしかなりません。つまり、1 台のサーバーで負荷テストを開始した場合、最大の最初のスケーリングイベントは 2 台分のサーバーのみになります。生成される負荷に 3 台分のサーバーが必要な場合、2 つのスケーリングイベントが必要になり、20 分以上かかることがあります。

スケールアップイベントに必要なトリガーと、スケーリングが実際の負荷に適しているかどうかを監視します。

スケールダウンイベントを実装している場合は、これを段階的にテストすることもできます。スケールダウンが既存の負荷に適用可能で適切かどうかを監視し、すぐにスケールアップが再開されないことを確認します。

継続的な高負荷がかかっていると、アプリケーションの動作は経時的に低下しますか?

一部の影響は、長時間にわたって負荷が発生している場合にのみ観察できます。最も重大な影響の 1 つはバックプレッシャーです。つまり、システムが遅すぎて大量のリクエストを受信する速度で処理できない場合、クライアントシステムのパフォーマンスが低下します。

これは、低速のシステムが負荷ターゲットになっていると、より観察しやすくなります。複雑なセットアップでは、負荷テストの影響が伝播した場合にのみ、影響を観察できます。分散システム内の各サービス間の応答時間を可視化できる追跡ソリューションは、結果をすばやく表示できるだけでなく、ボトルネックとなっているシステムの特定にも役立ちます。ログファイルからメッセージ相関 ID を取得することで、ボトルネックシステムを特定できます。各リクエストは、負荷テストを受けたすべてのシステムで同じ ID を保持します。

相関 ID を使用すると、プラットフォーム内のさまざまなコンポーネントを経由する 1 つのメッセージの流れ全体を追跡できます。この情報を使用して、メッセージが通過する単一コンポーネントごとの処理時間を計算し (processing_time = departure_time – arrival_time)、最も遅いコンポーネントを特定できます。Zipkin、Jaeger、AWS X-Ray は、この分野の優れたソリューションです。

最も信頼性の高い結果を得るには、一定のリクエストレートを設定できるツールを選択します。つまり、ターゲットシステムの処理速度が低下している場合は、テストツールの同時実行性を高めて、1 秒あたりのリクエスト数を一定に保つ必要があります。システムの応答が遅くなり始めると、使用するスレッドの数が増え、負荷生成ツールのリクエストレートが低下します。リクエストレートが一定のツールでは、障害発生時に同時実行数を増やす必要があるため、障害を早期に発見できます。達成した 1 秒あたりのリクエスト数で速度低下を測定する代わりに、レイテンシーや失敗したリクエスト数で測定することになります。

アプリケーションは動作していますか?

通常は、高い負荷を発生させず、機能性を検証するリクエストを適度な数だけ作成します。テスト対象のフローに顧客がアクセスしていない場合は、本番環境に対してこれを定期的に行い、別の監視層を設けることもできます。

簡単な方法として、すでに負荷テスト用に作成済みのシナリオを、負荷を低く設定して本番環境で再利用することもできます。