メインコンテンツまでスキップ

System Topologies（サービス構成・粒度）

System Topologies は、アプリケーションをどの粒度で分割し、どのように配置・デプロイするか を扱うアーキテクチャ層を対象とする。

  • “1 サービスの中身”ではなく 複数サービス／プロセス間の構成 が対象
  • モノリスからマイクロサービスまで、スケール戦略・組織構造と密接に関係する

✅ このカテゴリが扱う問題​

  • システムをどの粒度で分割すべきか
  • 変更とデプロイの単位をどう決めるか
  • チーム構造とアーキテクチャが噛み合わない問題
  • 可用性・スケール・フォールトアイソレーションをどう実現するか
  • マイクロサービスが“多すぎる／少なすぎる”問題

✅ System Topologies の代表スタイル​

● Monolith（モノリス）​

  • 単一デプロイ、単一プロセス構成
  • 小〜中規模、密結合で問題ない範囲では最も効率的
  • 強い内的整合性・簡単なデプロイがメリット

● Modular Monolith（モジュラーモノリス）​

  • 内部をモジュール化しつつ、デプロイは 1 つ
  • “将来のマイクロサービス化”を見据えるが、過度な分割はしない

● Microservices（マイクロサービス）​

  • プロセス単位で独立デプロイ可能なサービス群
  • チーム単位で進化できる構成
  • ただし運用コスト・可観測性のハードルが高い

● Service-Oriented Architecture（SOA）​

  • エンタープライズ統合の文脈で登場
  • ESB 中心の古典的 SOA と、API 中心のモダン SOA がある

● Serverless / FaaS​

  • Function 単位でデプロイ
  • 機能単位のスケール／コスト効率を目的
  • きめ細かい分割が可能だが複雑にもなりやすい

● Edge / Fog Architecture​

  • クラウドに加え、エッジ（端末/ローカル拠点）で処理分散
  • IoT・低レイテンシ系のアプリで重要

● Cell-based Architecture（セル構造）​

  • 超大規模システムで採用される構成
  • Cell（小さな独立クラスター）単位で水平スケール
  • フォールトアイソレーションとスケールを両立

● Multi-region Architecture（マルチリージョン構成）​

  • 複数リージョンにサービスを配置
  • 可用性・レイテンシ・DR を高水準で実現
  • Active-active / Active-passive 構成

✅ このカテゴリの読み方​

  1. 小 → 大、単純 → 複雑に進む順で理解する
  2. 自社／自分のシステム規模・組織規模をマッピングする
  3. コスト（認知・運用）と価値（独立性・スケール）を比較する

✅ 他の階層との関係​

  • Integration Styles：マイクロサービスでは通信方式が死活問題
  • Structural Styles：各サービス内部構造は別カテゴリ（Layered/Hex など）
  • Cross-cutting：Observability・SLO は特にマイクロサービスで必須
  • Data Architecture：分散データ整合性問題（CQRS / Event Sourcing）が登場