起源から4年、実例から読み解くマイクロサービス

本連載ではこれまで、以下のようなマイクロサービスの主要概念を説明しました。

• 旧来からの「monolith(一枚岩)」のアプリケーションから脱却
• SOAとは異なり分散統治やREST APIなど「軽量な」アプローチ

今回は、マイクロサービスの起源や流行具合、実例といった観点でマイクロサービスの裏側・背景に迫ります。

　マイクロサービスの起源と流行

マイクロサービスは「33rd Degree Conference - Conference for Java Masers」にて、James Lewis氏が2012年3月20日に発表した”Micro services - Java, the Unix Way“が始まりとされています。その後、James Lewis氏とMartin Fowler氏が2014年3月25日に”Microservices“を掲載し、こちらが各所で引用されています。

筆者はJavaやクラウド関連のセミナーや勉強会によく出席しますが、最近ではマイクロサービスという言葉を聞かないことはないくらい、流行りはじめている印象があります。現に「ガートナー. エンタプライズ・. アプリケーション&. アーキテクチャサミット 2016」「AWS Summit Tokyo 2016」「JJUG CCC 2016 Spring」といったイベントでもマイクロサービスがテーマの講演が用意されていました。

一方で、そうは言っても自分の業務での適用はまだまだ先だろうといった印象をお持ちの方も多いのではないでしょうか。

実際どうなのかという点を、客観的なデータを元に考察します。Google Trendsを見ると、マイクロサービスは2014年あたりから伸び始め、2015年に入って急激な伸びを示していることがわかります。

一方でクラウド、アジャイル、IoTといった以前より知名度の高い単語と比べると、まだまだ小さい値であることがわかります。また、EJBやSOAといった類似した単語と比べると、他が下降傾向にあるのに対し、マイクロサービスは増加しているので、数年後には逆転しているかもしれません。

また、ガートナーが2015年に発表したハイプ・サイクルは以下のようになっています。

これは、新しいテクノロジについて大胆な未来を予測するもので、IoTや機械学習、ソフトウェアデファインドセキュリティといった一歩先行く言葉が並んでいます。米国版は例年8月頃発表されていますので、今後マイクロサービスがこの中に入ってくるかどうかが注目です。

実例が示すマイクロサービスの特徴

マイクロサービスには、Amazon.com、クックパッド、Netflix、LINEなど、多くの事例が出てきています。アプローチはさまざまですが、共通して、巨大な一枚岩のシステムの課題に対して解を求めています。

特に興味深いのは、各所で同時多発的に発生している点です。ボトムアップでベストプラクティスとして各所で行われてきたことが、James Lewis氏とMartin Fowler氏によって、マイクロサービスとして形式知化および共通認識化が進み、より一層の盛り上がりを見せてきています。

マイクロサービスを実適用するうえでは、どういったサイズのサービスに分割するかが悩ましい点の一つです。

Amazon.comは「two pizza team」「You Build It, You Run It」

Amazon.comでは「two pizza team」と呼ばれるチームのサイズに分割し、その単位でサービスを開発します。その名の通り、2つのピザを分け合って食べる程度の人数(6-8人程度)にします。これはマイクロサービスの特徴の一つである「ビジネス遂行能力に基づいた組織整理」であり、サービス(ビジネスの単位)に基づいてチームを組成すべきだという考え方です。

また、各チームが担う作業範囲を端的に表す言葉として、Amazon Web Servicesの CTO を務めるWerner Vogels氏の「You Build It, You Run It」があります。これは、「コードを作った人は、運用の責任も持つ」というDevOpsの考え方で、マイクロサービスの特徴の一つである「プロジェクトではなくプロダクト」であり、コードを作成してシステムをカットオーバーさせればプロジェクトは終わりという考え方ではなく、運用を含めてシステムのプロダクトとしてのライフサイクル全体を管理すべきだという考え方です。

Netflixは「Chaos Monkey」で故意に障害を起こす

Netflixは、Amazonクラウド上で意図的に障害を起こすためのツール「Chaos Monkey」をオープンソースで公開しています。マイクロサービスでは「障害発生を前提とした設計」が重要視されますが、システム全体の停止に繋がらないよう、日々意図的に障害を起こし続け、そこから得られた知見を生かすというやり方をとっているのです。

以上のように、各所でベストプラクティスとして行われてきたことが、マイクロサービスの特徴に紐付いています。

*　　*　　*

今回は、起源やハイプ・サイクルを通じて、マイクロサービスの立ち位置を説明しました。また、一枚岩のシステムの課題に取り組む際、マイクロサービスが比較的自然なアプローチであり、結果として同時多発的に適用事例が生まれてきています。

次回は、これらのアプローチを可能にさせ、マイクロサービスを開花させた技術要素について、触れていきます。