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

Transcript

1. 大規模サービスの負荷試験を改善していった話 2024.08.28 1
2. 本発表で話すこと • 株式会社COMPASSでの負荷試験の実例 ◦ 実施していた負荷試験の歴史 ▪ 手動実行時代の話 ▪ 自動実行時代の話 ◦ 負荷試験基盤の具体的な仕組み 2
3. 自己紹介 名前: 福永健竜 所属: 株式会社COMPASS システム開発部SREチーム 経歴: 情報系大学(院) → レンタルサーバー会社 → ゲーム配信サービスの会社 → 現在 好きなこと: プリン・温泉 3
6. 6 飯田市 恵那市
7. キュビナ特有の事情 7
8. 朝学習の時間や授業のタイミングで負荷がかかりやすい 8 • サービスの特性上ユーザーの アクセスのタイミングが被りやすい ◦ 朝学習の時間 ◦ 授業の時間 ピーク時に負荷に耐えきれないと 日本中の小中学生が勉強できなくなっちゃう！ ある日のリクエスト量 (rps)
9. ~負荷試験手動実行時代~ 9
10. 負荷試験手動実行時代 • 負荷試験を始めた当初は手動で実施していた • 負荷試験を始めたきっかけは Akka Cluster Shardingという仕組みを外すため ◦ 大きな変更だったため、負荷試験を実施しないと不安が大きかった ◦ その後、リリース前に定常的に実施するように ▪ リリース前にパフォーマンスの問題を潰せるようになった 10
11. 負荷試験で採用したツール • k6 ◦ k6はGrafana Labsが開発している負荷試験ツール ◦ JavaScript, TypeScriptでシナリオを記述できる • k6-operator ◦ KubernetesのOperatorの一種 ◦ 複数クライアントからk6のシナリオを実行できる • Google Kubernetes Engine (GKE) ◦ k6-operatorを動かすために利用 11
12. 負荷試験のシナリオ • シナリオ ◦ 実際のユーザーを想定して 複数問題を解くシナリオ • 負荷量 ◦ 朝のピーク時を元に算出 12 ある日のリクエスト量 (rps) この時間帯のリクエスト量から 負荷量を算出
13. 負荷試験手動実行時代の負荷試験基盤 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 本番環境のデータをダンプして匿名化したもの （本番同等のデータの量・偏りを再現） 必要に応じてマイグレーションを実施 ③負荷試験を実施
14. 負荷試験手動実行時代の課題 14
15. 負荷試験手動実行時代の課題① • 必要手順が多かった ◦ 必要なコンポーネントの起動(CloudSQL, Redis etc...) ◦ DBのマイグレーション ◦ 負荷試験のマニフェストを負荷試験用k8sクラスタにApply ◦ 終了後ダッシュボードを見て時間を絞って結果を確認 ◦ 分析結果をレポートに纏める • 人によって実施手順に差があった ◦ 実施手順の差で結果に差が出ていた ▪ 暖気運転の有無など 15
16. 負荷試験手動実行時代の課題② • 負荷試験用ダッシュボードを用意していたが 見るべきポイントを整理できていなかった ◦ 関連するコンポーネントの メトリクスを纏めていた ◦ グラフの数が多く、分析する人によっては どこを見ればいいのか分からない状態だった 16 負荷試験用ダッシュボード
17. 負荷試験手動実行時代の課題③ • 負荷試験の結果レポートを毎回手作業で纏めていた ◦ 負荷試験を実施した時間、 想定した負荷量をかけられているのか、 p95タイルのレスポンスタイムなどなど... ◦ 手作業でレポートを作成することに 多くの時間と労力がかかった 17
18. 負荷試験手動実行時代の課題④ • リリース直前に負荷試験を実施していたので パフォーマンスの問題が見つかった時に大変だった ◦ 問題をすぐに特定できない場合 コミットごとに負荷試験を実施するなど複数回負荷試験を実施していた ◦ 複数回実施するだけで1日が終わった・・・ 18
19. 負荷試験手動実行時代のまとめ • 負荷試験を始めたことで リリース前にパフォーマンスの問題を潰せるようになった • 一方で負荷試験を実施するコストが高かった ◦ 実施・分析・記録のコストが高く、運用が大変だった 19
20. 〜負荷試験自動実行時代〜 20
21. 負荷試験の改善までの道のり • 負荷試験の実施・分析・記録のコストがやはり高かった • 定常的に負荷試験を回すことのメリットは大きかったので自動化することに • 以下の課題に注目して解決することを目標に ◦ 実施者による手順のばらつき ◦ リリース直前になるまでアプリのパフォーマンスが分からない ◦ パフォーマンス情報の分析が困難 ◦ 手作業で記録をする負担 21
22. 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
23. 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
24. 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
25. 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
26. 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
27. 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の投稿で 負荷試験結果が記録される
28. 分析を楽にするためにサマリーダッシュボード作成 見るべきポイントを絞り、問題がある場合は閾値ベースで警告を出すように ・ 28 ・
29. 実施コストを下げたことによって いろんなチームが 負荷試験に興味を持つように！ 29
30. ユーザーの体験を守る 体制作りに繋がった 30
31. 31 現場からの声
32. ユーザーの体験だけではなく 開発者も守れるように！ 32
33. 負荷試験自動実行時代のまとめ いつでも誰でも簡単に負荷試験を実行できるように！ = ユーザー & 開発者の体験を守れる体制に • 手動で実施していた時の課題を以下のように改善 ◦ 実施者による手順のばらつき ▪ GitHub Actionsによる自動化 ◦ リリース直前になるまでパフォーマンス状況の把握が遅れる ▪ 日次/ステージング環境更新時に自動で実行する ◦ パフォーマンス情報の分析が面倒 ▪ 見るポイントを絞ったダッシュボードを作成 ◦ 手作業で記録をする負担 ▪ Slackへレポートの自動投稿 33
34. 負荷試験の運用を続けた結果・・・ 34
35. 昨対比で サーバーが不安定になる事象の件数を 95%減らすことに成功!!! 35 ※ QAチームの品質検証の改善努力なども大きいため
 負荷試験だけが寄与しているわけではありません

36. • 副次的な効果だが、 社内での自動化へのモチベーションが上がった！ 余談 36
37. 今後の課題 • 負荷試験を実施するコストは下がったが 大きいリリースをする際には複数回の実施が必要になることが多い ◦ 現状の負荷試験基盤では一度に1つの負荷試験しか回せない • 今後の展望として並列に負荷試験を回せるようにしたい 37
38. まとめ • 負荷試験を定常的に回すことでサーバーが不安定になる事象が大幅に減少 • 不安なリリースがある時にすぐ負荷試験を回せる環境があると安心 • 負荷試験の実施コストを下げることは大事 ◦ いろいろな人から興味を持ってもらえる ◦ ＝ユーザー&開発者の体験を守る体制作りに繋がる • 株式会社COMPASSのテックブログに纏めてあるので興味ある人はぜひ！ ◦ この発表と同じタイトルです！ 38