arclamp

ITアーキテクト 鈴木雄介のブログ

MSA化レベル定義 - 低レベルなマイクロサービスはただのファイル連携と見分けがつかない

「低レベルなマイクロサービスアーキテクチャ(MSA)」というのは「ただの基幹システムとのファイル連携」でいいんだよ、という話。

f:id:arclamp:20170926233520j:plain
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つを考えてみました。

  • 疎結合
    • 目的:サービスの独立性維持、レジリエンス向上
    • 手段:システム間連携の非同期化、データの分離管理など
  • 自動化
    • 目的:リリースコスト/インフラ管理コストの低減
    • 手段:コードから稼働までの自動化、繰り返し作業の自動化など
  • 基盤化
    • 目的:構築スピードの向上、全体最適
    • 手段:横断的関心事の基盤整備、基幹システムのサービス化など
  • 自律化
    • 目的:ビジネス改善、個別最適化
    • 手段:小さなチームによる継続的な作業、個別の技術選択、個別のKPI設定など

MSA化レベル定義

そして、レベル感は以下のようなものを考えています。レベル上げのポイントや取り組むべき具体的な作業については別途。

Lv 疎結合 自動化 基盤化 自律化
0 完全に統合されたシステム ビルドは職人芸、コードは個別管理 物理インフラ 厳格なトップダウン
1 大きなシステム、ファイル連携やデータ共有 ビルドはコマンド化、CVS/SVN インフラの仮想化 ウォーターフォール、標準化強め
2 大きめなサービス、キューによる非同期連携 ビルドパイプライン、Git/ブランチ戦略 認証/ログなどの基盤化、パブリックPaaSの利用 アジャイル風、標準化弱め
3 適度なサービス粒度、データ分離 ブルーグリーンデプロイ 様々な汎用基盤サービスの活用 複数のアジャイルチーム、個別最適
4 小さなサービス、非同期ストリーム、イベントソーシング コンテナオーケストレーション 様々な独自基盤サービス たくさんのアジャイルチーム
5 かなり小さなサービス、独自プロトコル連携 数万ノード、数百回リリース 自作基盤をOSS すごくたくさんのアジャイルチーム

いかがでしょうか?これも軸にあるべきだとか、このレベルにはこういうものが必要だ、とかあれば、ぜひ教えてください。