本番環境を使用して負荷試験してみた
技術本部 サービスリライアビリティグループ（SRG）の谷成です。
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事は、機能切り替えによりキャパシティを把握するための負荷試験をおこなった経験を書き記したものです。
この記事についてプロジェクトの進行よし負荷試験環境を作ろうdevelop環境での負荷試験develop環境での負荷試験を終えて本番環境を使用しての試験の判断本番試験に向けての準備Let’s 負荷試験本番で負荷試験実施後の振り返り終わりに
この記事について
とあるシステムで刷新を行っている際、古い機能から新しい機能に切り替えてもらうために新しい機能を作成し切り替えを行ってもらうプロジェクトが進んでいました。
多数のサービスが使用しているので、順番に切り替え依頼を行い切り替えを進めていました。
最初のいくつかのサービスが切り替えている間は機能は問題なく提供できていましたが、いくつかのサービスが切り替えを完了した後、あるサービスがピーク帯を迎えると機能のレイテンシやエラーレートが増加する現象が発生しました。
そこでエラーレートとレイテンシが増加を調査し解決するために負荷試験を行うことにしました。
プロジェクトの進行
よし負荷試験環境を作ろう
まずはすぐ利用できるdevelop環境でテストを行うことを決めました。
負荷のシナリオは実際のシステムから叩かれていたエンドポイントの割合を出し、それぞれのエンドポイントを同じような割合で叩くような負荷シナリオを用意しました。
develop環境での負荷試験
前提として今回の該当システムはkubernetes上で運用されているものとなっております。
develop環境にて負荷をかけていったところエラーが発生しました。
該当システムはJava を使用しておりエラーを調査するためにスレッドダンプを取得して処理が詰まっているところなどを調査し、怪しい部分の修正を行いました。
システムの修正後に問題がないか確認するため再度負荷試験を行いました。
修正後はエラーは発生しなくなったものの特定の負荷量からRPSが増えなくなってしまいました。
原因を調査してみると該当システムが通信している別環境にあるシステムがボトルネックとなり十分な負荷がかけられていない状況となってしまいました。
develop環境での負荷試験を終えて
develop環境で統合的に負荷をかけるには別環境にあるシステムも増強しないといけない状況となっていました。
別環境のシステムも一つではなく複数あり、リソースを増やすにしても増設コストや増設のリソースに対するコストも発生します。
更に複数の別環境を増やすとなると、それなりに時間も要します。
本番環境を使用しての試験の判断
エラーの原因となっていた部分はdevelop環境での検証によって修正しており、実際にリクエストを捌けるようにになっている想定ではあるが、実際に同等の負荷を受けたときにエラーを返して切り替えてもらうプロジェクトに対して迷惑をかけてしまうので、実際にリクエストを捌けるかを確認する必要がありました。
前述の通りdevelop環境だと十分な負荷をかけることが困難であったので、本番環境のピーク帯の時間を外して実際に本番環境に対して負荷をかけて試験をすることにしました。
本番試験に向けての準備
もちろん本番環境を使用する上で負荷をかけたことによりサービスがダウンするようなことがあってはならないです。
そこで、サービスの状況をより正確に把握できるように普段集めているメトリクスをを見直しながら、更に必要そうなダッシュボードを作成したり、詳細なログを出力したりしました。
これにより、以前に増してサービスの状況がより素早く簡潔に把握できるようになった気がします。
Let’s 負荷試験
最初のきっかけとなったエラー発生時のリクエスト数などについては、通常収集しているログやメトリクスから判明していました。それを元に最終的に最大どのくらいリクエストが来そうなのかを見積もりプラスαを考え負荷をかけるリクエスト量を決めました。
準備が整ったので実際に負荷試験を行っていきます。
チームで集まり、ピーク帯を外した時間に作成した負荷試験環境から負荷をかけます。
実際負荷をかけてみると該当機能のバックエンドにあるサービスのリソースが枯渇しかけているのを見つけることができました。
該当リソースを増強し（該当サービスの裏側は古くからあるサービスでVM運用をしておりオートスケールなどの機能を持ち合わせていないため）再度負荷をかけて予定リクエスト数が来てもエラーレート上がることもなく正常にリクエストを返せていることを確認することができました。
本番で負荷試験実施後の振り返り
今回負荷試験を行う必要が出てきたのは、各システムのキャパシティが把握できていなかったことに起因します。
どのくらいのリソースを与えれば、どのくらいのリクエストを捌くことができるかのドキュメントが残っておらず把握できていなかったのが主な原因になります。（最近ではオートスケールするシステムなどを使用して気にする機会が少なくなって来ているかもしれないですが）
今回はその辺りも踏まえて、最初にdevelop環境で負荷試験を行った際に対象サービスが1 podでどの程度リクエストを捌けるかやスケールしたときに同様に捌けるリクエストがスケールしていくかなどの検証を行い、ドキュメントを残す作業も一緒に行いました。
また、負荷試験を行うことで見えてきたことや改善できたこと事がありました。それを元にチームでMTGを行い対応するものの優先度を付けて順次対応を行いました。
終わりに
今回は時間とリソースが限られた中で、どのように負荷試験を行っていくかについて考えて実行したことについて振り返りました。
以下の要因でシステムがどのくらい負荷に耐えることができることが把握できてない状況でした。
- 作成時に負荷試験を行っていない
- 負荷試験を行ったがドキュメントを残していない
- ドキュメントに残したが使用されるドキュメントツールの移行で無くなってしまった
今回の成果として、負荷試験によりボトルネックを修正してシステムとしてどのくらいのリソースでどのくらいのパフォーマンスを出せるかを明記したドキュメントを作成しました。
現時点ではチーム全員が共通で把握しているドキュメント置き場にドキュメントを残しておきましたが、チームが変わったときに引き継がれ無かったり、使用するドキュメントツールが変更になった際に移行されず失われてしまうなどの問題に関しては残っています。
これからの問題については引き続き考えていく必要がありそうです。
SRG では一緒に働く仲間を募集しています。
ご興味ありましたらぜひこちらからご連絡ください。
SRG では最近出たホットなIT技術や書籍などについてワイワイ雑談するポッドキャストを運営しています。ぜひ、作業のお供に聞いていただければ幸いです。
