APサーバ増設で改善しないECサイトのレスポンス劣化

結論：ボトルネックはAPではなくDBであり、APの増設はDBへの同時要求を増やして競合を悪化させた。

• レスポンスタイムの65%がDB待ちである以上、AP側の処理能力をいくら上げても全体の6割は短くならない。アムダールの法則でいえば、改善できる上限は約1.5倍（1÷0.35）にとどまる。
• コネクションプールは4台で合計80本、8台なら160本になるが、DBの最大同時接続数は100本である。100本を超えた接続はDB側で待たされ、AP台数を増やすほど待ち行列の長さが増す。
• DBのCPU使用率は60%で余裕があるのに待ちが大きい。これはCPU不足ではなく、I/O待ち（1件あたり40ms）とロック待ちによる直列化が支配的であることを意味する。CPUが空いていても処理は進まない。
• 増設後にロック待ちが急増したという監視結果は、同一行・同一ページへの更新競合が並列度の上昇で顕在化したことを示す。

したがって「APのCPU使用率95%」は、DB待ちでスレッドが滞留した結果としての見かけの高稼働であり、原因ではなく症状である。

施策1：参照系をDBから引き離す（キャッシュまたはリードレプリカ）

• 根拠：ピーク時リクエストの7割が更新を伴わない検索・在庫参照である。ここをAP前段のキャッシュやリードレプリカへ逃がせば、DBに到着する要求を大きく減らせ、ロック競合も同時に下がる。効果はリクエスト比率から見積もれる。
• 副作用：在庫の鮮度が落ちる。何秒までの遅れを業務が許容するかを商品区分ごとに決め、TTLと無効化の契機（更新イベント）を設計する必要がある。カート投入時の在庫確認だけは本番DBを参照するなど、参照先の使い分けが要る。

施策2：ホットスポット行の排他制御を見直す

• 根拠：ロック待ちの急増は特定行への集中が原因と考えられる。在庫引当を行の分割（確保数のパーティション化）や非同期の引当キューに変えれば、直列化の範囲を狭められる。
• 副作用：引当確定までの遅延と、二重引当を防ぐ補償処理・冪等キーの実装が必要になる。売り越しが許されない商材では、同期処理を残す判断もありうる。

補足として、AP側のプール合計をDBの最大接続数以下に保ち、取得タイムアウトとサーキットブレーカで待ちをAP側で打ち切る設定変更は、追加費用なしで同時に実施すべきである。

1. レイテンシの積み上げ：外部ストアへの参照が全リクエストに加わるため、往復回数を減らす（一度の取得でまとめる）、AP側に短TTLのローカルキャッシュを持たせる、同一AZ内に配置するなどの設計が要る。ここを誤ると、DB待ちを減らした分をセッション参照で食いつぶす。
2. ステートレス前提への再設計：スティッキーを外すと、画面遷移の途中状態や二重送信防止をセッション保持に頼れなくなる。トークン方式の二重送信対策、楽観ロック、画面ごとの状態の持ち方を見直す必要がある。カート内容の取りこぼしは直接売上損失になる。
3. 障害時の縮退と個人情報の最小化：外部ストアが落ちたときに再認証を求めるのか、閲覧だけ継続させるのかをあらかじめ決め、TTLと失効通知を設計する。セッションには会員IDなどの識別子だけを置き、クレジットカード情報や住所を保持しない。