なぜ今マイクロサービスなのか? マイクロサービスを開花させた技術要素

これまでの技術との違いを踏まえ、マイクロサービスを開花させた技術要素を解説します。

これまでの技術との違い

マイクロサービスをWebアプリケーション構築でよく用いられるMVCモデルに当てはめると、MとVCをサービスでつなぐイメージです。また、J2EE 1.4・Java EE 5.0界隈の方向けには、サーブレットとリモートEJBをそれぞれサービスとして構築するイメージです。

2005年頃、Java関連の技術雑誌等ではEJB 2.xが多く紹介され、弊社内でもJavaのWebアプリケーションと言えば、EJBを前提とした研修が行われてきました。EJBは3.xになってこそ、実装が簡易化されましたがインタフェース定義等の複雑さや機能の過剰性からか、爆発的な普及には至らなかった印象がありました。

• SessionBeanが持つejbCreate/ejbActivateといったライフサイクルに関するインタフェースの実装
• ejb-jar.xmlにおいてsession-typeやtransaction-typeといった設定

少し細かい話題から入ってしまいましたが、EJBとは何者かはさておき、マイクロサービスは、EJBやSOAといったこれまでの技術と「やろうとしていること」は大きく変わりません。

ただそれを「下支えしているテクノロジー」が変わってきて、サービスを容易に開発できるようになり、花開いてきているように感じます。例えば、Spring MVCやSpring BootといったJavaのフレームワークを当たり前のように使うようになり、REST APIの開発に対するハードルが下がってきていることなどは大きな影響を及ぼしています。

こうした流れは決して珍しいものではありません。技術要素の変化・進化によって実現・普及に至ったテクノロジーは、過去さまざまな分野において存在します。

例えばスマートフォンです。筆者は学生時代にPDAを利用し、スケジュール管理等の機能を使っていました。ハードとしての見た目は、今のスマホとあまり変わりませんでしたが、ピンチイン・ピンチアウト、LTEによる高速通信といった技術要素が欠けていたために、スマホほど普及しませんでした。

また、クラウドもその例の一つでしょう。クラウドが出てきたときには、ハウジングやホスティングといったものと何が異なるのだろう?と感じたものです。その後の隆盛はもはや語るまでもありませんが、ネットワークが高速化し、CPU/メモリ等が安価に手に入る時代になってきたからこそクラウド(雲)にリソースを配置し、サービスとして利用しようという流れが出てきたと言えます。

自動化範囲を拡大させる技術要素

続いて、マイクロサービスの開発を構成するフェーズ別の技術マップを説明しましょう。

連載第一回にて説明したフェーズに加えて、前後に環境構築・環境変更のフェーズを追加しています。今回はDevOpsとCI(Continuous Integration:継続的インテグレーション)、CD(Continuous Delivery:継続的デリバリ)にフォーカスします。

旧来と比べてビルドや環境構築といったフェーズについても、コーディングし自動化できるようになり、マイクロサービスを開花させる要因となっています。

DevOps

開発(DEVelopment)チームがシステム開発プロジェクトを担い、リリースしたら運用チーム(OPerations)に引き渡す――国内の企業は、そういったスタイルをとっているケースが多いのではないでしょうか。

以下のように開発と運用はそれぞれ利害が異なるケースがあります。

• 開発側がシステムをより使いやすいものに変えようと、機能追加等を行ったとしても、運用側としては手順が変わるため嫌がられる。

• 開発側はログ一つ取るのも運用側に依頼せざるを得ず、障害等の際にスピーディーに進められない。一方運用側は複数の開発チームからの五月雨式の依頼に対し、次々に対応しなければならず、苦慮している。

こうした開発と運用の相反する利害関係を解消するべく、一体となって日々の障害や機能追加等に対応していく考え方をDevOpsと言います。マイクロサービスを開発するチームを組成する際、この考え方が用いられます。

CI・CD

「まだビルド・デプロイメントで消耗しているの?」――先進的なプロジェクトの経験者から旧来のプロジェクトを見た際には、そんな言葉が口をつくはずです。

ビルド・デプロイメントの環境整備はライブラリ管理とも呼ばれ、大変苦労する領域の一つです。これを自動化し、短周期でのリリースを行うための仕組みがCI・CDです。JenkinsやGradleに代表される自動化ツールにて実現されます。

近年では、Jenkins 2.0のリリースなど、ビルド・デプロイメントを構成する単体のジョブに関する機能はもちろん、ビルドパイプラインと呼ばれる、ジョブのつながりを管理する機能が強化されてきました。

併せて、以下のようなスピーディーにビルド・リリースしていく仕組みが考えられています。

• 一部のユーザだけに先行してリリースする「カナリアリリース」
• 2つの環境を切り替えることによるデプロイメントを実現する「ブルーグリーンデプロイ」

マイクロサービスは複数の業務をサービスに分割し、疎結合にするアーキテクチャです。ビルド・デプロイメントの回数も必然的に多くなります。そのため、CIやCDの環境はなくてはならないものと言えます。

*　　*　　*

今回は、DevOpsを中心に、マイクロサービスを開花させた技術要素について説明しました。マイクロサービスは初めてだが、使っている技術は意外と馴染みが深いと感じられた方もいらっしゃるのではないでしょうか。次回は、今回説明できなかった残りの技術要素を交えながら、マイクロサービスと並び注目されてきている「クラウドネイティブ」について、触れていきます。