• 会員限定
  • 2020/08/25 掲載

マイクロサービスとは何か?何が優れているのか、どこでつまずいてしまうのか

  • icon-mail
  • icon-print
  • icon-hatena
  • icon-line
  • icon-close-snsbtns
記事をお気に入りリストに登録することができます。
ソフトウェア開発技法の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: マイクロサービスアーキテクチャはヒトの関係もアプリケーションの関係もシンプルにする

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

関連タグ

関連コンテンツ

あなたの投稿

    PR

    PR

    PR

処理に失敗しました

人気のタグ

投稿したコメントを
削除しますか?

あなたの投稿コメント編集

機能制限のお知らせ

現在、コメントの違反報告があったため一部機能が利用できなくなっています。

そのため、この機能はご利用いただけません。
詳しくはこちらにお問い合わせください。

通報

このコメントについて、
問題の詳細をお知らせください。

ビジネス+ITルール違反についてはこちらをご覧ください。

通報

報告が完了しました

コメントを投稿することにより自身の基本情報
本メディアサイトに公開されます

必要な会員情報が不足しています。

必要な会員情報をすべてご登録いただくまでは、以下のサービスがご利用いただけません。

  • 記事閲覧数の制限なし

  • [お気に入り]ボタンでの記事取り置き

  • タグフォロー

  • おすすめコンテンツの表示

詳細情報を入力して
会員限定機能を使いこなしましょう!

詳細はこちら 詳細情報の入力へ進む
報告が完了しました

」さんのブロックを解除しますか?

ブロックを解除するとお互いにフォローすることができるようになります。

ブロック

さんはあなたをフォローしたりあなたのコメントにいいねできなくなります。また、さんからの通知は表示されなくなります。

さんをブロックしますか?

ブロック

ブロックが完了しました

ブロック解除

ブロック解除が完了しました

機能制限のお知らせ

現在、コメントの違反報告があったため一部機能が利用できなくなっています。

そのため、この機能はご利用いただけません。
詳しくはこちらにお問い合わせください。

ユーザーをフォローすることにより自身の基本情報
お相手に公開されます