Service Mesh (サービス メッシュ) とは – 新しいテクノロジではなく新しいパターンです
サービス メッシュとは？
最近、サービス メッシュやソフトウェア アーキテクチャの未来に関する投稿や記事を目にすることが多くなってきました。これらの投稿や記事は、特定のベンダーを取り巻く偏った議論でしたが、これらの議論の共通するスレッドが、エンタープライズでの API の使用方法に関する議論に急速に変化してきています。
この短期間で、サービス API が、主に組織の外部の開発者と内部システムを結ぶエッジのインタフェースから、内部システム (マイクロサービス) と全体の機能をバインドする役割に変わってきています。つまり、データセンター内の内部コミュニケーションが増えることは、マイクロサービス指向アーキテクチャを採用する避けられない結果の一つとなっています。サービス メッシュは、既存のテクノロジを導入するために異なるフレームワークを提供することによって、E-W トラフィックの増加から生じるチャレンジに対する潜在的なソリューションとして誕生しました。
これらの会話に積極的に参加している Kong 社では、サービス メッシュに関して、よくある誤解に気付きました。混乱を解消し、議論を進めるために、次のことを明確に述べたいと思います – サービス メッシュはテクノロジではなくパターンです。
サービス メッシュはテクノロジではなくパターン
マイクロサービスが特定のテクノロジではなくパターンであるのと同じように、サービス メッシュも同様です。2 つの区別は、実際よりもずっと複雑に聞こえます。オブジェクト指向プログラミングのレンズを通してこれについて考えると、パターンは実装ではなくインターフェイスを記述します。
マイクロサービスのコンテキストでは、サービス メッシュの導入のパターンは、サイドカー プロキシ経由で E-W トラフィックをより良く管理する機能を持つ点で有利になります。モノリスを切り離し、マイクロサービスで新しい製品をビルドする際、トラフィックのトポロジも主に外部から徐々に内部に変化しています。データセンター内の E-W トラフィックが増加しているのは、モノリス内のファンクション コールをネットワークコールに置き換えているためです。つまり、マイクロサービスは、ネットワーク上を移動して相互に消費する必要があります。そして、ご存知のように、ネットワークは信頼できません。
サービス メッシュが異なる導入パターンを使用して、増加した E-Wトラフィックに関連した課題を対応します。伝統的な N-S トラフィックでは、ミドルウェアの処理に対して 100 ミリ秒のレイテンシは、理想的ではありませんが、受け入れ可能でした。一方で、E-W トラフィックによるマイクロサービス アーキテクチャでは許容範囲ではありません。その理由は、サービス間で増加した E-Wトラフィックが、そのレイテンシを複合化し、異なるサービス間の API リクエストのチェーンを実行し返すまでに、おそらく 700ms のレイテンシが発生するためです。
このレイテンシを短縮するために、マイクロサービスのプロセスと一緒に実行するサイドカー プロキシを導入し、ネットワークの余分なホップを削除します。サイドカー プロキシは、要求の実行パスのデータプレーンに対応しており、もはや単一の障害ポイントがないため、より良い復元力を提供します。しかし、サイドカープロキシは、マイクロサービスのすべてのインスタンスに対してプロキシのインスタンスを持つコストを負担します。これは、リソースの枯渇を最小限に抑えるために、小さなフットプリントを必要とします。
しかし、機能の観点から見ると、サービス メッシュの多くは、API 管理製品によって長年にわたって提供されています。観測性、ネットワーク エラー処理、ヘルス チェックなどの機能は、API 管理の特長です。これらの機能は、それ自体、新しいものではありませんが、パターンとして、サービス メッシュは、これらの機能をアーキテクチャ内に展開する新しいパターンを導入します。
伝統的な API 管理ソリューションの限界
マイクロサービスとコンテナーは、より軽量なプロセスに優先順位を付けることによってシステムを見なければならず、パターンとしてのサービス メッシュは、メインのマイクロサービスと一緒に実行するプロキシとリバース プロキシの両方として実行できる軽量なプロセスを提供することによって、この必要性を満たすことができます。ほとんどの伝統的な API 管理ソリューションでは、なぜこの新しい導入オプションを許可しないのか？ それらはモノリシックな世界で生まれたからです。
明らかに Docker と Kubernetes の登場前にビルドされた API 管理ソリューションは、それ自体がモノリスであり、新たなコンテナー エコシステム内で効果的に動作するようにはデザインされていませんでした。
伝統的な API 管理ソリューションが提供していた重いランタイムと低速なパフォーマンスは、従来の API-at-the-edge のユースケースでは受け入れられましたが、増加した E-Wトラフィックによりレイテンシが複合化するマイクロサービス アーキテクチャには、重いランタイムと低速なパフォーマンスはありません。本質的に、伝統的な API 管理ソリューションは、最終的には重すぎて、自動化が難しかったり、遅すぎて、マイクロサービス固有の増加したコミュニケーションを効率的に仲介できません。
開発者はこれを理解しているので、コンテナーの登場以前に生まれたレガシーな API 管理ソリューションは、「マイクロゲートウェイ」と呼ばれるものを導入し、E-W トラフィックを処理し、既存の膨大なモノリシック ゲートウェイ ソリューションを書き直すことを避けてきました。これの問題は、これらのマイクロゲートウェイは、軽量化されながら、ポリシー施行を実行するためにレガシーのソリューションと並行して実行する必要があることです。これはスタックに同じ古い重い依存関係を保つことを意味するのではなく、すべてのリクエスト間でレイテンシが増加することを意味します。なぜサービス メッシュがまったく新しいカテゴリのように感じるのかはわかります。それは新しいものではなく、これまでの API 管理ソリューションがそれをサポートできないからです。
まとめ
機能セットのコンテキストでサービス メッシュを見ると、伝統的な API 管理ソリューションは、明らかに N-S トラフィックのために長年行ってきたこととあまり変わりません。ネットワークと観測機能の多くは、N-S と E-W の両方のトラフィックのユースケースで有用で、導入パターンが変更されているため、ゲートウェイ/プロキシを軽量で高速なサイドカーとして実行できますが、基盤となる機能セットはありません。
サービス メッシュが提供する機能セットは、API 管理ソリューションが長年にわたって提供してきた機能セットのサブセットです。特に、ネットワークの信頼性、サービスの発見、および観測性の実現に役立ちます。サービス メッシュの革新は、その導入パターン自体で、軽量なサイドカー プロセス/コンテナーと同じ機能セットを実行できます。サービス メッシュに関する多くの会話のように、特定のパターンが基盤の技術と同じであるという考えで、非常に混乱することがあります。
Kong はサービス メッシュの導入をサポート
Kong プラットフォームでは、サービス メッシュの導入をサポートします。ユーザーはスタンドアローンのサービス メッシュとして Kong を使用でき、または Kong を Istio と他のサービス メッシュ プレイヤーと統合することができます。
Kong のプラットフォームは、軽量で柔軟性があり、導入に依存しないように設計されており、近年のマイクロサービス指向のアーキテクチャで増加した E-W ネットワークのトラフィックとレイテンシを簡単に管理できます。伝統的な API 管理プラットフォームでは、コンテナーのエコシステムのサービス間で約 200 ミリ秒の処理のレイテンシが発生する場合がありますが、10 ミリ秒未満の遅延を発生します。Kong のプラグイン アーキテクチャは、不要な機能を削除し、エコシステムの参加者とのシームレスな統合をサポートすることで、多くの柔軟性を提供し、パフォーマンスのレイテンシを向上します。
以前の伝統的な API ソリューションでは難しいですが、DevOps のプロとソリューション アーキテクトは、古いものと新しいもののいずれのアーキテクチャでも成功することができます。
記事参照：
© Kong Inc. 2018
2018 年 8 月 15 日
「Service Mesh – A New Pattern, Not A New Technology?」
2018 年 8 月 28 日
「Introducing Kong Support for Service Mesh Deployments」
