Slide 1

Slide 1 text

大規模サービスの負荷試験を改善していった話 2024.08.28 1

Slide 2

Slide 2 text

本発表で話すこと ● 株式会社COMPASSでの負荷試験の実例 ○ 実施していた負荷試験の歴史 ■ 手動実行時代の話 ■ 自動実行時代の話 ○ 負荷試験基盤の具体的な仕組み 2

Slide 3

Slide 3 text

自己紹介 名前: 福永健竜 所属: 株式会社COMPASS システム開発部SREチーム 経歴: 情報系大学(院) → レンタルサーバー会社 → ゲーム配信サービスの会社 → 現在 好きなこと: プリン・温泉 3

Slide 4

Slide 4 text

4

Slide 5

Slide 5 text

5

Slide 6

Slide 6 text

6 飯田市 恵那市

Slide 7

Slide 7 text

キュビナ特有の事情 7

Slide 8

Slide 8 text

朝学習の時間や授業のタイミングで負荷がかかりやすい 8 ● サービスの特性上ユーザーの アクセスのタイミングが被りやすい ○ 朝学習の時間 ○ 授業の時間 ピーク時に負荷に耐えきれないと 日本中の小中学生が勉強できなくなっちゃう! ある日のリクエスト量 (rps)

Slide 9

Slide 9 text

~負荷試験手動実行時代~ 9

Slide 10

Slide 10 text

負荷試験手動実行時代 ● 負荷試験を始めた当初は手動で実施していた ● 負荷試験を始めたきっかけは Akka Cluster Shardingという仕組みを外すため ○ 大きな変更だったため、負荷試験を実施しないと不安が大きかった ○ その後、リリース前に定常的に実施するように ■ リリース前にパフォーマンスの問題を潰せるようになった 10

Slide 11

Slide 11 text

負荷試験で採用したツール ● k6 ○ k6はGrafana Labsが開発している負荷試験ツール ○ JavaScript, TypeScriptでシナリオを記述できる ● k6-operator ○ KubernetesのOperatorの一種 ○ 複数クライアントからk6のシナリオを実行できる ● Google Kubernetes Engine (GKE) ○ k6-operatorを動かすために利用 11

Slide 12

Slide 12 text

負荷試験のシナリオ ● シナリオ ○ 実際のユーザーを想定して 複数問題を解くシナリオ ● 負荷量 ○ 朝のピーク時を元に算出 12 ある日のリクエスト量 (rps) この時間帯のリクエスト量から 負荷量を算出

Slide 13

Slide 13 text

負荷試験手動実行時代の負荷試験基盤 13 13 Load test Cluster (GKE) Datadog Application Cluster (GKE) ② k6リソースの マニフェストを適用 k6 runnner k6 runnner k6 runnner collect metrics, trace… Cloud SQL ① 関連するコンポーネントを起動 (CloudSQL, , Redis) Cloud MemoryStore 本番環境のデータをダンプして匿名化したもの (本番同等のデータの量・偏りを再現) 必要に応じてマイグレーションを実施 ③負荷試験を実施

Slide 14

Slide 14 text

負荷試験手動実行時代の課題 14

Slide 15

Slide 15 text

負荷試験手動実行時代の課題① ● 必要手順が多かった ○ 必要なコンポーネントの起動(CloudSQL, Redis etc...) ○ DBのマイグレーション ○ 負荷試験のマニフェストを負荷試験用k8sクラスタにApply ○ 終了後ダッシュボードを見て時間を絞って結果を確認 ○ 分析結果をレポートに纏める ● 人によって実施手順に差があった ○ 実施手順の差で結果に差が出ていた ■ 暖気運転の有無など 15

Slide 16

Slide 16 text

負荷試験手動実行時代の課題② ● 負荷試験用ダッシュボードを用意していたが 見るべきポイントを整理できていなかった ○ 関連するコンポーネントの メトリクスを纏めていた ○ グラフの数が多く、分析する人によっては どこを見ればいいのか分からない状態だった 16 負荷試験用ダッシュボード

Slide 17

Slide 17 text

負荷試験手動実行時代の課題③ ● 負荷試験の結果レポートを毎回手作業で纏めていた ○ 負荷試験を実施した時間、 想定した負荷量をかけられているのか、 p95タイルのレスポンスタイムなどなど... ○ 手作業でレポートを作成することに 多くの時間と労力がかかった 17

Slide 18

Slide 18 text

負荷試験手動実行時代の課題④ ● リリース直前に負荷試験を実施していたので パフォーマンスの問題が見つかった時に大変だった ○ 問題をすぐに特定できない場合 コミットごとに負荷試験を実施するなど複数回負荷試験を実施していた ○ 複数回実施するだけで1日が終わった・・・ 18

Slide 19

Slide 19 text

負荷試験手動実行時代のまとめ ● 負荷試験を始めたことで リリース前にパフォーマンスの問題を潰せるようになった ● 一方で負荷試験を実施するコストが高かった ○ 実施・分析・記録のコストが高く、運用が大変だった 19

Slide 20

Slide 20 text

〜負荷試験自動実行時代〜 20

Slide 21

Slide 21 text

負荷試験の改善までの道のり ● 負荷試験の実施・分析・記録のコストがやはり高かった ● 定常的に負荷試験を回すことのメリットは大きかったので自動化することに ● 以下の課題に注目して解決することを目標に ○ 実施者による手順のばらつき ○ リリース直前になるまでアプリのパフォーマンスが分からない ○ パフォーマンス情報の分析が困難 ○ 手作業で記録をする負担 21

Slide 22

Slide 22 text

GitHub Actionsによる自動化 22 GitHub Actions Load test Cluster (GKE) Slack Datadog Application Cluster (GKE) ③ 暖機運転/負荷試験用の マニフェストを適用 ⑤ 負荷試験の 結果を投稿 k6 runnner k6 runnner k6 runnner collect metrics, trace… ① 平日朝に 自動トリガー ① ステージング環境 更新時に自動トリガー Cloud SQL ② 関連するコンポーネントを起動 起動後にマイグレーションを実施 ① 手動でトリガー ④ 負荷試験を実施 Cloud MemoryStore

Slide 23

Slide 23 text

GitHub Actionsによる自動化 23 GitHub Actions Load test Cluster (GKE) Slack Datadog Application Cluster (GKE) ③ 暖機運転/負荷試験用の マニフェストを適用 ⑤ 負荷試験の 結果を投稿 k6 runnner k6 runnner k6 runnner collect metrics, trace… ① 平日朝に 自動トリガー ① ステージング環境 更新時に自動トリガー Cloud SQL ② 関連するコンポーネントを起動 起動後にマイグレーションを実施 ① 手動でトリガー ④ 負荷試験を実施 Cloud MemoryStore

Slide 24

Slide 24 text

GitHub Actionsによる自動化 24 GitHub Actions Load test Cluster (GKE) Slack Datadog Application Cluster (GKE) ③ 暖機運転/負荷試験用の マニフェストを適用 ⑤ 負荷試験の 結果を投稿 k6 runnner k6 runnner k6 runnner collect metrics, trace… ① 平日朝に 自動トリガー ① ステージング環境 更新時に自動トリガー Cloud SQL ② 関連するコンポーネントを起動 起動後にマイグレーションを実施 ① 手動でトリガー ④ 負荷試験を実施 Cloud MemoryStore

Slide 25

Slide 25 text

GitHub Actionsによる自動化 25 GitHub Actions Load test Cluster (GKE) Slack Datadog Application Cluster (GKE) ③ 暖機運転/負荷試験用の マニフェストを適用 ⑤ 負荷試験の 結果を投稿 k6 runnner k6 runnner k6 runnner collect metrics, trace… ① 平日朝に 自動トリガー ① ステージング環境 更新時に自動トリガー Cloud SQL ② 関連するコンポーネントを起動 起動後にマイグレーションを実施 ① 手動でトリガー ④ 負荷試験を実施 Cloud MemoryStore

Slide 26

Slide 26 text

GitHub Actionsによる自動化 26 GitHub Actions Load test Cluster (GKE) Slack Datadog Application Cluster (GKE) ③ 暖機運転/負荷試験用の マニフェストを適用 ⑤ 負荷試験の 結果を投稿 k6 runnner k6 runnner k6 runnner collect metrics, trace… ① 平日朝に 自動トリガー ① ステージング環境 更新時に自動トリガー Cloud SQL ② 関連するコンポーネントを起動 起動後にマイグレーションを実施 ① 手動でトリガー ④ 負荷試験を実施 Cloud MemoryStore

Slide 27

Slide 27 text

GitHub Actionsによる自動化 27 GitHub Actions Load test Cluster (GKE) Slack Datadog Application Cluster (GKE) ③ 暖機運転/負荷試験用の マニフェストを適用 ⑤ 負荷試験の 結果を投稿 k6 runnner k6 runnner k6 runnner collect metrics, trace… ① 平日朝に 自動トリガー ① ステージング環境 更新時に自動トリガー Cloud SQL ② 関連するコンポーネントを起動 起動後にマイグレーションを実施 ① 手動でトリガー ④ 負荷試験を実施 Cloud MemoryStore Slackの投稿で 負荷試験結果が記録される

Slide 28

Slide 28 text

分析を楽にするためにサマリーダッシュボード作成 見るべきポイントを絞り、問題がある場合は閾値ベースで警告を出すように ・ 28 ・

Slide 29

Slide 29 text

実施コストを下げたことによって いろんなチームが 負荷試験に興味を持つように! 29

Slide 30

Slide 30 text

ユーザーの体験を守る 体制作りに繋がった 30

Slide 31

Slide 31 text

31 現場からの声

Slide 32

Slide 32 text

ユーザーの体験だけではなく 開発者も守れるように! 32

Slide 33

Slide 33 text

負荷試験自動実行時代のまとめ いつでも誰でも簡単に負荷試験を実行できるように! = ユーザー & 開発者の体験を守れる体制に ● 手動で実施していた時の課題を以下のように改善 ○ 実施者による手順のばらつき ■ GitHub Actionsによる自動化 ○ リリース直前になるまでパフォーマンス状況の把握が遅れる ■ 日次/ステージング環境更新時に自動で実行する ○ パフォーマンス情報の分析が面倒 ■ 見るポイントを絞ったダッシュボードを作成 ○ 手作業で記録をする負担 ■ Slackへレポートの自動投稿 33

Slide 34

Slide 34 text

負荷試験の運用を続けた結果・・・ 34

Slide 35

Slide 35 text

昨対比で サーバーが不安定になる事象の件数を 95%減らすことに成功!!! 35 ※ QAチームの品質検証の改善努力なども大きいため
 負荷試験だけが寄与しているわけではありません


Slide 36

Slide 36 text

● 副次的な効果だが、 社内での自動化へのモチベーションが上がった! 余談 36

Slide 37

Slide 37 text

今後の課題 ● 負荷試験を実施するコストは下がったが 大きいリリースをする際には複数回の実施が必要になることが多い ○ 現状の負荷試験基盤では一度に1つの負荷試験しか回せない ● 今後の展望として並列に負荷試験を回せるようにしたい 37

Slide 38

Slide 38 text

まとめ ● 負荷試験を定常的に回すことでサーバーが不安定になる事象が大幅に減少 ● 不安なリリースがある時にすぐ負荷試験を回せる環境があると安心 ● 負荷試験の実施コストを下げることは大事 ○ いろいろな人から興味を持ってもらえる ○ =ユーザー&開発者の体験を守る体制作りに繋がる ● 株式会社COMPASSのテックブログに纏めてあるので興味ある人はぜひ! ○ この発表と同じタイトルです! 38