ECプラットフォーム提供会社
自社ECサイトプラットフォームの導入を行なっているA社は稼働中のECサイトをオンプレミスサーバーからクラウドサービスへ移行することになり、移行先環境が現行オンプレ環境と同等の性能を維持できているか試験することになった。
1.オンプレ環境でレスポンスを正常に返すことができる限界値の算出
2.移行先クラウド環境にてレスポンスを正常に返すことができる限界値の算出
3.移行先クラウド環境でオートスケールを設定し、想定を超えるアクセスがあった時の状況をモニタリング
試験実施期間は4週間とし、合計120分の負荷リクエストを実行、シナリオは当社エンジニアがヒアリングの元作成。
最大仮想ユーザー数は1,000人/秒、オンプレ環境と移行先クラウド環境それぞれを対象に深夜にテスト実施。
お客様指定のフォーマットによるレポート作成。
1.と2.の試験結果を比較し、クラウドサービスの特定のURLにおいて性能が大きく劣化することが判明した。（後日の調査でクラウド移行時にデータベースのインデックス作成の問題と判明）また、OS設定の不足がありチューニングすることで予定通りの構成で、オンプレ環境の1.5倍の性能を出すことができた。
オートスケールはスケールアウトするまでに想定以上の時間がかかることが判明したため、負荷が上がると想定される時間はあらかじめインスタンスを増やしておくことになった。
大手小売店
試験費用合計：22万円
全国に店舗を展開する大手小売店はキャンペーンによりクーポンチケットを配布することとなった。キャンペーン期間は数日だが、相当規模の瞬間アクセスが見込まれたため、LPが秒間10,000リクエストを処理できることを事前検証することとなった。
1.秒間10,000リクエストという大量トラフィックを処理可能か検証する
試験実施期間は3日とし、合計30分の負荷リクエストを実行、シナリオは当社エンジニアがヒアリングの元作成。
最大仮想ユーザー数は10,000人/秒、管理画面をお客様エンジニアに公開し、リアルタイムでサーバーの状況をモニタリングしながらテスト実施。
お客様で直接状況を確認しているためレポート作成は行わない。
負荷リクエストを実行したところ、エラーは発生しないものの秒間数千リクエストでレスポンスが極端に遅くなりクライアント側でタイムアウトが発生することが確認できた。
サーバー側の性能チューニングでは改善できず、回線のネットワークが限界であることが判明したため、一部の静的リソースをCDNに配置し、トラフィック分散を図ることで徐々に処理できるリクエスト数を増やすことができた。
また、サーバー自体も当初想定の3倍以上に増やすことで目標を達成できた。
行政サイト
試験費用合計：160万円
公開済み行政サイトのアクセスが増えることが見込まれ、CDN導入後の処理性能を検証した。
既存システムへの変更が難しいため同一構成のサイトを構築しCDNを導入することで本番環境との比較を行った。
CDNを導入した場合の処理性能を検証する。
利用者影響のない深夜帯に本番環境に対して10,000ユーザーの同時アクセスを行い、性能を測定した。合わせて本番環境と同一の構成ファイルを検証環境に展開し、CDNを導入して同じ負荷リクエストを実行した。システム利用料、検証環境構築、シナリオ作成、レポート作成、負荷テストの実施代行など一式を作業を実施。
本番環境への負荷テスト結果より、毎秒1,000リクエストを超えたあたりからレスポンスの遅延が顕著となった。ただし、静的ファイルを中心に構成されたサイトのため、サーバーが応答を返せなくなったりエラーは発生しなかった。 CDNを適用した検証環境は最大で毎秒6,000リクエストを程度を処理することができた。またレスポンスの大幅な遅延も発生しなかった。大量アクセスが発生したときにCDNが有効であることが検証結果より明らかになった。
食品メーカーキャンペーンサイト
試験費用合計：12万円
商品ラベル記載の応募サイトより、シリアルコードを入力して当選するとグッズがもらえるキャンペーンサイトの公開前に想定アクセスを処理できるかテストすることとなった。
同時に500ユーザーが応募サイトを参照しつつ、毎秒10回応募処理があったときに問題がないか、レスポンスの遅延が発生しないかを確認する。
試験実施期間は2日とし、500ユーザーによるトップページの参照を維持しつつ、毎秒10件の応募処理を実行した。お客様ご担当者に結果をHedgehogのURL共有機能でご報告することとし、レポート作成はしない。
負荷リクエストを実行したところ、エラーは発生しないものの応募処理でPOSTが実行されたタイミングでレスポンスが遅くなるタイミングがあることがわかった。ただしすべての応募処理は正しく処理されており、レスポンス時間も許容範囲内だったため、トップページのサイトの画像サイズを減らす、など調整程度に留めてリリースすることとなった。
大手外食チェーン店宅配アプリ
試験費用合計：80万円
テイクアウト商品のオンライン注文が可能なWebサイト、スマートフォン向けアプリのそれぞれで繁忙期の注文実績よりピーク帯の同時アクセス数を算出し、性能に問題がないかをテストすることとなった。
繁忙期と同程度のアクセスがあったときに問題がないかをサイト、スマートフォン向けアプリのそれぞれで検証する。
サイトについては通常の負荷テストと同様のシナリオを作成。アプリについては実行しているAPIをアプリ側の遷移と合わせて呼び出す形でシナリオを作成。100ユーザーの参照および10注文、アプリは500ユーザーによる利用を想定したシナリオを作成し、1ヶ月程度の時間をかけて順番にサーバー側チューニングも合わせて実施。
試験の実施結果を都度共有し、サーバー側のスケールアップ、スケールアウトを繰り返すことで必要リソースの見積もりができた。試験開始当初はエラーやレスポンスタイムが基準値を満たさない場合もあったが、お客様側でキャッシュの設定変更、アプリケーション側の改修も並行して進めることで、性能に関しては確証をもってリリース日を迎えることができた。アプリについてもAPIをシナリオ化することで本番と同等の負荷を再現でき、性能以外の問題点の洗い出しも行うことができた。