性能評価の指標を合わせる方法
負荷テストで性能評価をする場合は、比較する指標をそろえる必要があります。JMeterでは、「秒間のリクエスト数」（スループット）を計測することが可能です。「1万ユーザーの同時アクセスに対応できること」というような性能要件を、「秒間のリクエスト数」に直して比較するようにしましょう。
カテゴリー: 負荷テストのすすめ方入門
アプリケーション含めたシステムの全体最適化をオススメする理由
アプリケーションとインフラのキャパシティ特性についてまとめました。
アプリケーションをデータ件数に依存しにくいものにすることで、ＡＷＳをはじめとしたクラウドのメリットを活かすことが可能です。反対にデータ件数に大きく依存している場合、再現なくインフラをスケールさせる必要がでてくるため、非常にコストパフォーマンスが悪いシステムになってしまいます。
応急処置としてのスケールアップやアウトは積極的に行うべきですが、恒久的にはアプリケーション含めたシステムの全体最適化を考えてみましょう。
月間PVからピークアクセスを想定する方法
負荷テストを行う時に、対象システムのピークアクセス数の想定をする必要があります。（想定）月間PVくらいのデータしかない場合に、パレートの法則（80:20の法則）を使って、ピークアクセス数を試算する方法を紹介します。
基礎データの取得
基礎データは、最短の平均応答速度のことです。
これを最初に取得しておくことで、「正常に負荷がかかっているか」「キャパシティの限界近い負荷をかけているのか」「チューニングの効果測定」の判断を行うことが可能になります。
手戻りを少なくするためにも必要な作業となりますので、必ず行っておきましょう。
低負荷テスト
基礎テストとは、低い負荷をかけてシステムのスループットが想定通りに向上していくかを調べることで、環境のセットアップの妥当性を確認するテストです。
いきなり大きな負荷をかけると時間もかかり、切り分けも複雑になるため、大きな手戻りが発生します。
新規に負荷テストを実施する場合は、必ず行うようにしましょう。
負荷テストのすすめかた入門
負荷テストのすすめかたをご紹介。負荷テストを実施するには、「目的設定」「現状調査」「負荷テスト設計」「負荷テスト準備」「負荷テスト実施」「結果分析」「結果報告」「チューニングを実施し効果測定」といった工程が必要です。各工程ごとに実施する内容や勘所について細かく解説します。
負荷テストの実施目的とは
負荷テスト実施の目的は様々です。「事前定義した性能要件を満たしていることを証明する」「ナレッジ不足の補填」「メディア露出対策」「LINEプッシュ通知対策」「限定セールのための性能向上」「季節的なアクセス増加の対応とインフラ運用」「高負荷時に発生した障害の原因特定」という事例をご紹介します。
高負荷障害の対策を目的にする時の注意点
「高負荷障害の再発防止」を目的とした負荷テストを検討する時は、「ボトルネックを〇個解消させる」「性能を〇倍まで引き上げる」などの行動指標を目標として、繰り返し改善をかけていくことが重要になります。
現状調査を円滑に進めるポイント
必要なログが残っており、適切な調査ができると、どのようなアクセスが発生し、どこかボトルネックになりそうかの当たりをつけることが可能です。インフラ的観点では「各種リソース状況」「アクセス状況」「各種ログ情報」を、システム的な観点では「システムの特性」「システム全体像」「データ件数や増加の推移」「アクセス状況」を確認します。
負荷テスト設計の勘所
負荷テスト設計を適切に行うことで、実施フェーズを円滑に進めることが可能です。逆に十分な設計ができていないと、問題が頻発し余計な工数をかけることになってしまいます。「負荷テストツールの選定」「負荷テスト環境」「シナリオ」「積み上げデータ」「利用データ」「負荷テスト用のシステム改修の有無」といった勘所を抑えた負荷テスト設計を行いましょう。
アプリケーション含めたシステムの全体最適化をオススメする理由
アプリケーションとインフラのキャパシティ特性についてまとめました。
アプリケーションをデータ件数に依存しにくいものにすることで、ＡＷＳをはじめとしたクラウドのメリットを活かすことが可能です。反対にデータ件数に大きく依存している場合、再現なくインフラをスケールさせる必要がでてくるため、非常にコストパフォーマンスが悪いシステムになってしまいます。
応急処置としてのスケールアップやアウトは積極的に行うべきですが、恒久的にはアプリケーション含めたシステムの全体最適化を考えてみましょう。
月間PVからピークアクセスを想定する方法
負荷テストを行う時に、対象システムのピークアクセス数の想定をする必要があります。（想定）月間PVくらいのデータしかない場合に、パレートの法則（80:20の法則）を使って、ピークアクセス数を試算する方法を紹介します。
基礎データの取得
基礎データは、最短の平均応答速度のことです。
これを最初に取得しておくことで、「正常に負荷がかかっているか」「キャパシティの限界近い負荷をかけているのか」「チューニングの効果測定」の判断を行うことが可能になります。
手戻りを少なくするためにも必要な作業となりますので、必ず行っておきましょう。
低負荷テスト
基礎テストとは、低い負荷をかけてシステムのスループットが想定通りに向上していくかを調べることで、環境のセットアップの妥当性を確認するテストです。
いきなり大きな負荷をかけると時間もかかり、切り分けも複雑になるため、大きな手戻りが発生します。
新規に負荷テストを実施する場合は、必ず行うようにしましょう。
負荷テストのすすめかた入門
負荷テストのすすめかたをご紹介。負荷テストを実施するには、「目的設定」「現状調査」「負荷テスト設計」「負荷テスト準備」「負荷テスト実施」「結果分析」「結果報告」「チューニングを実施し効果測定」といった工程が必要です。各工程ごとに実施する内容や勘所について細かく解説します。
負荷テストの実施目的とは
負荷テスト実施の目的は様々です。「事前定義した性能要件を満たしていることを証明する」「ナレッジ不足の補填」「メディア露出対策」「LINEプッシュ通知対策」「限定セールのための性能向上」「季節的なアクセス増加の対応とインフラ運用」「高負荷時に発生した障害の原因特定」という事例をご紹介します。
高負荷障害の対策を目的にする時の注意点
「高負荷障害の再発防止」を目的とした負荷テストを検討する時は、「ボトルネックを〇個解消させる」「性能を〇倍まで引き上げる」などの行動指標を目標として、繰り返し改善をかけていくことが重要になります。
現状調査を円滑に進めるポイント
必要なログが残っており、適切な調査ができると、どのようなアクセスが発生し、どこかボトルネックになりそうかの当たりをつけることが可能です。インフラ的観点では「各種リソース状況」「アクセス状況」「各種ログ情報」を、システム的な観点では「システムの特性」「システム全体像」「データ件数や増加の推移」「アクセス状況」を確認します。
負荷テスト設計の勘所
負荷テスト設計を適切に行うことで、実施フェーズを円滑に進めることが可能です。逆に十分な設計ができていないと、問題が頻発し余計な工数をかけることになってしまいます。「負荷テストツールの選定」「負荷テスト環境」「シナリオ」「積み上げデータ」「利用データ」「負荷テスト用のシステム改修の有無」といった勘所を抑えた負荷テスト設計を行いましょう。