メッシュの上り(内向き)トラフィック

サービス メッシュは、メッシュ内で実行されているサービス間の通信を容易にします。しかし、トラフィックをメッシュに取り込む際にどのような方法が考えられるでしょうか。このステップ(メッシュの外部からエントリ ポイントを介してトラフィックをメッシュに転送するステップ)は、ゲートウェイを使用して解決できます。

このドキュメントでは、Cloud Load Balancing をゲートウェイとして使用し、トラフィックをメッシュに取り込む方法について説明します。

概要

サービス メッシュを設計する際は、次のソースからのトラフィックを考慮する必要があります。

  • メッシュ内で発生したトラフィック
  • メッシュ外で発生したトラフィック

メッシュ内で発生したトラフィックは、サービス メッシュのデータプレーン上を移動し、宛先サービスに関連付けられたバックエンドまたはエンドポイントに到達します。ただし、メッシュ外で発生したトラフィックは、まずサービス メッシュのデータプレーンに到達する必要があります。

メッシュ内で発生した次のトラフィックの例では、Traffic Director がサイドカー プロキシを構成します。これらのサイドカー プロキシは、サービス メッシュのデータプレーンを形成します。サービス A がサービス B と通信する必要がある場合:

  1. サービス A はサービス B に名前でリクエストします。
  2. このリクエストはインターセプトされ、サービス A のサイドカー プロキシにリダイレクトされます。
  3. サイドカー プロキシは、次にサービス B に関連付けられたエンドポイントにリクエストを送信します。
サービス メッシュのデータプレーンによって処理されるサービス メッシュの内部トラフィック(クリックして拡大)
サービス メッシュの内部トラフィックは、メッシュのデータプレーンによって処理されます(クリックして拡大)

次の例では、トラフィックはサービス メッシュの外部で発生し、サービス メッシュのデータプレーンに沿って移動することはありません。

サービス メッシュ外部のトラフィックは、サービス メッシュのデータプレーンで処理されません(クリックして拡大)
サービス メッシュ外部のトラフィックは、サービス メッシュのデータプレーンで処理されません(クリックして拡大)

この例では、クライアントはサービス メッシュの外部にあります。メッシュに直接参加していないため、クライアントはメッシュ内のサービスに属するエンドポイントを認識しません。つまり、クライアントは Traffic Director で構成されたプロキシを使用して送信リクエストを送信しないため、サービス A またはサービス B にトラフィックを送信する際に使用する IP アドレスとポートのペアを判別できません。この情報がないと、クライアントはメッシュ内のサービスにアクセスできません。

このドキュメントで説明するゲートウェイ パターンは、トラフィックをメッシュに取り込む方法に関するこの問題を解決する際に有用です。

このドキュメントの内容:

  • ゲートウェイに関する考慮事項の概要。
  • メッシュのゲートウェイを選択する際のオプションの概要。
  • ゲートウェイ トポロジに適用できるアーキテクチャに関する推奨事項。

ゲートウェイに関する考慮事項

このセクションでは、ゲートウェイを選択する際に考慮すべき問題の概要を説明します。

  • クライアントがゲートウェイにアクセスする方法
  • ゲートウェイに到達するトラフィックに適用するポリシー
  • ゲートウェイがメッシュ内のサービスにトラフィックを分散する方法

クライアントがゲートウェイ経由でメッシュに到達できるようにする

公共のインターネット、オンプレミス環境、または Google Cloud 内のいずれに存在する場合であっても、クライアントはメッシュ内のサービスにアクセスする方法を必要とします。これは通常、ゲートウェイに解決され、ルーティング可能なパブリックまたはプライベートの IP アドレスとポートを使用して実現できます。メッシュ外のクライアントは、この IP アドレスとポートを使用し、ゲートウェイを介してメッシュ内のサービスにリクエストを送信します。

Cloud Load Balancing には、メッシュに対するゲートウェイとして使用可能なさまざまな負荷分散オプションが用意されています。ゲートウェイとして機能する Google Cloud ロードバランサを選択する場合は、次の点を考慮する必要があります。

  • クライアントが公共のインターネットまたはオンプレミス環境に存在しているのか、Virtual Private Cloud(VPC)ネットワークの一部になっているのか。
  • クライアントはどの通信プロトコルを使用しているのか。

メッシュのゲートウェイの選択では、クライアントのロケーションと通信プロトコルに応じた Cloud Load Balancing のオプションの概要を説明しています。

ゲートウェイでのトラフィックの処理

ゲートウェイはメッシュのエッジ(メッシュ外のクライアントとメッシュ内のサービスの間)にあるため、トラフィックがメッシュに入る際にポリシーを適用する場所として適しています。たとえば、次のようなポリシーがあります。

  • トラフィック管理(ルーティング、リダイレクト、リクエスト変換など)
  • セキュリティ(TLS 終端と Google Cloud Armor による DDoS 対策など)
  • Cloud CDN のキャッシュ

メッシュのゲートウェイを選択すると、メッシュのエッジに関連するポリシーがハイライト表示されます。

ゲートウェイからメッシュ内のサービスへのトラフィック送信

ゲートウェイは、受信トラフィックにポリシーを適用した後、トラフィックの送信先を決定します。これは、トラフィック管理と負荷分散ポリシーを使用して構成します。たとえば、ゲートウェイはリクエスト ヘッダーを検査して、トラフィックを受信するメッシュ サービスを識別します。ゲートウェイはサービスを識別した後、負荷分散ポリシーに従って特定のバックエンドにトラフィックを分散します。

メッシュ用のゲートウェイの選択では、ゲートウェイがトラフィックを送信できるバックエンドの概要を説明します。

メッシュ用のゲートウェイの選択

Google Cloud には、メッシュに対するゲートウェイとして機能するさまざまなロードバランサが用意されています。このセクションでは、ゲートウェイのパターンに関連するディメンションに従って次のオプションを比較し、ゲートウェアを選択する方法について説明します。

このセクションでは、第 1 レベルと第 2 レベルのゲートウェイについて説明します。これらの用語は、1 つまたは 2 つのゲートウェイを使用してメッシュへの上り(内向き)トラフィックを処理することを表す際に使用します。

メッシュのゲートウェイとして機能するロードバランサは、1 つのレベルで 1 つだけにする必要があります。ただし、複数のゲートウェイを使用することが適切な場合もあります。これらの構成では、1 つのゲートウェイが Google Cloud に着信するトラフィックを処理し、第 2 レベルの別のゲートウェイがサービス メッシュに着信するトラフィックを処理します。たとえば、Google Cloud に着信するトラフィックに Google Cloud Armor のセキュリティ ポリシーを適用し、メッシュに着信するトラフィックに高度なトラフィック管理ポリシーを適用できます。2 つ目の Traffic Director で構成されたゲートウェイを使用するパターンについては、メッシュのエッジにおける第 2 レベルのゲートウェイのデプロイをご覧ください。

次の表は、選択したゲートウェイ オプションに応じて使用可能な機能を比較したものです。

ゲートウェイ クライアントのロケーション プロトコル ポリシー バックエンド / エンドポイント
内部 HTTP(S) 負荷分散 ロードバランサと同じリージョンにある Google Cloud ベースのクライアント

リクエストがロードバランサと同じ Google Cloud リージョンに届くオンプレミス クライアント(Cloud VPN や Cloud Interconnect を使用する場合など)
  • HTTP/1.1
  • HTTP/2
  • HTTPS
高度なトラフィック管理
セルフマネージド証明書を使用した TLS 終端
ロードバランサと同じ Google Cloud リージョンにあり、次の場所で実行されるバックエンド:

Compute Engine 上の仮想マシンのバックエンド

次の場所にあるコンテナ インスタンス:
  • Google Kubernetes Engine(GKE)
  • Kubernetes
HTTP(S) 負荷分散 公共のインターネット上のクライアント
  • HTTP/1.1
  • HTTP/2
  • HTTPS
  • トラフィック管理
  • Cloud CDN(Cloud Storage バケットのバックエンドを含む)
  • Google マネージド証明書またはセルフマネージド証明書を使用した TLS 終端
  • SSL ポリシー
  • DDoS とウェブ攻撃を防止する Google Cloud Armor
  • ユーザー認証における IAP サポート
任意の Google Cloud リージョンにあり、次の場所で実行されるバックエンド

Compute Engine 上の仮想マシン

次の場所にあるコンテナ インスタンス
  • Google Kubernetes Engine(GKE)
  • Kubernetes
内部 TCP / UDP 負荷分散 任意のリージョンにある Google Cloud ベースのクライアント。クライアントがロードバランサと異なるリージョンにある場合は、グローバル アクセスが必要です。

リクエストが任意の Google Cloud リージョンに届くオンプレミスのクライアント(Cloud VPN や Cloud Interconnect を使用する場合など)
TCP ロードバランサと同じ Google Cloud リージョン内にあり、次の場所で実行されるバックエンド

Compute Engine 上の仮想マシン
ネットワーク負荷分散 公共のインターネット上のクライアント 次のいずれか: TCP または UDP ロードバランサと同じ Google Cloud リージョン内にあり、次の場所で実行されるバックエンド

Compute Engine 上の仮想マシン
SSL プロキシ負荷分散と TCP プロキシ負荷分散 公共のインターネット上のクライアント SSL または TCP のいずれか Google マネージド証明書またはセルフマネージド証明書を使用した TLS 終端(SSL プロキシのみ)

SSL ポリシー(SSL プロキシのみ)
任意の Google Cloud リージョンにあり、次の場所で実行されるバックエンド

Compute Engine 上の仮想マシン

次の場所にあるコンテナ インスタンス
  • Google Kubernetes Engine(GKE)
  • Kubernetes
Traffic Director によって構成されたエッジプロキシ(VM またはコンテナ インスタンス上) クライアントは、次のいずれかに該当する場所に存在する必要があります。
  • Google Cloud が管理するロードバランサにリクエストを送信でき、ロードバランサがそのリクエストをエッジプロキシに送信する。詳細については、このドキュメントのメッシュのエッジにおける第 2 レベルのゲートウェイのデプロイをご覧ください。
  • Traffic Director によって構成されたプロキシ(サイドカー プロキシなど)を介してリクエストを送信できる。
  • エッジプロキシを実行している VM またはコンテナ インスタンスの IP アドレスとポートに直接リクエストを送信できる。
  • HTTP/1.1
  • HTTP/2
高度なトラフィック管理(正規表現のサポートを含む) 任意の Google Cloud リージョンにあり、次の場所で実行されるバックエンド

Compute Engine 上の仮想マシン

次の場所にあるコンテナ インスタンス
  • Google Kubernetes Engine(GKE)
  • Kubernetes

ロードバランサの機能のページでは、機能ごとの詳細な比較を確認できます。Traffic Director の機能のページでは、Traffic Director の機能の詳細を説明しています。

ゲートウェイのデプロイと構成

ゲートウェイを選択する際の最後の考慮事項は、使用するデベロッパー エクスペリエンスとツールです。Google Cloud には、ゲートウェイを作成して管理するための複数の方法が用意されています。

gcloud コマンドライン ツールと Compute Engine API

gcloud コマンドライン ツールと Compute Engine API を使用して、Google Cloud のマネージド負荷分散プロダクトと Traffic Director を構成できます。CLI と API は、Google Cloud リソースを命令的にデプロイして構成するためのメカニズムを備えています。反復タスクを自動化するスクリプトを作成できます。

Google Cloud Console

Google Cloud のグラフィカルなインターフェースである Cloud Console を使用して、Traffic Director と Google Cloud のマネージド ロードバランサを構成できます。ゲートウェイ パターンを構成するには、Cloud Load Balancing のユーザー インターフェースと Traffic Director のユーザー インターフェースの両方が必要となる場合があります。

GKE と複数クラスタ Ingress

GKE と Anthos ネットワーク コントローラは、コンテナ ネットワークとのネイティブ統合を目的とした Cloud Load Balancing のデプロイもサポートしています。ゲートウェイをデプロイして構成するための Kubernetes スタイルの宣言インターフェースを備えています。GKE Ingress コントローラと Anthos Ingress コントローラは、1 つのクラスタまたは複数の GKE クラスタにトラフィックを送信するための内部ロードバランサと外部ロードバランサを管理します。Ingress リソースは、GKE クラスタにデプロイされた Traffic Director で構成されたサービスを指すように構成することもできます。

ゲートウェイのアーキテクチャ パターン

このセクションでは、ゲートウェイのパターンの概要とアーキテクチャ図を示します。

パターン

最も一般的なパターンは、Google Cloud が管理するロードバランサをゲートウェイとして使用することです。

  1. クライアントは、Google Cloud で管理され、ゲートウェイとして機能するロードバランサにトラフィックを送信します。
    • ゲートウェイはポリシーを適用します。
  2. ゲートウェイは、メッシュ内のサービスにトラフィックを送信します。

より高度なパターンには、2 つのレベルのゲートウェイが含まれます。ゲートウェイは次のように動作します。

  1. クライアントは、Google Cloud で管理され、第 1 レベルのゲートウェイとして機能するロードバランサにトラフィックを送信します。
    • ゲートウェイはポリシーを適用します。
  2. ゲートウェイは、Traffic Director によって構成されたエッジプロキシ(またはエッジプロキシのプール)にトラフィックを送信します。
    • このエッジプロキシは第 2 レベルのゲートウェイとして機能します。このレベルで:
      1. たとえば、あるチームが Google Cloud に着信する上り(内向き)トラフィックを担当し、別のチームがそのチームのメッシュに着信する上り(内向き)トラフィックを担当するという場合の懸念について、明確に分けて考えることができます。
      2. Google Cloud が管理するロードバランサでサポートされていないポリシーを適用できます。
  3. 第 2 レベルのゲートウェイは、メッシュ内のサービスにトラフィックを送信します。

上り(内向き)パターンは、トラフィックがメッシュ内のサービスに到達すると終了します。以下では、一般的なケースと高度なパターンの両方について説明します。

インターネットからの上り(内向き)トラフィックを有効にする

クライアントが Google Cloud の外部にあり、公共のインターネットから Google Cloud にアクセスする必要がある場合は、次のいずれかのロードバランサをゲートウェイとして使用できます。

適切なゲートウェイを決定する際に有用なその他の情報については、メッシュのゲートウェイの選択をご覧ください。

ロードバランサを使用する、公共のインターネット上のクライアントからメッシュ内のサービスへの上り(内向き)トラフィック(クリックして拡大)
ロードバランサを使用する、公共のインターネット上のクライアントからメッシュ内のサービスへの上り(内向き)トラフィック(クリックして拡大)

このパターンでは、Google Cloud が管理するロードバランサがゲートウェイとして機能します。ゲートウェイは、メッシュ内のサービスに転送する前に上り(内向き)トラフィックを処理します。

たとえば、ゲートウェイとして HTTP(S) 負荷分散を選択し、次の対象を使用できます。

  • レイテンシとネットワーク トラバーサルのコストを最小限に抑える、一般公開されておりルーティングか可能なグローバル エニーキャスト IP アドレス
  • メッシュへのトラフィックを保護する Google Cloud Armor と TLS 終端
  • ウェブと動画のコンテンツを配信する Cloud CDN
  • ホストベースとパスベースのルーティングなどのトラフィック管理機能

Virtual Private Cloud と接続されたオンプレミス ネットワークのクライアントからの上り(内向き)トラフィックを有効にする

クライアントが VPC ネットワーク内にある場合、またはオンプレミスにありプライベート接続(Cloud VPN や Cloud Interconnect など)で Google Cloud サービスにアクセスできる場合は、次のロードバランサのいずれかをゲートウェイとして使用できます。

適切なゲートウェイを決定する際に有用なその他の情報については、メッシュのゲートウェイの選択をご覧ください。

ロードバランサを使用する、VPC ネットワーク上のクライアントからメッシュ内のサービスへの上り(内向き)トラフィック(クリックして拡大)
ロードバランサを使用する、VPC ネットワーク上のクライアントからメッシュ内のサービスへの上り(内向き)トラフィック(クリックして拡大)

このパターンでは、Google Cloud が管理するロードバランサがゲートウェイとして機能します。ゲートウェイは、メッシュ内のサービスに転送する前に上り(内向き)トラフィックを処理します。

たとえば、ゲートウェイとして内部 HTTP(S) 負荷分散を選択すると、次の機能を使用できます。

  • プライベートなアドレス指定が可能な IP アドレス
  • TLS 終端によるメッシュの保護
  • 重み付けに基づくトラフィック分割などの高度なトラフィック管理機能
  • バックエンドとしての NEG

メッシュのエッジで第 2 レベルのゲートウェイを使用して上り(内向き)トラフィックを処理する

必要に応じて、ゲートウェイを追加するより高度なパターンを検討できます。

ロードバランサとエッジプロキシを使用する、外部クライアントからメッシュ内のサービスへの上り(内向き)トラフィック(クリックして拡大)
ロードバランサとエッジプロキシを使用する、外部クライアントからメッシュ内のサービスへの上り(内向き)トラフィック(クリックして拡大)

このゲートウェイは、Google Cloud が管理するロードバランサの背後にある Traffic Director で構成されたエッジプロキシ(またはプロキシのプール)です。Compute Engine VM(MIG)または GKE サービスのプールを使用して、この第 2 レベルのゲートウェイをプロジェクトでホストできます。

このパターンはより高度ですが、次のようなメリットがあります。

  • Google Cloud が管理するロードバランサは、HTTP(S) 負荷分散を使用している場合の Google Cloud Armor の保護など、初期の一連のポリシーを適用します。

  • Traffic Director で構成されたエッジプロキシは、Google Cloud マネージド ロードバランサでは使用できない可能性がある 2 つ目の一連のポリシーを適用します。これらのポリシーには、HTTP ヘッダーに適用される正規表現と重み付けに基づいたトラフィック分割を使用する高度なトラフィック管理が含まれます。

このパターンは、組織構造を反映するように設定できます。例:

  1. あるチームが Google Cloud への上り(内向き)トラフィックの処理を担当し、別のチームがそのチームのメッシュへの上り(内向き)トラフィックの処理を担当する場合があります。

  2. 複数のチームが 1 つの共有 VPC でサービスを提供し、各チームが独自のサービス プロジェクトを所有している場合は、各チームはこのパターンを使用してそれぞれのメッシュ内でポリシーを管理、適用できます。各チームは、単一の IP アドレスとポートのペアで到達可能な Traffic Director で構成されたゲートウェイを公開できます。その後、チームは、チームのメッシュへの上り(内向き)トラフィックに適用されるポリシーを個別に定義して管理できます。

このパターンは、ロードバランサが Traffic Director で構成されたゲートウェイをホストするバックエンドにトラフィックを送信できる限り、Google Cloud が管理するロードバランサを使用して実装できます。各ロードバランサでサポートされているバックエンドについては、メッシュのゲートウェイの選択をご覧ください。共有 VPC で Traffic Director を使用する方法については、複数の GKE クラスタで共有 VPC を使用した Traffic Director の構成をご覧ください。