「低レベルなマイクロサービスアーキテクチャ（MSA）」というのは「ただの基幹システムとのファイル連携」でいいんだよ、という話。
Level 5 | Richmond, Virginia | Rebecca Morgan | Flickr
MSAというのは「どこかに存在する完成されたシステム」ではなく、現状のシステムを不断の努力によって進化させていった結果です。MSAに決まった構成はありません。あくまでもプラクティスやパターンがあり、それらの実現を手助けするソフトウェア製品（OSS）があるだけです。
というわけで、「MSAに取り組む」というのは道は遠くても（見えなくても）「目の前のシステムの継続的な改善に取り組む」ことでしかないのですが、最先端の話しかないと差が大きすぎてどう取り組めばいいのか分からない、あるいは再構築しか道はないと感じてしまうのだと思います。そこで段階的なレベル上げができる、というか、段階的なレベル上げをするしかない、という説明をしたいと考えています。つまり、MSA化のレベル定義。
MSAのレベル感
原典であるMartinFowler.comのエントリ「Microservices」に書かれたMSAの特徴をゆるめに表現すると以下のようになります。
- 全体システムを、機能別のシステム同士が連携することによって実現させていること（Componentization via Services）
- ビジネス機能にそった開発チームが組織されていること（Organized around Business Capabilities）
- WF型の一括構築ではなく、継続的に新機能開発を行うこと（Products not Projects）
- SOAのESBやEAIのような連携基盤を頼りすぎず、サービス自身が同期/非同期API連携を整備していること（Smart endpoints and dumb pipes）
- 開発規約やフレームワークなどを標準化をしすぎないこと（Decentralized Governance）
- マスタデータは可能な限り個別システムで管理すること（Decentralized Data Management）
- インフラ関連の作業は可能な限り自動化すること（Infrastructure Automation）
- 連携先システムが停止しているケースを想定すること（Design for failure）
- 一括再構築を避け、段階的に部分再構築をしていくこと（Evolutionary Design）
こう書いてしまうと、実は常識的なことしか書いてありません。MSAの基本的な考え方というのは複数のシステムが連携して、全体が機能することを目指しており、そのために最適な組織や障害要素を低減する必要がある、というだけです。
ですから、従来型のシステム群であっても、ファイルとはいえシステム同士が連携はしますし、チームは業務によって組織されています。その他のトピックするもやれるだけは取り組んでいるのではないでしょうか。これがレベル1。
そして、これらを突き詰めていくと最先端の企業の事例にあるような「最小サービスは1週間ぐらいで作れる大きさ」であり「1画面で数百のサービス」が動き、それらが「数万ノードに自動デプロイ」され、「リリースは1日の数十回～数万回」も行われている、ということになります。これがレベル5。
MSA化モデル軸
次にMSA化をモデル化する軸として、以下の4つを考えてみました。
MSA化レベル定義
そして、レベル感は以下のようなものを考えています。レベル上げのポイントや取り組むべき具体的な作業については別途。
| Lv | 疎結合化 | 自動化 | 基盤化 | 自律化 |
|---|---|---|---|---|
| 1 | 大きなシステム、ファイル連携メイン | ビルドはコマンド化 | インフラの仮想化 | ウォーターフォール、標準化強め |
| 2 | 大きめなサービス、キューによる非同期連携 | ビルドパイプライン | 認証/ログなどの基盤化、パブリックPaaSの利用 | アジャイル風、標準化弱め |
| 3 | 適度なサービス粒度、データ分離 | ブルーグリーンデプロイ | 様々な汎用基盤サービスの活用 | 複数のアジャイルチーム、個別最適 |
| 4 | 小さなサービス、非同期ストリーム、イベントソーシング | コンテナオーケストレーション | 様々な独自基盤サービス | たくさんのアジャイルチーム |
| 5 | かなり小さなサービス、独自プロトコル連携 | 数万ノード、数百回リリース | 自作基盤をOSS化 | すごくたくさんのアジャイルチーム |
いかがでしょうか？これも軸にあるべきだとか、このレベルにはこういうものが必要だ、とかあれば、ぜひ教えてください。
