理Kotowary

サービス別の構成例 — 同じ部品の組み合わせ方

大人こども
初級中級上級

概要 — まず全体をつかむ

ここまでの部品（フロント・API・バック・DB・キャッシュ・ストレージ・キュー・CDN）を、実際のサービスに当てはめてみましょう。どれも同じ部品の組み合わせ方が違うだけです。

詳細 — 1段階ずつ追う

例1: SNS・チャット

  1. 投稿する → フロント→API→バック→DBに保存
  2. 添付の画像は → ストレージに保存（DBにはURLだけ）
  3. タイムラインは何度も見られる → キャッシュに載せてDB往復を減らす
  4. 「いいね通知」など → すぐ返さなくていいのでキューで後処理
  5. アイコン・CSS・JS → CDNで近くから配信
この部分をもっと深く（中級）
  • 読みが多い（SNSのタイムライン・記事） — キャッシュ、CDN、DBのリードレプリカで読みを分散
  • 書きの正しさが重要（決済・在庫） — トランザクションで整合性を守る。安易にキャッシュしない
  • リアルタイム（チャット・通知） — WebSocket／SSE でつなぎっぱなしに

通常のHTTPは「お願い→返す」の都度接続なので、更新が起きても聞くまで届きません。サーバから更新を押し出すには、つなぎっぱなしのWebSocket（双方向）やSSE（サーバ→クライアントの一方向push）を使います。

アニメーション『リアルタイム通信（WebSocket/SSE）』を開く
リアルタイム通信の3方式① 通常のHTTP（ポーリング）クライアントサーバ① お願い（リクエスト）② 返す（レスポンス）③ また最初から…（都度接続）更新が起きても、こちらが「聞く」まで届かない（毎回つなぎ直す）② WebSocket（双方向・開きっぱなし）クライアントサーバ送る →← 送る一度つなげば、どちらからでも即プッシュできる（双方向）③ SSE（サーバ→クライアントの一方向push）クライアントサーバ更新① を push更新② を push更新③ を pushサーバが更新を一方的に押し出す（クライアント→サーバの送信はできない）更新をサーバから届けたいときは WebSocket ／ SSE

SNSのタイムラインは「いつ配るか」で設計が分かれます。投稿時に各フォロワーへ配る（読みが速い）か、読むときに集める（書き込みが軽い）かのトレードオフです。

アニメーション『タイムラインの配り方（fan-out）』を開く
fan-out on write（書く時に配る）投稿時に配っておく投稿者1回投稿受信箱フォロワー毎受信箱フォロワー毎受信箱フォロワー毎読むとき速い ⇔ 書き込みが重い（配る先が多い）fan-out on read（読む時に集める）読むとき集めて作る投稿フォロー相手投稿フォロー相手投稿フォロー相手閲覧者読む時に要求書き込みが軽い ⇔ 読むときが重い（毎回集める）大量フォロワーの有名人は「読み時に集約」が定石（配る先が多すぎるため）

登場人物メモ:

  • ※1 リードレプリカ — 読み取り専用のDB複製。読みを逃がす
  • ※2 WebSocket — つなぎっぱなしの双方向通信

例2: ネットショップ

  1. 商品ページ（みんな同じ）→ CDN・キャッシュで高速化
  2. 在庫・注文・会員 → DBで正しく管理
  3. 支払い → 自前で持たず、外部の決済APIに委ねる
  4. 注文確定後のメール送信・集計 → キューで後回し
この部分をもっと深く（中級）
  • チャット — WebSocketで双方向、メッセージはDB＋キャッシュ、既読/通知はキュー
  • 動画配信 — アップロードは署名付きURLでストレージへ、変換はキュー、配信はCDN、視聴履歴はDB
  • ネットショップ — 商品はCDN/キャッシュ、在庫・注文はDBのトランザクション、決済は外部API、確定処理はキュー

どのサービスも同じ発想

  • 読み（見る）が多い → キャッシュ・CDN で軽くする
  • 書き（変える）の正しさが大事 → DB とトランザクション
  • 重い処理・急な増加 → キューで後回し、サーバを増やす

サービスの性質で「どの部品を厚くするか」が変わるだけ、と分かると、初めて見る構成図も読めるようになります。

この部分をもっと深く（中級）
  • スケール — ステートレス＋ロードバランサで水平に。状態はDB/キャッシュへ
  • 整合性 vs 速さ — 強整合が要る所（在庫・残高）と、多少古くてよい所（タイムライン）を分ける
  • 障害設計 — 単一障害点を避け、リトライ・タイムアウト・フォールバックを用意
  • 外部依存 — 決済・地図・通知などは外部APIに委ね、失敗時の扱いを決めておく

⚠️ サービス特有のボトルネック

  • 動画配信 — ストレージと配信（CDN）、変換処理（キュー）が主役で重い
  • SNS — 大量のタイムライン生成が重い（キャッシュ設計が肝）
  • ネットショップ — 在庫の同時購入など、正しさ（整合性）が難所
この部分をもっと深く（中級）
  • 何でもキャッシュ — 在庫や残高をキャッシュして二重販売・不整合
  • 同時実行の見落とし — レースコンディション（在庫・ポイント）
  • 外部API頼み — 決済APIが落ちたときの設計が無い
  • リアルタイムの過負荷 — 接続数の増加に耐える設計（水平分割）が要る

理解度チェック

そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。

問1. いろいろなWebサービスの構成に共通しているのは？

問2. 画像や動画が主役のサービスで、特に重くなるのは？

問3. SNSで投稿に付けた画像は、ふつうどこに保存する？

問4. 「いいね通知」や集計など、すぐに返さなくてよい重い処理はどう扱うのがよい？

問5. ネットショップの支払い処理は、ふつうどうするのがよい？

問6. みんなが見る同じ商品ページを速く返すために厚くするのはどれ？

問7. アイコン・CSS・JSなどを、世界中の利用者の近くから速く配る仕組みを英字3文字で何と呼ぶ？

問8. 在庫や注文のように「書きの正しさ」が大事なとき、DBでまとめて成功か失敗かを保証する仕組みを何と呼ぶ？