なぜ必要なのか

家族が行事案内を保存し、参加費を払う学校アプリを作るとします。急ぎのボランティアタグは課金の公開を待てません。一チームが独立更新のため通信の調整を引き受けます。内部モジュールだけなら更新は共通です。

どう解決するのか

  1. 一チームがカタログ・ライブラリ・課金を各v1で運用。保存した学校行事の案内はタグなし。
  2. 互換性のあるタグ機能をライブラリv2だけに配布。カタログ・課金はv1のまま。
  3. ライブラリがネットワークでカタログを参照し、自分の保存先にボランティアを記録。書き込み前のタイムアウトはタグなし。失敗を伝え、復旧後に再試行。
独立リリースには遠隔障害への対処が必要

説明用の架空の例

一つの機能だけをリリース

学校行事アプリ · 一チーム · 学校行事にボランティアタグなし

変更：ライブラリにタグを追加。課金の動作は同じ。

契約の互換性を維持：新しいリリースはライブラリのみ。

  1. デプロイ単位 · 1

    カタログ

    v1 → v1

    動作は同じ

    所有する保存先カタログ

  2. デプロイ単位 · 2

    ライブラリ

    v1 → v2

    タグ機能を追加

    所有する保存先ライブラリ

  3. デプロイ単位 · 3

    課金

    v1 → v1

    動作は同じ

    所有する保存先課金

ネットワーク参照 · タグの書き込み前

ライブラリ → カタログ API

遠隔応答は保証されません。課金はこの参照経路に参加しません。

  1. 1 · 成功

    参照成功 → ボランティアを記録 → 学校行事のタグはボランティア。

  2. 2 · カタログ参照タイムアウト

    書き込み前に参照失敗 → タグなし。失敗を伝え、復旧後に再試行。

各サービスがデータを所有し、他サービスのテーブルを直接読みません。独立リリースでも監視と障害処理が必要で、依存先の障害は波及し得ます。

所有権の枠はアクセス規則を示し、データベースのマシン数を示しません。

独立配布で自動的に障害が隔離されるわけではありません。同期のカタログ依存はライブラリを止める場合があります。時間制限と再試行を定めます。

どんな考え方なのか

マイクロサービスは明示的な契約とデータ所有権を持ち、独立してデプロイする業務機能別サービスです。プロセス分割だけでは独立性は生まれません。Lewis・Fowler

ネットワーク障害とサービス間データの調整が必要です。他の機能はモジュラーモノリスに残せます。