サービスベースアーキテクチャ入門
導入：サービスベースアーキテクチャとは何か？
サービスベースアーキテクチャは、多くのビジネスアプリケーションにとって、非常に実用的で人気のある選択肢です
このアーキテクチャは、巨大な一枚岩のようなモノリシックアーキテクチャと、細かく分割されたマイクロサービスアーキテクチャの間に位置する、柔軟性の高い「ハイブリッド」な分散アーキテクチャです
マイクロサービスが持つ過度な複雑さや導入コストを抑えつつ、システムを機能ごとに分割して開発・デプロイできるという分散システムの利点を享受できるます
これにより、多くの開発チームにとって、モノリシックなシステムから、より現代的で俊敏なアーキテクチャへと移行するための、現実的で管理しやすい第一歩となるかなと思います
アーキテクチャの基本構造
サービスベースアーキテクチャは、主に以下の3つの主要コンポーネントで構成されます。
- ユーザーインターフェイス（UI）
フロントエンドのUI部分は、バックエンドのサービス群とは切り離され、それ自体で独立してデプロイが可能な単位となります - 粒度の粗いリモートサービス（ドメインサービス）
バックエンドは、ビジネスのドメイン（機能領域）ごとに分割された、複数のサービスで構成されます。これらのサービスは「粒度が粗い」のが特徴で、それぞれが独立してデプロイされます - モノリシックな共有データベース
複数のドメインサービスは、通常、単一のデータベースを共有してデータを管理します。これによりデータアクセスは簡素化されますが、同時に重大な結合点も生み出します
一般的に、アプリケーション内のサービス数は4から12個程度に収まることが多く、マイクロサービスのように数十、数百のサービスに分割されることはありません
UIと各ドメインサービス間の通信には、RESTなどのリモートアクセスプロトコルが使用されます
この基本構造は非常に柔軟であり、要件に応じていくつかのバリエーションを考えることも可能です
- UIの分割
単一のUIを、ドメインごと、あるいはサービスごとにさらに細かく分割できます
これは、明確に機能が分かれている大規模なアプリケーションで特に有用です - データベースの分割
共有データベースを、各サービスが個別のデータベースを持つマイクロサービスのような形態に分割することも可能です
これによりサービスの独立性は高まりますが、データ管理の複雑さも増大します。 - API層の追加
UIとサービスの間にAPIゲートウェイなどの層を設けることで、メトリクス収集、セキュリティ、監査要件、サービスディスカバリといった共通の横断的な関心事を効率的に統合できます。
この基本構造と柔軟性が、サービスベースアーキテクチャの大きな特徴です
設計における重要な2つのポイント
サービスベースアーキテクチャを効果的に実装するためには、特に「サービスの粒度」と「データベースの扱い方」という2つの設計概念を理解することが大切です
サービスの設計と粒度
サービスベースアーキテクチャの最大の特徴は、そのサービスが「粒度の粗い」ドメインサービスであるという点です
これは、単一のビジネス機能に責任を持つマイクロサービスの「粒度の細かい」性質とは対照的です
例として、「カタログチェックアウト処理」を考えてみましょう。
- マイクロサービスの場合
注文の発注、決済、在庫更新といった各処理は、それぞれが独立したマイクロサービスとして実装される可能性があります - サービスベースアーキテクチャの場合
これら一連のビジネスロジックは、単一の「注文サービス」が内部でオーケストレーションします
つまり、注文の発注、注文IDの生成、決済の適用、在庫の更新といった処理を、サービス内のロジックとして順次実行するのです
この「粒度の粗さ」は、特にトランザクション管理において大きな利点があります
処理が単一のサービスとデータベース内で完結するため、従来から使われているACIDトランザクション（コミットやロールバック）をそのまま利用できます
これにより、データの整合性を非常に保ちやすくなります
これは、複数のサービスにまたがる処理を扱うために、結果整合性に依存するBASEトランザクションといった複雑な技術を必要とすることが多いマイクロサービスアーキテクチャとの重要な違いです
データベース分割の考え方
サービスベースアーキテクチャでは単一のデータベースを共有することが一般的ですが、これは大きな課題も引き起こします
単一の共有ライブラリでデータベースアクセスを管理する際の最大の問題点は、データベーススキーマのごく一部を変更しただけで、その変更されたテーブルを使用しないサービスも含め、すべてのサービスの再コンパイルと再デプロイが必要になる可能性があることです
これはシステムの俊敏性を著しく損なう可能性があります
この課題に対する効果的な解決策が、「データベースの論理的分割」になります
これは物理的には単一のデータベースを維持しつつ、その内部をドメインごとに論理的に分割し、それぞれに対応する共有ライブラリを作成するというアプローチです
このアプローチによって、データベースの変更管理は以下のように改善されます
| 問題（単一の共有ライブラリ） | 改善（ドメインごとの共有ライブラリ作成後） |
|---|---|
| データベースのあらゆる変更でも、全てのサービスが影響を受ける可能性がある | 特定のドメインへの変更は、関連するサービスにのみ影響する |
| 変更の影響範囲が広く、リスクと調整コストが高い | 変更の影響範囲が限定され、リスクと調整コストが低い |
このようにデータベースを論理的に分割することで、変更による影響範囲を最小限に抑え、システムの保守性を大幅に向上させることができるのです
アーキテクチャの評価
どのようなアーキテクチャを選択するにしても、必ずトレードオフが伴います
サービスベースアーキテクチャも例外ではありません
利点
- 高いアジリティ、テスト・デプロイ容易性
ドメインサービスが独立しているため、変更、テスト、デプロイが迅速かつ低リスクで行えます - 高い耐障害性
一つのサービスが停止しても、他の独立したサービスには影響が及びません - コストと複雑さのバランス
他の分散アーキテクチャに比べ、実装が比較的容易でコストも低い -
トランザクション管理の容易さ
サービス内でACIDトランザクションを利用できるため、データの整合性を保ちやすい
欠点
- 中程度のスケーラビリティと弾力性
サービスの粒度が粗いため、マイクロサービスほど効率的なリソース利用やスケーリングはできません - 共有データベースによる結合
論理的に分割しても、モノリシックなデータベースはサービス間の結合点となり、変更管理の課題が残ります - 限定的な量子数（アーキテクチャ量子）
データベースやUIを共有している場合、システム全体の独立性が制限され、デプロイ・運用できる最小単位（アーキテクチャ量子）が1つになってしまうことがあります
この評価からわかるように、サービスベースアーキテクチャは、すべての面で最高評価を得るわけではありませんが、多くの重要な特性においてバランスの取れた優れた選択肢です
最終的に、このアーキテクチャスタイルは、ドメイン駆動設計との親和性が高く、特に「本格的なマイクロサービスの複雑さを避けつつ、分散アーキテクチャの利点を享受したい」と考えるプロジェクトにとって、非常に実用的な選択肢と言えます
ここまで読んでいただきありがとうございました！！！