フィオラノ ソフトウェア ジャパン ブログ
    Twitter
  • Facebook
  • Google+

マイクロサービス (その1) – モノリシックとの対比 —

miroservice-banner

SOA の難点とマイクロサービスへの期待

クラウド、ビッグデータ、API エコノミーなどデジタル ビジネスの領域に ”マイクロサービス *2” というバズワードが現れてきました。

サービス指向アーキテクチャ (SOA) への期待が薄れる中、アプリケーション開発のアーキテクチャ スタイルとしてマイクロサービスに注目が集まっています。

2000年代の初期に登場した SOA は、大きな期待を集め、また導入に成功したプロジェクトも多くありました。それにもかかわらず、今日では、いくつかの理由によって、過剰に宣伝されたハイプ (hype) なテクノロジーとみなされるようになってきました。

SOA は、サービス間のインタフェースを定義するだけで数か月も要する複雑でコスト高なものとみなされるようになっています。SOA のプロジェクトでは、サービスの粒度を非常に大きなものとし何種類ものインタフェースを有するものとして実装されがちです。これはサービスに汎用性を持たせようという意図の結果だと思われるのですが、却って使い勝手が悪くなり、SOA のメリットの1つであるサービスの共有/再利用を阻害してしまいます。別の極端な例は、サービスを数行のコードしか持たない小さなものとして実装してしまうケースです。このような小さなサービスでは簡単で単純な業務処理を実行するのに、数十、数百のサービスを連携しなければならず、サービス間の通信だけで多大な処理時間やコンピュータ リソースを費やしてしまうことになります。

SOA の難しさの1つに、サービスの粒度決定があるといってもよいでしょう。

このクラシックな SOA が持つ欠点を解消するものとして、アプリケーション連携のアーキテクチャへのマイクロサービスの応用に期待が集まっています。

マイクロサービスの詳細を見ていく前に、モノリシックなアプリケーション アーキテクチャと対比してみましょう。

 

モノリシック(Monolithic) なアプリケーション

次の図はモノリシック *1なアプリケーションとマイクロサービスのコンセプトを対比したもので、いろいろなサイトやブログでよく見られるものです。

comparisone

この図でマイクロサービスとはどのようなものか何となくわかりますが、少し抽象的すぎますのでより具体的な例にあてはめてみましょう。

下の図は、オンラインの販売アプリケーションをモノリシックに開発した例です。

monolithic

UI (ユーザー インタフェース)、ビジネス処理ロジック (アカウント管理、オーダー管理、在庫管理など) は単一のプロセスとして実行されます。必要なデータは、すべての機能で共有する DB に格納されています。処理ロジックはモジュール化の利点を活かして実装されます。

また、注文件数が多い場合には、複数のインスタンスを稼働させることでスケールアウトすることができます。

こうしてみると、モノリシックなアプリケーションでもうまく運用できるように思えます。

しかしながら、ビジネス戦略として配送拠点を増設することが頻繁に起こったり、アカウント管理を SaaS 形態の CRM に変更するなどの要請が IT システムによせられます。これに応じてアプリケーションも変更する必要が生じます。変更が大規模なものであれ小規模なものであれ、アプリケーション全体を再構築しなければなりません。変更を重ねるにつれて、モジュールの境界はあやふやなものとなり、ある処理ロジックを特定のモジュール内に隠蔽しておくことが難しくなってきます。

また、ビジネスの拡大によって注文リクエストが増大した場合でも、ユーザーインタフェース機能などの一部分のスケールが難しく、アプリケーション全体をスケールしなければなりません。膨大なハードウェア リソースが必要となってしまうのです。

 

マイクロサービスアーキテクチャによるアプリケーション

前述のモノリシックなアプリケーションに伴うフラストレーションを解消するものとして、マイクロサービスに注目が集まっているのです。

microservice

マイクロサービス アーキテクチャでは、単一の機能をマイクロサービスとして作成します。マイクロサービスは、他のマイクロサービスとはデータも含めて完全に独立しており、あるマイクロサービスの変更が他のマイクロサービスに影響を及ぼしません。マイクロサービスの実行も、それぞれ単独のプロセスとして稼働します。

このアーキテクチャによって、以下の利点を得ることができます。

  • 独立してデプロイできる (変更、置き換えが他のマイクロサービスに影響しない)
  • 独立してスケールできる (全体ではなくマイクロサービス単位の複数インスタンス化など)
  • 確固としたモジュールの境界をもつ(他のマイクロサービスに影響が及ばない
  • 様々なプログラミング言語で作成できる(変更、置き換えが他のマイクロサービスに影響が及ばない
  • マイクロサービス毎に異なるチームで運用管理できる

 

次回は、マイクロサービスのアーキテクチャについて更に掘り下げてみます。

 

参考 (資料、文献、Webサイト など)

1. モノリス、モノリシック

モノリス (monolith) という言葉は、『The Art of Unix Programming』 という本の中で “大きすぎるプログラム” を指す用語として使用され、以降 Unix コミュニティなどで使われ始めました。モノリシック (monolithic) はモノリスの形容詞です。また、日本では、Monolithic Program を “一枚岩プログラム” と訳したりします。
The Art of Unix Programming

2. マイクロサービス

マイクロサービス (microservices) という言葉は、ソフトウェアを他から独立してデプロイできるサービスの集合として設計する方法を指すものとして、James Lewis氏によって提案されました。この詳細については、Jmanes Lewis氏が Martin Fowler氏と共に著した『Microservices』という記事を参照してください。
Microservices

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

次のHTML タグと属性が使えます: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>