Azure Service Fabricの登場で個人的にはマイクロサービスに注目!

2015年8月3日 | By TatsuakiSakai | Filed in: Micosoft Azure, MSMVP.

お久しぶりです。ここのところ、AzureだけでなくKinect 2やユニバーサルアプリケーションと戯れる日々が続いておりました。

同時に、Azureの動向についても何とか振り落とされないようにしがみ付いておりました。なにせ、アップデートの頻度&数は相当なものがありますから・・・。

さて、最近のアップデートの中で「おや?」と思ったものがAzure Service Fabricとマイクロサービスです。

特に、マイクロサービスを見て「おや?」と思った方も中にはいらっしゃるのではないでしょうか?

私自身「ついに時代が追い付いてきたぞ!」と興奮せずにいられませんでした。(周囲は興奮しているように見えなかったようですが・・・・)

このアイディアは、今から13年ほど前、.NET黎明期に出てきたアイディアそのものです。

Patterns & Practicesで紹介されたこのドキュメントをまずはご覧ください。

少々時代が古いドキュメントではありますが、この中で紹介されている「ビジネスコンポーネント」の概念はまさにマイクロサービスそのものだと感じませんか?

当時は、WebサービスもSOAPベースのWCFであったり、メッセージフォーマットもXMLであったりと現在の姿とは異なりますが、考え方そのものは変わっていないことが分かるでしょう。こうした考え方が後にSOA(サービス指向アーキテクチャ)へと進化していったのでした。

そもそも、SOAがなぜ失敗したか(と敢えて言ってしまいますが) というと、構造自体が大袈裟であったことに他ならないと個人的に考えております。

サービスを公開するにも利用するにもその規約や手順があまりにも煩雑であり、サービスを利用する前にギブアップしてしまう人も多かったのではないでしょうか?

また、ESB(ビールではありません、エンタープライズ・サービス・バスです)製品が大変高価であったことも原因の1つであったかもしれません。

しかしながら、現在のマイクロサービスはより軽量なプロトコルやデータ表現、そしてよりシンプルな利用方法であり、気軽に利用できるというメリットがあります。

James Lewis/Martin FowlerによるMicrososervciesの解説(参照:日本語訳)にマイクロサービスとはどのようなものかが解説されております。

さておき、私もこの当時からこのアイディアを推進する立場であったため、マイクロサービスの登場は大歓迎です。

そもそも、マイクロサービスのように、アプリケーションをいくつかのパーツに分解して、キューやHTTPSなどを通じて連携するパラダイムは、Azureクラウドサービスにありました。これと何が異なるのか?

その解決のカギを握るのがService Fabricなのではないかと思います。

クラウドサービスの場合、スケール単位はロール単位でした。

つまり、スケールアウトする際にはロールをホストする仮想サーバが起動し、その中で1つのロールインスタンスが実行されていました。

この方式ではマイクロサービスを実行するには重厚長大すぎます。

クラウドサービスのロールと比べ、マイクロサービスは粒度の小さなサービスを想定しています。

そのため、この小さな粒度の単位でスケーラビリティを確保する必要があるのです。

そこで、Service Fabricなのです。

 

 

Service Fabricはアプリケーションをホスティングする一連のクラスタを構成します。このクラスタは数千台規模のマシンまでスケールアウトすることが可能です。また、複数のリージョンをまたがった構成も可能です。ここに複数のマイクロサービスがホストされます。

そうです、1つのService Fabricクラスタで複数のマイクロサービスをホストすることが可能なのです。これにより、サーバリソースを有効活用しつつマイクロサービス単位でのスケーラビリティを確保できるなど、マイクロサービスのメリットを享受しやすいアーキテクチャを実現することが可能です。

また、サービスの状態は多重化されたクラスタで守られています。Service Fabricが特定の状態を維持するステートフルなマイクロサービスのホストが可能である所以はここにあります。これにより、マイクロサービスはストレージやRDBに頼ることなく、その状態を保持し続けることが可能になります。当然ながらオーバーヘッドが低減されサービスの応答性が向上することも期待できます。もちろん、DRやバックアップを目的としてストレージやRDBに永続化状態を持つことも必要となります。

 

従来のクラウドサービスでは、サービス自体が永続的あるいは一時的に保持する状態を維持するために、Queueを用いたりTable(場合によってはCache)を用いたりすることがあります。こうしたサービスはクラウドサービスの外部のリソース(Azure内であっても)に頼る必要がありました。

一方、Service Fabricで実行されるマイクロサービスはこれらの状態維持が内包することが可能です。リソース管理も、サービスと状態が一体として実現されるため。サービスの障害時に参照関係が失われるという不安も解消できそうです。

この様に利点の多いService Fabricですが、こうした中でマイクロサービスはどうデザインされるべきでしょうか?

単機能を追求するわけですから、複雑性を極力排除してシンプルに構成されるべきではありますが、やり過ぎは禁物です。

たとえば、細かく分解しすぎてしまったがためにマイクロサービスAを利用するためには必ずマイクロサービスBが必要となるといったデザインがこれに当たります。(結構まじめな人ほどこのようなデザインをしてしまいがちです)

仮にサービスBが他のサービスからも利用される可能性が高いようであれば、このデザインを許容するしかありませんが、サービスBがサービスAのみから利用されるような場合はサービスBを分離する意味がありません。こうした懸念は、James Lewis/Martin Fowlerの記事でも指摘されています。

また、単機能を目指してデザインするマイクロサービスですから、HTTPのGET, POST, PUT(またはPATCH), DELETEで実現できる範囲に限定すると同時に、パラメーターにバリエーションを与え過ぎない方が良いと考えます。

たとえば、同じGETでもパラメーター数のバリエーションが0~10個もあったりしては単機能とは呼べません。パラメーター数のバリエーションは無いことが望ましいのですが、必須+省略可能オプションで2~3パターン程度に抑えることが現実的かと思います。

この例以外にも、マイクロサービスをデザインするにはまだまだ考慮すべき点があります。

しかしながら、まずは使ってみることが大切だと思います。

もちろん私も使っていきたいと思います。

その際、デザイン上で気づいた点などをこちらでご紹介していく予定です。

 


Comments are closed here.