Apigee と GKE 間の接続を、Private Service Connect および GKE Gateway を使ってモダナイズする
Google Cloud Japan Team
※この投稿は米国時間 2024 年 2 月 29 日に、Google Cloud blog に投稿されたものの抄訳です。
昨今のクラウドネイティブ全盛の状況において、企業はアジャイルな API 管理と、Kubernetes 上で動作するマイクロサービスの柔軟性の両方を求めています。Google Cloud は、総合的な API 管理機能を備えた Apigee と、コンテナ化アプリケーションのオーケストレーションのための Google Kubernetes Engine（GKE）という、高度なソリューションを提供しています。しかし、これらの環境を互いに接続し、Kubernetes ベースのマイクロサービスに対する API トラフィックを効率化することは容易ではありません。こんなときに役立つのが Private Service Connect（PSC）で、VPC から Google、サードパーティ、独自サービスへの安全なプライベート接続を確立することができます。PSC なら、Apigee からバックエンド ターゲットへのサウスバウンド通信において、安全で効率の良いスマートなソリューションを提供することが可能となります。
接続に伴う課題
Apigee と GKE を接続する従来の方法は、ネットワーキングの面でさまざまな複雑化を招きます。Apigee と GKE の接続の効率化を妨げる課題としては、一般的に以下のようなものがあります。
-
一般公開の状態になる: Apigee から GKE に API トラフィックをルーティングすると、GKE サービスを一般公開しなければならなくなることがよくあります。これにより、攻撃ベクトルが生じ、セキュリティ リスクが生まれる可能性があります。
-
トラフィックのボトルネックおよび費用: 公共のインターネット接続のみに頼ると、想定外のレイテンシが生じてパフォーマンスが低下し、下り（外向き）料金が増加する可能性があります。
-
管理が複雑: ネットワークおよび VPC ピアリング接続の構成や、CIDR 範囲の重複の回避、Apigee や GKE などのプラットフォーム間のアクセス権管理など、複雑な管理作業が発生します。
Private Service Connect のアプローチ
PSC は、Apigee デプロイメントが GKE サービスと連係する方法を根本的に変え、セキュリティのレベルアップと大幅な単純化を実現します。具体的には、以下のような特徴があります。
-
非公開の内部ネットワーキング: PSC では、サービス アタッチメントおよびエンドポイントを使用して、VPC 間でサービスを直接公開します。複雑な VPC ピアリングの設定は不要で、公共インターネットにクラスタを晒さずに済みます。PSC では、Google Cloud VPC 内で GKE Gateway 用の非公開のエンドポイントを容易に確立できます。これにより、Apigee と Kubernetes サービスの間の通信が Google Cloud の内部ネットワーク経由で直接行われるようになります。そのため、公共インターネットを完全にバイパスでき、複雑な VPC ピアリングの実装が不要です。
-
きめ細かなセキュリティ管理: PSC では、Apigee からのアクセスを GKE クラスタ内の一部のサービスに制限できます。このきめ細かな管理方法によって、リスクを最小化できます。
-
パフォーマンスの向上: Google Cloud の高パフォーマンス ネットワーク経由のプライベート接続により、レイテンシが短縮されるとともに信頼性が高まり、API レスポンス時間が全体的に改善します。
主な構成要素
-
Apigee: Google Cloud の堅牢な API 管理プラットフォーム。API の作成、管理、保護、モニタリングを簡素化するとともに、ポリシー適用、分析、収益化などの機能も提供します。
-
GKE Gateway: Kubernetes Gateway API（新しく柔軟な API 仕様）の GKE での実装。Ingress オブジェクトを改善した高度なネットワーキング リソースであり、GKE クラスタにおける内部および外部トラフィックのルーティングやロード バランシングの機能が拡張されています。
-
Private Service Connect: このインテグレーションの要である PSC によって、GKE クラスタをホストする VPC と Apigee VPC の間のプライベート接続を設定し、ルーティングを管理します。
安全な接続を設定
接続を確立するには、以下の手順に沿って操作します。ここでは、主に GKE Gateway の作成について詳しく説明します（その他の手順は非常に簡単で、詳しいドキュメントも提供されています）。
これは細かな手順に分かれていますが、概要としては以下を行う必要があります。
-
VPC ネイティブ クラスタを作成する。VPC ネイティブ クラスタとは、Pod やサービスが Google Cloud VPC ネットワークの IP アドレスを直接使用するクラスタを指します。
-
Gateway API および HTTP ロード バランシング アドオンを有効にする。これは、クラスタの作成時または更新時に、必要に応じて行えます。
-
プロキシ専用サブネットを構成する。これは、GKE クラスタを実行するサブネットとは異なります。REGIONAL_MANAGED_PROXY の目的で作成するようにしてください。
-
名前付き IP アドレスを作成する。名前付き IP アドレスを使うことで、Gateway リソース用の静的 IP を予約することができます。Gateway の IP アドレスを指定しない場合は、Gateway コントローラが自動的に IP アドレスを割り当てます。注: このブログ記事の公開時点では、PSC サービス アタッチメントは共有 IP アドレス（SHARED_LOADBALANCER_VIP）を使用する転送ルールに対応していません。しかし、名前付き IP アドレスを予約しなかった場合や、目的を明示的に定義せずに名前付き IP アドレスを作成した場合、Gateway が使用する IP アドレスのデフォルトの目的は SHARED_LOADBALANCER_VIP になります。これを回避するために、以下に示す gcloud コマンドを使って GCE_ENDPOINT という目的の名前付き IP アドレスを作成しましょう。GCE_ENDPOINT という IP アドレスの使用にあたっては、以下の点に留意してください。
-
Apigee から Gateway への HTTP トラフィックと HTTPS トラフィックの両方に、同じ IP アドレスの Gateway を使用することはできません。また、Gateway へのトラフィックを HTTP から HTTPS へと同じアドレス上でリダイレクトすることはできません。
-
Apigee から Gateway への通信で HTTP のみまたは HTTPS のみを使用している場合は、上記の事項はさほど問題になりません。ただし、HTTP と HTTPS の両方を使用する場合は、2 つの異なる Gateway（HTTP 用と HTTPS 用）で処理する必要があるため、2 つの名前付き IP アドレスが必要となります。
-
ただし、これは元のクライアントから Apigee への初期トラフィックには当てはまりません。初期トラフィックを処理する外部の L7 ロードバランサは、SHARED_LOADBALANCER_VIP という目的を使用しており、HTTP トラフィックと HTTPS トラフィックの両方に対応し、HTTP から HTTPS へのリダイレクトも行えます。
- この手順は、PSC サービス アタッチメントが SHARED_LOADBALANCER_VIP という目的の共有 IP アドレスを使用する転送ルールをサポートするようになった時点で、省略できるようになります。この手順を行う前に、この制限事項がまだ適用されているかどうかを確認してください。
- Gateway リソースを作成する: 名前付き IP アドレスを使って Gateway を作成する yaml ファイルの例を以下に示します。
- PSC サービス アタッチメントを設定する: GKE Gateway をデプロイする VPC ネットワークで、PSC サービス アタッチメントを作成します。GKE Gateway に対して作成した転送ルールを使って、サービス アタッチメントを構成するようにしてください。
- エンドポイント アタッチメントを作成する: これは Apigee 組織内で構成されます。
- GKE サービスへの Gateway ルートを構成する: これを行うことで、コンテナ化アプリケーションおよびルートのデプロイを、Gateway のデプロイ手順から切り離すことが可能となります。
まとめ
Private Service Connect は、Apigee による GKE ワークロードとの連係を改善し、セキュリティ、パフォーマンス、運用効率を向上させることができます。公共インターネットや複雑な VPC ピアリングの管理を回避し、Google Cloud 内部の安全なインフラストラクチャを活用することで、リスクを減らすとともに、クラウドネイティブの API サービス用の効率的で堅牢なバックボーンを実現できます。
ー カスタマー エンジニア NJ Njoku
ー ネットワーキング スペシャリスト Lorin Price
