理Kotowary

バックエンドサーバ — 「何を返すか」を考える頭脳

大人こども
初級中級上級

概要 — まず全体をつかむ

中級ではAPI・スケール・データアクセスを見ました。上級では、分散システムとしてのバックエンド——部分的に壊れる前提の設計へ。

詳細 — 1段階ずつ追う

分散は「部分故障」との戦い

1台の中では成功か失敗の二択ですが、サービスが分かれると「一部だけ落ちる・遅れる・返事が来ない」 が日常になります。ここが分散システムの本質的な難しさです。

  • ステートレス化 — 状態はDB／キャッシュ／トークンへ逃がし、どの台でも処理可能に
  • 境界の設計 — サービス分割の粒度、同期呼び出しの連鎖を減らす
やさしく言うと（中級）

バックエンドは、フロントからの要求を受けて業務ロジックを実行し、データ層を操作して結果を返すサーバです。設計の要点は次の3つ。

  • API の形 — REST（リソース単位）や GraphQL（必要な形で取得）など、決まった規約で会話する
  • ステートレス — サーバ自身に会話の状態を持たせない。状態はトークン・DB・キャッシュへ逃がす
  • 認証・認可 — 認証（誰か）はトークンやセッションで、認可（何ができるか）はロールや権限で

登場人物メモ:

  • ※1 REST／GraphQL — 代表的なAPIの形。前者はURL単位、後者は問い合わせ言語
  • ※2 トランザクション — 「全部成功か、全部なかったことにするか」をまとめて扱う単位

壊れても止まらない処理

  1. タイムアウト — 無限待ちを避ける（呼ぶ側が必ず設定）
  2. リトライ＋指数バックオフ＋ジッタ — 再送はだんだん間隔を空け、揃えない
  3. 冪等キー — 二重実行を無害化
  4. サーキットブレーカ — 失敗が続く相手を一時遮断し、フォールバック
  5. 分散トレーシング — 1リクエストが複数サービスを跨ぐ様子を追う
やさしく言うと（中級）
  1. 入口経由で API リクエストが届く
  2. トークン等で認証、ロール等で認可を確認
  3. 業務ロジックを実行（必要なら複数の操作をトランザクションでまとめる）
  4. DB／キャッシュ／ストレージにアクセス（読みはキャッシュ優先で軽くする）
  5. 結果を規約どおりの形（JSONなど）で返す
アニメーション『バックエンドの層（受付・業務・データ入出力）』を開く
バックエンドの層 — 役割で分ける受付 → 業務ロジック → データ入出力 → 保管庫コントローラController受付・入力を受け取り、形を整えて渡す・結果を決まった形（JSON）で返すサービスService業務ロジック・判断・計算・手順をまとめる・必要ならトランザクションで束ねるリポジトリRepositoryデータ入出力・DBとのやり取りを引き受ける・SQLの詳細を上の層から隠すDBデータの保管庫要求（下へ降りる）応答（上へ戻る）各層は自分の役割だけを持つ。だから直しやすく、入れ替えやすい

一貫性とデータの流れ

  • 結果整合性 — 分散では強整合を諦め、少し遅れて揃う設計が多い
  • Saga — 複数サービスにまたがる業務を、補償トランザクションで整える（2相コミットを避ける）
  • イベント駆動／CQRS — 変更をイベントで伝え、読み取りと書き込みのモデルを分ける
  • アウトボックスパターン — DB更新とイベント発行を、取りこぼしなく一致させる
  • バックプレッシャ — 過負荷時に受け入れを絞り、雪崩を防ぐ
やさしく言うと（中級）
  • 水平スケール — ステートレスにしておけば、混雑時はサーバを増やして分散できる
  • キャッシュ戦略 — 読み取りの多い結果はキャッシュに載せ、DB負荷を下げる
  • N+1問題 — 一覧＋各行ごとのクエリで本数が爆発する。JOINやまとめ取得で回避
  • コネクションプール — DB接続は毎回張り直さず、あらかじめ用意した接続を使い回す。ただし水平スケール時は「サーバ台数×1台あたりのプール数」がDBの接続上限を圧迫する点に注意
  • 非同期ジョブ — 重い処理はキューに積み、レスポンスと切り離す

⚠️ 分散特有の落とし穴

  • カスケード障害 — 1つの遅延が連鎖して全体を巻き込む
  • リトライストーム — 一斉リトライが相手をさらに潰す
  • スプリットブレイン — 分断で「両方が主」になり整合が壊れる
  • 可観測性不足 — ログ・メトリクス・トレースが無いと、分散の障害は追えない
やさしく言うと（中級）
  • タイムアウト — 処理が長すぎる。リトライするなら冪等性（何度実行しても同じ結果）に注意
  • デッドロック — 複数の処理が互いのロックを待って止まる
  • 整合性の乱れ — キャッシュとDBの内容がズレる（無効化の設計が甘い）

理解度チェック

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

問1. 下流サービスの障害が全体に連鎖するのを止める仕組みは？

問2. リトライで同じ処理が二重に走っても被害が出ないようにする、実務の定番手段は？

問3. 再送のたびに間隔をだんだん空け、しかも複数のクライアントが揃って再送しないようランダムなズレを加える。この組み合わせに最も近いのは？

問4. 複数サービスにまたがる業務を、補償トランザクションで整えつつ2相コミットを避けるパターンは？

問5. 「DB更新」と「イベント発行」を、取りこぼしなく確実に一致させたい。適したパターンは？

問6. 過負荷のとき、受け入れそのものを絞って処理の雪崩（オーバーロードの連鎖）を防ぐ仕組みは？

問7. ネットワーク分断により「両方のノードが自分こそ主（プライマリ）」と思い込み整合が壊れる状態を、カタカナで何と呼ぶ？

問8. 1つのリクエストが複数サービスを跨いで流れる様子を追い、遅延や失敗の箇所を特定する手法を何と呼ぶ？

バックエンドサーバ — 「何を返すか」を考える頭脳 | Kotowary