スケーラビリティ テストとは例で学ぶ

スケーラビリティテストとは何ですか?

スケーラビリティテスト スケーラビリティテストは、ユーザーリクエスト数を増減させた際のシステムまたはネットワークのパフォーマンスを測定する非機能テスト手法です。スケーラビリティテストの目的は、システムが予測されるユーザートラフィック、データ量、およびトランザクション頻度の増加に対応できることを確認することです。つまり、増大する需要に対応できるシステムの能力をテストします。

スケーラビリティテストは、 性能試験そのため、アプリケーションが大規模システムに展開されたとき、または過負荷状態で実行されたときの動作に焦点を当てています。 ソフトウエアエンジニアリングスケーラビリティテストは、アプリケーションがスケーリングを停止する時点を測定し、その原因を特定します。

スケーラビリティテストを行う理由とは？

容量の問題は、機能テスト中に発生することは稀です。それらは、年間で最も取引量の多い日、マーケティングキャンペーンの開始時、あるいは2年間静かに増加してきたデータセットが最終的にすべてのクエリを遅くするようになったときなどに顕在化します。スケーラビリティテストは、まず制御された環境でこれらの限界を明らかにします。具体的には、以下の点に役立ちます。

• ワークロードの増加に伴ってアプリケーションがどのようにスケーリングするか、そしてそのスケーリング曲線がどこで平坦になるかを判断する。
• 応答時間が許容範囲を超える前に、Webアプリケーションの同時接続ユーザー数の上限を決定してください。
• 負荷がかかった際のクライアント側の性能低下やエンドユーザーエクスペリエンス（画面レンダリングの遅延など）を特定する。
• CPU飽和、メモリリーク、接続プール枯渇など、サーバー側の堅牢性と劣化状況を判断する。

この関係は曲線でイメージするのが最も分かりやすいでしょう。処理能力は負荷の増加に伴って上昇しますが、リソースが飽和状態に達すると、追加のユーザーは待ち行列を長くするだけです。

スケーラビリティテストの種類

スケーラビリティは単一の特性ではないため、テスト計画では通常、複数の側面を網羅します。以下に挙げる4つのタイプは、ほとんどのチームが測定するものであり、最初の2つはテスト環境自体の構造を決定づけるものです。

垂直スケーリングは、アーキテクチャがほとんど変更されないためシンプルですが、単一のマシンには常に限界があります。水平スケーリングは、その限界を取り除き、耐障害性を向上させますが、ネットワーク遅延、データの一貫性、および調整オーバーヘッドが増大します。これらはすべて、テストで仮定するのではなく、測定する必要があります。

スケーラビリティテストでテストすべき内容

拡張性は、表示回数ではなく測定値に基づいて評価されます。最終的な数値だけでなく傾向を把握できるよう、各読み込みステップで以下の属性を記録してください。

スケーラビリティテストのためのテスト戦略

スケーラビリティ テストのテスト戦略は、テスト対象のアプリケーションの種類によって異なります。アプリケーションがアクセスする場合、 データベーステストパラメータには、ユーザー数に対するデータベースのサイズなどが含まれます。

スケーラビリティ テストの前提条件

• 負荷分散機能 負荷テストツールが、複数のマシンから負荷を生成し、中央制御ポイントから制御できるかどうかを確認してください。
• オペレーティングシステム — チェックする OS 負荷生成エージェントと負荷テストマスターは、以下の環境で実行されます。
• プロセッサ 仮想ユーザーエージェントと負荷テストマスターに必要なCPUの種類を確認してください。
• メモリ 仮想ユーザーエージェントと負荷テストマスターに必要なメモリ容量を確認してください。
• テスト環境 — 確認してください テスト環境 結果がそのまま適用できるほど、生産工程を十分に忠実に再現している。

スケーラビリティテストの実行方法

1. アプリケーションライフサイクル全体を通してスケーラビリティテストを実行するための、再現可能なプロセスを定義する。
2. スケーラビリティの基準を決定する
3. 負荷テストの実行に必要なソフトウェア ツールの候補リストを作成する
4. テスト環境を設定し、スケーラビリティ テストの実行に必要なハードウェアを構成する
5. テストシナリオとスケーラビリティテストを計画する
6. 仮想ユーザースクリプトを作成して検証する
7. 負荷テストのシナリオを作成して検証する
8. テストを実行する
9. 結果を評価する
10. 必要なレポートを生成する

スケーラビリティテスト計画

実際にテストを作成する前に、詳細なテスト計画を作成してください。これは、テストがアプリケーションの要件に適合していることを確認するための重要なステップです。

明確に定義された テスト計画 スケーラビリティテスト用。

• スクリプトの手順テストスクリプトには、ユーザーが実際に行う操作を正確に特定するための詳細な手順が含まれている必要があります。
• ランタイムデータテスト計画では、アプリケーションとのやり取りに必要な実行時データを特定する必要があります。
• データ駆動型テストスクリプトが実行時に様々なデータを必要とする場合、そのデータを必要とするすべてのフィールドを理解しておく必要があります。

スケーラビリティテストの例

季節限定セール期間中に2,000人の同時アクセスが見込まれるオンラインストアを例に考えてみましょう。チームはまず合格基準を定めます。それは、ユーザーの95%が3秒以内に決済を完了し、エラー率が1%未満であることです。

次に、テストでは同じ閲覧・検索・カート・チェックアウトのスクリプトを、仮想ユーザー数250、500、1,000、1,500、2,000で実行します。応答時間は、1,000ユーザーまでは2秒前後で推移し、1,500ユーザーでは2.8秒、2,000ユーザーでは9秒に達し、データベースのCPU使用率は98%になります。したがって、スケーラビリティの限界はおよそ1,500ユーザーであり、ボトルネックはチームが追加を計画していたアプリケーションサーバーではなく、データベース層であることがわかります。

スケーラビリティテストツール

スケーラビリティテストには、複数のマシンから同時に負荷を生成し、結果を一元的に報告できるツールが必要です。ツールの選択は通常、チームが使用する主要言語とテスト対象のプロトコルに基づいて行われます。

クラウドホスト型ランナーなど BlazeMeterLoadViewとGatling Enterpriseはこれらのエンジンのいくつかの上に構築されており、テストで数万人の仮想ユーザーや複数の地理的地域からのトラフィックが必要になった場合に検討する価値があります。このカテゴリのより広範な調査は、ガイドで入手​​できます。 パフォーマンステストツール.

スケーラビリティテストにおける課題とベストプラクティス

最も期待外れの拡張性結果 tracアプリケーションではなく、テスト環境の設定に立ち返ってみましょう。これらは繰り返し発生する問題であり、それらを未然に防ぐための習慣です。

共通の課題

• 狭小な環境 ―本番環境の半分のメモリを搭載したテスト環境では、本番環境では存在しないボトルネックが報告されている。
• 非現実的なワークロードモデル ― 思考時間やデータ変動のないスクリプトは、実際のユーザーが気づかないようなキャッシュにアクセスしてしまう。
• ノイズの多い結果 自動スケーリング、ガベージコレクション、および共有クラウドハードウェアにより、2つの同一の実行結果が異なる場合があります。
• 薄い観測可能性 サーバー側のメトリクスがない場合、処理速度が遅いということは何かが壊れたことはわかるが、何が壊れたのかはわからない。
• 費用 ―非常に高い同時実行性を実現するには、専用の負荷発生装置群が必要となるが、これは予算不足になりやすい。

ベストプラクティス

• 最初の実行前に、応答時間のパーセンタイル値やエラー率の上限値など、合格基準を合意しておく。
• 負荷を計画的な段階で増加させ、システムが安定するまで各段階を十分に長く維持する。
• キャッシュによって結果が歪められないように、仮想ユーザーごとにテストデータを変えてください。
• クライアント側の数値に加えて、アプリケーション、データベース、インフラストラクチャに関する指標も収集する。
• テストスクリプトはバージョン管理システムに保存し、ビルドごとに簡単なスケーラビリティチェックを実行し、リリース前にフルテストを実行する。
• 単一のレポートだけを単独で判断するのではなく、ビルド全体にわたる傾向を比較検討してください。

スケーラビリティテストと負荷テスト

両者は負荷をかけるため混同されがちですが、違いはそれぞれが答える質問にあります。スケーラビリティ テストはシステムがどれだけ成長できるかを問うのに対し、 負荷テスト 既に想定されている負荷に対応できるかどうかを問う。

両方とも下に座る 非機能テスト 傘の横に ストレス試験, スパイクテスト, 耐久試験 (NAIST) と ボリュームテストそして、成熟したパフォーマンス戦略では、通常、同じスクリプトに対して複数のテストを実行します。

よくあるご質問