こんにちは。JMDCインシュアランス本部ソリューション部の檜山です。
今年、JMDCではアドベントカレンダーに参加しています。
本記事は、JMDC Advent Calendar 2024 23日目の記事です。
はじめに
現在、私はiOSおよびAndroid向けアプリのバックエンド開発を担当しています。
モバイルアプリやWebサービスを問わず、性能試験は欠かせないプロセスです。例えば、ECサイトではページの表示速度が売上と相関関係があることが知られており、ページ表示速度はユーザー体験に直結する重要な要素となっています。
しかし、開発業務ではアプリ機能要件の試験が優先され、非機能要件の試験が後回しになってしまうことがよく起こります。特に開発スケジュールが厳しい場合、試験環境を占有する必要のある性能試験を効率よく実施する方法を見つけることが課題となります。
今回は手軽にある程度の規模の性能試験を実施したいと思い、AWSが提供している分散負荷テストのソリューション（Distributed Load Testing）を利用したので、ぜひ共有させていただければと思います。
ツール採用理由
負荷試験用のツールはたくさんありますが、今回AWS分散負荷テストを利用した理由は以下の通りです。
- バックエンドサーバーに負荷をかけた状態で、フロントエンドであるモバイルアプリのレスポンスタイムを測定したい
- 開発中のプロダクトは今後リソースを都度拡充していく想定のため、負荷試験用ツールを手軽に削除したり再利用したりしたい
- 開発メンバーが簡単に負荷試験を設定できるようにしたい
今回の負荷試験環境の構成図は以下のようになっています。
NAT GatewayとWAF以外は、CloudFormationのテンプレートを利用して自動的に作成されます。また、今回は対応していませんが、テンプレートをカスタマイズすることで、NAT GatewayやWAFもCloudFormationで作成・削除できるようになり、環境構築がさらに簡単になると思います。
負荷ソリューションの構成図は下記の公式ドキュメントをご参照ください。
Architecture overview - Distributed Load Testing on AWS
また、1 分を越えて継続する、1 Gbps (10 億ビット/秒) または 1 Gpps (10 億パケット/秒) を超える通信を行う場合はAWSへ申請が必要となります。今回実施した負荷試験の規模的には申請不要でした。
テストポリシー - Amazon EC2 | AWS
コスト感
実際にかかった費用は下図の通りです。
- サーバーレスな構成のため、負荷ソリューション自体の維持費はほぼかかっていない
- エンドポイントに負荷をかけた際は、Lambdaやコンテナ利用料金が発生する（ただし今回の試験では20分で約5500リクエストと、小規模な負荷試験でした。）
- NATGatewayやWAFは維持費としてかかっている
- CloudFormationで各リソースの作成、削除を行うためConfig費用が発生する
全体的に維持費はそれほどかからない印象でしたが、今回はWAFやNATで費用がかかるので試験終了後は削除し、再度使用したいときに再構築するのが良いと思いました。
使用感とメリット
CloudFormationによる環境構築の容易性
公式ドキュメントに従い、CloudFormationで環境構築を行います。
- CloudFormationの[スタックを作成]から[新しいリソースを使用]を選択します
- 公式ドキュメントからダウンロードしたテンプレートファイルをアップロードし、[次へ]を押下してパラメータ入力に進みます。
- 必須項目（Webコンソールのログイン情報を通知するメールアドレス、スタック名等）を入力します。
今回の場合、事前に作成したNAT GatewayのあるVPC上に構築する必要があったため、下図の通りパラメータに入力しました。
「AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。」にチェックを押し、デプロイを開始します。
デプロイが完了するとWebコンソール のURLとPW がパラメータに入力したメールアドレスに届きます。 また、今回はWebコンソールへのアクセスもIPアドレスで制限したかったため、WAFを別途作成しました。 CloudFormationにて構築されたCloudFrontにWAFを適用することで、環境構築は完了になります。
上記の手順でかかる時間は20～30分ほどで、短時間で手軽に環境構築ができることがわかります。
Webコンソールによる負荷試験
先ほど作成したWebコンソールにアクセスします。 ナビゲーションバーの「CREATE TEST」から負荷試験の設定を行うことができます。 今回は下記設定で負荷試験を実行します。
| 項目名 | 値 | 意味 |
|---|---|---|
| TASK COUNT | 3 | タスクを3つ起動して |
| CONCURRENCY | 1 | 同時実行数1で |
| RAMP UP | 0m | 0分かけてフル負荷状態にし |
| HOLD FOR | 20m | 20分フル負荷状態を維持する |
ぱっと見、3×1回のリクエストを繰り返すだけなのでそこまで負荷はかからないように見えますが、 レスポンスが返却されたら即座にリクエストを投げているようですので、結果20分で5500回ほどリクエストを行っていました。
実行中はリクエスト状況をリアルタイムでWebコンソール上にモニタリングしてくれています。
AWSマネジメントコンソールを開かずに、いつタスクが起動してリクエストを開始したかがわかるため便利でした。
タスクからのリクエストが始まったら、サーバー高負荷状態でモバイルアプリの挙動確認を行います。
終了したら下図の通り結果を見ることができます。
Percentile Response Timeの項目でレスポンスタイムの分布をみることができ、100%が最も長くかかったレスポンスタイムになります。
今回は最大1.7秒程度なのでひとまず安心しました。
サーバ側のCPU使用率を見ると、負荷試験のリクエストを処理するために一時的に使用率が上がっていることがわかります。
これにて負荷試験は完了になります。 Webコンソールから操作可能であるため、誰でもツールのインストールを行わずに負荷試験を行うことができます。
まとめ
実際にAWS分散負荷テストを使ってみたまとめと感想になります。
メリット
- とにかく環境構築が手軽
- サーバーに対して単純に負荷をかけたいだけの場合に最適
- レスポンスタイムが簡単に見ることができるため、非機能要件を満たしているかわかりやすい
デメリット
- 設定値のタスク数と同時実行数だけでは送信されるリクエスト数がわかりづらい
性能試験をサクッと行いたいけど、ツールを入れてスクリプトを作成するのが手間な方にはお勧めできると思います。 負荷試験ツールの選択肢の一つとして頭に入れておくと、今後の開発業務で役に立つのではないでしょうか。
明日24日目は、川島さんによる「Tableauを用いた分析サービスのユーザビリティを上げるために実施したこと」です。お楽しみに！
JMDCでは、ヘルスケア領域の課題解決に一緒に取り組んでいただける方を積極採用中です！フロントエンド /バックエンド/ データベースエンジニア等、様々なポジションで募集をしています。詳細は下記の募集一覧からご確認ください。
まずはカジュアルにJMDCメンバーと話してみたい／経験が活かせそうなポジションの話を聞いてみたい等ございましたら、下記よりエントリーいただけますと幸いです。
★最新記事のお知らせはぜひ X（Twitter）、またはBlueskyをご覧ください！
