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

1リクエストとは、HTTPリクエストを送り、HTTPレスポンスを受け取る1往復のこと。図の各ノードは、この往復の「どの区間」を担うかを表します。左のブラウザが起点、右のデータ層が終点です。

1. 名前解決（DNS ※1） — example.com のような名前を、実際の宛先（IPアドレス）に変換する
2. 接続（TCP＋TLS ※2） — 相手と通信路を確立し、HTTPSなら暗号化の鍵を交換する
3. HTTPリクエスト送信（※3） — メソッド（GET・POSTなど）＋パス＋ヘッダ（＋ボディ）を送る
4. 静的は CDN（※4） — エッジがキャッシュを持てば即レスポンス（cache hit）。無ければオリジンへ取りに行く（miss）
5. 入口（LB／リバースプロキシ／WAF ※5） — 空いているサーバへ振り分け、死活監視し、不正リクエストを遮断する
6. フロント（※6） — 静的配信、または SSR で初期HTMLを生成。以降の中身はAPI経由で取得する
7. API →バックエンド（※7） — REST/JSON などの形で要求。認証（誰か）・認可（何ができるか）を確認し、業務ロジックを実行する
8. データ層 — DB（※8・SQLで問い合わせ）／キャッシュ（※9・hitでDB回避）／ストレージ（※10・大きな塊を配信）
9. HTTPレスポンス（※11） — ステータスコード＋ヘッダ＋ボディを返す。逆順で戻り、ブラウザが描画する

登場人物メモ（※の説明）:

• ※1 DNS — ドメイン名→IPアドレスの電話帳。最初の一手
• ※2 TCP／TLS — 順序と到達を保証する通信路（TCP）＋暗号化（TLS）。HTTPSは「HTTP over TLS」
• ※3 HTTPリクエスト — メソッド・パス・ヘッダ・ボディの4点セット
• ※4 CDN — エッジのキャッシュ。TTLで鮮度を管理し、cache hit/miss で振る舞いが変わる
• ※5 入口 — ロードバランサ（振り分け・ヘルスチェック）／リバースプロキシ／WAF（アプリ層の防御）
• ※6 フロント — 静的配信か SSR（サーバ側でHTMLを組み立てる）か
• ※7 API／バック — REST・GraphQL などの窓口。認証と認可を確認してから処理
• ※8 DB — SQLで構造データに問い合わせ。インデックスで探索を速くする
• ※9 キャッシュ — Redis など。読み取りの多い答えを載せる。難所は「無効化（いつ捨てるか）」
• ※10 ストレージ — オブジェクトストレージ。大きなファイルは署名付きURLで直接配ることも
• ※11 レスポンス — ステータスコード＋ヘッダ＋ボディ

• CDN — エッジキャッシュで静的配信をオリジンから剥がす。効果は cache hit 率で決まる
• キャッシュ（Redis等） — 読み取りの重い答えを手元に。整合性（古いデータ＝stale）と無効化がトレードオフ
• ロードバランサ — ラウンドロビン等で分散し、ヘルスチェックで異常サーバを外す。水平スケールの前提
• 非同期（キュー・ジョブ） — 重い処理はレスポンスと切り離し、後でジョブとして実行（メール送信・集計など）

ステータスコードは「どの層で・何が起きたか」を読む手がかりです。

• 2xx 成功 — 200 OK など
• 3xx リダイレクト — 301（恒久）・302（一時）
• 4xx 依頼側の問題 — 400（不正）・401（未認証）・403（権限なし）・404（無い）・429（出しすぎ）
• 5xx 応答側の問題 — 500（内部エラー）・502（不正ゲートウェイ）・503（混雑）・504（タイムアウト）

遅いときのリトライ（再送）は、処理が二重に走らないか——冪等性（同じ操作を何度やっても結果が同じか）に注意します。