ボタンを押してから、画面が返ってくるまで

1リクエストは、責務の違う4つの層を通り抜けます。層で分けて考えると、障害の切り分けもスケールの設計も一気に見通せます。

• インフラ層（入口） — ロードバランサ・WAF・リバースプロキシ。振り分け・防御・死活監視
• フロント層 — 画面（HTML／静的資産）の生成と配信
• バック層（API） — 認証・認可と業務ロジック。「何を返すか」の判断
• データ層 — DB・キャッシュ・ストレージ。事実の保管と取り出し

各層は「上の層は下の層の中身を知らなくてよい」ように責務の境界で仕切られています。だから1つの層だけを増強・交換できます。

上から順に、それぞれの層で何が起きているかと、深掘り先を示します。

1. インフラ層 — 入口のロードバランサが空いているサーバへ分散し、ヘルスチェックで異常な台を外す。これが後述の水平スケールの前提になる（→ ロードバランサ）。前段のWAFがアプリ層の攻撃を弾く
2. フロント層 — 静的配信か、SSR（サーバ側でHTMLを組み立てる）か、CSR（ブラウザ側で組む）かを選ぶ。初期表示速度とSEOに直結する（→ フロントサーバ）
3. バック層 — APIの窓口で認証（誰か）・認可（何をしてよいか）を確かめ、業務ロジックを実行する。サーバを増やせるよう状態を持たない（ステートレス）設計が要（→ API・バックエンドサーバ）
4. データ層 — DBはインデックスで探索を速め、読み取りが増えればレプリケーションで読み書きを分離する（→ DBサーバ）。よく読む答えは手前のキャッシュで受ける（→ キャッシュ）。大きな塊はストレージから直接配る

各機械の内部は上のリンク先で深掘りします。ここで押さえたいのは、どの層に何の責務があり、どこが増やせて、どこが詰まりやすいかという全体の骨格です。

利用者が増えても倒れないための、システム側の3本柱です。

• キャッシュ階層 — 速さは「どれだけ手前で答えを返せるか」で決まる。CDNエッジ → 共有キャッシュ（Redis等） → DB内のバッファと、手前ほど速く安い。難所は無効化——いつ古い答え（stale）を捨てるか。手前に置くほど鮮度管理が難しくなる（→ キャッシュ・CDN）
• 非同期（キュー・ジョブ） — メール送信・集計・画像変換など重い処理は、レスポンスと切り離してキューに積み、後でジョブとして実行する。利用者は待たされず、突発的な負荷はキューが吸収する（→ 非同期処理）
• 水平スケール — サーバ1台を強くする（垂直）のではなく、同じ役割の台を並べて入口で分散する。前提は各サーバがステートレスであること——状態を持たないから、どの台に振られても同じ結果になり、増減が自由になる

この3つはいずれも「1本道を太くする」のではなく「道を増やす／手前で折り返す／後回しにする」という発想です。

規模が大きい系では、1点の不調が連鎖して広がります。層で考えると連鎖の断ち方が見えます。

• カスケード障害 — 遅い依存先で滞留したリクエストがスレッド・接続プールを食い潰し、入口を共有する無関係な機能まで巻き込む。タイムアウト・サーキットブレーカ・隔離（bulkhead）で連鎖を断つ
• リトライストーム — 障害時の一斉再送がさらに負荷を積み増す。指数バックオフと、二重実行を防ぐ冪等性の設計で抑える
• 単一障害点（SPOF） — 1台落ちれば全体が止まる箇所。DBやLB自身を冗長化して消す
• キャッシュ雪崩 — 多数のキャッシュが同時に期限切れし、負荷がDBへ殺到する。期限をばらす・鍵ごとに再生成を1本に絞るなどで防ぐ
• 層をまたぐ切り分け — 「遅い／落ちた」がどの層で起きたかを、まず入口・フロント・バック・データのどこかに当てるのが調査の第一歩。ネットワーク経路側の切り分けは URLを打ってから表示されるまで を参照