クラウド図鑑 Vol.89

「マイクロサービス アーキテクチャ」への注目度が高まっている。その理由は「変化に強い」「スケールしやすい」といったメリットがあるとされてアマゾンやNetflixが以前から導入し、国内企業でもキヤノンやクックパッドなどの導入企業が増えてきたことだ。この数年で急速にクラウドが普及したことによって、ITインフラの追加や変更が以前より圧倒的に迅速になったが、インフラだけでなくアプリケーション開発も迅速化し、企業のITサービス全体を「変化に強い」ものにする場合に マイクロサービス アーキテクチャ を検討すべきである。また、実際の導入企業においては、前述のアマゾン、Netflix、キヤノン、クックパッドなどがAWSを利用しており、クラウドとの相性も良い。しかしながら、マイクロサービス アーキテクチャ にはメリットだけでなくデメリットもあるため、導入にあたっては自社に対する適合性やアプリケーションに対する適合性も含めて適切な判断が必要である。また、AWSのLambdaに代表される「サーバーレス アーキテクチャ」と混同されることも多いが、マイクロサービス アーキテクチャは異なる概念・考え方であることを後述する。

2017年4月26日 株式会社クラウディット 中井雅也

マイクロサービス アーキテクチャとは

microservices architecture(クリックで拡大)

この分野におけるソートリーダーとされるマーチン・ファウラー氏によれば、「”マイクロサービス アーキテクチャ”とは、ソフトウェアアプリケーションを独立して配置可能なサービスの組み合わせ(suite)として設計する方法」である(マーチン・ファウラー氏のブログ”Microservices”より。一方で彼は「正確な定義はない」としている)。上の図では、典型的なECサイトのアプリケーションにおいて、「注文」「決済」「メール」を独立させてマイクロサービス化している例を示した。左が従来の方式「モノリシックアーキテクチャ(一枚岩)」だが、右のマイクロサービス アーキテクチャ においては、決済のような機能単位でアプリケーションを分割し、ハードウェアやデータベースも分割して独立運用する。分割したマイクロサービス間はREST APIやRPCによって通信して連携する。このような機能分割によって、例えば新しい決済方法を追加するときには独立した決済サービスだけに機能追加や変更ができるため柔軟性が高く変化に対応しやすい。

モノリシック アーキテクチャの課題

monolithic (クリックで拡大)

 

では、従来のモノリシック アーキテクチャにおいて課題は何か。総じてアプリケーションが小さいうちは問題は少なく、マーチン・ファウラー氏もモノリシックで済ませられるならマイクロサービス化は極力しないよう警告している。だが、アプリケーションが巨大化することによって、小さな修正や変更が全体に及ぼす影響が大きくなり、バグによってシステム全体が停止した場合のビジネスへの影響も大きなものになる。銀行の勘定系オンラインのシステムは巨大なモノリシックアプリケーションの代表といえるが、機能追加や変更はせいぜい1年に数回程度が通例であり、また、障害対策に巨額な費用を投じていることも周知のとおりである。

マイクロサービス アーキテクチャによって解決できること

microservices(クリックで拡大)

 

では、マイクロサービス アーキテクチャによって何が変わるのか。前述したように機能分割したマイクロサービスを、独立したアプリケーションとして独立したインフラの上に配置し、データベースも独立して持たせる。必然的にバックアップや障害対策などもマイクロサービスごとに独立したものとなる。体制面において開発チームは6人〜12人程度の小規模な単位でマイクロサービスごとに開発やメンテナンスを独立運営していく。AmazonのCEOジェフ・ベゾス氏が提唱している適切なチームの人数の考え方、いわゆる「2つのピザルール」といわれる単位で、複数のチームが同時並行で稼働し全体としては巨大なシステムを実現する。この考え方はアジャイル開発の考え方と合致しており、インフラの自動化を含めDevOpsも取り入れ、継続的インテグレーション/継続的デリバリーによって機能の追加・変更の頻度を高める。マイクロサービスごとに独立しているため、追加・変更は他に影響を及ぼさず、原則的にサービスの全体停止がない。また開発言語、データベース、ハードウェアも、マイクロサービスの特性やトレンドにあわせて最適なものを選択できる。

マイクロサービス アーキテクチャのメリットとデメリット

ここでメリットとデメリットについて簡単にまとめてみる。

メリット

  • 総じて「変化に強い」システムを実現しやすい
  • サービスごとに柔軟な追加、変更が可能で影響は全体に及ばない
  • サービスごとに障害対策がとれ、障害が全体に及ばない
  • サービスごとに最適なテクノロジー、言語やフレームワークを採用できる
  • サービスごとに性能をスケールすることができる
  • 全般的に柔軟な開発、運用ができる

デメリット

  • 全般的に冗長なシステムになりオーバーヘッドが多い
  • 全体を見渡しにくく障害の影響を予想しにくい
  • 全体のテストやデバッグがしにくい
  • テクノロジーの標準を定めにくい
  • サービスをまたぐトランザクションや整合性を保つしくみがない
  • アジャイル開発、DevOps、インフラ運用の自動化などが前提で新しいITスキルが必要

総じていえば、マイクロサービス アーキテクチャによって柔軟性や変化への対応性は高まるが、冗長でオーバヘッドも多い。もともとアマゾンやNetflixが提供するようなシステムを、分散システム上で数多くの小規模チームによって実現するためのアーキテクチャであり、全体としては巨大なシステムを大規模な人数で開発・運営してためのアプリケーションおよび開発体制の分割のための手法ともいえる。そもそも米国企業は数多くのプログラマーを社内に抱え、また、新しいサービスを提供するために外部から新しくプログラマーを雇用することができるため、マイクロサービスアーキテクチャのメリットを享受しやすいが、日本はそうではない。一方で、マイクロサービス アーキテクチャによって、APIベースの開発に移行することで、Netflixが実現したマルチデバイス対応など副次的なメリットもあり、導入にあたっては、メリットやデメリットを多角的に見極める必要がある。

サーバーレス アーキテクチャとの違いについて

上述のように、マイクロサービス アーキテクチャとは、全体として巨大なシステムを、数多くの小規模チームで分割して開発・運営するための手法である。これによって柔軟性は高まるが、例えばサービスごとにバックアップを行うなど、むしろ全体としての運用負荷は大きくなる。これに対してサーバーレスアーキテクチャは、サーバーなどのインフラを用意することなく、ほぼ運用なしで、障害対策や拡張性なども気にすることなく、プログラムを実行するサービスであり、解決する課題が異なっている。また、現在のサーバーレスのサービスにはさまざまな制約があり、全てのアプリケーションには適用できないため、特定の限られた用途・処理を選ぶことも念頭に置くべきである。現在の主なサーバーレスのサービスについては「サーバーレス アーキテクチャの選択」を参照していただきたい。