ECカートの負荷テストとパフォーマンスチューニングの実践

2026/10/22 パフォーマンスチューニング夜話 feat.おたのし味テック会 発表資料

Transcript

1. ECカートの負荷テストと パフォーマンスチューニングの実践 @ykagano 2026/10/22 パフォーマンスチューニング夜話 feat.おたのし味テック会 © 2012-2026 BASE, Inc.
2. 自己紹介 氏名：加賀野 祐（ ykagano） 所属：BASE株式会社 BASE Department Product Division 役割：シニアエンジニア（バックエンド） 趣味：お酒、旅行、キャンプ ykagano 2024年8月にBASE株式会社に入社 その前は以下の開発を経験してきました - 2009年〜：NET CASH - 2012年〜：WebMoney - 2017年〜：Yahoo!ウォレット、 PayPay © 2012-2026 BASE, Inc. 2
3. アジェンダ 1 はじめに 2 キャパシティプランニング 3 負荷テスト環境の構築 4 負荷検証環境の構築 5 環境を本番同等にする 6 パフォーマンスチューニング 7 パフォーマンスを維持する 8 さいごに © 2012-2026 BASE, Inc. 3
4. はじめに © 2012-2023 BASE, Inc. 4
5. 2025年のBASEの負荷テストには課題があった 1 2 3 テストシナリオが動かない モックのコード修正が必要 今のキャパシティが分から ない k6のシナリオはJavaScriptで書く。購 入に必要なAPIやパラメータが一つ増 えるだけで修正が必要になる 社外の決済APIに負荷はかけられない ため、応答に見立てたモックを用意し ている。外部APIの仕様が変わるとモッ クもコード修正が必要 改修の度に負荷テストをしていない。 当時の記録はあるが、仕様変更後も 同じキャパシティを保てているかは測り 直さないと分からない 測り直そうにも、①と②がハードルになり、すぐには負荷テストができない © 2012-2026 BASE, Inc. 5
6. いい加減・・・ 継続的な負荷テスト環境 が 必要だ・・・！ © 2012-2026 BASE, Inc. 6
7. 当時話題の商品は負荷が高かった 博覧会 グッズ アイドルグッズ 人気キャラ グッズ 各種シール などなど © 2012-2026 BASE, Inc. 7
8. BASEは成長している だからこそ、 負荷対策 が 喫緊の課題に なっていた © 2012-2026 BASE, Inc. 8
9. キャパシティプランニング © 2012-2023 BASE, Inc. 9
10. 性能不足はビジネス損失に直結する 性能問題 起きること ビジネスへの影響 スループット不足 セールで新規流入したユーザーが アクセスできない 売上の機会損失 レスポンスタイム遅延 画面が遅く、ユーザーが購入を諦める ユーザーの離反 © 2012-2026 BASE, Inc. 10
11. 負荷テストの目的 アプリケーションが要求性能を満たせることを確認する スムーズな購入体験を守る © 2012-2026 BASE, Inc. 11
12. 見積もりの基準は事業計画と注文 API 負荷テスト環境を構築するため、まず 2つの点を確認した 1 BASEのGMVはこの先どれぐらい増 える想定か 事業計画を参照すれば分かる 2 本番環境での現在の最大負荷はいく つか カート機能の注文 APIへの負荷を 基準にする © 2012-2026 BASE, Inc. 12
13. 注文APIの目標キャパシティは 2,000rps ① 基準：注文 APIの過去の最大負荷 2,000rps 1,000rps 1,500rps ② 事業計画： 2年後のGMVが1.5倍 1,500rps 1,000rps 上振れ分 +500 成長分 +500 成長分 +500 2年後（成り行き） 目標値 ③ 上振れを考慮：増加分 500rpsを2倍 2,000rps ※ 数値は説明用の仮の値です 現在の最大負荷 © 2012-2026 BASE, Inc. 13
14. 今後の成長を考えると 2倍、3倍・・・いや 10倍の負荷を 計測できる環境を作らなければ・・・！ © 2012-2026 BASE, Inc. 14
15. 負荷テスト環境の構築 © 2012-2023 BASE, Inc. 15
16. 継続的な負荷テスト環境に求めた 3つの要件 1 2 3 自動で定期実行し、結果を レポートできる 負荷生成ツールもモックも スケールアウトできる モックをノーコードで更新 できる 定期的に負荷テストを行い、 仕様変更によるエラーなどを 早期に検知する システム規模が大きくなって も台数を増やし、高負荷を与 え続けられる PHPの独自実装をやめて OSSのモックツールを使い、 コードを変えずに仕様を更新 する ※負荷生成ツール：システムに大量 のリクエストを投げて負荷を与える ツール © 2012-2026 BASE, Inc. 16
17. AWSのベストプラクティスとも一致させた ✓ 実際のワークロードで試験する ✓ 本番同等のサイズ・データで試験する ✓ アーキテクチャ全体に大規模な負荷をかける ✓ デリバリーパイプラインで自動実行する 本番環境でどう動作するかを確認する 本番データの匿名化や模擬作成で、量とバリエーションも揃える 負荷テストの考え方が 間違っていないことの 裏付けになった ユーザーの実際の行動をリプレイ、またはプログラムで再現する 性能目標と比較し、要求性能を満たせるかを継続的に保証する 引用：負荷テストの全体像を理解しよう｜AWS（第1回/全3回） https://aws.amazon.com/jp/builders-flash/202308/distributed-test-on-aws/ © 2012-2026 BASE, Inc. 17
18. 負荷テストは野球 ツールが投げて システムが打って © 2012-2026 BASE, Inc. モックが抑える 18
19. Locustが大量のリクエストを投げる 詳しくはテックブログを参照ください 「継続的な負荷テスト環境をBASEに構築しました 〜 第2回: 負荷生成ツールの構築と運用」 https://devblog.thebase.in/entry/2026/04/22/110000 ここから Locustが リクエスト © 2012-2026 BASE, Inc. 19
20. それをBASEのECシステムが処理 詳しくはテックブログを参照ください 「継続的な負荷テスト環境をBASEに構築しました 〜 第1回: 負荷テストの全体像」 https://devblog.thebase.in/entry/2026/04/15/110000 ここがBASEの ECシステムの 負荷検証環境 © 2012-2026 BASE, Inc. 20
21. WireMockが外部通信先になる 詳しくはテックブログを参照ください 「継続的な負荷テスト環境をBASEに構築しました 〜 第3回: モックツールの構築と運用」 https://devblog.thebase.in/entry/2026/04/28/110000 ここで WireMockが 外部APIになる © 2012-2026 BASE, Inc. 21
22. 負荷テストツール Locustの構成 Web UI操作 MasterとWorkerのタスクに分かれて起動 ECS Locust Master Task Master Task Web UIとWorkerの管理を行う 負荷テスト指示 Worker Task 実際の負荷をリクエストする Locust Worker Task #1 Locust Worker Task #2 Locust Worker Task #3 Workerの数を増やすことで 負荷リクエストの上限 も 増やせる構成 負荷リクエスト © 2012-2026 BASE, Inc. 22
23. 外部APIモックWireMockの構成 負荷リクエスト ALB 負荷テスト用 Nginx (Rate-Limiter) ECS WireMock Instance #1 WireMockを2台起動（負荷テスト時のみ） Nginxで外部APIのRate-Limiter（流量制限）を再現 WireMock Instance #2 スタブ同期 WireMock Hub（All-in-One版） WireMock Hub (All-in-One) WireMock Hub スタブ同期 スタブ登録 WireMock Instance (Included) 1つのコンテナに Nginx + WireMock Hub + WireMockを内包 Web UIを持つWireMock Hubがスタブデータを管理し 負荷テスト用 WireMockへ同期 異常系検証リクエスト Hubだけを日常的に起動しておけば Nginx スタブ登録 外部APIの異常系テストなどで UI付きのWireMockを日常使いできる 異常系検証リクエスト © 2012-2026 BASE, Inc. 23
24. 負荷検証環境の構築 © 2012-2023 BASE, Inc. 24
25. 本番と同等の負荷検証環境 既に以前から使っている Goldという検証環境があった © 2012-2026 BASE, Inc. 25
26. Gold環境は定期実行には重すぎた 負荷テストの流れ データ準備（数時間） 起動 負荷テスト 破棄 ↑ 途中で止まり、再実行が必要になることも 準備だけで数時間かかる 巨大なDBはコストも大きい 本番相当のデータ量を準備するため、定期実行の途中で タイムアウトする可能性がある。再実行が増えると定期実 行に支障が出る DBは存在するだけで多大なコストがかかる。定期的に数 時間利用するだけでも、多大なコストになる © 2012-2026 BASE, Inc. 26
27. 縮小環境「 Bronze」を新たに用意した • 本番よりスペックの低い縮小環境 Gold Silver Bronze • データベースは開発環境のものを流用 • 本番の構成を縮小した形で仕様を決定 本番同等の 検証環境 別用途で 使用中 今回用意した 縮小環境 • テストシナリオの修正と確認も手軽にできる ※本番同等の環境で負荷テストを行うというベスト 名前の由来 Silver環境はすでに別用途で使っていたため、Bronzeと 命名 プラクティスには反します © 2012-2026 BASE, Inc. 27
28. Goldで最終検証し、 Bronzeで継続的に検知する 項目 Gold環境 Bronze環境 目的 本番想定の最終的な負荷検証 継続的な負荷テスト・定点観測 スペック 本番同等 本番より縮小 データ量 本番同等（大規模） 開発環境のデータを流用 起動時間 数時間（データ準備に時間がかかる） 比較的短時間 コスト 高い 低い 実行頻度 必要に応じて実施 定期実行（週次） 主な用途 最終確認・性能限界の検証 早期検知・継続的な品質担保 メリット 本番に近い精度で検証できる 手軽に何度でも実行できる デメリット コスト・準備時間が大きい 本番との差異がある © 2012-2026 BASE, Inc. 28
29. 環境を本番同等にする © 2012-2023 BASE, Inc. 29
30. 本番と同じ環境を作るって 実は難しい 実際に動かしてみると結構違う © 2012-2026 BASE, Inc. 30
31. 元からある DBが本番同等ではなかった DB Gold環境の差異 1 / 5 本番 本番のDB DB ≠ Gold環境（当初） 本番同等ではなかった 構築当初は同等だったのかも 対応 本番と同等の DBを別途構築（コストは数倍） © 2012-2026 BASE, Inc. 31
32. DBのメモリ設定が本番と違っていた DB設定 Gold環境の差異 2 / 5 本番 動的 メモリ使用量 ≠ Gold環境（当初） 固定 構築当初は同等だったのかも 対応 設定を本番に合わせる © 2012-2026 BASE, Inc. 32
33. RDS Proxyの接続数設定が違っていた RDS Proxy Gold環境の差異 3 / 5 本番 99% DB接続数の上限 Gold環境（当初） ≠ 100% なので高負荷時に RDS Proxy自身の接続が溢れた 対応 設定を本番に合わせる © 2012-2026 BASE, Inc. 33
34. 外部APIの通信時間をモックに反映 外部API Gold環境の差異 4 / 5 本番（外部 API） 外部APIの実際の通信時間 通信時間 ≠ Gold環境（モック） モックの通信時間 この辺りもどの計測時間と合わせるかで変わる 対応 モックの通信時間を外部 APIと合わせる © 2012-2026 BASE, Inc. 34
35. 外部APIのRateLimitをモックに設定 外部API Gold環境の差異 5 / 5 本番（外部 API） 外部APIのRateLimit RateLimit ≠ Gold環境（モック） モックに RateLimitがない あとから気付いた 対応 モックに RateLimitを設定する © 2012-2026 BASE, Inc. 35
36. 本番で可変するスケールも最大に合わせる 例 フロントの台数を 50台に バックエンドの台数を 100台に スケールアウト 本番想定の最大負荷をかけて、 ほぼ同じ TPSが出た 🎉 © 2012-2026 BASE, Inc. 36
37. パフォーマンスチューニング © 2012-2023 BASE, Inc. 37
38. パフォーマンスを上げる 前回 vivionさんのイベントでお話しした内容ですが 非常に効果が大きかった 改善なので こちらでもお話しさせてください © 2012-2026 BASE, Inc. 38
39. ボトルネックを発見 429 Too Many Requests AIにログを分析 外部APIへの通信時に発生 どこで流量制限されているか 原因 決済時ではなく、その手前の 情報取得系 APIでRateLimitに引っかかっていた © 2012-2026 BASE, Inc. 39
40. 情報取得系 APIの通信に減らせる箇所があった 気付き 改修イメージ チームメンバーが「この処理、減らせる かも」と共有してくれた 改修 必要な情報は①で取得済み → ②の処理を削減 © 2012-2026 BASE, Inc. 40
41. リリース前の負荷テスト 負荷生成ツールがリクエスト送信 実施内容 モックが外部 APIを代行 リリース前に 負荷テストを実施 外部APIのRateLimitを再現するため、 Nginxを挟んで RateLimitをかけた 結果 RateLimitに引っ掛からずに決済できることを確認しリリース → 決済流量を増やすことができた © 2012-2026 BASE, Inc. 41
42. 実は システムの改善だけでなく、購入体験を考慮した流量制御も検討していた 検討案1 見送り 検討案2 見送り 待合室を作る 購入順序を制御する アクセスが一定を超えたら待合室に待機してもらい、自分の順番が来るまで 待ってもらう 決済を通せる流量は一定のため、先に購入を試みたユーザーが優先的に 買えるような仕組みを入れる 結果 減らせる処理があるという気付きがあったことで、 上記案は見送ることができた 重要 システムの処理能力を高めるだけでなく、限界を超えた場合の購入体験も考えておくことが重要 © 2012-2026 BASE, Inc. 42
43. パフォーマンスを維持する © 2012-2023 BASE, Inc. 43
44. AIの台頭により PRの変更行数が爆増していた レビューが追いつかない・・・！ なんとかしなければ・・・！ © 2012-2026 BASE, Inc. 44
45. 過去のナレッジをルール化して AIに渡す ルール化 過去のナレッジ 負荷テストやチューニングで得た知見 ねらい checkout-rule.md AIコーディング ナレッジをルールとして コーディング時に ファイルに残す ルールをAIへ読み込ませる コードを書く時点 で性能問題を防ぐ © 2012-2026 BASE, Inc. 45
46. 書かれたコードも AIでチェックする ルール化 過去のナレッジ 負荷テストやチューニングで得た知見 ねらい checkout-rule.md AIが一次レビュー ナレッジをルールとして レビュー時にも ファイルに残す AIへ読み込ませる 書かれたコード でも性能問題を防ぐ © 2012-2026 BASE, Inc. 46
47. AIの台頭により PRの変更行数が爆増している まだちょっとレビューが 追いつかない・・・！ ので対策を募集中です！ © 2012-2026 BASE, Inc. 47
48. 毎週月曜に負荷テストを自動実行 ワークフローのジョブ（約 40分） 毎週月曜日 1 負荷テスト開始の通知 2 Bronze環境の起動 3 負荷テストツールの起動 4 負荷テストの実行（メインシナリオ 1） AM7:00 5 負荷テスト結果の通知 負荷テストの自動実行 6 負荷テストの実行（メインシナリオ 2） 7 負荷テスト結果の通知 8 負荷テストツールの停止 9 Bronze環境の停止 10 負荷テスト完了の通知 AM3:00 アプリケーションの自動デプロイ GitHub Actionsのワークフローで 右のジョブを 約40分 で実行 © 2012-2026 BASE, Inc. 48
49. 週次の自動負荷テストで得られる効果 定期テスト 第1週 第2週 第3週 第4週 自動負荷テスト ✓ 自動負荷テスト ✓ 自動負荷テスト ✓ 自動負荷テスト ✓ 効果1 効果2 テストシナリオの鮮度を保つ パフォーマンスの低下を検知する 仕様変更でシナリオが動かなくなっても、すぐに気づいて直せる 毎週の結果を比較し、改修による性能劣化を早めに見つける 実行結果レポートの例（ Slack投稿） 負荷テスト結果 : success シナリオ : 〇〇決済 post_orders: requests=2000 failures=0 avg_time=20ms avg_rps=8.0, aggregated: requests=80000 failures=400 avg_time=500ms avg_rps=300.0 © 2012-2026 BASE, Inc. 49
50. 日次の高負荷ダッシュボードで可視化 可視化 高負荷ダッシュボード 日次 AI 高負荷！ 一定の基準で高負荷を判定 AIで高負荷を分析 可視化した高負荷の原因をAIで分析し、対策に つなげる 月 火 水 木 金 土 日 © 2012-2026 BASE, Inc. 50
51. 購入の流量を 4つのポイントで計測 購入の場合は流量のポイントがあり、ここを計測しています BASE 外部システム 外部システム BASE 購入ボタンを押すと 購入処理が走る 外部システムで 決済を行う（要求） 外部システムで 決済を行う（応答） 購入処理が完了 購入処理の rps 決済処理の rps 決済処理の tps 購入処理の tps どれだけの購入要求が来て、そのうちどれだけを処理できたか そして、 どこがボトルネックになっているか の全体像を把握できます © 2012-2026 BASE, Inc. 51
52. さいごに © 2012-2023 BASE, Inc. 52
53. 負荷対策は「やり切る」ことが大事 現実 だからこそ 負荷は顕在化しかけたときに、よう やく対応コストをかけられる これは仕方ない 組織がパフォーマンスチューニング の価値を正しく理解していることが 大事 高負荷の特徴 高負荷になるタイミングはそこまで 多くない しかし高負荷になったら関係者が 全員注視してしまう 負荷対策は「ここまでの負荷（〇〇 rpsまで）は問題ない」という 共通認識が持てるところまで やり切りましょう © 2012-2026 BASE, Inc. 53
54. BASEグループでは 価値の交換が最適化された未来をともに実現するメンバーを募集しています BASEグループ採用情報 https://binc.jp/jobs ご清聴ありがとうございました！！ © 2012-2026 BASE, Inc. 54