マイクロサービス vs. SOA - 「軽量さ」の理解を深める

マイクロサービスとの対比で語られることの多い、SOA(Service Oriented Architecture:サービス指向アーキテクチャ)との違いから、「軽量さ」を理解していきましょう。

REST API

マイクロサービスでは、サービス間をシンプルで軽量な手段である「REST API(REpresentational State Transfer API)」で連携させます。この通信方式が大きな特徴の一つです。

REST APIはTwitterやFacebook等で採用されている技術で、URIに紐づくリソースにHTTPでアクセスする仕組みです。Twitter APIを例にとりますと、ユーザのタイムラインやツイート等の情報にアクセスする際、リクエストはHTTPのGETやPOSTを用い、レスポンスとしてJSON形式のリソースを取得します。

なお、OAuth等を使った認可の仕組みを利用し、セキュリティ対策も実施できるなど、軽量な手段でありながらも、実開発で必要な機能を備えています。

では、実際の通信はどういったイメージでしょうか。例えば、Twitterのユーザのタイムラインを取得する場合、以下のURIでJSON形式のリソースにアクセスします 。

https://api.twitter.com/1.1/statuses/user_timeline.json

JSON形式のレスポンスのイメージは以下です 。

[
  {
    "coordinates": null,
    "favorited": false,
    "truncated": false,
    "created_at": "Wed Aug 29 17:12:58 +0000 2012",
    "id_str": "240859602684612608",
    "entities": {
      "urls": [
        {
          "expanded_url": "https://dev.twitter.com/blog/twitter-certified-products",
          "url": "https://t.co/MjJ8xAnT",
          "indices": [

...略...

REST APIの具体的な通信がイメージできたでしょうか。以降、これを踏まえてSOAとの比較によりマイクロサービスの「軽量さ」を説明します。

SOAとの違い

歴史的に見ると、企業の業務プロセスにおいて、紙ベースで処理されていたものが、システムでの処理に置き換わっていき、一つの企業内においてもシステムが乱立する時代を迎えました。

その中で各システムを適切に分割し、システム構築を最適化するEA(Enterprise Architecture)の思想が生まれてきました。EAの思想と重なりますが、SOAはシステムをサービスとして切り出すことで、各サービス間を連携させ、システムをスリムに正規化しようとしました。

ここまでの説明だと、「サービス化」の面ではマイクロサービスの説明と同じだと感じた人も多いのではないでしょうか。マイクロサービスの文脈では「サービスを通じたコンポーネント化」と表現され、コンポーネント化による疎結合を実現しようとする点は共通しています。

では、どういった部分に違いがあるのでしょうか？

SOAとの違い(1) 開発のアプローチ

一つ目の違いは「開発のアプローチ」です。

トップダウンで各種システムをつなげ、利用する技術の標準化を強く推し進めようとしたのがSOAです。これを、「中央集権的な統治」と表現することもあります。

システムを取り巻く外部環境の面から見ると、システムをSOAのように社内で中央集権的に統治すれば良かった時代から、SNS、Google Map APIやTwitter API等、外部のシステムとサービスを通じて深く連携していく時代になってきており、システム開発のスピードや柔軟性に対する要求が高まってきています。

マイクロサービスは「分散統治」と表現され、各サービスがJavaでもC++でもNode.jsでも構いません。作りはそれぞれのサービスの特性に応じて、サービス開発を構成するチームやメンバーのスキル等に委ねられるため、このような状況へ対応しやすいと言えます。

少し話が逸れますが、近年SoR(System of Record)とSoE(System of Engagement)という概念が出てきています。誤解を恐れずに言うと、SoRは基幹系等の企業に閉じたシステムのことで、SoEはSNSやソーシャルアプリ等企業・個人間をまたがったシステムのことを指すと考えてよいでしょう。SoEでは、さまざまなAPIが公開され、システム間をサービスでつなぐことでアプリケーションを構築していく風潮があります。こういった点は、マイクロサービスの思想との類似点の一つと捉えられます。

SOAとの違い(2) 通信方式面での複雑さ

二つ目の違いは、「通信方式面での複雑さ」です。

マイクロサービスはREST APIのみで簡易に実現できるのに対し、SOAはSOAPやWSDLといった仕様群を用いてサービスを実現し、サービス間をESB(Enterprise Service Bus)と呼ばれるミドルウェア製品を介して連携させます。時にはBPELエンジンを持つミドルウェアを導入の上、ワークフローアプリケーションを構築することもあります。

なお、ESBは以下のような機能を持ちます。

• インタフェースの違いを吸収する機能 : プロトコル変換、メッセージ変換等
• 非機能面を担保する機能 : 高負荷制御やセキュリティ等

本連載はSOAがテーマではないので、各々の仕様や技術について詳しくは述べませんが、SOAは端的に言うと、通信に関わる部分にESB製品を利用でき高機能である反面、導入のハードルが高かったのです。

これに対し、マイクロサービスは「スマートエンドポイントとシンプルな土管」と呼ばれる思想を前提にしており、通信部分にスマートさ(高機能)を載せるのではなく、シンプルな通信経路(土管)とし、サービス(のエンドポイント)に対して必要な機能を設けます。

*　　*　　*

今回は、SOAとの比較によりマイクロサービスおよびREST APIの「軽量さ」を中心に説明しました。マイクロサービスは、「分散統治」により技術面・組織面で独立性が高まり、この観点でも「軽量さ」を備えていると言えます。

次回は、マイクロサービスの起源や適用事例を踏まえ、そもそも今なぜマイクロサービスなのかについて触れていきます。