マイクロサービスアーキテクチャ¶
| メモレベル |
どんなもの？¶
大規模で複雑なアプリケーションを構築するときは、なんらかのモジュール性が必要。⇒古来からの原則「分割統治」
これまでのモノリシックアプリケーションは、論理的にはモジュール化されていたとしても、物理的には一枚岩（モノリシック）となっており、コードベースが大きく開発者が理解困難、コードの変更から本番デプロイまでの道（変更のマージ、コードの安定化、テストサイクル）が険しい、アプリケーションのリソース要件が各モジュールの総和でサーバ構成が難しい。（「マイクロサービスパターン」Chapter 1からエッセンス要約）
如何にモジュール化するかというアーキテクチャとして上述の問題を解決するものがマイクロサービスアーキテクチャ。
モジュールを「サービス」と定義し、サービスはAPIを通してのみ他の要素（サービス、他）と連携。
サービス単位で開発・ビルド・デプロイする。
サービスごとにデータベースを持つ。
サービス同士はプロセス分離されているので、API（プロセス間通信）を介さずに内部にアクセスはできない。これによりサービスの独立性を確保する。
似ているもの¶
SOA¶
サービス指向アーキテクチャ（SOA）との類似性が指摘される。
違いとしては、サービス間通信が軽量（ESBやSOPA WS*ではなく、MQ、REST、gRPCなど）、データが局所性（グローバルではなくローカル）、サービス規模（モノリシックに近い大黄なサービスではなく小さなサービス）。
メリットデメリット¶
メリット
- 大規模で複雑なアプリケーションの継続的デリバリー／デプロイを可能とする
- 個々のサービスが小さく、簡単にメンテナンスできる
- サービスをそれぞれ個別にデプロイできる
- サービスをそれぞれ個別にスケーリングできる
- チームに自主性、自律性を与える
- 障害分離に優れている
- 新しいテクノロジを簡単に実験、採用できる
デメリット
- サービスの適切な分割方法を見つけるのが難しい
- 分散システムは複雑であり、開発／テスト／デプロイが難しくなる
- 複数のサービスにまたがって使わる機能のデプロイには綿密な調整が必要になる
- いつマイクロサービスがアーキテクチャを採用すべきかの判断が難しい
設計要素
h3. スケーリング¶
スケールキューブ¶
スケーリングのための3つの分割方法
| 軸 | 概要 | モノリシック | マイクロサービス |
|---|---|---|---|
| X軸 | 同じアプリケーションの複数インスタンス、ロードバランサーで公平に散らす。 | ✔ | ✔ |
| Z軸 | 同じアプリケーションの複数インスタンスで各インスタンスはデータのサブセットだけを処理、ルーターで処理可能なインスタンスに振り分け。 | ✔ | ✔ |
| Y軸 | アプリケーションをサービスに分割する。各サービスをさらにX/Z軸スケーリングすることも可。 | N/A | ✔ |
参考文献¶
- [1] マイクロサービスパターン（Chris Richardson=著、樽澤広亨=監修、インプレス刊、2020年）