検索ボタンを押すと、一瞬で結果が返ってくる。あの数百ミリ秒のあいだに、裏では何台もの機械がバケツリレーをしています。まず全体を1枚の地図で見て、次に順番に追いかけましょう。
この記事は「サービス全体の構成の旅」です。そもそもURL入力から画面表示までの通信経路の詳細は URLを打ってから表示されるまで で見られます。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
まず全体を1枚で
アニメーション『1リクエストの流れ（全体図）』を開く
左のあなた（ブラウザ）から出たお願いが、右のデータまで往復して戻ってくる——これが1リクエストの流れです。各マスをクリックすると、その機械の解説へ飛べます（このあと1つずつ作っていきます）。
ポイントは2つの「囲い」：
- ネットワーク＝これらの機械をつなぐ土台。図の線はぜんぶネットワーク。
- セキュリティ＝あなたの手元（端末）以外を、まとめて守る囲い。
この部分をもっと深く（中級）
アニメーション『1リクエストの流れ（全体図）』を開く
1リクエストとは、HTTPリクエストを送り、HTTPレスポンスを受け取る1往復のこと。図の各ノードは、この往復の「どの区間」を担うかを表します。左のブラウザが起点、右のデータ層が終点です。
リクエストの旅（順番に追う）
- あなた（ブラウザ ※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 ストレージサーバ — 画像・動画・ファイルなど大きな塊の倉庫
この部分をもっと深く（中級）
- 名前解決（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 レスポンス — ステータスコード＋ヘッダ＋ボディ
速くする・強くするための工夫
基本は「ブラウザ→入口→フロント→バック→DB」の一本道。そこに、快適さのための脇役が足されます。
- CDN — “配信”を速く。近くの倉庫から静的なものを返す
- キャッシュ — “処理”を速く。よく使う答えを手元に置き、DBまで行かない
- 入口（ロードバランサ） — 混雑に強く。同時に来たお願いを複数のサーバへ振り分ける
CDNとキャッシュは名前が似ていますが、CDN＝配信の近道／キャッシュ＝処理の近道、と向きが違います。
この部分をもっと深く（中級）
- CDN — エッジキャッシュで静的配信をオリジンから剥がす。効果は cache hit 率で決まる
- キャッシュ（Redis等） — 読み取りの重い答えを手元に。整合性（古いデータ＝stale）と無効化がトレードオフ
- ロードバランサ — ラウンドロビン等で分散し、ヘルスチェックで異常サーバを外す。水平スケールの前提
- 非同期（キュー・ジョブ） — 重い処理はレスポンスと切り離し、後でジョブとして実行（メール送信・集計など）
⚠️ うまくいかないとき
- 混雑 — アクセスが集中。入口が複数サーバに分散するが、それでも溢れると「503（混んでいます）」
- 見つからない — そのページが無い →「404」
- 裏で失敗 — サーバの処理でエラー →「500」
- 遅い — 毎回DBまで行くと遅い → キャッシュ・CDNで近道を作る
どれも「どの機械で起きたか」を知っていると、原因の見当がつくようになります。
この部分をもっと深く（中級）
ステータスコードは「どの層で・何が起きたか」を読む手がかりです。
- 2xx 成功 — 200 OK など
- 3xx リダイレクト — 301（恒久）・302（一時）
- 4xx 依頼側の問題 — 400（不正）・401（未認証）・403（権限なし）・404（無い）・429（出しすぎ）
- 5xx 応答側の問題 — 500（内部エラー）・502（不正ゲートウェイ）・503（混雑）・504（タイムアウト）
遅いときのリトライ（再送）は、処理が二重に走らないか——冪等性（同じ操作を何度やっても結果が同じか）に注意します。
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. 画像やCSSなど「変わらないもの」を、利用者の近くから速く配る係はどれ？
問2. CDN と（アプリの）キャッシュの違いとして正しいのは？
問3. 「何を返すか」を考える頭脳として、判断・計算・データ出し入れの指示を担うのはどれ？
問4. 同時に来たお願いを空いているサーバへ振り分け、あやしいお願いを弾く「入口」の役はどれ？
問5. 表の形に整理されたデータを保管し、探す・並べるのが得意な係はどれ？
問6. アクセスが集中し、入口が振り分けても捌ききれず溢れたときに返りやすいのはどれ？
問7. よく使う答えを手元に置き、DBまで行かずに即返す“処理の近道”の仕組みを何と呼ぶ？
問8. 画像・動画・ファイルなど「大きな塊」を保管する倉庫のサーバを何サーバと呼ぶ？