マイクロサービス：Dev Basics／Keyword

マイクロサービスとは、単一のアプリを「粒度の小さなサービスの集合として開発する」というアプリ開発のスタイルであり、さまざまなメリットがある。

» 2016年03月04日 05時00分公開

[かわさきしんじ，Insider.NET編集部]

連載目次

　マイクロサービス（アーキテクチャ）とは、単一のアプリを「粒度の小さなサービスの集合として開発する」というアプリ開発のスタイルを意味している。もともとはジェームス・ルイス氏とマーチン・ファウラー氏によって提唱された概念だ。

モノリシックなアプリ

　マイクロサービスは「モノリシック」（一枚岩的）なアプリ開発スタイルと比較して語られることがよくある。モノリシックな開発スタイルではアプリは全ての機能を含んだ単一の存在となる。以下に示すのはモノリシックなWebアプリの構成だ。

モノリシックなWebアプリ

　このような構成では、サーバサイドで実行されるWebアプリはモノリシックな実行単位となる。開発段階ではクラスや各種のライブラリ、フレームワークなどを活用して、モジュール的な設計が行われるとしても、実行時にはそれらの要素は密結合され、単一のプロセス内で実行される。

　モノリシックなスタイルで作られたアプリの特徴を（マイクロサービスと対比的に）挙げると次のようになる。

アプリ全体が単一のプロセスで実行される
アプリをスケールさせる際には、アプリ全体のインスタンスが対象となる
アプリのどこかに修正を加えた場合、全てを再デプロイする必要がある
（アプリ内の）モジュール間の通信はメソッド／関数呼び出し

　昨今ではWebアプリをクラウドで継続的に展開するのが当たり前となりつつあり、デプロイも頻繁に行われる。そのため、モノリシックなアプリの微細な部分に対する修正でアプリ全体をビルド、デプロイするのは好ましいことではない。

マイクロサービスベースのアプリ

　これに対して、マイクロサービスを使ったアプリはおおよそ次のような構成になる。

マイクロサービスを用いて構成されたWebアプリ

　マイクロサービスでは、アプリは複数の小規模なサービスへと分割される（図中の小さな円）。これらのサービスはおおよそ次のような特徴を持つ。

サービスは小規模な機能を実装し、独自のプロセスで実行される
スケールが必要なときには、必要なサービスだけをスケールできる
アプリを変更したときには、そのサービスだけを個別にデプロイできる
他のサービスとはHTTPベースのAPIなどを使用してやりとりをする（サービスの疎結合化）
サービスは、そのサービスが実現する機能に合った言語を使って実装できる
サービスには、そのサービスで必要となるデータ管理機能も含める（上の図に「データベース」がなかったのはこのため）

　つまり、アプリをサービスを介してコンポーネント化することで、それらの独立性が高まり、適切な言語やデータベースを利用して実装を行い、変更があったときにはアプリ全体の動作には影響を与えることなく特定のサービスだけをデプロイできるようになる（あるいはサービス間の調整が低減される）。これはモノリシックなアプリに対する大きなメリットといえる。

　もう1つ重要なことがある。それは組織のありようだ。モノリシックなアプリでは、技術レイヤーに着目してUIチーム、ビジネスロジックチーム、データアクセスチームのように組織を構成することがよくある。

　しかし、マイクロサービスでは、アプリはビジネスで何を実現するかを基に個々のサービスへと分割される。そして、サービスはそれに必要なもの（UI要素、データアクセス、他のサービスに公開するAPIなど）を全て含んだものとなる。であれば、サービスを実装するチームも技術レイヤーを基に切り分けるのではなく、さまざまなスキルを持ったメンバーで構成される。ただし、そのためには従来とは異なる組織のありようを許容できるようになる必要があるかもしれない。

マイクロサービスに共通の特徴

　上ではマイクロサービスの概要を述べたが、ジェームス・ルイス氏とマーチン・ファウラー氏はマイクロサービスに共通する特徴として次の要素を挙げている（ただし、全てのマイクロサービスが全ての要素を満たすわけではない）。詳細は割愛するが、興味のある方は原文もしくはid:kimito_k氏によるその日本語訳に当たってみてほしい。

サービスを介したコンポーネント化
ビジネスで何を実現するかを基にした組織
プロジェクトではなくプロダクト
インテリジェントなエンドポイント、メッセージを通すだけのパイプ
分散されたガバナンス
分散されたデータ管理
インフラの自動化
失敗に備えた設計
進化していく設計

　上で述べた特徴も含まれているが、分かりにくいところを補足しておこう。

　まず、「プロジェクトではなくプロダクト」とは、アプリをプロジェクトとして完成させることが目的なのではなく、アプリが提供されている間、チームはそれに対して責任を持つことを意味する。

　次に「インテリジェントなエンドポイント、メッセージを通すだけのパイプ」（原語：smart endpoint, dumb pipe）とは、サービス間はHTTPベースのAPIなどを使用してやりとりをするだけで、何らかの処理を行うのはあくまでもサービスであることを意味している。

　「分散されたガバナンス」と「分散されたデータ管理」は上でも述べたように、サービスごとに適切な言語やデータベースを選択するという話だ。「失敗に備えた設計」とは、他のサービスを利用するサービスは障害発生時に対処できるように設計すべきということだ。

　最後の「進化していく設計」は、アプリをサービスに分割することで、アプリを徐々に（個々のサービスを変更することで）進化させていけることを意味する。アプリの一部を変更することがその全体をスタックさせることはなく、むしろ、粒度の低いサービスに変更を加えることで、その変化を制御しながら頻繁にアプリを更新できるようになる。

マイクロサービスとサービス指向

　スペースが尽きてきたので、最後に簡単にSOA（サービス指向アーキテクチャ）との関係に触れておく。

　サービス、疎結合といった観点からはSOAとマイクロサービスはよく似ている（「マイクロサービスは粒度の小さなSOA」という表現もある）。その一方で、マイクロサービスの提唱者であるジェームス・ルイス氏とマーチン・ファウラー氏によれば、SOAでは多くの場合、「モノリシックなアプリをESBを使って統合する」という点でマイクロサービスとはそのスタイルが異なっていると述べている（他にもSOAが指すのが巨大すぎる点も問題だと述べている）。

　対して、マイクロサービス（アーキテクチャ）はHTTPベースのAPIを利用した軽量なサービスを用いて、モノリシックなアプリをどのようにコンポーネントへと分割していくか（あるいは、モノリシックなアプリとマイクロサービスを共存させるにはどうすればよいか）、そのために必要な要素を表すものといえる。

　マイクロサービスでは、それぞれのサービスは独立して動作する存在だ。これにより、アプリ内で必要な部分だけの変更やデプロイが容易になり、個々のサービスを独立して変更していくことで、アプリを徐々に進化させていくことが可能となる。ただし、そのためには、前述のようにこれまでとは異なる開発スタイルを導入する必要があるかもしれない。

　また本稿では述べなかったが、マイクロサービスが全ての局面で有効かどうかはまた別の話だ。これについては「MicroservicePremium」などを参考にしてほしい。