オルタナティブ・ブログ > Innovationを探しに行こう >

世界を変える何かは、既に近くにあるかもしれない

マイクロサービスとSOAについて考えてみた

»

小さなサービスを組み合わせて複雑なアプリケーションを構成するアーキテクチャスタイルであるマイクロサービス (Microservices)が注目を集めている.最近は,お祭り的なバズワードから,その強みと弱みを見極めるといった,地に足のついた議論も増えてきた.

マイクロサービスが盛り上がるトリガーとなったのが,両氏によって書かれたMicroservicesという記事である.この中でマイクロサービスは,以下のように説明されている.

In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.
(試訳) マイクロサービスは,一つのアプリケーションを小さなサービスを組み合わせて開発するアーキテクチャースタイルである.各サービスはそれぞれのプロセス内で実行され,軽量なメカニズムを使って通信する.HTTP Resource APIを使うことが多い.

その後,マイクロサービスの素晴らしさは様々な所で語られているので (私も素晴らしいと思う),ここではあえて,SOA (Service oriented Architecture)との関係,マイクロサービスの課題,コンテナとの関係,などについてまとめてみたいと思う.最初は全部まとめて書くつもりだっ たけど,まずは,SOAとマイクロサービスの関係から...

ちなみに,敢えてマイクロサービスとSOAの「違い」と書かない(書きたくない)のは,個人的には本質的には違いがないと考えてることもあるけれど,違いを見出すことが問題ではないとも思うからだ.

前述のJamesとMartinの記事の中に,"Microservices and SOA"というコラムがある.ここで挙げられているのは,マイクロサービスとSOAはよく似ているけれど,SOAという言葉には複数の意味がありわかりにくいこと,SOAの構成要素の一つであるEnterprise Service Bus (ESB)のような複雑さを持ち込ないことがマイクロサービスの特徴である,など.

確かにSOAは,サービス指向アーキテクチャという本来の意味の他に,複雑であるという意味合いで引き合いに出されることが多い :-) SOAPやWSDLに代表されるWebサービスの標準仕様が周辺技術を含めると巨大になってしまい,軽量なRESTやJSON派との間で大きな論争になっ たのも懐かしい (もっとも,最近JSONにセキュリテやスキーマが,みたいな話を聞くと何だかなあとも思う :-))

そもそもマイクロサービスとSOAを分けるものが,複雑さである,という議論には少し違和感がある.複雑さは簡単にはなくならないからだ (マイクロサービスの複雑さについては,別途議論したい)

氏は "Microservices is SOA, for those who know what SOA is." (2014年3月)というブログの中で,マイクロサービスとSOAを比較し,両者に本質的な違いがないと主張している.これを解説したMark Little氏の "Microservices and SOA" も興味深い (翻訳もあるのでぜひ読んでほしい "マイクロサービスとSOA" ).

George Lawton氏は,2015年1月のHow microservices bring agility to SOAというブログで,複雑でモジュールが絡みあった(モノリシックな)アプリを小さなサービス分割するアプローチはSOAに端を発しているとし,マイクロサービスを,SOAのそもそもの理念を示す"Classic SOA"と関連付けている.

Bob Rhubart氏は,2015年3月のブログ"Microservices and SOA" の 中で,マイクロサービスとSOAを同一視する見方,違うものであるという見方の両方を紹介している.興味深いコメントは,「SOAは,企業のITを変革す るための戦略的な活動として生まれたものであり,マイクロサービスは,アプリケーションとそれを開発するチームの構成の新しいアプローチである」ということ.マイクロサービスは,各サービスが独立してデプロイされるが,SOAでは,各サービスが背後のモノリシックなプロセスに依存する場合もある,と指摘している.これは確かにそうだと思う.

2015年6月に投稿された鈴木雄介氏のブログ「マイクロサービスアーキテクチャとは何か」で は,SOAとマイクロサービスの違いは,「トップダウン」と「ボトムアップ」,「君主制」と「民主制」の差であるとしている.SOAのパターンの一つとし て企業をまたがるフローもあるし,マイクロサービスベースのアプリでも,どこかで組み上げてコントロールする必要があると思うけど,わかりやすく両者の 考え方の違いを示したものだ.スライド資料も公開されていて参考になる.

個人的には,機能を明確な入出力を持つサービスとして定義し,それらのサービスを組み合わせて大きなサービスを作るサービス指向アーキテクチャーがどんどん浸透していくことが大事で,両者の違いは大きな問題ではないと思う (議論を眺めるのは楽しいけど :-))

私の記憶が確かならば,SOAやWebサービスを紹介していた頃に強調していたことは

  • 呼び出すことができるサービスが明確に定義されて標準化されている
  • サービスの実装やプラットフォームが隠蔽されており,異なるベンダーや企業間でサービスを結合することができる (CORBAでは難しかったよね,みたいな :-))
  • サービスが疎結合である

各サービスが,独立して実行される(例えば別のデータベースを使って)という観点は確かにあまりなかった.これは,SOAが提案された当時は,サー ビスの定義や標準化が課題であったことに対し,マイクロサービスは,Web ServicesやRESTの普及によって,サービスという単位が存在しているところから生まれたという違いもあるだろう.

もう一つ当時強調していたのは,サービスの動的あるいは遅延結合だった.例えば,eコマースアプリで,商品を購入して発送する際に,条件に応じて発 送業者(のサービス)を切り替えるというシナリオである.疎結合であることでこのような柔軟な結合が可能になるが,オートバランスやバックップを除いて, 異なるサービスを動的に結合し選択するというシナリオは,マイクロサービスではあまり強調されていないように思う.

さらにもうひとつ,SOAにおいて,WSDLを使ったサービス定義とSOAPを使ったメッセージ交換はそれなりに市民権を得たが,サービスの登録と 発見のための仕組みであるUDDIはあまり流行らなかった.今から思うとSOAでは,企業内や関連企業間のサービスを組み合わせる場合が多く,どんなサービスがあるか は自明であったからであったからのように思う.反面,マイクロサービスが解こうとしている現在の環境では,関連企業を超えたサービスの連携が普通であり, サービスを登録し適切なサービスを発見することは大きな意味を持つと思われる.何だか楽しみである.

Comment(0)