開閉ボタン
ユーザーメニュー
ユーザーメニューコンテンツ
ログイン

  • 会員限定
  • 2020/08/25

マイクロサービスアーキテクチャは何が優れているのか、どこでつまずいてしまうのか

ソフトウェア開発技法の1つ、マイクロサービスアーキテクチャに関する議論は近年、活発です。「マイクロサービスアーキテクチャの採用でビジネスを拡大させた」という声が聞かれる一方で、「挫折してモノリシックアーキテクチャに回帰した」という声もあります。単に新しくて良いアーキテクチャ(設計)なのであれば、なぜそこに多くの挫折や失敗が生じているのでしょう?マイクロサービスアーキテクチャとは何か、どのような特徴を持っているのかあらためて振り返り、確認しましょう。

NTT Ltd. Group 波多野 敏明

NTT Ltd. Group 波多野 敏明

米国でオープンソースIaaS基盤ソフトウェアの開発を経験した後、IaaSサービスの開発・運用を経て、現在は国内内製クラウドサービスの設計・開発に従事。 サービスのAPI設計から、開発環境のサーバ・ネットワークのお守りや各種SaaSの管理、スクラムマスター、社内ITの改善、ユーザの利用傾向分析まで、必要なことならなんでもやる。 「漢は黙って最新バージョン」を座右の銘にしているが、現実はなかなか思い通りにならない。

photo
流行のマイクロサービスアーキテクチャ、その長所と短所をまとめる
(Photo/Getty Images)


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

 マイクロサービスアーキテクチャとは、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リンクにまで増えます。

画像
図1: メンバーの増加に対して、関係の複雑性は2乗で増加する

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

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

画像
図2: チームを適切なサイズに保つことで、複雑さをヒトが扱える規模に抑える

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

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

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

注1:日本語では”逆コンウェイの法則”と言われることが多いようですが原語は“Invert Conway Maneuver” であり、法則を逆手に取った戦略という含みのある語ですので、ここでは逆コンウェイ戦略と訳すことにします。

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

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

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

画像
図 3: モノリシックアーキテクチャの「共有される部分」は関係性を複雑にする

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

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

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

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

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

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

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

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

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

 独立したチーム内での開発は、チーム間での調整に比べてはるかに簡単に進めることができます。また複数チームがそれぞれの開発を並行して進められるため、アプリケーション全体の開発速度を速めることができるのです。
画像
図4: マイクロサービスアーキテクチャはヒトの関係もアプリケーションの関係もシンプルにする

【次ページ】マイクロサービスアーキテクチャが生み出す新たな複雑さとは

お勧め記事

Web開発 ジャンルのトピックス

Web開発 ジャンルのIT導入支援情報

PR

ビジネス+IT 会員登録で、会員限定コンテンツやメルマガを購読可能、スペシャルセミナーにもご招待!