
一般的な負荷テストは専用ツールを使用し、Webコンテンツに対して擬似的に大量アクセスをかけ、反応を検証します。ソーシャルアプリの多くは、ブラウザ等のインターフェースを使用しないため、Flashアプリケーション上で特定の動作、機能に対する負荷をかけることが出来ません。
弊社では 、専用ブラウザ と クラウド環境( Amazon EC2 ) を使用し負荷テストを実現させています。 負荷テスト時には、各プラットフォーマー様のサーバーはサービスに影響が出るため使用できません。そのため、本検証サービスではプラットフォームを経由しない方法にて負荷テストを実現させています。事前に決められたアプリケーション内での一連の動作を、専用ブラウザ上で自動化したシナリオを用います。
サービス公開時の実際のアクセス状況に類似した「waitユーザー90%、activeユーザー10%」 にて 負荷テストを行い、負荷状況を作り出し接続ユーザー数の限界、サーバー側のリソース状況の確認を行う事が出来ます。
※ブラウザ等のインターフェースを使用しない。
そのため、Flashアプリケーション上で特定の動作、機能に対する負荷をかけることが出来ない。
通常のソーシャルアプリでは、ユーザーがアプリにアクセスをするとプラットフォームを経由してアプリサーバーに 接続をします。アプリでの情報(ユーザーのデータ等)はプラットフォーマー様のAPIサーバーに接続をして取得をする仕組みとなっています。
Flash等のリッチコンテンツで構成されるソーシャルアプリではページ遷移はせず、同一のページ(URL)上で
ゲームが進行するため、通常の負荷テストツールでは評価することが出来ません。
そこで、専用の検証が必要となります。
弊社では 、専用ブラウザとクラウド環境( Amazon EC2 )を使用し負荷テストを実現させています。
activeユーザー
対象アプリケーションとインフラが、決められたユーザー数に耐える事が出来るか評価をします。事前に決められたシナリオに沿って常に動き続けます。また、シナリオ内の事前に定められたチェックポイントの時間を計測します。
waitユーザー
ログインをした後は何も動作せず待機をしています。同時接続数を確認し、決められたユーザー数に到達出来るかを確認します。
今現在のサービス内容として、下記の通りの検証を提供しています。
『waitユーザー90%、activeユーザー10%』
『activeユーザー100%』
『 waitユーザー90%、activeユーザー10% 』
フラッシュのアプリであればログイン状態を維持する事でサーバーと通信が発生するため、サーバーへの負荷は発生します。アプリに接続している1000ユーザーが接続している場合でも、全ユーザーが何かしらの動作をしているわけではないため、アクティブ:ウェイトが1:9の割合で仮想ユーザーを動作させる事で、実際のアクセス状況に近づける事が出来ると想定しています。
『 activeユーザー100% 』
モバイルアプリ、アプリの演出部分のみFlashの場合等、限定的に使用されている場合におすすめです。
上記の事から、 『waitユーザー90%、activeユーザー10%』 にて負荷テストを行う事でサービス公開時の実際のアクセス状況に類似した負荷状況を作り出し接続ユーザー数の限界、サーバー側のリソース状況の確認を行う事が出来ます。
事前 | ユーザー数の確定 シナリオ作成に必要な情報、アプリへのアクセス情報を頂く |
3営業日 | シナリオ作成 アプリの内容確認を行い、事前に頂いている情報でシナリオ動作可能かどうか等の確認作業含む |
前日 | 事前テスト実施 本番のテストを実施する前に、クラウド環境にてシナリオが問題なく動作するかその他問題がおきないか等をチェックするために事前テストを実施します。 |
当日 | 負荷テスト実施 仮想ユーザーは、決められたユーザー数で同時にアクセスするのではなく、徐々にアクセスしていきます。例えば、1000ユーザーにて負荷テストを行う場合、200ずつアクセスしていく様な流れです。テスト時間は基本6時間以内です。 |
負荷テスト後に各動作のレスポンスタイムをまとめ、レポートを提出致します。