初級では「バケツリレー」で全体をつかみました。中級では、その1往復が HTTP という約束事の上で動くこと、各機械がどんな言葉で会話するかを見ます。
ここではシステム構成の各機械に焦点を当てます。URL入力から画面表示までの通信経路（DNS・TCP・TLS…）の詳細は URLを打ってから表示されるまで を参照してください。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
まず全体を1枚で
アニメーション『1リクエストの流れ（全体図）』を開く
1リクエストとは、HTTPリクエストを送り、HTTPレスポンスを受け取る1往復のこと。図の各ノードは、この往復の「どの区間」を担うかを表します。左のブラウザが起点、右のデータ層が終点です。
この部分をもっと深く（上級）
アニメーション『1リクエストの流れ（全体図）』を開く
1リクエストは、責務の違う4つの層を通り抜けます。層で分けて考えると、障害の切り分けもスケールの設計も一気に見通せます。
- インフラ層（入口） — ロードバランサ・WAF・リバースプロキシ。振り分け・防御・死活監視
- フロント層 — 画面（HTML／静的資産）の生成と配信
- バック層（API） — 認証・認可と業務ロジック。「何を返すか」の判断
- データ層 — DB・キャッシュ・ストレージ。事実の保管と取り出し
各層は「上の層は下の層の中身を知らなくてよい」ように責務の境界で仕切られています。だから1つの層だけを増強・交換できます。
やさしく言うと（初級）
アニメーション『1リクエストの流れ（全体図）』を開く
左のあなた（ブラウザ）から出たお願いが、右のデータまで往復して戻ってくる——これが1リクエストの流れです。各マスをクリックすると、その機械の解説へ飛べます（このあと1つずつ作っていきます）。
ポイントは2つの「囲い」：
- ネットワーク＝これらの機械をつなぐ土台。図の線はぜんぶネットワーク。
- セキュリティ＝あなたの手元（端末）以外を、まとめて守る囲い。
リクエストの旅（順番に追う）
- 名前解決（DNS ※1） —
example.comのような名前を、実際の宛先（IPアドレス）に変換する - 接続（TCP＋TLS ※2） — 相手と通信路を確立し、HTTPSなら暗号化の鍵を交換する
- HTTPリクエスト送信（※3） — メソッド（GET・POSTなど）＋パス＋ヘッダ（＋ボディ）を送る
- 静的は CDN（※4） — エッジがキャッシュを持てば即レスポンス（cache hit）。無ければオリジンへ取りに行く（miss）
- 入口（LB／リバースプロキシ／WAF ※5） — 空いているサーバへ振り分け、死活監視し、不正リクエストを遮断する
- フロント（※6） — 静的配信、または SSR で初期HTMLを生成。以降の中身はAPI経由で取得する
- API →バックエンド（※7） — REST/JSON などの形で要求。認証（誰か）・認可（何ができるか）を確認し、業務ロジックを実行する
- データ層 — DB（※8・SQLで問い合わせ）／キャッシュ（※9・hitでDB回避）／ストレージ（※10・大きな塊を配信）
- 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 レスポンス — ステータスコード＋ヘッダ＋ボディ
この部分をもっと深く（上級）
上から順に、それぞれの層で何が起きているかと、深掘り先を示します。
- インフラ層 — 入口のロードバランサが空いているサーバへ分散し、ヘルスチェックで異常な台を外す。これが後述の水平スケールの前提になる（→ ロードバランサ）。前段のWAFがアプリ層の攻撃を弾く
- フロント層 — 静的配信か、SSR（サーバ側でHTMLを組み立てる）か、CSR（ブラウザ側で組む）かを選ぶ。初期表示速度とSEOに直結する（→ フロントサーバ）
- バック層 — APIの窓口で認証（誰か）・認可（何をしてよいか）を確かめ、業務ロジックを実行する。サーバを増やせるよう状態を持たない（ステートレス）設計が要（→ API・バックエンドサーバ）
- データ層 — DBはインデックスで探索を速め、読み取りが増えればレプリケーションで読み書きを分離する（→ DBサーバ）。よく読む答えは手前のキャッシュで受ける（→ キャッシュ）。大きな塊はストレージから直接配る
各機械の内部は上のリンク先で深掘りします。ここで押さえたいのは、どの層に何の責務があり、どこが増やせて、どこが詰まりやすいかという全体の骨格です。
やさしく言うと（初級）
- あなた（ブラウザ ※1）が「このページください」とお願いを出す
- 画像や見た目の部品は、まず近くの CDN（※2） が持っていれば即返す（往復が短くて速い）
- データが要るお願いは、入口（※3） が受け取り、空いているサーバへ振り分ける（同時に、あやしいお願いは門番が弾く）
- フロントサーバ（※4） が画面の器を用意し、中身を バックエンド（※5） に頼む
- バックエンドが「何を返すか」を考え、必要なデータを DBサーバ（※6） に取りに行く
- よく使うデータは キャッシュ（※7） にあれば、DBまで行かずに即返す（近道）
- 画像・動画など大きな塊は ストレージサーバ（※8） から出す
- 集めたデータでバックが答えを組み立て、フロント経由であなたに返る → 画面が表示される
登場人物メモ（※の説明）:
- ※1 ブラウザ — あなたの手元の画面。お願いを出し、返ってきたものを表示する。この図では「フロント（前面）」の役
- ※2 CDN — 世界中に分散した“利用者の近くの倉庫”。変わらないもの（画像・CSS・JS）を配る係。無ければオリジンに取りに行く
- ※3 入口（ロードバランサ／WAF） — 混雑を捌く受付（振り分け）＋あやしいお願いを弾く門番
- ※4 フロントサーバ — 画面（見た目）を組み立てて返す係
- ※5 バックエンドサーバ — 「何を返すか」を考える頭脳。判断・計算・データ出し入れの指示
- ※6 DBサーバ — 表の形に整理されたデータの保管係。探す・並べるが得意
- ※7 キャッシュ — よく使う答えを手元に置く“メモ”。DBより速い（Redisなど）
- ※8 ストレージサーバ — 画像・動画・ファイルなど大きな塊の倉庫
速くする・強くするための工夫
- CDN — エッジキャッシュで静的配信をオリジンから剥がす。効果は cache hit 率で決まる
- キャッシュ（Redis等） — 読み取りの重い答えを手元に。整合性（古いデータ＝stale）と無効化がトレードオフ
- ロードバランサ — ラウンドロビン等で分散し、ヘルスチェックで異常サーバを外す。水平スケールの前提
- 非同期（キュー・ジョブ） — 重い処理はレスポンスと切り離し、後でジョブとして実行（メール送信・集計など）
この部分をもっと深く（上級）
利用者が増えても倒れないための、システム側の3本柱です。
- キャッシュ階層 — 速さは「どれだけ手前で答えを返せるか」で決まる。CDNエッジ → 共有キャッシュ（Redis等） → DB内のバッファと、手前ほど速く安い。難所は無効化——いつ古い答え（stale）を捨てるか。手前に置くほど鮮度管理が難しくなる（→ キャッシュ・CDN）
- 非同期（キュー・ジョブ） — メール送信・集計・画像変換など重い処理は、レスポンスと切り離してキューに積み、後でジョブとして実行する。利用者は待たされず、突発的な負荷はキューが吸収する（→ 非同期処理）
- 水平スケール — サーバ1台を強くする（垂直）のではなく、同じ役割の台を並べて入口で分散する。前提は各サーバがステートレスであること——状態を持たないから、どの台に振られても同じ結果になり、増減が自由になる
この3つはいずれも「1本道を太くする」のではなく「道を増やす／手前で折り返す／後回しにする」という発想です。
やさしく言うと（初級）
基本は「ブラウザ→入口→フロント→バック→DB」の一本道。そこに、快適さのための脇役が足されます。
- CDN — “配信”を速く。近くの倉庫から静的なものを返す
- キャッシュ — “処理”を速く。よく使う答えを手元に置き、DBまで行かない
- 入口（ロードバランサ） — 混雑に強く。同時に来たお願いを複数のサーバへ振り分ける
CDNとキャッシュは名前が似ていますが、CDN＝配信の近道／キャッシュ＝処理の近道、と向きが違います。
⚠️ うまくいかないとき
ステータスコードは「どの層で・何が起きたか」を読む手がかりです。
- 2xx 成功 — 200 OK など
- 3xx リダイレクト — 301（恒久）・302（一時）
- 4xx 依頼側の問題 — 400（不正）・401（未認証）・403（権限なし）・404（無い）・429（出しすぎ）
- 5xx 応答側の問題 — 500（内部エラー）・502（不正ゲートウェイ）・503（混雑）・504（タイムアウト）
遅いときのリトライ（再送）は、処理が二重に走らないか——冪等性（同じ操作を何度やっても結果が同じか）に注意します。
この部分をもっと深く（上級）
規模が大きい系では、1点の不調が連鎖して広がります。層で考えると連鎖の断ち方が見えます。
- カスケード障害 — 遅い依存先で滞留したリクエストがスレッド・接続プールを食い潰し、入口を共有する無関係な機能まで巻き込む。タイムアウト・サーキットブレーカ・隔離（bulkhead）で連鎖を断つ
- リトライストーム — 障害時の一斉再送がさらに負荷を積み増す。指数バックオフと、二重実行を防ぐ冪等性の設計で抑える
- 単一障害点（SPOF） — 1台落ちれば全体が止まる箇所。DBやLB自身を冗長化して消す
- キャッシュ雪崩 — 多数のキャッシュが同時に期限切れし、負荷がDBへ殺到する。期限をばらす・鍵ごとに再生成を1本に絞るなどで防ぐ
- 層をまたぐ切り分け — 「遅い／落ちた」がどの層で起きたかを、まず入口・フロント・バック・データのどこかに当てるのが調査の第一歩。ネットワーク経路側の切り分けは URLを打ってから表示されるまで を参照
やさしく言うと（初級）
- 混雑 — アクセスが集中。入口が複数サーバに分散するが、それでも溢れると「503（混んでいます）」
- 見つからない — そのページが無い →「404」
- 裏で失敗 — サーバの処理でエラー →「500」
- 遅い — 毎回DBまで行くと遅い → キャッシュ・CDNで近道を作る
どれも「どの機械で起きたか」を知っていると、原因の見当がつくようになります。
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. 「403 Forbidden」が返ってきた。最も近い原因は？
問2. HTTPSの「S」が主に担うのは？
問3. 「429 Too Many Requests」が返ってきた。最も近い意味は？
問4. リクエストの最初の一手であるDNSが担うのはどれ？
問5. HTTPリクエストを構成する4点セットとして正しいのは？
問6. 遅いときにリクエストを再送（リトライ）する際、まず気をつけるべき性質はどれ？
問7. CDNのエッジがキャッシュを持っていて、オリジンへ行かずに即返せた状態を英語2語で何と呼ぶ？
問8. サーバ側の予期しない内部エラーを表す、代表的なHTTPステータスコードを3桁の数字で答えよ。