アプリボットにおける負荷試験への取り組み【CAGC2024】

Slide 1

Slide 1 text

アプリボットにおける負荷試験への取り組み 1 SRE 西村遊　Nishimura Yu

Slide 2

Slide 2 text

2 アジェンダ ● アプリボットにおける負荷試験  ● 3つの課題  ● まとめ 

Slide 3

Slide 3 text

3 ● 負荷試験で行ったテスト内容の詳細   ● 具体的なチューニング設定  話さないこと

Slide 4

Slide 4 text

4 アプリボットにおける負荷試験

Slide 5

Slide 5 text

アプリボット　沿革 5 参照リンク: https://www.applibot.co.jp/recruit/

Slide 6

Slide 6 text

アプリボットにおける負荷試験 6 数々のリリースをおこなった経験の中には、当然成功と失敗がありました。都度知見をアップデートしていくものの、扱うタイトルの規模も大きくなり、必要とされる目標値も常に更新されていきました。負荷試験

Slide 7

Slide 7 text

アプリボットにおける負荷試験 7 そんな数多くの負荷試験をおこなってきた中で乗り越えてきた３つの課題とどのように解決してきたかについてお話しさせていただきます

Slide 8

Slide 8 text

8 3つの課題

Slide 9

Slide 9 text

3つの課題 9 1.スケジュールの確保 2.サーバ費用の高騰 3.経験の属人化

Slide 10

Slide 10 text

10 課題 1. スケジュールの確保

Slide 11

Slide 11 text

事象当初の計画ではリリース 2ヶ月前に2週間程度の負荷試験を予定。追加開発、不具合修正が優先された結果、日程はずるずると後回しに。他チーム＆グループ会社の協力で、なんとかリリース前に試験は完了。しかし、リリース後にインフラ起因の問題が起きてしまった。課題 1. スケジュールの確保 11

Slide 12

Slide 12 text

原因負荷試験に必要とする時間の認識が甘い課題 1. スケジュールの確保 12

Slide 13

Slide 13 text

原因負荷試験に必要とする時間の認識が甘い ● 社内で負荷試験を多くおこなっていた人が、このタイミングでは退社していた ○ 人数をかけずに短期間で行える、というイメージだけが先行していた ○ 具体的な試験項目について、調整しきれていなかった ● コードフリーズの遅れに伴い、優先度が見直されないまま予定日が後ろ倒しに ○ 対応予定だったメンバーも、改修に追われアサインできない課題 1. スケジュールの確保 13

Slide 14

Slide 14 text

課題 1. スケジュールの確保 14 解決策サービスのリリースに必須であると、プロジェクト全体が理解する - 負荷試験が行えていない状態でリリースを行うと、結果的に想定外の問題への対応に多くの時間を取られてしまう - なぜ必要なのか？実行するためには何が必要なのか？を理解する - 負荷試験を実行する人以外にも、役割を明確化する

Slide 15

Slide 15 text

15 15 目標の決定負荷試験の成功事業責任者負荷試験リーダーエンジニア＆ SRE 目標の達成達成要件の明確化開発ディレクター適切な試験準備課題 1. スケジュールの確保

Slide 16

Slide 16 text

16 課題 1. スケジュールの確保役割の明確化 - それぞれが試験を行うにあたって、必要な工程を洗い出す - どの段階で何を用意すれば良いのかを確認 - 試験を行う前の準備も含めて、スケジュールを確保する

Slide 17

Slide 17 text

17 　　開発初期〜　ミニマム　負荷試験　準備期間　　　　　　　　　　リリース　　　　　　　　　　負荷試験　　　　　　　　　　準備期間リリース  負荷試験  ミニマム  負荷試験  負荷試験  ツール選定  スケール環境準備  ミニマム環境準備  定常  シナリオ作成  コスト  削減設定  定常シナリオ  全API対応  試験項目の洗い出し  新規技術の  検証判断  負荷試験リーダーバックエンドエンジニア mock  作成  SRE DAU想定他  要件の収集  APIログ  バッチ  など実装  クラウド  上限緩和  課題 1. スケジュールの確保 APMの  組み込み  リリース  シナリオ作成 

Slide 18

Slide 18 text

課題 1. スケジュールの確保役割の明確化これらを実施するためのスケジュールを確保するには、事業責任者を巻き込み、プロジェクト全体で目標を定義し行う試験であることを、周知する必要がある。 18

Slide 19

Slide 19 text

まとめ - 安定リリースには負荷試験が必須 - プロジェクト全体で認識をもつ - それぞれの役割毎に必要な工数を洗い出す - 作業担当者のみで調整を行わない - 必要な情報を、必要な人に聞き、当事者意識を持って対応課題 1. スケジュールの確保 19

Slide 20

Slide 20 text

課題 2. サーバ費用の高騰 20

Slide 21

Slide 21 text

事象前回の反省を踏まえ、入念に計画をたて、スケジュール通り負荷試験を実行。予定していた試験は完了し、無事故リリース！しかし、振り返ってみると試験全体で多くの費用がかかっていた。課題 2. サーバ費用の高騰 21

Slide 22

Slide 22 text

原因安全にリリースできることを最優先とした計画課題 2. サーバ費用の高騰 22

Slide 23

Slide 23 text

原因安全にリリースできることを最優先とした計画 - コストはかかっても、目標値はマストで達成するという前提 - 過剰なサーバ構成で何度も試験 - シナリオ修正や、コード修正確認でも常にリリース想定の構成 - 利用しない時間でも環境が起動 - 休日・夜間の環境停止忘れ - 朝から起動したが、試験を行なったのは夕方以降 - 一定量のリクエストを24h継続して流す試験 - RDSのI/O料金・ログの転送による各種課金量を想定できていなかった課題 2. サーバ費用の高騰 23

Slide 24

Slide 24 text

課題 2. サーバ費用の高騰 24 解決策小さい構成、短い期間で試験を行える仕組みをつくる

Slide 25

Slide 25 text

25 課題 2. サーバ費用の高騰解決策小さい構成、短い期間で試験を行える仕組みをつくる ● 前提 ○ インフラ環境はAWS ○ モニタリングはDatadog ○ ログ分析はSnowﬂake ● 共通して挙げられるのが、「従量課金」であること

Slide 26

Slide 26 text

26 課題 2. サーバ費用の高騰解決策小さい構成、短い期間で試験を行える仕組みをつくる ● 環境の起動・スケール・停止を誰でも簡単に行えるようにする ○ Jenkinsジョブに登録し、実行するだけの状態 ○ 停止忘れ防止として0時を過ぎたら自動停止 ● 大量のリクエストが必要な試験以外で、大きい構成を利用しない ● 試験目的、手順を確定してから試験環境を起動する ○ 何を見る試験か、がない状態での起動は行わない

Slide 27

Slide 27 text

用途によって使い分けができるよう、2種類の環境を用意するミニマム環境 ● 構成要素を最小に抑えた環境 ● スケール可能な部分は最小の台数、DB、KVSの分割数、スペックも最小限スケール環境 ● 大規模負荷をかける環境 ● 目標値に耐えられるDB、KVSの分割数、スペック 27 課題 2. サーバ費用の高騰

Slide 28

Slide 28 text

1つの環境のスペック調整で対応しようとすると、 ● 変更にかかるオペレーションと待機時間が発生する ○ 何回も発生してしまうとかなりの時間が取られてしまう ○ 変更の手間を嫌って、過剰な構成での試験を続けてしまう ● 構成自体に無駄な部分が生じることは避けられない ○ DB・KVS分割数の変更環境を分けることで、オペレーションの手間をなくし、過剰な構成で試験を継続してしまうことを避ける。 28 課題 2. サーバ費用の高騰用途によって使い分けができるよう、2種類の環境を用意する

Slide 29

Slide 29 text

ミニマム環境では以下を確認する ● 負荷シナリオの正当性 ● 特定処理におけるボトルネック箇所 ● 1台（1コンテナ）あたりの限界性能 29 29 負荷試験クライアント Cloudfront ALB ECS RDS ElastiCache 課題 2. サーバ費用の高騰

Slide 30

Slide 30 text

ミニマム環境の利用 30 負荷試験のメインループ定常シナリオ試験目標RPS達成シナリオ作成・修正 APIサーバー 1台あたりの限界RPS測定課題 2. サーバ費用の高騰

Slide 31

Slide 31 text

スケール環境では以下を確認する ● 想定リクエスト数がエラー、遅延無く実行可能か ● 分散処理は均等に行われているか ● スケールアップ・スケールアウトでリクエスト数を伸ばせるか 31 負荷試験クライアント Cloudfront ALB ECS RDS ElastiCache 課題 2. サーバ費用の高騰

Slide 32

Slide 32 text

スケール環境で確認しないこと ● ミニマム環境で通していないシナリオ ● 何を確認したいのか、を説明できない試験規模、サイズが大きい環境なため、起動しているだけでお金が飛んでいく目標値を達成することを焦ってしまうと、この環境でテストを全て回してしまいがちアプリケーション自体の動作、シナリオ修正はミニマム環境で確認できる 32 課題 2. サーバ費用の高騰

Slide 33

Slide 33 text

負荷試験のメインループ定常シナリオ試験目標RPS達成スケールアウト試験ミニマム環境障害試験ロングラン試験など運用試験周辺システム検証限界性能試験などシナリオ作成・修正想定 DAU スケール環境最大 DAU 想定 DAU 課題 2. サーバ費用の高騰 33

Slide 34

Slide 34 text

まとめ - 小さい構成、短い期間で試験が行えるようにする - ミニマム環境・スケール環境を使い分ける - 何のために行う試験か、を明確化 - とりあえず、で試験を進めない - 試験内容、実施可能な時間を加味し、環境の起動時間をコントロール 34 課題 2. サーバ費用の高騰

Slide 35

Slide 35 text

課題 3. 経験の属人化 35

Slide 36

Slide 36 text

課題 3. 経験の属人化事象負荷試験を経験し、様々な経験、知識を得ることができた。しかし、試験結果は残っているが、必要な工数、目標値、期間、費用の出し方など、基本残っていない・・・ 36

Slide 37

Slide 37 text

課題 3. 経験の属人化原因　  経験が人に貯まり、社内に十分な展開ができていない 37

Slide 38

Slide 38 text

原因　経験が人に貯まり、社内に十分な展開ができていない - 結果は残っているが、それ以外が残っていない場合も多い - 調整時期、予算、計画内容など - 経験を貯めた人がいなくなった際に残らない課題 3. 経験の属人化 38

Slide 39

Slide 39 text

解決策経験を人で終わらせない為に、「負荷試験指南書」を作成 39 課題 3. 経験の属人化

Slide 40

Slide 40 text

負荷試験指南書とは ● Applibotで得た負荷試験の知見をまとめたもの ○ 一般的なメディア上にはない知見 ○ 大規模開発でしかわからないこと ○ アプリボット内での仕事の進め方やフローの実例 ○ 参考となる具体的な数字 40 課題 3. 経験の属人化

Slide 41

Slide 41 text

負荷試験指南書とは ● Applibotで得た負荷試験の知見をまとめたもの ○ 一般的なメディア上にはない知見 ○ 大規模開発でしかわからないこと ○ アプリボット内での仕事の進め方やフローの実例 ○ 参考となる具体的な数字負荷試験指南書を利用して今後の負荷試験を実施新たな知見を負荷試験指南書に貯めていくサイクルを作る 41 課題 3. 経験の属人化

Slide 42

Slide 42 text

42 負荷試験指南書（プロジェクト編）の概要対象読者: 事業責任者、開発ディレクター、バックエンドエンジニア、SRE 1章　負荷試験とは - 負荷試験の目的、目標数値の考え方、負荷試験の実施タイミングとスケジュール感 2章　役割毎のミッションと取り組むべきこと - 各役割の方に意識していただきたいこと - 負荷試験にかかる費用、実施しないことに対するリスク、負荷試験のスケジュールの確保、運用時の戦略を含めたシナリオ作成等 3章　過去の事例まとめ課題 3. 経験の属人化

Slide 43

Slide 43 text

負荷試験指南書（サーバーサイド＆SRE編）の概要対象読者: バックエンドエンジニア、SRE 1章　負荷試験全体の流れ 2章　負荷試験の準備期間でやるべきこと 3章　負荷試験の実施に当たっての心構え 4章　ミニマム負荷試験の実践 5章　本リリース向け負荷試験の実践 6章　過去の事例 43 課題 3. 経験の属人化

Slide 44

Slide 44 text

まとめ ● 経験が組織に蓄積されるよう、負荷試験指南書を作成 ○ 指南書をベースに試験を行う ○ 試験毎に内容を見直し、アップデートサイクルを作る 44 課題 3. 経験の属人化

Slide 45

Slide 45 text

45 まとめ

Slide 46

Slide 46 text

● 負荷試験はプロジェクト全体で行う ○ 目標と期間をプロジェクト全体で取り組み、実施しましょう ● 小さい構成、短い期間で試験を行う仕組みをつくる ○ ミニマム環境・スケール環境の2環境を用意 ■ 試験内容から必要な構成を考え、過剰な環境で試験を行わない ● 経験が人に貯まる ○ 属人化で終わらせないために、負荷試験指南書を作成 ○ 経験を組織に貯め、継続的に安定したリリース行える状態を作る 46 まとめ

Slide 47

Slide 47 text

全ては障害の無い、快適なユーザー体験を支えるために。知見を共有し、アップデートし続ける組織を目指します。 47 まとめ

Slide 48

Slide 48 text

ご清聴ありがとうございました 48