前回、負荷試験の全体の概要について書きましたが、今回はその時に行った外部APIの負荷試験について行った内容を書こうと思います。
今回の記事は、前回の記事【はじめてのAPIサーバー負荷試験で得た最低限の負荷試験知識】の「ここがむずかしいよ負荷試験」の「外部サービスのAPIを叩いている」という項目に値します。
負荷試験を行ったサーバー構成
今回作成したAPIサーバーは、API内部で外部サービスのAPIを叩いています。
今回は外部サービスのsundboxは存在しなかった為、直接外部サービスを含んだ負荷テストは出来ないという状況でした。
しかも、今回の仕組みは初回時に外部サーバーで認証を行い、認証が通って初めて他のAPIが叩けるという構成になっていた為、ここで問題が発生してしまうと、新規ユーザーが一切処理が行えなくなってしまう程、重要な役割を占めていました。
外部サービスに行う負荷試験の目的
- 外部サービスのAPIの性能がどの程度影響を及ぼすのかを調べる
- 外部のサービスが絡んでいる場合、外部サービスのパフォーマンス状況に自社サーバーのパフォーマンスが大きく左右される事になります。 問題時に対応する為には、どの程度の影響力があるのかを事前に知っておく必要があります。
どうやって試験をするか
冒頭でも言いましたが、今回は外部サービスのAPIにsundbox環境が存在しなかった為、負荷試験時に直接外部サービスに繋げて試験を行う事が出来ませんでした。
そこで、ダミーサーバーを用意し、今回はダミーサーバーに接続する事で、負荷試験を行う事にしました。
では、どのようにダミーサーバーでテストするのかという事なのですが、今回ダミーサーバーに1つだけ便利機能を付けて、その機能を使用する事で外部サーバーの影響度を計る事ができました。
ダミーサーバーの条件
-
通常の外部APIと同じリクエストを受付け、 同じ型のレスポンスを返す。
- まずは、当たり前の事ですが、実際に使用する外部APIと同じ振る舞いをする事が最低条件です。
-
レスポンスタイムを指定できる。
- これが今回使用した便利機能です。レスポンスタイムを調整出来る事により、外部サーバーのパフォーマンスを何パターンか想定し、負荷試験を行う事が出来ます。
例を書くと、下記の様にヘッダーのX-Sleepの値によってレスポンスタイムが調整出来るようにしています。
curl -d '{"user":"hoge"}' https://dummy-server.jp/test/api -H "Content-type: application/json" -H "X-Sleep: 2000"
負荷試験の方法
- CPU使用率50%以下を正常値とします。
- locasutで外部APIと連動しているAPIのみのシナリオを作成し、負荷をかけます。
- ダミーサーバーのAPIのレスポンスタイム100ms から 3000msの間で固定した数パターンで計測し、ダミーサーバーのAPIのレスポンスタイムによってどのように影響するのかを計測します。
- タイムアウトの設定時間等によって計測するレスポンスタイムは変えた方が良い。
- Medianが安定しなくなる、又は502エラーが置き始めた所を限界値して、そこまでのRPSをとCPU使用率を計測します。
- Median(中央値)が一気に跳ね上がった時は負荷によってパフォーマンスが劣化した事が考えられる
- Median(中央値)が一気に跳ね上がった時は負荷によってパフォーマンスが劣化した事が考えられる
試験結果
下記が負荷試験結果の例です。
| レスポンスタイム | RPS | CPU使用率 |
|---|---|---|
| 100ms | 230 | 90% |
| 200ms | 220 | 80% |
| 300ms | 200 | 75% |
| 400ms | 200 | 72% |
| 500ms | 190 | 65% |
| 600ms | 185 | 60% |
| 700ms | 175 | 60% |
| 800ms | 170 | 55% |
| 900ms | 155 | 50% |
| 1000ms | 140 | 45% |
| 1500ms | 110 | 30% |
| 2000ms | 85 | 20% |
| 3000ms | 60 | 15% |
この結果から、レスポンスタイムが1000ms以上になった場合にCPU使用率が50%を越え、パフォーマンスが劣化している事が分かります。
この結果で導きだされる内容は、外部サーバーのレスポンスタイムの平均が約1000ms以上だった場合に自社APIサーバーに影響をもたらす可能性があるという事です。
負荷試験結果に添った考えられる対応
- サービスINした時に外部サーバーAPIのレスポンスタイムを計っておいて、レスポンスタイムの平均が1000ms以上だった場合はサーバー台数を増やす等の対応を行い、パフォーマンスを維持する事をいち早く判断できます。
- また、外部サービスAPI接続時のTimeOutの時間設定や、リトライを行うかどうか等の判断も上記の結果を元に選定できます。
さいごに
今回はこの様なアプローチで試験をしましたが、もっと他に良い方法があるかどうかは調べないとなーと思います。
ただ、何もしないよりは数字として、何か情報を持っていると安心感が違いますね。