負荷テスト

負荷テストを行い、構成の最適化やキャパシティの可視化が可能です。

LINEのプッシュ通知やテレビなどのメディア露出、メルマガ配信、SNSでの拡散など、ウェブサイトへアクセス集中する機会が増えています。

ウェブサービスは突発的なアクセス集中に弱いのが特徴です。アクセス集中に備えた設備を用意しておくとインフラ費用が高額になってしまいます。反対にインフラ費用を低額に抑えておくとアクセス集中に対応できません。

あらかじめ負荷テストを行うことで、キャパシティや拡張方式の把握をすることができ、アクセス集中に備えることが可能になります。

専用のシナリオを作成します

負荷をかけるための専用シナリオを作成します。ECサイトであれば、ログインを行い、商品詳細を選択し、その商品をカートに入れて決済を行う、というような一連の流れを負荷テストシナリオとします。複数ユーザーからのログインを想定したテストなどにも対応可能です。

大規模な負荷を掛けることが可能です

数千人規模のユーザーが同時にアクセスしてくることを想定したテストの実施が可能です。事前にヒアリングさせていただきご要望に応じてシナリオや規模を決めさせていただきます。

導入の流れ

流れ	概要
ヒアリング	お客様の問題についてヒアリングを行います
テスト計画作成	ヒアリングにもとづき、テスト計画およびテストシナリオを作成します
テスト環境構築	負荷テストツールおよびテスト環境の構築を行います
負荷テスト実施	シナリオに従い、負荷テストを実施します。テスト結果リソース情報およびログ情報を収集し、集計します。
ボトルネック調査	負荷テスト結果をもとに、ボトルネックの調査を行います。
チューニング	ボトルネックに対して、チューニングを行い、効果測定を行います。
報告書作成	負荷テスト・チューニング結果を報告書へまとめます。
報告会	報告書の内容をご報告します。

利用シチュエーション

解決したい課題

• システムが秒間どのくらいのPV数に耐えられるかを把握したい
• ボトルネックを把握し、インフラ増強のポイントを明らかにしたい

一定数のアクセスを想定したインフラを用意する事はよくあります。
そのような場合は、過去実績をもとにサイジングを行うことになります。しかしながら、稼働するシステムの負荷によって、対応可能なアクセス数は大きく変わってきてしまいます。

データベースサーバがボトルネックになっている場合、ウェブサーバをいくら増やしても問題は解決しません。
アクセス集中に対応するためには、ボトルネックを把握し、効果的な増強ポイントを知る必要があります。

解決方法

負荷テストを行い、スループットおよびボトルネックを把握します。

利点

• システムのキャパシティを定量的に把握することが可能です
• ボトルネックを把握することで、サーバの拡張計画を立てることができます
• ボトルネックをチューニングすることで、スループットの向上が期待できます

キャパシティを「スループット」という具体的な数字で表現できるようになります。スループットとは、秒間の受付可能なアクセス数（pv/秒)を表す指標です。

スループットが頭打ちになった原因をボトルネックといいます。ボトルネックを把握することで、次に拡張すべきことがわかるので、拡張計画を立てることが可能です。

ボトルネックを取り除くことができれば、スループットを向上させることが可能です。目標スループットがある場合は、チューニングを行いボトルネックを取り除き、目標スループットに近づけることが可能です。

注意点

• 本番環境とは別に負荷テスト環境を構築する必要があります
• テストデータの用意が必要です
• システムの改修も必要になる場合があります

負荷テストでは、システムの限界近い負荷をかける必要があります。そのため、本番環境に対して行うことはできません。本番環境をもとにして、負荷テスト用の環境を構築する必要があります。

システムの処理負荷はデータ件数に大きく依存することが多くあります。テスト用の環境に加えて、充分な量のテスト用データを用意することが重要です。

目標スループットがある場合は、ボトルネックのチューニングが必要になります。サーバ側のチューニングだけでは、目標スループットに達しない場合があります。特にデータベースサーバがボトルネックになってしまうと、取れる選択肢が限られてきてしまいます。そのような場合は、システムの改修が必要になる場合があります。