ソフトウエアの複雑化・大規模化やクラウドの利用拡大が急速に進むなか、それに従った形でソフトウエアアーキテクチャおよび開発方法も大きく変わろうとしています。その兆候の1つとして「マイクロサービス（Microservices）」という新しい開発手法の登場があります。AmazonやeBayと言った世界規模で大規模なWebサービスを提供する企業を中心に採用されていることから、昨年ごろから注目を集めています。

「マイクロサービス」という言葉は、James Lewis氏が2012年に発表した"Micro services - Java, the Unix Way"が起源^参考1とされており、その後、2014年にLewis氏がMartin Fowler氏と執筆した記事"Microservices^参考2"により各所で大きく取り上げられるようになりました。その記事において、マイクロサービスは下記のように説明されています。

また、少々概念的ではありますが、これまでの古いアーキテクチャスタイルを「一枚岩のアーキテクチャ（Monoliths）」として捉え、それとの比較によりマイクロサービスを説明できます（図）。

一枚岩のアーキテクチャでは、複数の機能を1つのアプリケーションの実行物として構築します。これまでの多くのアプリケーションはこの形で構築されています。例えば、サーバーサイドのWebアプリケーションの実装は、ビジネスロジック、UI、データベースアクセスなどが一体となった実行物としてビルド・配備されます。これまではこのような一枚岩のアーキテクチャでも問題はなかったのですが、非常に大規模で複雑になるWebサービスを提供する上では、いくつか問題が目立つようになりました。具体的には、大規模Webサービスに特有のニーズ――「ビジネス変化への素早い対応に向け、非常に高い変更頻度^注1が求められる」、「クライアント数の爆発などの変化に即応する高性能・高可用性が求められる」――に対応するために、下記のようなアーキテクチャ上の問題が顕在化しています。

マイクロサービスはこれらの問題への解決策として、アプリケーションを構成する個々のサービスは独立したプロセスで実行されるように配備します。それにより、きめ細かにスケールできるようになります。また、それぞれのサービスを独立性の高い単一のビジネス機能を提供するものとして作ることで、変更の影響範囲を限りなく小さくします。

しかしながら、そのようなマイクロサービスの構築は簡単なことではありませんし、当然のことながらトレードオフが存在します。マイクロサービスの大きなデメリットとして、分散化するシステム設計が複雑になる、通信オーバヘッドが大きくなる、運用管理が大変である、といったものがあります。小さなサービスとして機能分割するため、アプリケーション全体から見た整合性をとることが困難です。特に、異常処理やトランザクション処理の設計は顕著に難しくなります。また、小さく分割されたサービス間で行われる通信が大量に発生することになります。さらに大量になるサービスの運用コストも高くなります。ある事例では1つのアプリケーションを構成するサービスが20個にのぼり、それが40～60プロセスで実行されているため、それらの運用管理は非常に労力がかかってしまったことが報告されています^参考3。

勘のよい方は気づいたかもしれませんが、同じようなコンセプトとして約10年前から流行した「サービス指向アーキテクチャ（SOA、Service Oriented Architecture）」があります。そのため「マイクロサービスはSOAの焼き直しである」という意見もあります。筆者も技術的な観点において両者に本質的な相違はないように思います。ただ10年前と比べて異なることは、

といった変化です。それらの変化により、（本質的な意味で）SOAに対する必要性が増し、SOAの実現が容易になってきているのではないかと考えています。その結果がマイクロサービスです。

一方でマイクロサービスには課題もまだ多くあります。これに対して、マイクロサービス構築に適したフレームワーク（Spring Boot等）やライブラリ（Netflix OSS等）などが提供されはじめています^参考4。マイクロサービス構築技術や設計技法の成熟化が今後の普及の鍵となるでしょう。