はじめに
本記事は、New Relic Advent Calendar 2023の7日目の記事となります。
本記事は、Distributed Load Testing on AWSを用いた負荷テストをPythonベースのWEBアプリケーションDjangoに対して実行し、その内容をNewRelicで観察したものである。
前提条件
-
負荷テスト対象のネットワーク環境は、ざっくりですが下記の通りです。
※DLTによるアクセスが、インターネット→ALB→EC2といった流れでアクセスする。
-
負荷テスト対象のEC2のスペックは、「t3.small(2vCPU/メモリ2GiB)」である。
-
負荷テスト対象のOS内の環境は、下記記事をベースに環境構築したものである。
- NewRelicAgent及びPythonAgentのインストール及びNewRelic Synthetic Monitoringは、事前に設定済みとする。また、PythonAgentに関しては、下記記事を参考に設定。
負荷テストの前準備
負荷テストを実施するために、負荷を与えるソリューションを事前に構築します。
今回利用する負荷ソリューションは、Distributed Load Testing on AWSというサービスを活用します。
こちらは、CloudFormationで簡単に負荷実行環境を構築できるとても素晴らしいサービスです。
下記のハンズオンページでは、環境構築の仕方や負荷のかけ方などを細かく記載しているので、興味がある方がいれば、ご参考いただければと思います。
負荷テストの実施
公開実施する負荷テストは、下記2パターンとなります。
今回のテストでは、インスタンス数が1個 且つ t3.smallのインスタンスなので、処理がさばききれずにエラーが出てしまう想定です。※下記2テストとも、GET処理のみのテストです。
| 名前 | Task Count | Concurrency | Ramp Up | Hold For |
|---|---|---|---|---|
| タスク数20での負荷テスト | 20 | 1 | 1 | 3 |
| タスク数30での負荷テスト | 30 | 1 | 1 | 3 |
それでは、実際にDLTで負荷をかけていきましょう。
下記が、負荷をかけた際の画面キャプチャとなります。
タスク数20での負荷テスト
タスク数30での負荷テスト
上記2回の負荷テストを実施したが、NewRelic側ではどのような負荷を記録しているかを次項以降で書いていきます。
NewRelic側で観察
NewRelic側の観察項目として、今回は下記3つの視点でそれぞれ見ていこうと思います。
- ①Hosts画面から見た負荷
- ②NewRelic APM & Services(Python)画面から見た負荷
- ③NewRelic Synthetic Monitoring画面から見た負荷
①Hosts画面から見た負荷
Hostsのメトリクスを確認したところ、CPU使用率とNetworkTrafficの値が高くなっていることが確認が取れました。
ただ、OS観点のメトリクスを見ただけでは、いまいち良くわからないので、次を確認していきます。
②NewRelic APM & Services(Python)画面から見た負荷
NewRelicAPMでは、きちんとエラーとして記録されることを確認しました。実際に出たエラーは下記です。
Critical priority issue is active
Metric query deviated from the baseline for at least 5 minutes on 'High Application Response Time'
DLTで高負荷をかけ続けたので、アプリケーションの応答速度が遅くなり、それでエラーとして判定されました。
ここでは、 Web transactions time の値が高いので、ウェブ アプリケーションの合計実行時間の負荷が高いことがわかります。参考
次に、下記の画面では、どういう呼び出し処理がどのぐらいあったかを確認することができます。
下記の画面では、1リクエストごとに、どのぐらいの負荷があったかの詳細情報を確認することができます。
上記の観点では、NewRelicのPythonAPMを用いた分析を行うことで、処理が遅くなった原因追跡を行う際に役にたつサービスだなと感じました。
③NewRelic Synthetic Monitoring画面から見た負荷
次に、NewRelicの外形監視機能である Synthetic Monitoring から見た負荷内容を見ていこうと思います。
今回設定したSynthetic Monitoringは、単純なGET処理となります。
GET処理の実行元は、複数選択することができる為、グローバルにサービスを展開している場合はありがたい機能だなと思いました。※下記が実際に選択できる実行元です。
では、Synthetic Monitoringで、今回ピックアップする画面は下記となります。
私としては、HTTP response codesの数量が可視化されているのはすごくいいなと思いました。
今回のテストでは「302」と「200」しか発生しませんでしたが、特定の時間のみに発生するエラーなどを追跡する際などに役に立つなと感じました。
最後に
NewRelic初心者の私が、色々と試しながら、「おぉ、NewRelicすげぇ」と言いながら、殴り書しした記事なので、多少の不格好さはご了承ください笑
今後もNewRelicを使用し続けていき、いずれはNewRelicマスターになれるように頑張っていきます。
O・WA・RI ( ﾟДﾟ)