本記事は Kong Blog の記事を翻訳し転載しています。

Baptiste Collard
Kong テクニカル アカウント マネージャー

多くの組織は、複数のクラウド環境にわたる API ゲートウェイの管理に苦労しています。このブログ記事では、Kong Mesh がこれらの課題を解決し、シームレスなクラウド間接続を可能にする方法を探ります。

マルチクラウドAPIゲートウェイの課題

多くの大企業は、APIゲートウェイを複数の地域やクラウドサービスプロバイダーで運用しています。これは戦略的な決定である場合もあれば、地域の規制 (GDPR、オープン バンキングなど)によって規定されている場合もあります。

さらに、APIゲートウェイの無秩序な増加は、さまざまなオーディエンス(公共、パートナー、企業、輸出管理など)に対するAPIの可視性など、さまざまなビジネス上の理由から生じる場合もあれば、組織が主導する場合もあります。企業は、既存の API に基づくイノベーションを促進するために、開発者ポータルで補完されたパブリックAPI ゲートウェイを実装することがよくあります。逆に、プライベートAPI ゲートウェイは、社内目的、ドメイン間の共有、またはダーク IT (野良IT、シャドーIT など) を排除するために利用されます。

APIゲートウェイがクラウド全体に普及することで、新たな接続の課題が生じています。特定のクラウド プロバイダーのネットワーク インフラストラクチャに頼るのが最善でしょうか、それとも通信事業者の閉域ネットワークを活用するのが最善でしょうか？ 最も安全なのはどれでしょうか？ データセンター間接続の暗号化標準はどのようなものでしょうか？

クラウドネイティブ時代のゼロトラストとサービスメッシュ

クラウドネイティブ テクノロジーの時代において、ゼロトラスト ネットワーキングとサービス メッシュ プラットフォームという、クラウド接続のトレンドを反映した 2 つのバズワード（buzzword）を耳にしたことがあるはずです。ZTN (ゼロ トラスト ネットワーク) には幅広いテクノロジーとアプローチが含まれますが、サービスメッシュはゼロトラストのサブセットであり、アプリケーションのEast-West トラフィック制御に特化しています。

サービス メッシュ テクノロジーは、導入ギャップと学習曲線のため、使用、運用、拡張が複雑であると考えられることがよくあります。とはいえ、導入を成功に導く道筋は実証済みです。一般的なアプローチのひとつは、アップストリームAPIやテクニカルサービスではなく、まず（API）ゲートウェイをメッシュに組み込むことです。これは簡単でリスクのないステップであり、2つの利点があります。プラットフォーム管理者はこの新しいテクノロジーから学び始め、もしAPIゲートウェイの機能に欠けているものがあれば、（例えばテレメトリーや回復力などを）メッシュの機能で補完することができるのです。

さらに、メッシュ内に API ゲートウェイを配置すると、少なくともマルチクラスターを念頭に置いて設計されたKong Meshなどの最新のサービス メッシュ プラットフォームでは、接続性の面で新たな可能性が開かれます。

Kong Mesh は、OSS Kuma 上に構築されたサービス メッシュ プラットフォームであり、サービス間のクロス プラット フォーム接続とグローバル ルーティングを容易にします。「Zone Ingress」と呼ばれる構成要素の 1 つは、East-West トラフィック用の特別な種類のゲートウェイを表しています。これらのZone Ingress は、エンド ユーザーにとっては透過的です。重要なのは、異なるプラットフォームで実行されている 2 つのサービスが相互に通信する必要がある場合に、メッシュによって自動的に構成されることです。接続は mTLS トンネルを介して保護されるため、（標準的なVPNのように）インターネットのようなパブリック ネットワーク インフラストラクチャを使用しても問題ありません。

開発者側では、他の場所にデプロイされたサービスを簡単に使用できるように、サービスの名前付けを容易にすることも重要です。繰り返しになりますが、Kumaが優れているのは、その連合アーキテクチャのおかげです。

メッシュの一部であるすべてのサービスは、自動生成されたメッシュ側のホスト名でルーティング可能になります。ルーティングがどのように行われ、セキュリティと回復力のメカニズムが追加されるかについては、まさにEnvoyマジックです！

サンプル事例で説明

API ゲートウェイをメッシュの一部にすることの価値を示すために、Azure と Google Cloud の両方で Kubernetes クラスタを運用する架空の会社acme.corp の例を次に示します。
このcatalog APIはGoogle Cloud上でのみ動作しますが、各クラスタ上で実行する両方のAPIゲートウェイからアドレス指定が可能です。

2 つのゲートウェイは、メッシュ内で通常のワークロードとしてタグ付けされます。

外部接続と内部接続の両方を可能にするために、Google Cloud で実行されているゲートウェイは、さまざまなサブドメインで機能するワイルドカード証明書を公開しています。

Azureで実行されるゲートウェイでcatalog APIを構成するための方法として、メッシュが提供するバーチャル ドメイン名があります。

Azure 上のゲートウェイもメッシュの一部であるため、アウトバウンド リクエストは Google Cloud 上の他のゲートウェイにルーティングできます。

Azureの観点からKong Gatewayにバーチャル ドメイン名を割り当てるには、以下に示すようにHostnameGenerator CRDを使用します。

メッシュの一部であるものや、そうでない場合も、あらゆる種類のワークロードに対して、より豊富な接続パターンを想定できます。

この最後の図では、Azure で実行されている別のクライアントも、Kong ゲートウェイを介して Azure で実行されている「catalog」 API を使用できます。

このセットアップでは、クロスクラウド接続のためのKong Meshのような最新のサービスメッシュ プラットフォームの能力について説明しました。MeshTLS、HostnameGenerator、Zone Ingressなどの優れたプリミティブの助けを借りることで、APIがかつてないほど身近なものになりました！
この種のアーキテクチャが実際のマルチクラウドアーキテクチャに響いた場合、またはマルチメッシュ プラットフォームやエンタープライズ対応のサービスメッシュプラットフォームとしてのKong Meshについて詳しく知りたい場合は、チャットしましょう!私たちのチームは、Kong Meshがマルチクラウド戦略を合理化し、API接続を強化する方法について議論したいと考えています。

原文：Mesh to the Rescue of API Gateways for Cross-Cloud Connectivity