マイクロサービス

🐾 猫で例えると？

別々のベッドで休む猫たちを、各サービスが自分の範囲を持つイメージに重ねます。ただし同じ部屋の温度やご飯に影響されるように、サービスにもネットワークや共有基盤への依存があります。小さく分けるだけで完全独立になるわけではありません。

💻 アプリ・Web開発における「マイクロサービス」とは？

従来のWebアプリケーション開発では、すべての機能（会員登録、商品検索、決済、配送管理など）を1つの巨大なプログラムとして作成する「モノリシック（一枚岩）アーキテクチャ」が主流でした。しかし、システムが巨大化するにつれて、「一部のコードを修正しただけで全く関係のない機能にバグが出る」「一部の機能へのアクセス集中（負荷）のせいで、システム全体が重くなる」といった深刻な問題に直面するようになりました。

業務上のまとまりに沿ってサービスを分け、それぞれを独立して変更・配備できることを目指します。データの所有者も明確にし、他サービスの内部テーブルへ直接依存しない境界を考えます。別々の物理DB機器が必ず必要、という意味ではありません。

⚠️ マイクロサービスの仕組みと注意点

マイクロサービスを導入すると開発の柔軟性は爆発的に向上しますが、インフラの複雑さは格段に跳ね上がります。サービス同士がネットワーク越しに通信し合うため、通信遅延（ネットワークレイテンシ）の発生や、データの整合性を担保することが難しくなるという課題があります。

サービス間連携における分散APIリクエストの例

次のJSONは、注文から決済と在庫へ連携する先を説明する架空のデータです。実行プログラムでも標準のワークフロー形式でもなく、これだけで非同期処理や整合性が保証されるわけではありません。

// 注文サービス（Order Service）から各自律サービスへの分散処理リクエスト
{
  "order_id": "ord_20260526_9981",
  "routing_flow": [
    {
      "target_service": "Payment-Service",
      "action": "authorize_credit_card",
      "endpoint": "https://api.internal/v1/payments"
    },
    {
      "target_service": "Inventory-Service",
      "action": "reserve_stock_items",
      "endpoint": "https://api.internal/v1/inventory"
    }
  ]
}

決済が成功し在庫の確保が失敗したら、取り消しや返金、再試行などをどう行うか決めます。補償処理は、DBトランザクションをそのまま巻き戻す操作とは異なり、補償自体の失敗も考慮します。サービスをまたぐ業務の状態を追える必要があります。

🛠️ マイクロサービスを賢く使うためのポイント

モダンなクラウドネイティブ開発でマイクロサービスを成功させるには、高度な運用自動化プラットフォームの選定とアーキテクチャ設計の標準化が求められます。

• 運用できる構成を選ぶ： コンテナーやKubernetesは有力な道具ですが、マイクロサービスの必須条件ではありません。チームが扱える配備・監視・障害対応の仕組みと、分割して得る効果を比較します。
• 独立して変更できる境界： 一つの修正で毎回全サービスの同時配備が必要なら、分割の境界や契約を見直します。サービス数を増やすこと自体を目標にしないようにします。
• 分散トレーシングによる可視化： トラブル発生時に「どのサービスのどの通信でエラーが起きたか」を追跡できるよう、リクエストに一意の共通IDを付与して全体を監視する仕組み（JaegerやOpenTelemetryなど）を導入します。

別々のベッドを使う2匹のように、サービスごとの独立性を高めるのがマイクロサービスの狙いです。一方で通信や運用の管理は増えます。分けた後のデータの整合性、障害の追跡、配備の方法まで扱えるかを考えて採用しましょう。