モノリスとマイクロサービスの比較

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

マイクロサービス（そして、その「大親友」としてよく引き合いに出されるコンテナ）は、幅広い開発者の支持を集め始めています。疎結合、APIのみの連携、きめ細かな設計というマイクロサービスの原則を採用しているのは、スタートアップだけではありません。大企業もこの流れに加わりつつあります。

導入が拡大するにつれ（クラウドインフラストラクチャ監視プロバイダーのDatadogは、2014年9月からの12か月間で約5倍の成長を遂げています）、モノリシックアプリケーションは終焉を迎え、そのアーキテクチャはまったく不適切で、単に時代遅れなだけでなく、明らかに劣悪だと声高に主張する声も上がっています。

しかし、Gigaomの最近の記事で指摘されているように、すべてのモノリシックアプリケーションを片っ端から100もの異なるマイクロサービスに分割する前に、検討すべきトレードオフがあります。ちなみに、これは新しい考え方ではありません。マイクロサービスの父と呼ばれるMartin Fowlerは、かなり以前からこうしたトレードオフについて論じており、マイクロサービスの「盲目的な導入」としか言いようのない動きに警鐘を鳴らしてきました。実際、Gigaomの記事は、より簡潔にまとめられているものの、概ねFowlerと同じ点を指摘しています。

両方の要点をまとめると、基本的には次のとおりです。マイクロサービスは運用を複雑化させ、パフォーマンスの面でアプリケーションエクスペリエンスに悪影響を及ぼす可能性があります。どちらも望ましくない結果であり、多くの場合は意図せず生じます。データセンターにいる誰かが比喩的な削岩機を使い始める前に、こうした影響をあらかじめ理解しておく必要があります。

とはいえ、なぜLoriがそこまで気にするのでしょうか。そもそも、LoriもF5もアプリケーションの構築や設計を事業としているわけではありません。モノリスであれ、マイクロサービスであれ、あるいは＜ここに次世代のアプリケーションアーキテクチャを入力＞であれ、F5はそれらのアプリケーションをデリバリーします。

確かにそのとおりです。しかし、F5は、そうしたアプリケーションを配信するアプリケーションサービスの構築とデプロイを事業としており、DevOpsやマイクロサービス（そしてコンテナブーム）といった最近の動向によって、F5の領域でも同じ問いが生じています。つまり、ADCプラットフォームに通常デプロイされるアプリケーションサービスを、マイクロサービスアーキテクチャにより近いモデルで、よりきめ細かく、アプリケーションとの親和性が高いサービスへと分割すべきなのでしょうか。

依然として重要なのはトレードオフ

アプリのアーキテクチャとアプリサービスのアーキテクチャのどちらについてであっても、そのような決定を下す前に、伴うトレードオフを理解することが重要である点に変わりはありません。

プラットフォーム（モノリシック）アプローチ

これは、あらゆる種類のアプリケーションのセキュリティ確保、スケーリング、最適化に必要なアプリサービスを提供する従来型のアプローチです。サービスは、単一の共有プラットフォームに導入されます。基盤となるプロキシのアーキテクチャにより、このアプローチにはパフォーマンスを向上できるという利点があります。すべてのリクエスト（およびレスポンス）が同じ環境内で必要なサービスを通過できるためです。そのため、追加のネットワークホップ（およびそれに伴うレイテンシ）や接続（リソース、レイテンシ）は必要ありません。各サービスは個別にスケーリングおよび管理できますが、いずれも単一の共有ハードウェア（COTSまたはカスタム）に依存します。つまり、この共有ハードウェアが単一障害点となり、1つだけでなく複数のサービスに影響を及ぼします

アプリ単位のプロキシ（マイクロサービス）アプローチ

このモデルは、DevOpsや新たなアプリケーションアーキテクチャの手法により適合しています。各サービスは個別にデプロイ、管理、スケーリングされます。そのため、管理対象のインスタンスが増え、管理コストも増加します。各サービスを同じプラットフォームにデプロイすれば、こうしたコストの一部を軽減できる一方、異なるプロバイダーのサービスを柔軟に組み合わせることも可能です。このアプローチの利点は、一般的な自動化フレームワークとの統合も含め、サービスをアプリケーションアーキテクチャとより密接に関連付け、その一部として組み込めることです。

アプリケーションデリバリを個々のアプリケーションサービスに分解すると、パフォーマンスの問題や複雑性の増大といった同様のデメリットが生じます。一方、開発者がモノリシックな構成を避け、マイクロサービスを採用している理由、すなわちアジリティ、多様性、モジュール性へのニーズは、アプリケーションデリバリにも当てはまります。

ここでは、Martin Fowlerの言葉をそのまま引用します。「多くの開発チームは、マイクロサービスアーキテクチャスタイルがモノリシックアーキテクチャよりも優れたアプローチだと考えています。しかし、チームによっては、生産性を低下させる負担になると捉えています。他のアーキテクチャスタイルと同様に、マイクロサービスにもコストとメリットがあります。適切な選択をするには、それらを理解し、個々の状況に照らして判断する必要があります。」

この指摘は、アプリケーションサービスにもそのまま当てはまります。従来型（モノリシック）とモダン型（マイクロサービス）のどちらのアプローチにもコストとメリットがあり、配信、保護、最適化の対象となるアプリケーションの状況に応じて検討する必要があります。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事