負荷試験の知識を深める為に、本「Amazon Web Services負荷試験入門 クラウドの性能の引き出し方がわかる」（以下、「Amazon Web Services負荷試験入門」）を呼んでみることにしました。
自分の思考整理と、この記事に辿り着いて下さったみなさんの為に、「Amazon Web Services負荷試験入門」を読んで、理解したことを整理しておきます！
参考図書
本記事は主にChapter3「負荷試験の基礎知識」を基に書いています！
良い負荷試験である条件
以下では、「良い負荷試験とは？」について、「AWS負荷試験入門」本を引用しつつ、自分の言葉で追加解説してみようと思います。
「AWS負荷試験入門」によると、良い負荷試験の条件は以下の2つであると紹介されています。
- 試験対象とするシステムに負荷が集中している状態
- ボトルネックを特定できている状態
以下で深掘りします。
試験対象とするシステムに負荷が集中している状態
複数のサブシステムにて構成された試験の場合、それぞれのサブシステムに個別で負荷をかけて挙動を調査する必要があります。負荷試験の最中に特定のハードウェアリソースが過負荷に陥るのは決して悪いことではなく、非常に良い負荷試験が実施できていることを意味します。
※「AWS負荷試験入門 クラウドの性能の引き出し方がわかる」から引用
システムの構成は、時として「自前で作った部分」と「外部サービスを呼んでる部分」に別れることがあります。
仮に、あるフェーズでの負荷試験の目的が「『自前で作った部分』の性能を測り、改善していくこと」だったとしましょう。
この場合、負荷試験を実施した結果、「外部サービスを呼んでる部分」が過負荷となってしまうと、良い性能試験にはなりません。
本当は自前で作った部分で「不要なクエリをDBに飛ばしている」だったり、「DBに必要なインデックスが足りてない」とか、そういったことを検証するためのデータが出てきて欲しいのですが、「外部サービスが遅い」だけが結果になってしまうと、改善のしようがありません。
これがアンチパターンであり「試験対象とするシステムに負荷が集中してない」状態です。これを避ける為には、外部サービス呼び出しをモックするような擬似ロジックを埋め込んだりして、自前で作った部分に負荷がかかるよう調整する必要があります。
※補足
負荷試験で観測したい対象や目的はフェーズによって変わっていくため、「外部サービス処理も含めた性能」も見たい場合があります。その場合は外部サービスをモックせずに試験することになります。
ボトルネックを特定できている状態
負荷試験実施中は、常に現在実施中の試験におけるボトルネックはどこになっているのかを意識する必要があります。また、その特定をしやすい手順で実施することで、非常に効率的に試験を行えます。
※「AWS負荷試験入門 クラウドの性能の引き出し方がわかる」から引用
ボトルネックとは「そのシステムの処理の中で一番スループットが低い場所」です。その場所がシステム全体の処理性能を決めています。
逆にいうと「そこさえ改善すればシステム全体の処理性能を上げられる場所」なので、ボトルネックの推定・特定は大事な作業ですね。
負荷試験は卓球のラリー
コラムとして紹介されていた程度なのですが、「イメージ掴みやすいな」と思ったので紹介です。
「Amazon Web Services負荷試験入門」では、負荷試験は卓球のラリーであると紹介されていました。
※「AWS負荷試験入門 クラウドの性能の引き出し方がわかる」コラムを参考に作成
このイメージを持てば、負荷試験における注意すべき以下3点についてイメージがしやすいとのことです。
- 攻撃ツールで観測されるレイテンシはサーバの応答速度とは異なる
- クライアントの同時起動数とサーバで処理される同時接続数は異なる
- クライアントは前のリクエストが完了しないと次のリクエストを発行しない
※「AWS負荷試験入門 クラウドの性能の引き出し方がわかる」から引用
攻撃サーバ側を「ラリーのサーバ」、負荷試験対象システム側を「レシーバ」と言い換えて、卓球になぞらえるとこんな感じになるでしょうか。
- ラリーのサーバが観測する「打ってから球が帰ってくるまでの時間」はレシーバの「球を受けてから打ち返すまでの時間」とは異なる
- 球が卓球台を通過する時間があるから
- ある時刻に「ラリーのサーバが何人いるか」と「レシーバがいくつの球を処理しているか」は異なる
- 球がサーバとレシーバのどちら側にいるかによる
- ラリーのサーバはレシーブが帰ってきて初めて次の球を打ち返す
- 当たり前
「球が卓球台を通過する時間」はシステムの文脈だと「ネットワークを通過する時間」に置き換えられます。
山根は以前現場で「攻撃サーバは試験対象システムからネットワーク的に近い場所に置こう」という指摘をもらったことがありますが、その理由がこの例えでかなり腑に落ちました。
確かにネットワーク的に近い場所に置いておかないと、観測したい指標が確認できませんね。
まとめ
簡単ではありますが、「AWS負荷試験入門」を呼んで学びになったなと思う箇所をまとめてみました。
負荷試験はシステム全体を見ないといけない、総合力が試されるタスクだと思うので、引き続き研鑽を重ねていこうと思います。
学びになりそうなところは発信も続けていくので、今後ともお楽しみに！