マイクロサービス（microservices）という言葉をご存知でしょうか？　今、エンタープライズ界隈のソフトウェアエンジニアの間でマイクロサービスという言葉がにわかに盛り上がりつつあります。

マイクロサービスはJames Lewis氏によって提案された言葉です。詳細については、彼がMartin Fowler氏と共著で書いた「Microservices」という記事を参照してほしいのですが、ようするにひとつのアプリケーションを、Railsのような一枚岩のアーキテクチャではなく、複数の軽量なサービスを連携させたアーキテクチャでつくろうというアプローチです。

上述の記事 では、マイクロサービスの特徴が九つほど上げられています。

• サービスによるコンポーネント化：ライブラリではなく別プロセスで動作するサービスによってアプリケーションのコンポーネント化を実現している。
• ビジネスケイパビリティに基づく組織化：役割ごとにチームが構成されるのではなく、複数の役割が混在したチームがひとつのサービスを構築する。（コンウェイの法則！）
• プロジェクトではなくプロダクト：コンポーネントは期限のあるプロジェクトとして開発されるではなく、継続的なプロダクトとして提供される。
• スマートエンドポイント、ダムパイプ：サービス間のメッセージは、HTTP経由でAPI呼び出しされるか、RabbitMQやZeroMQといった軽量メッセージングシステムによる通信で交換される。
• 分散ガバナンス：サービスごとに言語やデータベースなどは統一されず、個別に適切なものが選択される。
• 分散データ管理：サービスごとにデータを持ち、統合されていない。
• インフラストラクチャ自動化：継続的デリバリが実現され、自動テスト、自動デプロイなどが採用されている。
• 障害設計：構成されるサービスの障害に耐性を持つように設計されている。
• 進化的設計：各サービスごとに変更が行なわれ、漸進的に設計がされる。

このような特徴が挙がっているものの、SOAとどう違うのかという疑問を抱くかもしれません。実際のところ、マイクロサービスはSOAの焼き直しにすぎないという主張もあります。

しかし、SOAという用語は既に多くの場面で語られすぎていて、多義的な用語となっています。SOAと一言でいったときに、設計思想といった広い概念を指す場合もあれば、WS-*やESBの導入といった狭い概念を指す場合もあります。マイクロサービスという用語が指し示す領域は、SOAという概念と交差する部分もあるものの、組織構造から要素技術、インフラストラクチャー自動化、設計思想といった領域も含む用語となっています。

マイクロサービスは新しい言葉です。そして、その言葉が指し示そうとしている内容は、アーキテクチャというよりも、スタイルであるといった方がわかりやすいのかもしれません。

私個人としては、マイクロサービスという用語は、モノリシックなアーキテクチャを採用して成長してきたウェブ企業がその問題に対応していくなかで、自然と培ってきたテクニックやスタイルに名前がついたものとしてとらえています。

モノリシックなアプリケーションのコードベースが巨大化すると、まず、全体像を把握できるエンジニアがいなくなります。そして、他のエンジニアによるデグレーションを防止するための自動テストの数が増加し、実行に多大なコストを支払わなくてはならなくなっていきます。多数のサーバにアプリケーションを配置するデプロイメントのプロセスは複雑になり、その把握が困難になってきます。

そういった問題を解決するために、巨大な一枚岩のアプリケーションを個々の独立したサービスへ分割していこうというのは、自然なアプローチとなります。そのときに、エンタープライズ向け製品のベンダーが提供するSOAミドルウェア製品群を採用するのではなく、RESTful APIといったウェブで利用されている技術を採用するというのも、ウェブ企業にとっては自然な選択です。

マイクロサービスという用語は、SOAの焼き直しのように見えます。また、それを構成するとされている要素についても、目新しいものはありません。私は、だからこそ、マイクロサービスという用語が、自分たちの開発スタイルやアーキテクチャを自然に表現するものとして気に入っています。今後、自分たちのアーキテクチャを紹介するときには、SOAという用語を違和感を持ちながらつかうのではなく、マイクロサービスという用語を使いたいとおもいます。