unless’s blog

日々のちょっとした技術的なことの羅列

負荷試験を定期的に実施できるように体系化した話

これはなに?

Kyash Advent Calendar 2021 22日目の記事です

昨年のAdvent Calendarでは負荷試験環境を作った話を書きました
今回は負荷試験の実施方法を体系化し、定期的に実施できる状態を作ることができてきたので、その話をまとめていきたいと思います

おまえだれ?

Kyashで主にお金の入出金周りを担当しているチームでBackend Engineerをしている @uncle__ko です
銀行やコンビニなどとシステム接続を行ったり、各種電文のParserを作ったり、電文の暗号化/復号化をしたり、マイクロサービス間&外部システムとの結果整合性の担保に苦心したりしています

事前準備

負荷試験をただ闇雲に行っていても意味がありません
何事もゴールを定めるのがとても重要ですし、負荷試験においても例外ではないと思ってます
ですので、Backend Engineer,SRE,PdM等の関係者を集めて全員の認識を揃えることが重要です

目的を設定せよ

今回の負荷試験の結果で何を得たいのかを決めます
それによってアプローチも変わってきますので、まずは全員で目的を定めていきます

    • 想定されるピーク時のRequestを受けても問題なく稼働することが知りたい
    • 現状のシステムで捌ける限界値を知りたい
    • Push通知のrate limitを決めたい

観点を決めよ

負荷試験を実施するにあたりどのような観点でテストをするのかを決めます
目的によって色々な観点がでるかと思います
どのようなアプローチで負荷テストして、どのような値を注視していくのかを決めることで、負荷試験結果を振り返りやすくします

    • 瞬間的なピーク値のテスト
    • 広告/キャンペーン/push通知など瞬間的に負荷が増大するテスト
    • 長時間の平均値のテスト
    • 通常稼働時のテスト
    • 負荷を大きくしていくテスト
    • 限界を知るためのテスト

対象を定めよ

何処にどの程度の負荷を掛けるべきかを決めます
目的に応じて必然的に決まるかと思います

負荷を試算せよ

  • ピーク値
  • 平均値

を決めます
ここに関しては負荷試験の目的ベースにエンジニアだけではなくPdMやドメインに詳しい人と一緒に、実際のユーザ数等を含め現実に使い数値を算出します
ちなみに負荷試験でここが一番難しいと感じます
定石も正解もない部分だと思ってます

ただ、あまり現実的じゃない数値でテストしたところで、サーバがオーバースペックになってしまったり、逆に想定より多くてシステムが耐えれなかったりしたら意味がないので、とても重要な部分です

    • 大規模なキャンペーンでPush通知を全ユーザに打つので耐えられるかを試験する
      • 送信ユーザ数と開封率を考慮して、想定されるアクセス数を試算
      • Push通知の遷移先で叩かれうるAPIを調査
      • これらの情報をもとに目標負荷を設定する

確認方法を決めよ

どの項目をどのように確認するかを決めます
チェック項目と確認方法を事前に決めておくことで、振り返りをしやすくします

    • datadogでRDSの aws.rds.cpuutilization を見る
    • Amazon CloudWatchでRDSの aws.rds.cpuutilization を見る

ちなみにKyashではDatadogを使ってシステムのmonitoringをしているので、負荷試験用のdashboardを作っています

dd_dashboard

シナリオを作成せよ

やっとシナリオが作成できます
Kyashの場合は昨年の記事にあるようにlocustを使っているので、locustのシナリオファイルとして、ここまで決めてきたものを取り入れたコードを記述していきます
記述の方法や構成等は昨年の記事をご覧ください

Locust + AWS ECS(Fargate)で負荷試験環境を作った話 - unless’s blog

実施

https://1.bp.blogspot.com/-6pDrDpYKUCg/Xor0RTjWgtI/AAAAAAABYL0/-y57hak6vKEhfrtHwOashooPxNMUaYJ8ACNcBGAsYHQ/s400/online_kaigi_man.png

実施については、負荷試験担当の人以外にも興味がある人は参加できるように事前にSlack等で声がけしたりしてます
また、負荷試験用の専用Channelを用意していて、負荷試験に関することはそのChannelに情報が集約されてます
そして、負荷試験当日はみんなでわいわいしながら負荷試験を実施してます
上で紹介したdashboardを見ながらネックになっている処理や、マイクロサービスを特定しながらみんなで意見交換しつつ負荷を掛けていきます

結果の共有

負荷試験の結果を振り返るMTGを実施します
目標を達成していない場合はどこを直すべきか、それはすぐに可能か別の方法はあるか等をメンバーで考えます
また、その結果を受けて何をいつまでに実施しないといけないのか、次回の負荷試験の日程はいつなのかなどを決めるようにしています
このように、実施と振り返りを目標が達成できるまで繰り返していきます

Kyashでは実施結果をGitHub issueで管理していて、議事録としてその時の結果やメンバー、振り返り内容とネクストアクションを残しておき、後世に知見を残せるようにしています 結果に関してはスクリーンショットも残すようにしています

issue

next_action

まとめ

このようにKyashでは闇雲に負荷試験を実施するわけではなく、目的、観点、対象を把握した上で目標を設定し、その目標をクリアするために負荷試験を行なっています
この実施方法が正解とも思っていませんし、まだまだ改善の余地はあるかもしれませんが、ある程度はこの方法で回るようになってきたかなと思っております
負荷試験などはどうしても後回しにされがちで、特にベンチャー企業などではなかなか実施できないことも多いと思います
Kyashでも大きめのプロジェクトのタイミングなどでは実施できていましたが、定期的に実施することは出来ていませんでした
しかし、このようにある程度体系だった方法を確立し提案資料にまとめてEMやPdMに提案していったところ四半期に1回実施できるような体制が作れるようになりました
今後も実施方法をブラッシュアップしつつ、しっかり負荷対応も行っていき、品質の高い、ユーザが安心して使用できるアプリを作っていきたいと思います

さいごに

Kyashでは一緒に負荷試験を実施してくれる仲間を募集しています
すこしでも興味を惹かれましたらぜひ応募してください!

サーバーサイドエンジニア / Serverside Engineer - 株式会社Kyash

また、下記もぜひチェックしてみてください!

Kyash Advent Calendar 2021はまだ続きます!明日の投稿もお楽しみに!