マイクロサービスを理解するための3つのポイント

マイクロサービス(Microservies)という言葉を聞いたことがあるでしょうか。

マイクロサービスはIT辞典で以下の通りに定義されている用語です。

複数の小さなサービスの集合体としてシステムを構築し、各サービス同士をHTTP経由のAPIやメッセージングなどの軽量な通信で連携する手法。

James Lewis氏によって提案された言葉で、同氏がMartin Fowler氏と執筆した記事「Microservices」により各所で取り上げられるようになった。

複数の機能をひとつのアプリケーションの実行物として構築する「モノリシック(一枚岩)」アーキテクチャと比較される。

昨今急速に認知度が高まっていて、技術セミナーなどで耳にすることも多くなってきました。それでも、クラウドやアジャイルといった用語と比べるとまだまだ理解度は低く、以下のような感覚のエンジニアが多いようです。

• 少しバズワードっぽいが、とりあえず流行り言葉の一つだから抑えておきたい
• 触ってみて自システムへの導入検討につなげたい
• アマゾンやクックパッドなど、実例は多いものの、SOA(Service Oriented Architecture:サービス指向アーキテクチャ)との違いが今一つわからない

本連載では、マイクロサービスを取り巻く技術要素や位置付け、実開発適用のポイント等を解説していきたいと思います。

マイクロサービスを理解するための3つのポイント

マイクロサービスを理解するには、まずは以下の3点を抑えておく必要があると考えています。

• 「モノリシック(Monolithic:一枚岩)」の課題とマイクロサービスが生まれてきた経緯
• 「HTTP経由のAPI」の実態である「REST API」など、マイクロサービスを下支えしている技術
• 類似のアーキテクチャとして語られることの多い「SOA」との違い

もっと突っ込んで知りたい場合にはマイクロサービスを特徴付ける9つの要素だったり、クラウドなど、マイクロサービスを取り巻く多くの技術要素だったりを理解すると良いでしょう。

本連載では、これらについて順を追って説明していきます。今回はモノリシックです

Microservice vs Monolith(モノリス)

マイクロサービスの特徴はシステム全体を小さな粒度に分けて構築していく点です。

それとは対照的な従来型の開発スタイルは、Monolith(モノリス)と呼びます。Monolithとは一枚岩の意で、システムを単一のアプリケーションで構築します。

一枚岩のアプリケーションは、各業務等が密結合であるため、「開発」「ビルド」「デプロイメント」のそれぞれのフェーズにてさまざまな問題を発生させます。アプリケーションの単位のイメージはJava EE界隈の方であれば、ear/warを想像するとわかりやすいでしょうか。

従来、アプリケーションの密結合の問題を解決し、独立性を高めるために、以下のような対策が実施されてきました。

• コンテキストルートを分けて複数のアプリケーションに分割。ただしアプリケーション間の通信が必要
• アプリケーション内の一部の処理をライブラリ化
• MVCモデルやフレームワーク(Struts/Spring/Hibernate等)を活用し、画面・ロジック・DBアクセスといった層に分割

上記の効果は主に「開発」フェーズに限定され、「ビルド」および「デプロイメント」のフェーズになると、その単位は一枚岩、つまり同時に行われる必要がありました。

こういった状況は「変更容易性」を下げる要因となっていました。システムが巨大化すればするほど、全体を把握するのが困難となるのは言うまでもありませんが、各層が密結合していたために、影響範囲を見極めるのが難しかったのです。また、同時に「ビルド」「デプロイメント」に時間かかり、スピーディーな障害改修や機能追加を妨げてきました。

「ビルド」フェーズにはソースコードのコンパイルのみではなく、JUnit等の単体テストの実行や、SeleniumやSelenideといった結合テストの実行まで含まれ、これらにかかる時間は大きくなります。

ここでは、詳しくは述べませんが、CI(Continuous Integration:継続的インテグレーション)やCD(Continuous Delivery:継続的デリバリ)により、「ビルド」や「デプロイメント」の自動化が当たり前の時代になり、これらのフェーズにかかる時間や労力はこれまでよりも小さくなりました。それでも一枚岩であるが故に、いまだに一大イベントとなってしまうほどの時間がかかります。

筆者が開発を始めて間もない頃、先輩から開発(コーディング作業)にかかる時間の７割は「ビルド」している時間だと言われたことがありました。当時はあまりピンときませんでしたが、大規模なJava EEアプリケーション開発を経験していくにつれ、実感が生まれてきたように感じます。

極端な例では、メガステップ級のJava EEアプリケーションを開発する場合、Eclipseプラグインのような開発ツールの利用方法によっては、コードを書いてはコンパイルや静的チェックに数分待つことも珍しくありません。そのため、プログラマーはずっと腕組みをして画面を見つめているといったケースや、Sakuraエディタ等で開発し終わったらEclipseのエディタにコピーするといった苦肉の策をとっているケースも見られました。

また、性能観点での「拡張容易性」を下げる要因にもなっていました。デプロイメントが一枚岩であるがため、性能面で拡張しようとすると、一枚岩の単位でハード面を増強・追加し、Tomcat等のアプリケーションサーバのプロセスを増やす必要があります。

相性の良いシステムは?

以上、従来型のMonolithなアプリケーションと比較した場合のマイクロサービスのメリットを中心に説明しました。

一枚岩のアプリケーションに対して、マイクロサービスはシステムを複数のサービスに分割し、相互のやり取りをREST APIを用いて行います。これにより、各サービスはそれぞれ異なるプログラミング言語を利用していても構わないため、「開発」の独立性が高まります。さらに、サービスとして分割された業務ごとに「ビルド」可能なため、修正の影響が局所化され、「ビルド」にかかる時間が極小化されます。性能面で拡張が必要な場合は業務ごとの対応が可能となります。

次回以降、REST等、より突っ込んだ内容を説明し、マイクロサービスの動作イメージを深めていきたいと思います。

なお、Martin Fowler氏も『MicroservicePremium』にて注意を促していますが、マイクロサービスはいわゆる「銀の弾丸」ではなく、適合するシステムなどに関して注意すべき点もありますので、そのあたりも説明していきたいと思います。また、「クラウドネイティブ」といった昨今注目されている領域の開発スタイルにより、組織や文化等にどういった変化が生まれてくるかについても、言及していきたいと思います。