2015年7月23日

イマ旬キーワード

マイクロサービス

Webサービス企業を中心に、新しいシステム・ソフトウエア開発のアーキテクチャスタイルである「マイクロサービス(Microservices)」が注目されています。

技術開発本部 吉田 英嗣

マイクロサービス(Microservices)とは?

ソフトウエアの複雑化・大規模化やクラウドの利用拡大が急速に進むなか、それに従った形でソフトウエアアーキテクチャおよび開発方法も大きく変わろうとしています。その兆候の1つとして「マイクロサービス(Microservices)」という新しい開発手法の登場があります。AmazonやeBayと言った世界規模で大規模なWebサービスを提供する企業を中心に採用されていることから、昨年ごろから注目を集めています。

「マイクロサービス」という言葉は、James Lewis氏が2012年に発表した"Micro services - Java, the Unix Way"が起源参考1とされており、その後、2014年にLewis氏がMartin Fowler氏と執筆した記事"Microservices参考2"により各所で大きく取り上げられるようになりました。その記事において、マイクロサービスは下記のように説明されています。

マイクロサービスとはアーキテクチャスタイルの1つであり、小さなサービスの組み合わせにより単一のアプリケーションを開発するアプローチです。そして、その小さなサービスはそれぞれ自身のプロセスで動作し、軽量な方式で通信をします(通常、HTTP Resource APIが使われます)。個々のサービスは、業務上の機能に沿って構築され、その配備は完全に自動化されたものになります。それらサービスに対しての集中管理は最低限にし、また、それぞれのサービスは異なるプログラミング言語や異なるデータストレージ技術を利用します。

本稿筆者による翻訳

Microservice vs Monoliths

また、少々概念的ではありますが、これまでの古いアーキテクチャスタイルを「一枚岩のアーキテクチャ(Monoliths)」として捉え、それとの比較によりマイクロサービスを説明できます(図)。

【図】

一枚岩のアーキテクチャでは、複数の機能を1つのアプリケーションの実行物として構築します。これまでの多くのアプリケーションはこの形で構築されています。例えば、サーバーサイドのWebアプリケーションの実装は、ビジネスロジック、UI、データベースアクセスなどが一体となった実行物としてビルド・配備されます。これまではこのような一枚岩のアーキテクチャでも問題はなかったのですが、非常に大規模で複雑になるWebサービスを提供する上では、いくつか問題が目立つようになりました。具体的には、大規模Webサービスに特有のニーズ――「ビジネス変化への素早い対応に向け、非常に高い変更頻度注1が求められる」、「クライアント数の爆発などの変化に即応する高性能・高可用性が求められる」――に対応するために、下記のようなアーキテクチャ上の問題が顕在化しています。

  • 変更が容易ではない

    ちょっとした変更でも、全体のリビルドと再配備に時間を必要とする。また、時間経過とともにソフトウエア全体の把握が難しくなり、それが変更をさらに遅くさせる。

  • スケーリング注2に柔軟性がない

    アプリケーションの一部の機能をスケールさせることが必要だったとしても全体を複製しなければならない。

マイクロサービスはこれらの問題への解決策として、アプリケーションを構成する個々のサービスは独立したプロセスで実行されるように配備します。それにより、きめ細かにスケールできるようになります。また、それぞれのサービスを独立性の高い単一のビジネス機能を提供するものとして作ることで、変更の影響範囲を限りなく小さくします。

しかしながら、そのようなマイクロサービスの構築は簡単なことではありませんし、当然のことながらトレードオフが存在します。マイクロサービスの大きなデメリットとして、分散化するシステム設計が複雑になる、通信オーバヘッドが大きくなる、運用管理が大変である、といったものがあります。小さなサービスとして機能分割するため、アプリケーション全体から見た整合性をとることが困難です。特に、異常処理やトランザクション処理の設計は顕著に難しくなります。また、小さく分割されたサービス間で行われる通信が大量に発生することになります。さらに大量になるサービスの運用コストも高くなります。ある事例では1つのアプリケーションを構成するサービスが20個にのぼり、それが40~60プロセスで実行されているため、それらの運用管理は非常に労力がかかってしまったことが報告されています参考3

SOAとの違い、今後の動向

勘のよい方は気づいたかもしれませんが、同じようなコンセプトとして約10年前から流行した「サービス指向アーキテクチャ(SOA、Service Oriented Architecture)」があります。そのため「マイクロサービスはSOAの焼き直しである」という意見もあります。筆者も技術的な観点において両者に本質的な相違はないように思います。ただ10年前と比べて異なることは、

  • ソフトウエア変更のスピードと柔軟性に対するニーズの高まり
  • イネーブラ技術の進歩―Docker等のコンテナ仮想化技術やContinuous Integration等のインフラ自動化技術

といった変化です。それらの変化により、(本質的な意味で)SOAに対する必要性が増し、SOAの実現が容易になってきているのではないかと考えています。その結果がマイクロサービスです。

一方でマイクロサービスには課題もまだ多くあります。これに対して、マイクロサービス構築に適したフレームワーク(Spring Boot等)やライブラリ(Netflix OSS等)などが提供されはじめています参考4。マイクロサービス構築技術や設計技法の成熟化が今後の普及の鍵となるでしょう。

注釈

  • 注1ここで言う更新頻度は1日で何度もリリースするくらいの高い更新頻度である。
  • 注2性能・処理能力の向上のためにハードウエアなどのリソースを増強すること。

著者プロフィール

【写真】

技術開発本部 吉田 英嗣

開発自動化技術を中心としたソフトウエア生産技術に関する技術開発に従事。これまではソフトウエア開発自動化をテーマに研究開発から実践導入まで主導してきた。2015年よりNTT DATA Technology Foresight策定を担当。Java等に関する書籍・記事執筆も行う。

お気軽に
お問い合わせ
ください

マイクロサービス(Microservices)に関するお問い合わせ

お問い合わせフォーム

マイクロサービス(Microservices)に関連する情報

サービス

システム開発の手順・環境やサポートを一体化したトータルソリューションで、お客様業務の大幅効率化を実現