Loading article…
スケーラビリティ テストは、ソフトウェア アプリケーションの非機能的な能力に関して スケールアップまたはスケールアウトする能力を測定するためのテストです。
パフォーマンス、スケーラビリティ、信頼性のテストは、通常、ソフトウェア品質アナリストによってグループ化されます。
スケーラビリティテストの主な目的は、Webアプリケーションのユーザー制限を決定し、高負荷状態でもエンドユーザーのエクスペリエンスが損なわれないようにすることです。1つの例は、応答の遅延を最小限に抑えてWebページにタイムリーにアクセスできるかどうかです。もう1つの目的は、サーバーが対応できるかどうかを確認することです。つまり、高負荷時にサーバーがクラッシュするかどうかです。[1]
テスト対象のアプリケーションに応じて、さまざまなパラメータがテストされます。Webページをテストする場合は、可能な限り多くの同時ユーザーがテストされます。[2]また、テスト対象のアプリケーションに応じて、テストされる属性も異なります。これには、CPU使用率、ネットワーク使用率、ユーザーエクスペリエンスなどが含まれます。
テストが成功すれば、ネットワーク、データベース、ハードウェア/ソフトウェアに関連する問題のほとんどを特定できます。[3]
スケーラビリティテストの作成
新しいアプリケーションを作成する場合、1 年、2 年、さらには 5 年後のユーザー数を正確に予測することは困難です。推定はできますが、正確な数ではありません。ユーザー数の増加に伴う問題は、新しい障害領域が発生する可能性があることです。たとえば、10 万人の新しい訪問者がいる場合、問題になるのはアプリケーションへのアクセスだけではありません。これらの新しい顧客のすべてのデータを保存する必要があるデータベースにも問題が発生する可能性があります。[4]
負荷の増加
このため、スケーラビリティ テストを作成するときは、段階的にスケールアップすることが重要です。これらのステップは、小負荷、中負荷、高負荷に分割できます。
各段階で異なる側面をテストするため、段階的にスケールアップする必要があります。小さな負荷では、システムが基本レベルで正常に機能することを確認します。中程度の負荷では、システムが期待どおりに機能するかどうかをテストします。高負荷では、システムが高負荷に対応できるかどうかをテストします。[5]
テスト環境
正確で信頼性の高い結果を得るためには、テスト中は環境を一定に保つ必要があります。テストが成功すれば、パフォーマンスに比例した変化が見られるはずです。たとえば、システムのユーザー数が倍になると、パフォーマンスは50%低下するはずです。[6]
あるいは、メモリや CPU の使用率などのシステム統計を時間の経過に沿って測定する場合、どちらの軸にもユーザーがプロットされていないため、比例しない異なるグラフが表示されることがあります。
スケーラビリティテストの結果
すべての段階のデータが収集されると、分析対象の特定の変数とメトリックに合わせて調整されたさまざまなグラフを使用して結果をプロットすることができます。選択するグラフの種類は、データの性質と分析の目的によって異なります。
不均衡な結果
図1では、時間の経過に伴うリソース使用量（この場合はメモリ）を示すグラフを見ることができます。グラフは比例的ではありませんが、システムが稼働し始めると最初は増加段階があり、ユーザーが追加されてもメモリ使用量にほとんど変化がないため、テストに合格したと見なすことができます。[7]これは、現在のメモリ容量がテストの3つの段階すべてに対応できることを意味します。
比例的結果
図2では、ユーザー数とレポート実行にかかる時間を比較すると、より比例した増加が見られます。低負荷の20ユーザーでは平均時間は5.5秒ですが、負荷を中負荷（40ユーザー）と高負荷（60ユーザー）に増やすと、平均時間はそれぞれ9.5秒と18秒に増加します。[6]
場合によっては、サーバーのソフトウェアやハードウェアに変更を加える必要があるかもしれません。必要なアップグレードが完了したら、テストを再実行して、アップグレードが以前に提起された問題に効果的に対処することを確認する必要があります。[8]
比例的な結果が得られれば、規模を拡大してシステムにかかる負荷を増やしてもボトルネックは発生しません。[9]
垂直および水平スケーリング
スケーラビリティ テストの結果、ソフトウェアとハードウェアのアップグレードが必要になる場合があります。これらのアップグレードは、垂直スケーリングと水平スケーリングに分けられます。
垂直スケーリングは、スケールアップとも呼ばれ、コンポーネントを、一般的にはより強力または改良されたデバイスに置き換えるプロセスです。たとえば、プロセッサをより高速なものに置き換えるなどです。水平スケーリングは、スケールアウトとも呼ばれ、たとえば別のサーバーを元のサーバーと並行して実行して、ワークロードを共有するようにセットアップすることです。[10]
利点と欠点
どちらのスケーリング方法にも長所と短所があります。スケールアップの方が簡単かもしれませんが、ハードウェアリソースの追加により収益が減少する可能性があります。[11]つまり、たとえばプロセッサをアップグレードするたびに、前回の変更と同じレベルのメリットが得られるとは限りません。
しかし、水平スケーリングは非常に高価になる可能性があり、サーバーなどのシステム全体のコストだけでなく、定期的なメンテナンスコストも考慮する必要があります。[11]
参考文献
- ^ 「負荷テストの計画」。docs.oracle.com 。2015年10月23日閲覧。
- ^ 「スケーラビリティ テスト」 。パフォーマンス ブログ。2015 年 10 月 25 日閲覧。
- ^ Joshi, Prateek. 「なぜパフォーマンステストが必要なのか?」Perpetual Enigma . 2015 年 10 月 25 日閲覧。
- ^ 「スケーラビリティ テストに適したメトリックの発見」www.theserverside.com 。2015年 10 月 25 日閲覧。
- ^ 'Cytowski' 'Bernardini'、'Maciej' 'Matteo' (2013)。「Prac Scalability Analysis」(PDF)。欧州先進コンピューティングパートナーシップ。
- ^ ab 「IBM Cognos Proven Practices: IBM Cognos BI の成功するパフォーマンスおよびスケーラビリティー テストの設計」www.ibm.com。2011 年 11 月 17 日。2015年 10 月 25 日閲覧。
- ^ 「エンタープライズ パフォーマンスとテスト結果」(PDF)。Serena 。2011年。
- ^ 「スケーラビリティ テスト: サイトのパフォーマンスをスケールアップできるかどうかを確認する」。support.smartbear.com。2015年 10 月 28 日閲覧。
- ^ 「Netflix 技術ブログ: AWS での Cassandra のスケーラビリティのベンチマーク - 1 秒あたり 100 万回以上の書き込み」。techblog.netflix.com。2015年11 月 4 日閲覧。
- ^ Bondi, André (2014).ソフトウェアおよびシステムパフォーマンスエンジニアリングの基礎: プロセス、パフォーマンスモデリング、要件、テスト、スケーラビリティ、および実践。セクション11.2。ISBN 0321833821。
- ^ ab 「スケーラビリティテスト」(PDF)。Comp Nus Education。
外部リンク
- Visual Studio .NET を使用した分散アプリケーションの設計: スケーラビリティ