モノリスとマイクロサービスについて

マイクロサービス (および頻繁に言及されるその親友であるコンテナ) は、あらゆる開発者の心をつかみ始めています。 マイクロサービスの疎結合、API のみ、細分化された設計原則を採用しているのはスタートアップ企業だけではありません。大企業も参入しています。

導入が進むにつれて (クラウド インフラストラクチャ監視プロバイダーのDatadog は、2014 年 9 月以降の 12 か月間でほぼ 5 倍の成長を遂げています)、モノリシック アプリケーションとその完全に不適切なアーキテクチャは時代遅れであるだけでなく、単純に悪いものとして終焉を宣言する声が非常に高まっています。

しかし、 Gigaom の最近の記事で指摘されているように、削岩機を取り出してすべてのモノリシックを 100 個の異なるマイクロサービスに分解する前に、考慮する必要があるトレードオフがあります。 ちなみに、これは新しい概念ではありません。 マイクロサービスの父、マーティン・ファウラー氏は、これらのトレードオフについてずっと以前に書いており、マイクロサービスの「盲目的な導入」としか考えられないようなものに対して警告を発しています。  実際、Gigaom の記事は、より簡潔な形式ではあるものの、おおむね Fowler の記事と同じ点を指摘しています。

両方の要約を述べると、基本的には次のようになります。マイクロサービスは運用上の複雑さを増し、パフォーマンスの面でアプリケーション エクスペリエンスに悪影響を与える可能性があります。 どちらも望ましくない、そして多くの場合は意図しない結果であり、データ センターの担当者が比喩的な削岩機を使い始める前に、事前に理解しておく必要があります。

そうは言っても、ロリは一体なぜ気にするのでしょうか? 結局のところ、彼女も F5 もアプリケーションの構築や設計をビジネスとしているわけではないのです。 F5 は、モノリス、マイクロサービス、次世代のアプリ アーキテクチャなど、どのようなアプリでも提供していきます。

すべて本当です。 しかし、私たちは、それらのアプリケーションを提供するアプリケーション サービスを構築および展開するビジネスに携わっており、DevOps やマイクロサービス (およびコンテナ熱) などの最近の動向は、私たちの領域にも同じ疑問をもたらしています。 つまり、ADC プラットフォームに通常展開されるアプリ サービスを、マイクロサービス アーキテクチャとより密接に一致するモデルで、より細分化されたアプリケーションに適したサービスに分解する必要があるのでしょうか。

依然としてトレードオフについて

アプリ アーキテクチャについて話しているのか、アプリ サービス アーキテクチャについて話しているのかに関係なく、答えは、そのような決定を下す前に伴うトレードオフを理解することです。

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

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

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

このモデルは、DevOps や新しいアプリケーション アーキテクチャのプラクティスとより密接に連携します。 各サービスは個別に展開、管理、拡張されます。 これにより追加の管理コストが発生しますが (結局、管理するインスタンスが増えるため)、各サービスを同じプラットフォームに展開すると、それらのコストの一部が軽減されますが、異なるプロバイダーのサービスを「組み合わせる」機能は提供されます。 このアプローチの利点は、一般的な自動化フレームワークとの統合を含め、サービスをアプリケーション アーキテクチャとより密接に関連付け、したがってアプリケーション アーキテクチャの一部として組み込むことができることです。

アプリケーション配信を複合アプリケーション サービスに分解すると、パフォーマンスと複雑さの増大という同じ欠点が発生します。 逆に、開発者がマイクロサービスを採用し、モノリスを回避する理由、つまり俊敏性、多様性、モジュール性を求める理由は、アプリケーション配信にも当てはまります。

マーティン・ファウラーの言葉をそのまま引用します。 「多くの開発チームは、マイクロサービス アーキテクチャ スタイルがモノリシック アーキテクチャよりも優れたアプローチであることに気付きました。 しかし、他のチームでは、それが生産性を低下させる負担になっていることがわかりました。 他のアーキテクチャ スタイルと同様に、マイクロサービスにはコストとメリットが伴います。 賢明な選択をするには、これらを理解し、特定の状況に適用する必要があります。」

この記述はアプリケーション サービスにも同様に当てはまります。 従来の (モノリシック) アプローチと最新の (マイクロサービス) アプローチの両方にコストと利点があり、提供、保護、最適化するアプリケーションのコンテキスト内で考慮する必要があります。