マイクロサービスとは

　マイクロサービスとは、1つのアプリケーションを、下記のような特性を持つ細かなサービス（マイクロサービス）の組み合わせで構成することだ[1]と言われています。


　これは具体的にはどういうことでしょうか？なぜそのようにするのでしょう？

　実のところ、マイクロサービスは単なるソフトウェアのアーキテクチャというよりは、「どのようにそれを作るか」という方法論や、「どのようなチームでそれを作るか」という組織論の側面を持っています。

前提1：分割は複雑すぎる関係性をシンプルにする

　アプリケーションの話をする前に、まずはそれを作るヒトの話をしましょう。

　みなさんはアマゾン CEO ジェフ・ベゾス氏の「2 pizza rule」について聞いたことがあるでしょうか？　「チームのサイズはピザ2枚を分け合ってちょうどいいサイズにするのが良い。大きすぎるチームではメンバー間の意思疎通が困難になり生産性が低下する」という観点から設けられたルールだと言われています。

　図1に示すとおり、メンバーが増加するとその関係性の複雑さは2乗で増加していきます。たとえばA・Bの2人だと関係性はA×Bの1リンクしかありませんが、ABCの3人だとA×B、A×C、B×Cの3リンクに増えます。これが6人に増えると、関係性は15リンクにまで増えます。


　ハーバード大学心理学部でありチーム力学の専門家のJ. リチャード・ハックマン教授も、チームのサイズは「まず2桁はいけない。私の授業では6名以上のチームを許可していない。大概の場合、大きなチームはメンバーの時間を無駄にして終わるから」と述べています[2]。

　図2に示すように、大きな組織がチームを分けるのは珍しいことではありません。つまり、ヒトは複雑すぎる関係性をうまく扱えないので、扱いやすい規模に分割する戦略があるということです。

前提2：チームを分割しても、アプリケーションの複雑さは残る

　次に、アプリケーションを作る話をしましょう。

　「コンウェイの法則」について聞いたことはあるでしょうか？コンピュータ科学者であるメルヴィン・コンウェイが提唱した、「システム設計（アーキテクチャ）は、設計する組織の構造を反映させたものになってしまう」という法則です[3]。この法則を逆手に取り、作りたいシステムアーキテクチャの形にチームを組む、逆コンウェイ戦略（注1） という組織論を聞かれたことがある方もいるかもしれません。


　これはつまり、チームを分割したほうが良いほどの開発規模なのであれば、そのチームが作るアプリケーションも分割したほうが良い（あるいはチームを分割した時点で、できあがるアプリケーションも分割される傾向にある）ということにほかなりません。

　では、もし分割されたチームがモノリシック（1枚板・分割しない）なアプリケーションを開発していくとどのような不具合が生じるのでしょう？

　図3にモノリシックアーキテクチャを複数チームで開発した場合を図示します。


　モノリシックアーキテクチャとはいえ複数チームでの開発ですから、おそらくチームごとに分担を決めて開発することでしょう。図3では黄色・緑色・青色・赤色でそれぞれヒトのチームとアプリケーション内の分担を示しました。

　アプリケーションの中央に灰色で示したものは、モノリシックアーキテクチャでは避けがたい「共有される部分」です。それは、たとえばデータベースやテスト、ビルド、デプロイ、あるいはパフォーマンス、冗長化などかもしれません。単一のアプリケーションとして作るのですから、共有される部分が生じてしまうのは避けがたいことです。

　ですが、こんな話を聞いたことはないでしょうか？　

「隣のチームの書いた処理に時間が掛かりすぎて、アプリケーション全体が無応答になってしまった」
「データベースのスキーマに手を加えたほうが綺麗だけど、ほかのチームも使っているテーブルだから、改修には全体での合意が必要だ。合意形成には時間が掛かるから、暫定的に別テーブルを足して凌ぐしかない」
「コアなライブラリに修正があったので、全部のチームがその対応を取り込むまではテストもビルドも通らない」「他のチームの開発遅れの影響で結合試験が始められない、我々の次のリリースのスケジュールも遅れそうだ」
などなど。

　上記は一例ですが、モノリシックなアーキテクチャを採用した場合、多かれ少なかれ生じる問題ではないでしょうか。やっかいなことに、「共有される部分」に関することはそのアプリケーションに関わるすべてのチームに影響してしまう傾向にあり、チームの中に閉じて解決できる問題に比べ、解決にずっと労力が掛かる問題になってしまっています。

　チームを分割して複雑な関連性を整理しても、アプリケーションのアーキテクチャがモノリシックでは、チームをまたいだ複雑な関連性が残ってしまうことがわかります。

マイクロサービスは複雑さをどう解消するのか

　マイクロサービスはそのような問題に対する、1つの答えです。

　図4に示すように、チームの形に合わせてアプリケーションを区切り、「共有される部分」をバラバラにして、それぞれが独立した小さなサービスの中に取り込んで、共有されないようにしてしまえば良いのです。

　独立したチーム内での開発は、チーム間での調整に比べてはるかに簡単に進めることができます。また複数チームがそれぞれの開発を並行して進められるため、アプリケーション全体の開発速度を速めることができるのです。
【次ページ】マイクロサービスが生み出す新たな複雑さとは