アプリボットにおける負荷試験への取り組み【CAGC2024】※2025年3月6日までの公開

アプリボットがこれまでに行なってきた負荷試験の課題と解決策についてご紹介いたします。
負荷試験では、スケジュールやコストといった計画の問題や、目標の数値の決め方など、こうしておけばよかったということが毎回発生しますが、このような経験はどうしても属人化しがちです。
また、負荷試験の成功のためには、エンジニアだけでなくプロジェクト全体の協力も必要不可欠です。
これらの課題を繰り返すことなく安定したサービスのリリースを行なっていくために、会社として今後どのように負荷試験に取り組んでいくかについて解説いたします。

https://cagc.cyberagent.co.jp/2024/session/index.html?id=Up3Q7sqL

© SQUARE ENIX Powered by Applibot, Inc.　CHARACTER DESIGN: TETSUYA NOMURA / CHARACTER ILLUSTRATION: LISA FUJISE
Copyright © CyberAgent, Inc.

Transcript

1. アプリボットにおける 負荷試験への取り組み 1 SRE 西村 遊　Nishimura Yu
2. 2 アジェンダ • アプリボットにおける負荷試験
 • 3つの課題
 • まとめ

3. 3 • 負荷試験で行ったテスト内容の詳細 
 • 具体的なチューニング設定
 話さないこと
4. 4 アプリボットにおける負荷試験
5. アプリボット　沿革 5 参照リンク: https://www.applibot.co.jp/recruit/
6. アプリボットにおける負荷試験 6 数々のリリースをおこなった経験の中には、 当然成功と失敗がありました。 都度知見をアップデートしていくものの、 扱うタイトルの規模も大きくなり、 必要とされる目標値も 常に更新されていきました。 負荷試験
7. アプリボットにおける負荷試験 7 そんな数多くの負荷試験をおこなってきた中で乗り越えてきた ３つの課題と どのように解決してきたか についてお話しさせていただきます
8. 8 3つの課題
9. 3つの課題 9 1.スケジュールの確保 2.サーバ費用の高騰 3.経験の属人化
10. 10 課題 1. スケジュールの確保
11. 事象 当初の計画ではリリース 2ヶ月前に2週間程度の負荷試験を予定。 追加開発、不具合修正が優先された結果、日程はずるずると後回しに。 他チーム＆グループ会社の協力で、なんとかリリース前に試験は完了。 しかし、リリース後にインフラ起因の問題が起きてしまった。 課題 1. スケジュールの確保 11
12. 原因 負荷試験に必要とする時間の認識が甘い 課題 1. スケジュールの確保 12
13. 原因 負荷試験に必要とする時間の認識が甘い • 社内で負荷試験を多くおこなっていた人が、このタイミングでは退社していた ◦ 人数をかけずに短期間で行える、というイメージだけが先行していた ◦ 具体的な試験項目について、調整しきれていなかった • コードフリーズの遅れに伴い、優先度が見直されないまま予定日が後ろ倒しに ◦ 対応予定だったメンバーも、改修に追われアサインできない 課題 1. スケジュールの確保 13
14. 課題 1. スケジュールの確保 14 解決策 サービスのリリースに必須であると、 プロジェクト全体が理解する - 負荷試験が行えていない状態でリリースを行うと、 結果的に想定外の問題への対応に多くの時間を取られてしまう - なぜ必要なのか？実行するためには何が必要なのか？を理解する - 負荷試験を実行する人以外にも、役割を明確化する
15. 15 15 目標の 決定 負荷試験 の成功 事業責任者 負荷試験 リーダー エンジニア＆ SRE 目標の 達成 達成要件 の明確化 開発 ディレクター 適切な 試験準備 課題 1. スケジュールの確保
16. 16 課題 1. スケジュールの確保 役割の明確化 - それぞれが試験を行うにあたって、必要な工程を洗い出す - どの段階で何を用意すれば良いのかを確認 - 試験を行う前の準備も含めて、スケジュールを確保する
17. 17 　　開発初期〜 　ミニマム 　負荷試験 　準備期間 　　　　　　　　　　リリース 　　　　　　　　　　負荷試験 　　　　　　　　　　準備期間 リリース
 負荷試験
 ミニマム
 負荷試験
 負荷試験
 ツール選定
 スケール 環境準備
 ミニマム環 境準備
 定常
 シナリオ作 成
 コスト
 削減設定
 定常シナリオ
 全API対応
 試験項目の 洗い出し
 新規技術の
 検証判断
 負荷試験リーダー バックエンドエンジニア mock
 作成
 SRE DAU想定他
 要件の収集
 APIログ
 バッチ
 など実装
 クラウド
 上限緩和
 課題 1. スケジュールの確保 APMの
 組み込み
 リリース
 シナリオ作 成

18. 課題 1. スケジュールの確保 役割の明確化 これらを実施するためのスケジュールを確保するには、 事業責任者を巻き込み、 プロジェクト全体で 目標を定義し行う試験であることを、周知する必要がある。 18
19. まとめ - 安定リリースには負荷試験が必須 - プロジェクト全体で認識をもつ - それぞれの役割毎に必要な工数を洗い出す - 作業担当者のみで調整を行わない - 必要な情報を、必要な人に聞き、当事者意識を持って対応 課題 1. スケジュールの確保 19
20. 課題 2. サーバ費用の高騰 20
21. 事象 前回の反省を踏まえ、入念に計画をたて、スケジュール通り負荷試験を実行。 予定していた試験は完了し、無事故リリース！ しかし、振り返ってみると試験全体で多くの費用がかかっていた。 課題 2. サーバ費用の高騰 21
22. 原因 安全にリリースできることを最優先とした計画 課題 2. サーバ費用の高騰 22
23. 原因 安全にリリースできることを最優先とした計画 - コストはかかっても、目標値はマストで達成するという前提 - 過剰なサーバ構成で何度も試験 - シナリオ修正や、コード修正確認でも常にリリース想定の構成 - 利用しない時間でも環境が起動 - 休日・夜間の環境停止忘れ - 朝から起動したが、試験を行なったのは夕方以降 - 一定量のリクエストを24h継続して流す試験 - RDSのI/O料金・ログの転送による各種課金量を想定できていなかった 課題 2. サーバ費用の高騰 23
24. 課題 2. サーバ費用の高騰 24 解決策 小さい構成、短い期間で試験を行える仕組みをつくる
25. 25 課題 2. サーバ費用の高騰 解決策 小さい構成、短い期間で試験を行える仕組みをつくる • 前提 ◦ インフラ環境はAWS ◦ モニタリングはDatadog ◦ ログ分析はSnowflake • 共通して挙げられるのが、「従量課金」であること
26. 26 課題 2. サーバ費用の高騰 解決策 小さい構成、短い期間で試験を行える仕組みをつくる • 環境の起動・スケール・停止を誰でも簡単に行えるようにする ◦ Jenkinsジョブに登録し、実行するだけの状態 ◦ 停止忘れ防止として0時を過ぎたら自動停止 • 大量のリクエストが必要な試験以外で、大きい構成を利用しない • 試験目的、手順を確定してから試験環境を起動する ◦ 何を見る試験か、がない状態での起動は行わない
27. 用途によって使い分けができるよう、2種類の環境を用意する ミニマム環境 • 構成要素を最小に抑えた環境 • スケール可能な部分は最小の台数、DB、KVSの分割数、 スペックも最小限 スケール環境 • 大規模負荷をかける環境 • 目標値に耐えられるDB、KVSの分割数、スペック 27 課題 2. サーバ費用の高騰
28. 1つの環境のスペック調整で対応しようとすると、 • 変更にかかるオペレーションと待機時間が発生する ◦ 何回も発生してしまうとかなりの時間が取られてしまう ◦ 変更の手間を嫌って、過剰な構成での試験を続けてしまう • 構成自体に無駄な部分が生じることは避けられない ◦ DB・KVS分割数の変更 環境を分けることで、 オペレーションの手間をなくし、過剰な構成で試験を継続してしまうことを避ける。 28 課題 2. サーバ費用の高騰 用途によって使い分けができるよう、2種類の環境を用意する
29. ミニマム環境では以下を確認する • 負荷シナリオの正当性 • 特定処理におけるボトルネック箇所 • 1台（1コンテナ）あたりの限界性能 29 29 負荷試験 クライアント Cloudfront ALB ECS RDS ElastiCache 課題 2. サーバ費用の高騰
30. ミニマム環境の利用 30 負荷試験のメインループ 定常シナリオ試験 目標RPS達成 シナリオ 作成・修正 APIサーバー 1台あたりの 限界RPS測定 課題 2. サーバ費用の高騰
31. スケール環境では以下を確認する • 想定リクエスト数がエラー、遅延無く実行可能か • 分散処理は均等に行われているか • スケールアップ・スケールアウトでリクエスト数を伸ばせるか 31 負荷試験 クライアント Cloudfront ALB ECS RDS ElastiCache 課題 2. サーバ費用の高騰
32. スケール環境で確認しないこと • ミニマム環境で通していないシナリオ • 何を確認したいのか、を説明できない試験 規模、サイズが大きい環境なため、起動しているだけでお金が飛んでいく 目標値を達成することを焦ってしまうと、この環境でテストを全て回してしまいがち アプリケーション自体の動作、シナリオ修正はミニマム環境で確認できる 32 課題 2. サーバ費用の高騰
33. 負荷試験のメインループ 定常シナリオ試験 目標RPS達成 スケールアウト 試験 ミニマム環境 障害試験 ロングラン試験 など 運用試験 周辺システム検証 限界性能試験 など シナリオ 作成・修正 想定 DAU スケール環境 最大 DAU 想定 DAU 課題 2. サーバ費用の高騰 33
34. まとめ - 小さい構成、短い期間で試験が行えるようにする - ミニマム環境・スケール環境を使い分ける - 何のために行う試験か、を明確化 - とりあえず、で試験を進めない - 試験内容、実施可能な時間を加味し、環境の起動時間をコントロール 34 課題 2. サーバ費用の高騰
35. 課題 3. 経験の属人化 35
36. 課題 3. 経験の属人化 事象 負荷試験を経験し、様々な経験、知識を得ることができた。 しかし、試験結果は残っているが、必要な工数、目標値、期間、費用の出し方など、 基本残っていない・・・ 36
37. 課題 3. 経験の属人化 原因　
 経験が人に貯まり、 社内に十分な展開ができていない 37
38. 原因　 経験が人に貯まり、 社内に十分な展開ができていない - 結果は残っているが、それ以外が残っていない場合も多い - 調整時期、予算、計画内容など - 経験を貯めた人がいなくなった際に残らない 課題 3. 経験の属人化 38
39. 解決策 経験を人で終わらせない為に、 「負荷試験指南書」を作成 39 課題 3. 経験の属人化
40. 負荷試験指南書とは • Applibotで得た負荷試験の知見をまとめたもの ◦ 一般的なメディア上にはない知見 ◦ 大規模開発でしかわからないこと ◦ アプリボット内での仕事の進め方やフローの実例 ◦ 参考となる具体的な数字 40 課題 3. 経験の属人化
41. 負荷試験指南書とは • Applibotで得た負荷試験の知見をまとめたもの ◦ 一般的なメディア上にはない知見 ◦ 大規模開発でしかわからないこと ◦ アプリボット内での仕事の進め方やフローの実例 ◦ 参考となる具体的な数字 負荷試験指南書を利用して今後の負荷試験を実施 新たな知見を負荷試験指南書に貯めていくサイクルを作る 41 課題 3. 経験の属人化
42. 42 負荷試験指南書（プロジェクト編）の概要 対象読者: 事業責任者、開発ディレクター、バックエンドエンジニア、SRE 1章　負荷試験とは - 負荷試験の目的、目標数値の考え方、負荷試験の実施タイミングと スケジュール感 2章　役割毎のミッションと取り組むべきこと - 各役割の方に意識していただきたいこと - 負荷試験にかかる費用、実施しないことに対するリスク、負荷試験の スケジュールの確保、運用時の戦略を含めたシナリオ作成等 3章　過去の事例まとめ 課題 3. 経験の属人化
43. 負荷試験指南書（サーバーサイド＆SRE編）の概要 対象読者: バックエンドエンジニア、SRE 1章　負荷試験全体の流れ 2章　負荷試験の準備期間でやるべきこと 3章　負荷試験の実施に当たっての心構え 4章　ミニマム負荷試験の実践 5章　本リリース向け負荷試験の実践 6章　過去の事例 43 課題 3. 経験の属人化
44. まとめ • 経験が組織に蓄積されるよう、負荷試験指南書を作成 ◦ 指南書をベースに試験を行う ◦ 試験毎に内容を見直し、アップデートサイクルを作る 44 課題 3. 経験の属人化
45. 45 まとめ
46. • 負荷試験はプロジェクト全体で行う ◦ 目標と期間をプロジェクト全体で取り組み、実施しましょう • 小さい構成、短い期間で試験を行う仕組みをつくる ◦ ミニマム環境・スケール環境の2環境を用意 ▪ 試験内容から必要な構成を考え、過剰な環境で試験を行わない • 経験が人に貯まる ◦ 属人化で終わらせないために、負荷試験指南書を作成 ◦ 経験を組織に貯め、継続的に安定したリリース行える状態を作る 46 まとめ
47. 全ては障害の無い、 快適なユーザー体験を支えるために。 知見を共有し、 アップデートし続ける組織を目指します。 47 まとめ
48. ご清聴ありがとうございました 48