マイクロサービスアーキテクチャを、あなたの開発チームは本当に使うべきなのか：Gartner Insights Pickup（229）

ソフトウェアエンジニアリングリーダーは、分散アプリケーションをなぜ、いつ、どのように使うかを理解して、このアプリケーションの効果的な活用につなげなければならない。

[Laura Starita, Gartner]

ガートナーの米国本社発のオフィシャルサイト「Smarter with Gartner」と、ガートナー アナリストらのブログサイト「Gartner Blog Network」から、＠IT編集部が独自の視点で“読むべき記事”をピックアップして翻訳。グローバルのITトレンドを先取りし「今、何が起きているのか、起きようとしているのか」を展望する。

　Gartnerが行ったソーシャルメディア分析調査によると、2019年1月から2020年9月までの間に、「マイクロサービスアーキテクチャ」への言及数は42％減少した。

　この傾向は、マイクロサービスアーキテクチャへの幻滅の高まりを示している。マイクロサービスアーキテクチャは、サービス指向アーキテクチャとドメイン駆動設計原理を分散アプリケーション――つまり、マイクロサービスに適用することで、アジリティ（開発の迅速性）、デプロイ（展開）の柔軟性、きめ細かいスケーラビリティ（精緻な拡張性）を向上させることを目指す設計パラダイムを指す。

　Gartnerは、マイクロサービスを「機能範囲が小さく、強固にカプセル化され、疎結合型で、独立した展開可能アプリケーションコンポーネント」と定義している。マイクロサービスアーキテクチャは大きなメリットを提供するが、なぜ、いつ、どのように使うかについての誤解から、導入がうまくいかないことが多い。

　「ソフトウェアエンジニアリングチームがつまずく原因は2つある。複雑さと、文化的なディスラプション（創造的破壊）だ」と、Gartnerのアナリストでディスティングイッシュト バイスプレジデントの、アン・トーマス（Anne Thomas）氏は指摘する。

　「複雑さは、マイクロサービスがアーキテクチャ上のメリットを実現するには、厳密に独立していなければならず、開発者は新しいパターンを導入し、多くのアーキテクチャ上の制約に従って、マイクロサービスの独立性を確保しなければならないことに起因している。文化的なディスラプションに関して言えば、マイクロサービスの活用を成功させるには、チーム構造の変更と分散コンピューティングスキルの向上、成熟したアジャイルおよびDevOpsプラクティスの実行が必要になる」（トーマス氏）

　マイクロサービスアーキテクチャはアジリティとスケーラビリティを高めるが、どんな状況にも適するわけではない。実際、このアーキテクチャを使うことが明らかに誤りである可能性がある。マイクロサービスの導入と活用を成功させる可能性を高めるために、ソフトウェアエンジニアリングリーダーは、マイクロサービスプラットフォームをセットアップする前に、マイクロサービスアーキテクチャに関する3つの基本的な質問に答えられなければならない。それは、なぜ、いつ、どのように使うかだ。

なぜ使うか？

　「なぜ使うか？」の理想的な答えが出せれば、明確なROI（投資対効果）を示したビジネスケース（投資対効果検討書）が作成できるだろう。ソフトウェアエンジニアは、アプリケーションの新機能の継続的デリバリーを実現するために、マイクロサービスアーキテクチャを導入することが最も多い。実際、継続的デリバリープラクティスを実装しようとしているのでなければ、より粒度の粗いアーキテクチャモデルを使う方が得策だ。Gartnerは、このモデルを「メッシュのアプリ＆サービスアーキテクチャ（MASA）」や「ミニサービス」と呼んでいる。

　マイクロサービスアーキテクチャに関する以下の重要な事実は、リーダーがこのアーキテクチャを使う魅力的な理由を考えるときに、誤解を避けるのに役立つ。

• マイクロサービスアーキテクチャはアジリティを高める

　マイクロサービスアーキテクチャはアジャイルなDevOpsや継続的デリバリーのプラクティスを促進し、ソフトウェアエンジニアリングチームは、新機能をデプロイするサイクルを加速できる。

• マイクロサービスアーキテクチャは複雑

　マイクロサービスアーキテクチャは、個別に開発やテスト、デプロイ、スケール、更新できる分散コンポーネントのセットとして、機能の実装に重点を置いている。このため、複雑な設計を要求する。

• マイクロサービスは費用の節約につながらない

　通常、マイクロサービスアーキテクチャの実装コストは、モノリシックアーキテクチャよりも高くつく。

• マイクロサービスはAPIとは異なる

　マイクロサービスアーキテクチャは、APIの背後にある機能を実装する1つの方法だが、API自体とは別物だ。

• マイクロサービスは共有してはならない

　マイクロサービスアーキテクチャのアジリティの目標を達成する鍵は、個々のマイクロサービスの独立性にある。

• マイクロサービスはコンテナとは異なる

　ほとんどのチームは、マイクロサービスをコンテナにデプロイする。だが、コンポーネントの独立性を保証する設計パターンを採用しなければ、マイクロサービスアーキテクチャを使っているとはいえない。

いつ使うか？

　ソフトウェアエンジニアリングチームが、ミニサービスとアジャイルなDevOpsや継続的デリバリーのプラクティスを既に導入しているものの、ソフトウェアエンジニアリングのサイクル目標を達成できていない場合、マイクロサービスアーキテクチャを導入すべきかもしれない。

　ただし、時と場合を選ぶ必要がある。マイクロサービスアーキテクチャは非常に複雑であるため、むやみに使うのは禁物だ。このアーキテクチャをいつ適用するかについては、しゃくし定規にではなく、実務的に判断する必要がある。分散アプリケーションの全ての要素を、マイクロサービスにしてはならない。「機能をモノリスや粒度の粗いモジュールとして維持するのではなく、個別にデプロイ可能なサービスへと分解するのが適切なのはいつか」。それをチームが理解することが重要だ。機能分解の大原則は、「ともに変化するものはまとめておくべし」というものだ。

どのように使うか？

　マイクロサービスの導入と活用を成功させるには、ソフトウェアエンジニアリングリーダーは以下の点を変更、または重点的に推進する必要がある。

• チームの構造と責任
• 運用モデル
• 分散コンピューティングアーキテクチャパターンの知識と適用
• アジャイルとDevOpsの導入

　チーム構造は、マイクロサービスと同じビジネスドメインに対応していなければならない。1つの機能横断チームがビジネス機能のフルセットに責任を負い、その提供に自律的に取り組めるようにするためだ。

　このチーム構造は、プロダクト指向の運用モデルを採用することで最も効果的に機能する。このモデルは、エンジニアリングチームがプロダクトに関する意思決定権限を持ち、ビジネス成果の実現によって評価されるというものだ。

　この取り組みを成功させるには、チームメンバーがアジャイルとDevOpsのプラクティスに精通し、さまざまな分散コンピューティングアーキテクチャパターンを理解しておく必要がある。

出典：Should Your Team Be Using Microservice Architectures？（Smarter with Gartner）

筆者　Laura Starita

Contents Writer, Gartner associate