あけましておめでとうございます。

2016年もスタートして1週間以上経ち、今週から仕事始めだった方も多かったことと思います。

2016年を迎えるにあたり、いくつかご報告があります。

 

1.ランドコンピュータを卒業いたしました

昨年末をもって株式会社ランドコンピュータを退職いたしました。

2年1か月という短い期間ではありましたが、新規ソリューション開発と新規ビジネス立ち上げのための仕掛け作りに邁進してまいりました。

会社も無事東証2部への新規上場を果たし、周囲からは「何故この時期に?」聞かれたこともありました。

決してネガティブな理由で退職したわけではなく、今後のエンジニア人生を考えて残りの期間でできる限りのことをやりたい、、、と思っての決断でした。

会社自体はとてもイノベイティブであり、今回の決断に少々躊躇することもありましたが今回の決断が正しかったと信じております。

今後ともランドとは良好な関係を築いていきたいとかんがえております。

 

2.Microsoft MVPの受賞を辞退させていただきました

毎年1月はMicrosoft MVPを受賞させていただく時期ですが、今年度の受賞は辞退させていただきました。

今年からもうMVPではありませんが、引き続きJAZUGのお手伝いは続けさせていただきます。

今後ともよろしくお願いいたします。

 

3.日本マイクロソフトの一員となりなした

実は上記2つのご報告の理由はこれでございます。

2016年1月1日付で日本マイクロソフトにJoinさせていただきました。

クラウドソリューションアーキテクトとして、企業や公共機関などのお客様に対してMicrooft Azureを活用していただくためのお手伝いをさせていただきます。

日本企業の皆様にAzureの良さを感じていただき、ビジネスの中でどんどん活用していただければと思っております。

また、Azureに関する情報提供も今までよりも一層、積極的に進めていきたいと思います。

まだまだ新参者のアーキテクトではありますが、今後ともよろしくお願いいたします。

 

12466244_10208197481675891_2547206140484594342_o

 

 

前回のポストでご紹介した通り、マイクロサービスの発想は全く新しいものではなく、ソフトウェアを部品化して組み合わせ部品を再利用するというアプローチはもはやソフトウェア業界の常套手段といっても過言ではありません。

つまり、これまでのアプローチとマイクロサービスには大きな違いはなく、単に実現手段が異なるだけです。

では、どのような方針でマイクロサービスを設計すべきでしょうか?

まず、大原則として、「マイクロサービスは独立した単機能である」ということを掲げておきます。

つまり前回ご紹介した通り、様々な依存関係を含む複合型のサービスはマイクロサービスとは言えない訳です。

ではどのように考えたらよいか、以下の例を基に考えてみましょう。

今あなたが旅行に行こうと思い立ったとしましょう。

国内、海外と様々な行き先がありますが、「○○に行こうか」と、場所が決まったとしましょう。

この際、あなたはどちらの行動を取りますか?おそらく、以下の2パターンに分類できるかと思います。

第1のパターンは、旅行代理店に出向きパッケージツアーのパンフレットを入手したり、雑誌やネットなどでパッケージツアーの情報を探したりするケースです。

おそらく旅慣れていない方はこちらのパターンが多いかと思います。

なぜなら、この場合は航空券(または列車などの交通機関)やホテル(旅館)、アトラクションなどの詳細はパッケージツアーの企画者にお任せできるからです。

第2のパターンは自身で交通機関やホテルの空き状況を検索し、自身で現地の観光情報を探すパターンです。

頻繁に訪れる場所への旅行や旅慣れた人の場合はこちらのパターンかもしれません。

一口で「旅行を計画する」といっても、このようにアプローチが異なります。

しかし、両者の行動には違いがあるものの、実は共通する部分があります。

一見、全く異なるように見えますが、両者には「外部のサービスを利用する」という共通点があるのです。

パッケージツアーのパンフレットも、航空便のスケジュール照会も、誰かの提供するサービスであるのは異論ありませんよね?

単に入手できる情報の粒度が異なるだけの違いです。

前者は日程からフライト、宿、現地の交通、市内観光まですべて揃った形で情報が得られます。

後者は、それぞれの結果が出てきて、これらの結果を基に自身で旅程を組みわせます。

ここでピンときませんか?そう、後者の解決方法はまさにマイクロサービスの組合せによる問題解決に類似しています。

しかし、パッケージツアーも「完全にお任せ」型のサービスとも限らず、航空会社、ホテル、滞在日数、オプショナルツアーなど選択肢が多くあり、これらの選択で成立していることに気付くと思います。

たとえば、特定の航空会社が良いとか、ホテルのグレードは4つ星以上に限るとか・・・。

言ってみれば、一見一枚岩に見えるパッケージツアーも、複数のマイクロサービスの組合せで成り立っていると考えることができます。

単純なパッケージツアーの構成は「航空便検索&予約」、「宿泊先検索&予約」、「オプショナルツアー検索&予約」のマイクロサービスから構成されます。

仮に、複数の都市に滞在するような場合でも、これらのサービスを滞在都市分だけ繰り返し利用するだけで旅行プランは概ね作成できます。

そして、これに「レストラン検索&予約」などのサービスも加われば、旅程の計画と予約は完璧でしょう。

また、こうした一枚岩のサービスを分割したものを、マイクロサービスとして切り出しWeb APIを公開していたとしたら、外部のサイトやサービスから利用可能になります。

この様に、特定のビジネスシナリオをベースにしたアプローチで、マイクロサービス化していくことができます。

これも、1つのアプローチとしてされて有効でしょう。また、こうしたサービスは多くの場合外部サービスにより再利用されることを想定しています。

もう1つのアプローチとして、技術的側面から複数のマイクロサービスに分割するアプローチも存在するでしょう。

これは、再利用性よりも単独のアプリケーションのスケーラビリティやセキュリティの最適化を優先するアプローチとなります。

先の旅行予約の例を挙げれば、航空便の検索と予約では負荷の集中するタイミングやトラフィックが異なります。

フライトスケジュール検索は平均的にトラフィックが発生し、旅行シーズンに検索が集中するかもしれません。

予約は検索ほどの負荷増大は無いかもしれませんが、予約開始日や割引運賃適用期限前に集中することが予想されます。

検索、予約のそれぞれを最適化するのであれば、これらのサービスを分離した方が望ましいでしょう。

たとえば、「検索」では乗継を含めたフライトスケジュールの検索機能を提供するサービスとして提供し、「予約」は各便の空席照会と予約機能を提供するサービスとして提供します。

この様に、フライトの手配は「検索」と「予約」の2種類のマイクロサービスから構成されるようにしておけば、それぞれを独立して配置・実行することが可能です。

また、予約に関しては決済を伴いますので、セキュアなサービスとして分離することも求められるでしょう。

ここで注目してほしいことは、技術的側面からサービスの粒度が決定される場合においても、必ずビジネスシナリオを実現する1ステップ単位でマイクロサービスが分割さていることです。

どうしてもアプリケーションを分割するとなると、「UI」、「ビジネスロジック」、「データコンポーネント」といったn層型アプリケーション的な分割を考えてしまいがちですが、マイクロサービスはこうしたアプローチとは視点が異なります。

そもそも、マイクロサービスはバックエンド処理を提供することを想定しているかも知れませんが、この場合でも分割単位は「ビジネスロジック&データコンポーネント」ではなく「ビジネスシナリオ&ビジネスシナリオのステップ」となります。

あくまで個人的な意見ですが、マイクロサービスの粒度を決定する際、以下のようなチェックポイントで検討すると良いと考えます。

 

・インタフェースを介してサービスの提供機能を独立させることが可能であるか?

・1セットの機能(CRUD操作等)に集約されているか?

・呼出しの頻度が多すぎることなく、サービス間の関係が疎結合になっているか?

・サービスのライフサイクルは独自に決定可能か?

 

また、サービス間はWeb API (HTTPS)やメッセージ・キュー(AMQP)等のインタフェースを用い、コントラクト(受け渡されるデータ形式)はJSONやCSVなど、比較的軽量なテキストで受け渡されることが望ましいでしょう。

また、参考になるアプローチとしてドメイン駆動アプローチがあります。

Microsoft のドキュメントではPatterns & practicesの各種ガイダンスが参考になると思います。

最後に、「悪戯に細かなサービスを量産しない」ことが、マイクロサービス活用の成功への近道だと考えます。

お久しぶりです。ここのところ、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パターン程度に抑えることが現実的かと思います。

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

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

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

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

 

Azure Service Fabricの登場で個人的にはマイクロサービスに注目! はコメントを受け付けていません。 Micosoft Azure, MSMVP