中学生でも分かるアーキテクチャ解説
給食センター vs 各クラスの給食係
〜サーバー構成のたとえ話〜
従来型とエッジ型、どちらが速くて安全？
2つの給食方式を比べてみよう
あなたの学校はどっち？
＝ 従来型サーバー構成
┌─────────────────┐
│ 給食センター │ ← 1箇所で全校分を作る
│ （大きな工場） │
└────────┬────────┘
│
┌──────────┼──────────┐
│ │ │
▼ ▼ ▼
┌───┐ ┌───┐ ┌───┐
│1年│ │2年│ │3年│ ← 配送トラックで届ける
└───┘ └───┘ └───┘
- ●学校の外にある大きな工場で調理
- ●トラックで各学校に配送
- ●配膳室で受け取って各クラスへ
＝ エッジ型構成
┌───┐ ┌───┐ ┌───┐
│1-1│ │1-2│ │1-3│
│係 │ │係 │ │係 │ ← 各クラスに給食係
└───┘ └───┘ └───┘
↓ ↓ ↓
すぐ すぐ すぐ ← 目の前で配膳
配膳 配膳 配膳
※ 材料は共通倉庫から取り寄せ
- ●各クラスに給食係がいる
- ●材料は共通の倉庫から
- ●目の前ですぐに配膳
比較① 行列（待ち時間）
お腹が空いているのに待たされる？
配膳室の前に長い行列ができる
🧑🧑🧑🧑🧑🧑🧑🧑 → [配膳室] → 🍽️
「まだかなー」「お腹すいた...」
問題: 全員が1箇所に集まるので行列ができる
サーバーで言うと → ロードバランサーで振り分けても、サーバー台数に限りがあるので混雑時は待たされる
各クラスで同時に配膳
[1-1] 🍽️🍽️🍽️ ← 30人分を係が配膳
[1-2] 🍽️🍽️🍽️ ← 30人分を係が配膳
[1-3] 🍽️🍽️🍽️ ← 30人分を係が配膳
「みんな同時にいただきます！」
解決: 各クラスで同時に配膳するから行列ゼロ
サーバーで言うと → エッジサーバーが世界中にあるので、近くのサーバーがすぐ対応
結論: ロードバランサーで行列を整理するより、そもそも行列を作らない方が速い
比較② 管理負担
誰がどれだけ大変？
🏭 給食センターの管理
調理師の配置、衛生管理、設備メンテナンス
🚚 配送トラックの管理
ドライバーの手配、車両メンテナンス、配送ルート
📋 配膳室の管理
受け取り確認、保温管理、食器の回収
📊 数量管理
「今日は何人分作る？」を毎日計算
サーバーで言うと → Nginx, Express, ORM, PostgreSQL, Redis, Worker, Cron... 全部自分で管理
👋 給食係の仕事だけ
「今日のメニューはこれ」と配るだけ
🏪 材料の倉庫は共通
倉庫の管理は業者さんにおまかせ
管理不要になるもの:
- ✓ 工場の管理 → 不要
- ✓ トラックの管理 → 不要
- ✓ 配膳室の管理 → 不要
- ✓ 数量予測 → 必要な分だけ自動で
サーバーで言うと → Cloudflareが全部やってくれる。自分はコードを書くだけ
結論:セッション管理不要、接続プール不要。本当に必要なこと（料理を配る）だけに集中できる
比較③ 準備時間（Cold Start）
「お腹すいた！」と言われてからどれくらいで出せる？
朝6時: 工場を起動（電気・ガス・水道）
↓
朝7時: 調理開始
↓
朝10時: 調理完了
↓
朝11時: トラック出発
↓
昼12時: やっと届く！
【準備時間: 約6時間】
問題:工場が止まっていると起動に時間がかかる
サーバーで言うと → Cold Start: コンテナ起動に100〜500ms、DBコネクション確立に追加時間
昼12時: 「お腹すいた！」
↓
昼12時: 給食係がすぐ配膳開始
↓
昼12時: もう食べられる！
【準備時間: 0秒】
※ 給食係は常にスタンバイ中
解決:給食係はいつでも準備OK
サーバーで言うと → Cold Start 0ms: V8 Isolateで即座に起動、DBコネクション管理も不要
| サービス | Cold Start時間 | 給食で例えると |
|---|---|---|
| AWS Lambda (Node.js) | 100〜500ms | トラックがエンジンかけて出発するまで |
| Cloud Functions | 100〜300ms | 配膳室の準備が終わるまで |
| Cloudflare Workers | 0ms | 「はい、どうぞ！」ですぐ配膳 |
結論:Cold Start 0ms。「お腹すいた」と言われた瞬間に配膳できる
比較④ 事故耐性
もし問題が起きたら？
🏭 工場で火事が起きたら？
→ 全校の給食がストップ
🚚 トラックが故障したら？
→ その学校の給食が届かない
🦠 食中毒が起きたら？
→ 全校に被害が広がる
サーバーで言うと → データセンター障害で全サービス停止、DDoS攻撃で全ユーザー影響
👋 1組の給食係が休んだら？
→ 隣のクラスの係が手伝う。他のクラスは影響なし
🏪 倉庫の材料が切れたら？
→ 近くの別の倉庫からすぐ補充
🦠 1クラスで問題が起きたら？
→ そのクラスだけ対応。他は通常運転
サーバーで言うと → 1つのエッジが落ちても他が対応、DDoS攻撃もCloudflareが自動防御
結論:1箇所が止まっても他が自動でカバー。 全体が止まることはない
Before / After まとめ
従来型とエッジ型の違い
┌─────────────────────────────────────┐
│ 従来型構成 │
├─────────────────────────────────────┤
│ │
│ ユーザー │
│ │ │
│ ▼ │
│ [ロードバランサー] ← 行列整理係 │
│ │ │
│ ▼ │
│ [Webサーバー(Nginx)] ← 受付 │
│ │ │
│ ▼ │
│ [アプリサーバー(Express)] │
│ │ ← 調理担当 │
│ │ │
│ ┌──┴──┬──────┬──────┐ │
│ ▼ ▼ ▼ ▼ │
│ [DB] [Redis] [Worker] [Cron] │
│ ↑ ↑ ↑ ↑ │
│ └─────┴──────┴──────┘ │
│ 全部自分で管理 │
│ │
└─────────────────────────────────────┘
┌─────────────────────────────────────┐
│ エッジ型構成 │
├─────────────────────────────────────┤
│ │
│ ユーザー（東京） ユーザー（大阪） │
│ │ │ │
│ ▼ ▼ │
│ [Workers] [Workers] │
│ (東京エッジ) (大阪エッジ) │
│ │ │ │
│ └────────┬─────────┘ │
│ ▼ │
│ ┌────────────────┐ │
│ │ Firestore / R2 │ │
│ │ (データ保管) │ │
│ └────────────────┘ │
│ ↑ │
│ Cloudflareが管理 │
│ │
└─────────────────────────────────────┘
| 比較項目 | 給食センター方式（従来型） | 各クラス給食係方式（エッジ型） |
|---|---|---|
| 行列（待ち時間） | 配膳室に行列 | 行列なし（各クラスで配膳） |
| 管理負担 | 工場・トラック・配膳室を管理 | 給食係の仕事だけ |
| 準備時間 | 工場起動に時間がかかる | いつでも即座に対応 |
| 事故耐性 | 工場が止まると全校停止 | 1クラス止まっても他は通常 |
結論
エッジ型構成を選ぶ理由
ロードバランサー不要
行列を整理する人がいらない。そもそも行列ができないから。
🍽️ 各クラスで同時に配膳するので、配膳室に並ばなくていい
セッション管理不要
「この人は誰」を覚えておく仕組みがいらない。
🍽️ 給食係は自分のクラスの生徒だけ覚えていればいい
接続プール不要
データベースへの接続を使い回す仕組みがいらない。
🍽️ 材料倉庫は全員が自由にアクセスできる共有スペース
Cold Start 0ms
起動待ち時間ゼロ。いつでも即座に対応。
🍽️ 給食係は常にスタンバイ中。「お腹すいた」で即配膳
大きな給食センターより、
各クラスの給食係の方が速くて安全
従来型は「1箇所で全部やる」ので、その1箇所が混んだり止まったりすると大変。
エッジ型は「近くで分散してやる」ので、速くて、止まりにくい。
大人向け一文要約
「従来型アーキテクチャのロードバランサー、セッション管理、コネクションプールは、中央集権型の設計に起因する複雑性であり、 エッジコンピューティングではそもそも不要になる。 結果として、Cold Start 0msと99.9%の可用性を、より少ないコードと低コストで実現できる。」