クラウド ネイティブ要素の概要: 抽象エンドポイント

[[434881]]

[51CTO.com クイック翻訳]分散コンピューティングにおける最も基本的な概念の 1 つはエンドポイントです。オブジェクト、マイクロサービス、アプリケーションなどの各ソフトウェアは、インタラクション エンドポイントと呼ばれる入力と出力の観点から理解できます。

分散コンピューティングの歴史を通じて、エンドポイントは、ソケット、IP アドレス、インターフェース、Web サービス、ポータルなど、さまざまな形式で登場してきました。性質に関係なく、他のソフトウェアは適切なエンドポイントを見つけ、それらに接続またはバインドし、それらと対話できる必要があります。

エンドポイントは攻撃対象領域の穴でもあるため、それらを保護することも重要です。最も基本的な意味では、エンドポイントは物理的な分散コンピューティング アーキテクチャの一部です。ただし、物理的なエンドポイントだけを扱う場合、柔軟性がほとんどないため、プログラミング性が制限され、使いやすさが大幅に制限されます。これらの理由から、多くの企業は長年にわたってエンドポイントを抽象化するためのさまざまなアプローチを採用しており、現在もクラウドネイティブ インフラストラクチャを構築しながらこの傾向を続けています。

ただし、新しいクラウド ネイティブ コンピューティング パラダイムでは、抽象的なエンドポイントが新しい意味を持ちます。

抽象エンドポイント層

実際、抽象的なエンドポイントは平凡で一般的なものでもあります。 DNS サーバーは IP アドレスを抽象化し、その割り当てを必要に応じてドメイン名に再割り当てできます。ロード バランサは、要求元が気付かないうちに、要求をさまざまなサービスまたはアプリケーション エンドポイントに送信できます。

本質的に、Representational State Transfer (REST) は URL を使用してエンドポイントとそれらがサポートする操作を抽象化します。基盤となるインフラストラクチャは、Web サーバー、ロード バランサー、API ゲートウェイ (またはそれらの組み合わせ) を使用して URL を解決し、トラフィックを適切な物理エンドポイントに誘導する場合があります。

REST シナリオは、抽象エンドポイントの重要な原則を強調しています。多くの場合、メッセージは複数の異なるテクノロジを通過し、それぞれが異なる抽象エンドポイントのレイヤーを追加します。これらのレイヤーによりアーキテクチャは複雑になりますが、エンドポイントの消費者にとっての柔軟性とシンプルさの向上によるメリットは、通常、この複雑さによるコストを上回ります。

クラウドネイティブコンピューティングにおける抽象エンドポイント

クラウド ネイティブ コンピューティングには、他の形式の分散コンピューティングでは必要のない追加の抽象エンドポイントが必要です。

この追加の複雑さの理由は、Kubernetes 自体の目標である、コンテナ、ポッド、クラスター レベルで迅速かつ無制限の水平スケーラビリティを提供することに根本的に関係しています。

サービス メッシュは、プロキシを使用して特定のマイクロサービス インスタンス間の「東西」トラフィックをルーティングしますが、通常、要求元のマイクロサービスは、特定の時点で使用可能なインスタンスの数や IP アドレスが何であるかを認識していません。

言い換えれば、サービス メッシュはエントリ ポイントで抽象的なエンドポイントを提供します。これは、Kubernetes 上で実行されるマイクロサービスの操作に不可欠です。

要求者が関連するマイクロサービスのドメイン外にいる場合、同じ原則が「南北」トラフィックに適用されます。このような場合、API ゲートウェイは抽象エンドポイントを処理します。

これらの抽象エンドポイントを実装する基盤となるテクノロジーは異なります。東西トラフィックの場合はサイドカーとプロキシ、南北トラフィックの場合はポリシー主導の安全な API ゲートウェイです。

クラウドネイティブゼロトラスト

抽象エンドポイントに十分かつ適切なセキュリティを提供すると、インフラストラクチャ チームとセキュリティ チームに新たな課題が生じます。 Kubernetes デプロイメントの動的な性質とハイブリッド IT シナリオのサポートを考慮すると、ゼロトラスト アプローチでは、信頼できることが証明されない限り、すべてのエンドポイントを信頼できないものとして扱います。

ただ 1 つ問題があります。それは、「従来の」ゼロ トラスト アプローチでは対応できないということです。ゼロ トラストへのこの独自のアプローチでは、エンドポイントが人間のユーザーに関連付けられていたため、従来の ID およびアクセス管理テクノロジは、エンドポイントに関連付けられた人間の ID の管理にのみ適用できました。

対照的に、クラウドネイティブの世界では、エンドポイントはマイクロサービス、API、スマートフォン、IoT センサー、またはその他のさまざまなタイプのテクノロジーである可能性があります。したがって、人間の ID を使用してほとんどの抽象的なエンドポイントにアクセスすることはできなくなります。クラウドネイティブのゼロトラストには異なるアプローチが必要です。

接続性と統合

クラウドネイティブ コンピューティングの抽象エンドポイントにより、他のエンドポイント (コンシューマー/リクエスター、メッセージ ソースまたはレシーバーなど) が、特定のインフラストラクチャのコンテキスト内でそのエンドポイントを見つけてバインドできるようになります。このインフラストラクチャには、Kubernetes、サービス カタログ、その他のサポート テクノロジが含まれる場合があります。

この機能はエンドポイント接続と呼ばれます。実際、「接続性」という用語自体は、既存のエンドポイント抽象化を活用して、それらのエンドポイントが抽象化を定義するポリシーに従って相互に対話できるようにする抽象化を表しています。

ただし、接続性と統合性は同じではありません。統合エンドポイントには接続性が必要なのは当然ですが、エンドポイント間でメッセージを移動するメカニズムも必要です。 Kubernetes 以前の世界では、統合テクノロジーによって、データ変換、セキュリティ、プロセス ロジック実行など、さまざまな「インテリジェント」な機能も提供されていました。

このタイプの統合ミドルウェアに依存して重い処理を実行するアーキテクチャは、「スマート パイプ、ダム エンドポイント」アーキテクチャとして知られています。企業は業務の大部分で統合テクノロジを活用しているだけでなく、それぞれの契約 (Web サービスの WSDL 契約や RESTful エンドポイントのインターネット メディア タイプなど) を遵守する以上の作業を行うためにエンドポイントに依存する必要がありません。

サービス指向アーキテクチャ (SOA) 時代の最も重要な教訓の 1 つは、スマート パイプ アプローチは集中化されすぎているため、クラウド コンピューティングには特に適していないということです。分散コンピューティング アーキテクチャがクラウド コンピューティング、そしてクラウド ネイティブへと移行するにつれ、人々は重労働をミドルウェアから移行し、代わりに軽量のキューイング テクノロジやその他のオープン ソース統合アプローチに依存するようになっています。

このようにパイプがスマートからダムに変更されると、エンドポイントはダムからスマートにのみ変更されます。スマート エンドポイントが抽象エンドポイントである限り、ある程度はそうであるはずです。結局のところ、物理エンドポイントは IP アドレス、API、または URL である可能性があります。このようなプロトコルやテクノロジーが以前よりもスマートになることは期待できません。

代わりに、人々は抽象化されたエンドポイント インフラストラクチャに依存して、データ変換、セキュリティ、ポリシーの適用、およびエンタープライズ サービス バス (ESB) やその他の従来のミドルウェアに必要なその他のすべての機能を処理する方法を理解します。ただし、Kubernetes のスケーラビリティと一時的な環境からは抽象化されています。

抽象的に統合することもできますか?

1 つのエンドポイントが IoT センサーで、もう 1 つがクラウドベースの API であるとします。これらのエンドポイントが十分に抽象化されている場合、それらへの接続が提供されます。

しかし、メッセージは依然として物理的に一方から他方へ転送される必要があり、この作業には、たとえば 5G、専用の MPLS リンク、何らかのミドルウェア、選択したクラウド プラットフォームへのアクセスなどが必要になる可能性があります。

理想的なクラウドネイティブの世界では、確立されたポリシーに基づいて、このような統合の構成、管理、セキュリティを自動的に処理し、統合とエンドポイント自体を抽象化して、エンドユーザーに知られることなく、パフォーマンスやコスト上の理由から、あるテクノロジーから別のテクノロジーに切り替えることが可能になります。

その結果、意図に基づいた統合が実現します。利害関係者はエンドポイント間のやり取りに関するビジネス上の意図 (レイテンシ、データ主権、信頼性、その他の要件) を表明し、インフラストラクチャは、その意図に継続的に適合するように最適なルーティング トポロジと統合テクノロジを自動的かつ動的に選択します。

SD-WAN などのテクノロジーは部分的なソリューションを提供しますが、この意図ベースの統合の全体的な範囲はまだ計画段階にあります (ただし、オープンソースの NATS プロジェクトはこのビジョンの実現に向けて順調に進んでいます)。しかし、待つ理由はありません。抽象化されたエンドポイントは今日では現実のものとなっているため、クラウド ネイティブ シナリオでそれらを実装する方法を理解することは、Kubernetes の約束を果たすために重要です。

リクエスト/レスポンス

非同期のやり取りよりも説明や理解が簡単なため、この投稿ではリクエスト/応答の例を使用しています。実のところ、クラウド ネイティブ コンピューティングでは、非同期のリアルタイム ストリーミング インタラクションの方が標準であり、要求/応答パターンは特殊なケースです。

したがって、抽象エンドポイントは非同期ストリーミングのユースケースでも同様に重要であることを指摘することが重要です。実際、今日のサービス メッシュが東西トラフィックと南北トラフィックの両方で非同期ストリーミング データ フローを処理する機能をカプセル化する、新しいクラスの「イベント メッシュ」テクノロジがあります。

もちろん、ストリーミング データ フローのポリシー適用、セキュリティ、信頼性の処理には、抽象エンドポイントの重要性の基準を引き上げるなど、独自の課題が伴います。

エッジ コンピューティングが成熟し、ストリーミング データがエンタープライズ コンピューティングで標準となるにつれて、クラウド ネイティブ コンピューティングによって約束されるスケーラビリティ、柔軟性、回復力を維持するために、統合とエンドポイントを抽象化することがますます重要になります。

原題: Cloud-Native Essentials: Abstracted Endpoints、著者: Jason Bloomberg

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。