人気商品が「ちゃんと買える」をつくる ー ECの負荷改善

2026/8/27 PHP Tech Talk Night ～ after phpcon 2026 ～ 発表資料

Transcript

1. 人気商品が「ちゃんと買える」をつくる ー ECの負荷改善 @ykagano 2026/8/27 PHP Tech Talk Night ～ after phpcon 2026 ～ © 2012-2026 BASE, Inc. 11
2. 自己紹介 氏名：加賀野 祐（ ykagano） 所属：BASE株式会社 BASE Department Product Division 役割：シニアエンジニア（バックエンド） 趣味：お酒、旅行、キャンプ ykagano 2024年8月にBASE株式会社に入社 その前は以下の開発を経験してきました - 2009年〜：NET CASH - 2012年〜：WebMoney - 2017年〜：Yahoo!ウォレット、 PayPay © 2012-2026 BASE, Inc. 22
3. アジェンダ • 本日お話すること • 負荷テスト環境の構築 • 高負荷時のデータ分析 • ボトルネックを改善する • いつでも買えるようにする • まとめ © 2012-2026 BASE, Inc. 3
4. • 本日お話すること 👈 • 負荷テスト環境の構築 • 高負荷時のデータ分析 • ボトルネックを改善する • いつでも買えるようにする • まとめ © 2012-2023 BASE, Inc. 4
5. 人気商品にはリクエストが殺到する ネットショップ作成サービス「 BASE」では人気商品に購入リクエストが殺到すると、 どうしてもエラーが発生してしまうことがあります またどうしても処理に時間がかかってしまうこともあります © 2012-2026 BASE, Inc. 55
6. 買えない時にどうするか 購入ボタンを何度も押しますよね？ それで買える時もあれば、先に在庫がなくなって買えない時もあります 原因は様々です Botが殺到したせいで買えなかったということもあります 皆さんも似たような経験があるかもしれませんが、これは体験が良くない状態です システムの負荷が高い状態であっても安定して買えることが求められます © 2012-2026 BASE, Inc. 66
7. 改善し続ける 高負荷への対策はこれまでも行ってきました しかし利用者が増え、販売方法も多岐に渡る今、高負荷状態にも様々なパターンがあります ・1つのショップの 1つの商品に購入が集中している ・抽選や予約販売の商品で人気商品の販売が始まった ・複数ショップで同時に人気商品の販売が始まった こうした本番環境で起こる様々な高負荷状態を分析し、対策し、負荷を再現して検証するには、 継続的に改善するための体制が必要です © 2012-2026 BASE, Inc. 77
8. チームができた 人気商品が「ちゃんと買える」状態を保つため、 2026年1月にCheckout Reliabilityチームが作られました 今日はCheckout Reliabilityチームがやってきた約半年間の歩みを話せる範囲でお話しします！ © 2012-2026 BASE, Inc. 88
9. • 本日お話すること • 負荷テスト環境の構築 👈 • 高負荷時のデータ分析 • ボトルネックを改善する • いつでも買えるようにする • まとめ © 2012-2023 BASE, Inc. 9
10. 負荷テスト環境の構築 まず進めたのは高負荷状態の再現でした 今後も使えるよう、継続的な負荷テスト環境の構築を行いました 詳しくはテックブログを参照ください 「継続的な負荷テスト環境をBASEに構築しました 〜 第1回: 負荷テストの全体像」 https://devblog.thebase.in/entry/2026/04/15/110000 ここが「 BASE」の ECシステムの 開発環境 © 2012-2026 BASE, Inc. 10 10
11. 負荷テスト環境の構築 システムに大量のリクエストを投げる 詳しくはテックブログを参照ください 「継続的な負荷テスト環境をBASEに構築しました 〜 第2回: 負荷生成ツールの構築と運用」 https://devblog.thebase.in/entry/2026/04/22/110000 負荷生成ツールには Locustを選定しています ここから Locustが リクエスト © 2012-2026 BASE, Inc. 11 11
12. 負荷テスト環境の構築 外部通信先を代行するモックツールには 詳しくはテックブログを参照ください 「継続的な負荷テスト環境をBASEに構築しました 〜 第3回: モックツールの構築と運用」 https://devblog.thebase.in/entry/2026/04/28/110000 WireMockを選定しています ここで WireMockが 外部APIになる © 2012-2026 BASE, Inc. 12 12
13. 負荷テスト環境の構築で工夫した点 Claude CodeでTerraformを使って構築したため、 以前の手動構築に比べると構築スピードは何倍にもなっていると思います しかし、それはあくまで構築の話で、構築の前提となる部分は人間のチェックが必要でした • システム設計と技術選定 • SREチームとの連携と責任範囲の確認（構築・運用は自チーム） • 構築することで運用コストがどれくらい増えるかのコスト試算 • 0→1でのAI Agentを使ったチーム開発（ Terraform, Docker構成, Locustのシナリオ等々） 負荷改善を重ねた現在も課題を解決しつつ運用できているため、方向性は合っていたものと感じています © 2012-2026 BASE, Inc. 13 13
14. • 本日お話すること • 負荷テスト環境の構築 • 高負荷時のデータ分析 👈 • ボトルネックを改善する • いつでも買えるようにする • まとめ © 2012-2023 BASE, Inc. 14
15. 高負荷時のデータ分析 高負荷時のデータを分析するため、以下の 2つの取り組みを行いました 1. NewRelicのカスタムイベントを追加し、外部 APIの応答時間、ステータスコードを計測しました 2. NewRelicでのログの保持期限がデフォルトでは 30日しかなかったことから、 長期的な高負荷状態の計測を目的に、 Snowflakeにログを連携して分析できる環境を用意しました © 2012-2026 BASE, Inc. 15 15
16. 1.外部APIの応答時間、ステータスコードを計測 NewRelicには外部 APIのメトリクス計測用に標準で Spanイベントが用意されていますが、 サンプリングされた一部データしか計測されていません Spanイベントにあるデータをチャートで見ると これに独自のカスタムイベントを追加することで 星空のように散らばっています 実測値で全て計測できるようにしました © 2012-2026 BASE, Inc. 16 16
17. 1.外部APIの応答時間、ステータスコードを計測 通信クライアントが requestメソッドをコールすると、カスタムイベントとして記録される © 2012-2026 BASE, Inc. 17 17
18. 2.Snowflakeにログを連携して分析 NewRelicをGraphQL APIで検索し、前日の対象期間のログを s3に格納した後、 Snowflakeに投入しています 高負荷だった期間のログを検索する際に、以下の 2つの流れでデータを絞り込んでいます 1.粗スキャン 1日分を5分刻みの軽いクエリでざっと見て、◯ rps以上の時間帯を候補として拾います （5分平均に丸められた rpsになるため、閾値の低い篩にかけます） 2.精査スキャン 候補区間だけを 1秒刻みで見直し、瞬間的に◯◯ rps以上出た区間だけを本物の高負荷として残します © 2012-2026 BASE, Inc. 18 18
19. 2.Snowflakeにログを連携して分析 Snowflakeのダッシュボードで確認 全体を日別のピーク RPSで確認できます 毎朝のデイリーで、前日の高負荷を確認して、 高負荷時のパフォーマンス低下がないか確認しています 日毎の詳細情報を確認できます © 2012-2026 BASE, Inc. 19 19
20. 2.Snowflakeにログを連携して分析 Claude CodeのSkillを使って、 NewRelic MCPに接続し、該当時間のログを解析し、 複数観点から調査したレポートを分析しています skillの大枠は以下となっています • Step 0: 期間・ショップの特定 • Step 1: 全体概況の把握 • Step 2: 購入ファネル • Step 3: 決済チャネル分析 • Step 4: ピーク RPS 推移 • Step 5: エラー分析 • Step 6: 外部APIフロー分析 © 2012-2026 BASE, Inc. 20 20
21. 仮説を立てる 分析してもボトルネックがどこにあるかは確定ではありません またすでに顕在化しているボトルネックだけでなく、より良くするための改善には人間の気付きが必要です そのため、何か気付きがあったものは負荷改善の仮説として NotionのDBに登録するようにしています © 2012-2026 BASE, Inc. 21 21
22. • 本日お話すること • 負荷テスト環境の構築 • 高負荷時のデータ分析 • ボトルネックを改善する 👈 • いつでも買えるようにする • まとめ © 2012-2023 BASE, Inc. 22
23. ボトルネックを発見 外部APIへの通信時に 429（Too Many Requests）が発生することがありました そのログを AIに分析してもらった結果、決済時ではなく、 その手前の情報取得系 APIでRateLimit（流量制限）に引っかかっていることがわかりました © 2012-2026 BASE, Inc. 23 23
24. 情報取得系 APIの通信 具体的には以下の図のイメージです チームメンバーがこの処理が減らせるかもという気付きを共有してくれたため、それを元に改修を行いました 必要な情報は①ですでに取得できていたため、②に減らすことのできる処理があったのです © 2012-2026 BASE, Inc. 24 24
25. リリース前の負荷テスト リリース前には負荷テストを実施しました 負荷生成ツールがリクエストを送り モックツールが外部 APIを代行 外部APIのRateLimitを再現するため、 Nginxを挟んで RateLimitをかけました 結果、RateLimitに引っ掛からずに決済ができることを確認し、リリースしました これにより、決済流量を増やすことができました © 2012-2026 BASE, Inc. 25 25
26. 今後もゾーン Aの通信数を増やさない Checkout Reliabilityチームは自分たちの管理する Checkoutモジュールのコードオーナーになっています 他チームからの PullRequestにゾーン Aの通信数が増える改修が入っていたことがありました その時は幸い気付くことができたので、通信が増えないようにしてもらいました 恐ろしく何気ないプルリク オレでなきゃ見逃しちゃうね © 2012-2026 BASE, Inc. 26 26
27. AIのルールで気付けるようにする 今後同じような変更が入ってくる場合があるため、対策が必要でした Checkoutモジュールの改修・レビューでは、 AIにコンテキストを与えるようにしています そこに「ゾーン Aへのリクエストは最小限に抑える」というルールを追加しました 以下の優先順位で通信量を抑えるようにしています • 削減する : そのリクエストが本当に必要か確認し、不要なら送信しない • 使い回す : 一連の処理の先頭で 1回だけ取得し、取得済みのオブジェクトを引数で引き回して再利用する © 2012-2026 BASE, Inc. 27 27
28. • 本日お話すること • 負荷テスト環境の構築 • 高負荷時のデータ分析 • ボトルネックを改善する • いつでも買えるようにする 👈 • まとめ © 2012-2023 BASE, Inc. 28
29. 1ショップへの集中が他ショップに影響 しかし、決済流量が増えてもまた別の問題がありました 1ショップに購入リクエストが集中すると、他のショップでも決済が遅くなるという問題です ショップ 決済レートリミット アクセス集中ショップの流量制限 制限内に収める その他のショップの流量制限 © 2012-2026 BASE, Inc. 29 29
30. RateLimiterの導入 1ショップには決済流量をぎりぎりまで使ってもらうものの、他のショップの決済流量を残すという調整をする RateLimiterを導入することにしました 専用のValkey（Redis互換のインメモリ KVS）を構築し、 外部APIへの通信が発生する直前で RateLimitをかけることにしました 詳しくは同僚のOgaさんが書いたテックブログを参照ください 「どのショップでもいつでも購入できるカート機能を目指してRateLimiter を導入した話」 https://devblog.thebase.in/entry/2026/06/29/103526 © 2012-2026 BASE, Inc. 30 30
31. トークンバケット RateLimitにはトークンバケットアルゴリズムを採用しています トークンバケットは、リクエストを通してよい数を「トークン」として貯めておく仕組みです リクエストが来るたびにトークンを 1つ消費し、トークンが残っていれば処理を通します トークンは一定速度で補充されるため、継続的な流量を制限しつつ、貯まっている分だけ一時的なアクセス集中も許 容できます © 2012-2026 BASE, Inc. 31 31
32. トークンバケットの動作 © 2012-2026 BASE, Inc. 32 32
33. 1ショップへの集中にキャップをかける アクセス集中の影響を、全体でどう受け止めるか アクセス集中ショップ用の上限 ① アクセス集中ショップがいない その他のショップが余さず使える ② アクセス集中ショップは上限未満 その他のショップの流量が多くても両者とも通 る ③ アクセス集中ショップが上限到達 その他のショップの取り分として残る その他のショップ アクセス集中ショップ その他のショップ × ここで頭打ち アクセス集中ショップ 引き算で残るその他のショップの取り分 ↑ アクセス集中ショップの消費 その他のショップの消費 空き アクセス集中ショップ用の上限 33 © 2012-2026 BASE, Inc. 33
34. グローバルバケットと専用バケット アクセス集中ショップ用に専用のトークンバケットを用意しました • 全ショップが共通のグローバルバケットからトークンを消費する • アクセス集中ショップだけアクセス集中ショップ用バケットからも追加で消費する • アクセス集中ショップ用バケットの上限をグローバルバケットより小さく設定する 判定のルールを整理すると、次のようになります • アクセス集中ショップ： グローバルバケットとアクセス集中ショップ用バケットの両方に空きがあってはじめて許可 • その他のショップ：グローバルバケットに空きがあれば許可 © 2012-2026 BASE, Inc. 34 34
35. バケット消費のフローチャート トークン消費要求 グローバルバケットに 空きがある？ ない × 制限 グローバル枠の枯渇 ない × 制限 専用レーン枠の枯渇 ある ✓ 許可 グローバルを消費 いいえ アクセス集中ショップ？ はい ✓ 許可 グローバル＋専用を消費 ある 専用バケットに空きがあ る？ © 2012-2026 BASE, Inc. 35 35
36. RateLimitのリリース こちらも検証のために負荷テストを行いました 先ほどのチャートの条件を満たす形で RateLimitがちゃんとかかるかどうか確認を進めた形です 現在はリリース済みで、高負荷状態の RateLimitの記録状況を見守りながら、設定の微調整を行っています 決済流量を調整できるようになり、全てのショップに安心して「 BASE」を使ってもらうことができます これでいつでも買えるようになりました © 2012-2026 BASE, Inc. 36 36
37. • 本日お話すること • 負荷テスト環境の構築 • 高負荷時のデータ分析 • ボトルネックを改善する • いつでも買えるようにする • まとめ 👈 © 2012-2023 BASE, Inc. 37
38. まとめ 負荷対策として以下のプロセスを行ってきました • 計測 ：外部 APIの応答時間やステータスコードを可視化し、高負荷時のログを永続化しました • 分析・仮説：情報取得系 APIのRateLimitがボトルネックであることを突き止めました • 対策 ：外部 APIの通信数を減らし、 1ショップの占有を避けるため RateLimiterを導入しました • 検証 ：負荷テストを行い、課題が解消されていることを検証しました 負荷対策は「計測」 →「分析・仮説」 →「対策」 →「検証」の繰り返しであることが分かります © 2012-2026 BASE, Inc. 38 38
39. チームで走り続ける 決済流量が増えるとまた次のボトルネックが表に出てきたため、今はその対策を行っています Checkout Reliabilityチームは走り続けます © 2012-2026 BASE, Inc. 39 39
40. 最後にBASEグループでは 価値の交換が最適化された未来をともに実現するメンバーを募集しています BASEグループ採用情報 https://binc.jp/jobs ご清聴ありがとうございました！！ © 2012-2026 BASE, Inc. 40 40