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

by ykagano

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

自己紹介氏名：加賀野祐（ ykagano）所属：BASE株式会社 BASE Department Product Division 役割：シニアエンジニア（バックエンド）趣味：お酒、旅行、キャンプ ykagano 2024年8月にBASE株式会社に入社その前は以下の開発を経験してきました - 2009年〜：NET CASH - 2012年〜：WebMoney - 2017年〜：Yahoo!ウォレット、 PayPay © 2012-2026 BASE, Inc. 22

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

改善し続ける高負荷への対策はこれまでも行ってきましたしかし利用者が増え、販売方法も多岐に渡る今、高負荷状態にも様々なパターンがあります・1つのショップの 1つの商品に購入が集中している・抽選や予約販売の商品で人気商品の販売が始まった・複数ショップで同時に人気商品の販売が始まったこうした本番環境で起こる様々な高負荷状態を分析し、対策し、負荷を再現して検証するには、継続的に改善するための体制が必要です © 2012-2026 BASE, Inc. 77

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

負荷テスト環境の構築まず進めたのは高負荷状態の再現でした今後も使えるよう、継続的な負荷テスト環境の構築を行いました詳しくはテックブログを参照ください「継続的な負荷テスト環境をBASEに構築しました〜第1回: 負荷テストの全体像」 https://devblog.thebase.in/entry/2026/04/15/110000 ここが「 BASE」の ECシステムの開発環境 © 2012-2026 BASE, Inc. 10 10

Slide 11

Slide 11 text

負荷テスト環境の構築システムに大量のリクエストを投げる詳しくはテックブログを参照ください「継続的な負荷テスト環境をBASEに構築しました〜第2回: 負荷生成ツールの構築と運用」 https://devblog.thebase.in/entry/2026/04/22/110000 負荷生成ツールには Locustを選定していますここから Locustがリクエスト © 2012-2026 BASE, Inc. 11 11

Slide 12

Slide 12 text

負荷テスト環境の構築外部通信先を代行するモックツールには詳しくはテックブログを参照ください「継続的な負荷テスト環境をBASEに構築しました〜第3回: モックツールの構築と運用」 https://devblog.thebase.in/entry/2026/04/28/110000 WireMockを選定していますここで WireMockが外部APIになる © 2012-2026 BASE, Inc. 12 12

Slide 13

Slide 13 text

負荷テスト環境の構築で工夫した点 Claude CodeでTerraformを使って構築したため、以前の手動構築に比べると構築スピードは何倍にもなっていると思いますしかし、それはあくまで構築の話で、構築の前提となる部分は人間のチェックが必要でした ● システム設計と技術選定 ● SREチームとの連携と責任範囲の確認（構築・運用は自チーム） ● 構築することで運用コストがどれくらい増えるかのコスト試算 ● 0→1でのAI Agentを使ったチーム開発（ Terraform, Docker構成, Locustのシナリオ等々）負荷改善を重ねた現在も課題を解決しつつ運用できているため、方向性は合っていたものと感じています © 2012-2026 BASE, Inc. 13 13

Slide 14

Slide 14 text

Slide 15

Slide 15 text

高負荷時のデータ分析高負荷時のデータを分析するため、以下の 2つの取り組みを行いました 1. NewRelicのカスタムイベントを追加し、外部 APIの応答時間、ステータスコードを計測しました 2. NewRelicでのログの保持期限がデフォルトでは 30日しかなかったことから、長期的な高負荷状態の計測を目的に、 Snowﬂakeにログを連携して分析できる環境を用意しました © 2012-2026 BASE, Inc. 15 15

Slide 16

Slide 16 text

1.外部APIの応答時間、ステータスコードを計測 NewRelicには外部 APIのメトリクス計測用に標準で Spanイベントが用意されていますが、サンプリングされた一部データしか計測されていません Spanイベントにあるデータをチャートで見るとこれに独自のカスタムイベントを追加することで星空のように散らばっています実測値で全て計測できるようにしました © 2012-2026 BASE, Inc. 16 16

Slide 17

Slide 17 text

Slide 18

Slide 18 text

2.Snowﬂakeにログを連携して分析 NewRelicをGraphQL APIで検索し、前日の対象期間のログを s3に格納した後、 Snowﬂakeに投入しています高負荷だった期間のログを検索する際に、以下の 2つの流れでデータを絞り込んでいます 1.粗スキャン 1日分を5分刻みの軽いクエリでざっと見て、◯ rps以上の時間帯を候補として拾います（5分平均に丸められた rpsになるため、閾値の低い篩にかけます） 2.精査スキャン候補区間だけを 1秒刻みで見直し、瞬間的に◯◯ rps以上出た区間だけを本物の高負荷として残します © 2012-2026 BASE, Inc. 18 18

Slide 19

Slide 19 text

Slide 20

Slide 20 text

2.Snowﬂakeにログを連携して分析 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

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

リリース前の負荷テストリリース前には負荷テストを実施しました負荷生成ツールがリクエストを送りモックツールが外部 APIを代行外部APIのRateLimitを再現するため、 Nginxを挟んで RateLimitをかけました結果、RateLimitに引っ掛からずに決済ができることを確認し、リリースしましたこれにより、決済流量を増やすことができました © 2012-2026 BASE, Inc. 25 25

Slide 26

Slide 26 text

今後もゾーン Aの通信数を増やさない Checkout Reliabilityチームは自分たちの管理する Checkoutモジュールのコードオーナーになっています他チームからの PullRequestにゾーン Aの通信数が増える改修が入っていたことがありましたその時は幸い気付くことができたので、通信が増えないようにしてもらいました恐ろしく何気ないプルリクオレでなきゃ見逃しちゃうね © 2012-2026 BASE, Inc. 26 26

Slide 27

Slide 27 text

AIのルールで気付けるようにする今後同じような変更が入ってくる場合があるため、対策が必要でした Checkoutモジュールの改修・レビューでは、 AIにコンテキストを与えるようにしていますそこに「ゾーン Aへのリクエストは最小限に抑える」というルールを追加しました以下の優先順位で通信量を抑えるようにしています ● 削減する : そのリクエストが本当に必要か確認し、不要なら送信しない ● 使い回す : 一連の処理の先頭で 1回だけ取得し、取得済みのオブジェクトを引数で引き回して再利用する © 2012-2026 BASE, Inc. 27 27

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

トークンバケット RateLimitにはトークンバケットアルゴリズムを採用していますトークンバケットは、リクエストを通してよい数を「トークン」として貯めておく仕組みですリクエストが来るたびにトークンを 1つ消費し、トークンが残っていれば処理を通しますトークンは一定速度で補充されるため、継続的な流量を制限しつつ、貯まっている分だけ一時的なアクセス集中も許容できます © 2012-2026 BASE, Inc. 31 31

Slide 32

Slide 32 text

Slide 33

Slide 33 text

1ショップへの集中にキャップをかけるアクセス集中の影響を、全体でどう受け止めるかアクセス集中ショップ用の上限 ① アクセス集中ショップがいないその他のショップが余さず使える ② アクセス集中ショップは上限未満その他のショップの流量が多くても両者とも通る ③ アクセス集中ショップが上限到達その他のショップの取り分として残るその他のショップアクセス集中ショップその他のショップ × ここで頭打ちアクセス集中ショップ引き算で残るその他のショップの取り分 ↑ アクセス集中ショップの消費その他のショップの消費空きアクセス集中ショップ用の上限 33 © 2012-2026 BASE, Inc. 33

Slide 34

Slide 34 text

グローバルバケットと専用バケットアクセス集中ショップ用に専用のトークンバケットを用意しました ● 全ショップが共通のグローバルバケットからトークンを消費する ● アクセス集中ショップだけアクセス集中ショップ用バケットからも追加で消費する ● アクセス集中ショップ用バケットの上限をグローバルバケットより小さく設定する判定のルールを整理すると、次のようになります ● アクセス集中ショップ：グローバルバケットとアクセス集中ショップ用バケットの両方に空きがあってはじめて許可 ● その他のショップ：グローバルバケットに空きがあれば許可 © 2012-2026 BASE, Inc. 34 34

Slide 35

Slide 35 text

Slide 36

Slide 36 text

RateLimitのリリースこちらも検証のために負荷テストを行いました先ほどのチャートの条件を満たす形で RateLimitがちゃんとかかるかどうか確認を進めた形です現在はリリース済みで、高負荷状態の RateLimitの記録状況を見守りながら、設定の微調整を行っています決済流量を調整できるようになり、全てのショップに安心して「 BASE」を使ってもらうことができますこれでいつでも買えるようになりました © 2012-2026 BASE, Inc. 36 36

Slide 37

Slide 37 text

Slide 38

Slide 38 text

まとめ負荷対策として以下のプロセスを行ってきました ● 計測：外部 APIの応答時間やステータスコードを可視化し、高負荷時のログを永続化しました ● 分析・仮説：情報取得系 APIのRateLimitがボトルネックであることを突き止めました ● 対策：外部 APIの通信数を減らし、 1ショップの占有を避けるため RateLimiterを導入しました ● 検証：負荷テストを行い、課題が解消されていることを検証しました負荷対策は「計測」 →「分析・仮説」 →「対策」 →「検証」の繰り返しであることが分かります © 2012-2026 BASE, Inc. 38 38