月曜日, 6月 22, 2015

マイクロサービスで守るべきたった一つのこと このエントリーを含むはてなブックマーク


最近、マイクロサービスという言葉をよく聞く。  一つだけ言いたいことがある。

マイクロサービスとSOA

かつて私はIBMのSE時代にSOAを広めようとしたがうまくいかなかった。 
一言でいえば概念先行の「絵に描いた餅」から抜け出すことができなかったからだと思う。

それが最近ようやく、マイクロサービスという形で本物になってきた。 

マイクロサービスはSOAと目指すところは同じだと思うが決定的に違うものが一つある。

それは、SOAのような概念先行ではなく、実際に存在する優れたウェブサービスのアーキテクチャーに付けられた名前であり、後付けの理屈であるということだ。

「優れたウェブサービスを観察したところ同じようなアーキテクチャだったので、それをマイクロサービスアーキテクチャと名付けた」ということらしい。

I/Fを決めて疎結合にすることが重要

モノリシックなアプリをコンポーネントに分割して、小さなサービスの集合体として構築する方法といえば、SOAと同じだと言えなくもない。

しかし、単に分割してWebサービスで繋いだとしても実質的にはモノリシックのまま変わらないだろう。 

ポイントは、I/Fをきっちり決めてコンポーネント間を疎結合にすることである。 
疎結合とは、実装面でいえば、自コンポーネントに何かしら影響のあったとしても、他のコンポーネントへの影響がないようにすることだ。

 I/Fから先は関知しないというのが鉄則であり、サービスの実装がどうなっていようと実行結果が保証されていれば問題ないという立場を取る。 
また、非同期実行により遅延などを許容する仕組みにすることも有効かもしれない。 

このように突き詰めていくと、おのずと「プロジェクトではなくプロダクト」という考え方になっていくのだと思う。

SPAと疎結合

SPAにおいてもこの考え方は有効だと思う。

I/Fを元に疎結合にすればクライアント開発者とサービス開発者は並行して開発できるようになる。 

それが、I/FではなくRDBのテーブルをクライアント開発者がイメージするようになると、すぐに密結合に陥るので要注意である。
(そうなるとクライアント開発者はRDB設計者に大いに振り回されることになる) 

ただ、クライアントもサービスも同じ人が設計するような小規模開発の場合は、I/F分割などを考えずにモノリシックに作った方が効率的かもしれない。 

開発効率を優先して、最初は敢えてモノリシックに作っておき、後で大規模になったときにマイクロサービス化して分割するという方法もありだ。 
 

追記:マイクロサービス ⊂ Reactive Systems?

最後に、Reactive Systemとの関係について。

私はESBに代表されるようなほとんどのSOAが失敗に終わったのだろうと考えているが、以下に言及されているように、SOAもまた「同期的な文法で非同期プログラミングができる」というコンセプトの一つであったように思う。

レイテンシや処理の失敗、ネットワークの不安定性、あるいはそれを補うための運用監視といった話題は無視できません。過去に、「同期的な文法で非同期プログラミングができる」というコンセプトを打ち出したプログラミングモデルが大体失敗に終わったのは、そういった事情でしょう。 http://okapies.hateblo.jp/entry/2015/06/26/024505
また、この資料によれば、マイクロサービスはReactive Systems、つまり、「大規模システムの要求に対応できるような設計原則を備えるシステム」の具体例の一つと考えることができ、そこには、非同期メッセージングで疎結合コンポーネントを連携させるといった適切かつ現実的な実装方法が含まれている。

「同期プログラミングにとっての異物」をプログラマの目から隠してしまうのではなく、少し考え方を変えて明示的に扱った方が、最終的には幸せになれる気がしてきます。そして、Future/Promise や(Rx の)Observable のような関数型インタフェースは、非同期な実行モデルに基づくデータフローを記述する上で、優れた抽象化を提供してくれます。
マイクロサービスは後付けの成功パターンということであったが、Reactive Systemsのような設計原則に基づいた話でもあるというのは新しい発見である。

 
参考記事
 
© 2006-2015 Virtual Technology
当サイトではGoogle Analyticsを使ってウェブサイトのトラフィック情報を収集しています。詳しくは、プライバシーポリシーを参照してください。