PHPで作られた大規模ECサイトから学ぶ負荷対策入門 in PHP Conference 2026

https://fortee.jp/phpcon-2026/proposal/fc3d00e7-91ab-431a-94ae-d79601d9d585

Transcript

1. PHPで作られた大規模 ECサイトか ら学ぶ負荷対策入門 PHP Conference 2026 合同会社DMM.com 二次元コンテンツ開発部 尾崎耕多 日付やバージョンなど © DMM
2. About me 合同会社DMM.com 二次元コンテンツ開発部 テックリード 尾崎 耕多 © DMM 2
3. デジタルコンテンツを扱う ECサービスの話をします © DMM 3
4. ECサービスの特徴 © DMM
5. ECサービスの特徴 クリエイ ター向け 運営向け 共通DB 社内API2 社内API1 社内API N EC 元々全社で1つのシステムだったのがここまで分割された ECはアグリゲーションでユーザー最適化された描画が行われている © DMM 5
6. ECサービスの特徴 - 毎年PV数が140％前後の増加 - 0時過ぎにアクセスピーク - 休日にアクセス量が増加 - 月初にアクセス量が増加 - 夏/冬の大規模イベント後にアクセス量が増加 - クーポン/キャンペーンでアクセス量が増加 - キャンペーン終了タイミングでアクセス量が増加 © DMM 6
7. ECサービスの特徴 冬のキャンペーンは先にあげたアクセス増加要因が全て入る 毎年の最大ピークは年初に記録されます というのもあり、2023、2024の冬キャンペーンではアクセスに耐えきれずに障害が発生していました © DMM 7
8. 基礎としての PHPのキャパシティ確保 © DMM
9. 基本は計測と算出 下記の式が成り立つようにする 要求処理数/秒 = 基準日の処理数/秒 x ( 1 + 想定増加率 + α ) 要求処理数/秒 = 秒間処理数/台 x サーバー台数 秒間処理数/台 = pm.max_children x 1000ms / 平均処理時間ms pm.max_children = 割り当て可能なメモリ / memory_limit 基準日の処理数、平均処理時間msは計測から取得する。特に今入っていないならAPMを入れると最 低限必要なものは取得できる ※ PHP-FPMの例 ※ 1つの考え方で常にこれに合わせる必要はない © DMM 9
10. DBやキャッシュ、APIの接続数を算出する PHPからの接続先は下記の式が成り立つようにする 最大同時接続数 = pm.max_children x サーバー台数 接続先の最大接続数 >= 最大同時接続数 レプリカなどで複数台に分散する場合は下記の式が成り立つようにする 接続先の最大接続数 >= 最大同時接続数 / 台数 * 偏り係数 これは成り立たない場合は最悪ケースでは接続上限でエラーが発生する ※ 1つの考え方で常にこれに合わせる必要はない。非同期系入れてると成り立たない © DMM 10
11. 負荷をかけて検証する 負荷をかけないと見えないメトリクスはある。要求レート増加に対してレイテンシが悪化するさいには何 らかのボトルネックが顕在化している。オートスケール環境では逆の動きになることも多い。理想として はレイテンシは常に一定になる状態が望ましい © DMM 11
12. 計測 検証 仮説 計測、仮説、検証のサイクル 仮説を立てれないときは計測漏れの可能性を疑い計測の追加、詳細化を行う © DMM 12
13. 2023年、2024年の 冬のキャンペーンで発生した問題 © DMM
14. 2023年 冬キャンペーン障害 購入後処理が捌ききれずに購入した作品を表示できなくなった バスケット レジ 購入 後処理 1. 0時前にクーポンの期限間際の駆け込み需要で購入上限数の購入が多く発生 2. それに伴いDBが高負荷になる 3. 後処理が遅延＆滞留によりDBでToo many connectionsでリトライが発生しさらに遅延 4. 0時過ぎのピーク後に購入減少し、順次リトライすることによって収束 © DMM 14
15. 2024年 冬キャンペーン障害 Redisの遅延によりサービス全体で遅延やDBエラーが発生 データ取得 Redis DB 1. ピークタイムの0時過ぎになるとRedisで遅延が発生 2. それにともないDBの接続がスパイクしToo many connectionsの発生 3. 一部機能で利用不可、遅延、購入不整合などの多大な影響が発生 © DMM 15
16. 問題が連鎖することでサービスに影響がでる 問題の起因を解決する、影響の連鎖を止めるの2軸が重要になる © DMM 16
17. 2025年冬キャンペーンのために ボトルネックを特定し問題を解決する © DMM
18. 問題を分解する 2024年のRedis遅延の問題は5つぐらいの問題の複合で起きている 端的に言えばRedisの処理能力不足だがその引き金は複数の事象が引いている © DMM 18
19. 事実を元にタイムラインを書く 23:59 00:00 キャッシュ解放バッチが動作 Redisのexpired_keysがXX増 加RedisのCPU使用率がYY増 加 キャッシュ解放ジッターが動作 開始 Redisのexpired_keysがXX増 加RedisのCPU使用率がYY増 加 00:01 00:02 キャッシュ解放バッチが終了 - Redisのexpired_keysの増加 率がXX減少 RedisのCPU使用率がYY減少 Redisのgetのレイテンシが XX 増加 該当時間帯に起きたこと、変化したメトリクスを時系列にまとめる 前後関係が重要なことが多いので可能なら秒単位でまとめられるのが望ましい あくまでも仮説を立てるための道具であり完全である必要はない ※ メトリクスだけで仮説を立てられることはあるので必ずしもタイムラインは必須ではない © DMM 19
20. タイムラインから仮説を立てる タイムラインを元に仮説を立てる 1. 5分間隔でレイテンシが悪化しており、同間隔で動作するバッチが負荷をかけている => バッチを改善する 2. 新規コネクションスパイクと一部連動しておりコネクション処理が負荷をかけている => ECからの接続を永続化する 仮説が立たない、実際のタイムラインやメトリクスでは説明がつかないときは必要なメトリクスが不足し ていることが多い また複合要因の場合は想定した1つの原因と結果が必ずしも一致しないことがある 仮説は必ずしも1つである必要はなく、思いつくものを洗い出すと次策が手に入る © DMM 20
21. 仮説を検証する 仮説を元に修正を行い、仮説通りの変化がおきるか検証をする 仮説なので必ずしも問題が解決する訳ではない また複合要因の場合はそれで緩和しても解決には至らない © DMM 21
22. 計測 検証 仮説 計測、仮説、検証のサイクル 問題が解決するまでサイクルを繰り返すのが重要になる © DMM 22
23. 2025年冬キャンペーンのために サービス継続性を高める © DMM
24. 障害を前提に設計する 過去の問題を対策すれば未来に問題が起きないわけではない 問題は必ず起きるものとして扱いその上でサービスをデザインする © DMM 24
25. レジリエンスを高める手法 © DMM Bulkhead Graceful Degradation リソースを分離して 障害の波及を防ぐ 手法 非重要機能を縮退 し重要な機能を継 続させる手法 Webサーバーを分 けて振り分け、専用 DBレプリカを設け るなど 機能の非表示化や 直近キャッシュの 表示など Fail Fast 成功が見込めない 処理を早期に打ち 切り滞留を防ぐ手 法 適切なタイムアウト 設定や過負荷時の 早期拒否など 25
26. 無条件に入れられるものではないことに注意 ECサービスでもトレードオフを見極めた上で採用している © DMM 26
27. そして2025年冬キャンペーン © DMM
28. 無事に冬キャンペーンを乗り越えました 2024年を超えるピーク負荷の状況で、無事故で乗り越えることができました © DMM 28
29. 時間が余ってたら話す ・障害は冬キャンペーンだけでなく随時ポストモーテムを行い改善が行われている ・毎朝のメトリクスチェックからのパフォーマンス改善は随時行われている ・キャンペーン中には毎週別途パフォーマンス確認のMTGを実施 ・毎回キャンペーンの前にキャパシティ予測を行い、関係チームと調整 ・各開発チームと毎月ヒアリング会を実施して、状況や問題の確認 ・可視化の強化も随時行われこの2年で見えない領域はかなりなくなった - 可視化によって見えるようになり、問題の把握、予測の精度が向上 した ・全体として問題に対処する世界から、問題を事前に潰す攻めの世界への変化 ・とは言っても、もちろん全てが完全な状況ではない © DMM 29
30. まとめ © DMM
31. 計測 検証 仮説 大事なのはサイクルを回すこと、回し続けること 銀の弾丸はないので泥臭くやりましょう © DMM 31
32. © DMM
33. ご清聴ありがとうございました © DMM