メッシュの上り（内向き）トラフィック
サービス メッシュは、メッシュ内で実行されているサービス間の通信を容易にします。トラフィックをメッシュに取り込む際にどのような方法が考えられるでしょうか。ゲートウェイを使用すると、メッシュ外部からエントリ ポイントを介してトラフィックをメッシュに転送できます。
このドキュメントでは、Cloud Load Balancing をゲートウェイとして使用してメッシュにトラフィックを取得する方法を説明します。内容には以下が含まれます。
- ゲートウェイに関する考慮事項の概要。
- メッシュのゲートウェイを選択する際のオプションの概要。
- ゲートウェイ トポロジに適用できるアーキテクチャに関する推奨事項。
このドキュメントは、Traffic Director のサービス ルーティング API に適用されます。準備手順が完了したら、Ingress ゲートウェイの Traffic Director の設定をご覧ください。Ingress ゲートウェイを使用してデプロイする手順が記載されています。
サービス メッシュを設計する際は、次のソースからのトラフィックを考慮します。
- メッシュ内で発生したトラフィック
- メッシュ外で発生したトラフィック
メッシュ内で発生したトラフィックは、サービス メッシュのデータプレーン上を移動し、宛先サービスに関連付けられたバックエンドまたはエンドポイントに到達します。ただし、メッシュ外から発生したトラフィックは、まず最初にサービス メッシュ データプレーンに接続する必要があります。
メッシュ内で発生した次のトラフィックの例では、Traffic Director がサイドカー プロキシを構成します。これらのサイドカー プロキシは、サービス メッシュのデータプレーンを形成します。サービス A がサービス B と通信する必要がある場合、次のようになります。
- サービス A はサービス B に名前でリクエストします。
- このリクエストはインターセプトされ、サービス A のサイドカー プロキシにリダイレクトされます。
- サイドカー プロキシは、次にサービス 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 レベルのゲートウェイを使用して上り（内向き）トラフィックを処理するをご覧ください。
次の表は、選択したゲートウェイ オプションに応じて使用可能な機能を比較したものです。
| ゲートウェイ | クライアントのロケーション | プロトコル | ポリシー | バックエンド / エンドポイント |
|---|---|---|---|---|
| 内部アプリケーション ロードバランサ | ロードバランサと同じリージョンにある Google Cloud ベースのクライアント。 ロードバランサと同じ Google Cloud リージョンにリクエストが届くオンプレミスのクライアント（Cloud VPN や Cloud Interconnect を使用する場合など）。 |
HTTP/1.1 HTTP/2 HTTPS |
高度なトラフィック管理 セルフマネージド証明書を使用した TLS 終端 |
ロードバランサと同じ Google Cloud リージョンにあり、次の場所で実行されるバックエンド:
|
| 外部アプリケーション ロードバランサ | 公共のインターネット上のクライアント | HTTP/1.1 HTTP/2 HTTPS |
トラフィック管理 Cloud CDN（Cloud Storage バケットのバックエンドを含む） Google マネージド証明書またはセルフマネージド証明書を使用した TLS 終端 SSL ポリシー DDoS とウェブ攻撃を防止する Google Cloud Armor ユーザー認証における Identity-Aware Proxy（IAP）サポート |
任意の Google Cloud リージョンにあり、次の場所で実行されるバックエンド:
|
| 内部パススルー ネットワーク ロードバランサ | 任意のリージョンにある Google Cloud ベースのクライアント。クライアントがロードバランサと異なるリージョンにある場合は、グローバル アクセスが必要です。 リクエストが任意の Google Cloud リージョンに届くオンプレミスのクライアント（Cloud VPN や Cloud Interconnect を使用する場合など）。 |
TCP | ロードバランサと同じ Google Cloud リージョンにあるバックエンド。Compute Engine 上の VM で動作します。 | |
| 外部パススルー ネットワーク ロードバランサ | 公共のインターネット上のクライアント | TCP または UDP | ロードバランサと同じ Google Cloud リージョンにあるバックエンド。Compute Engine 上の VM で動作します。 | |
| 外部プロキシ ネットワーク ロードバランサ | 公共のインターネット上のクライアント | SSL または TCP | Google マネージド証明書またはセルフマネージド証明書を使用した TLS 終端（SSL プロキシのみ） SSL ポリシー（SSL プロキシのみ） |
任意の Google Cloud リージョンにあり、次の場所で実行されるバックエンド:
|
| エッジプロキシ Traffic Director によって構成され、VM またはコンテナ インスタンス上にある |
クライアントは、次のいずれかに該当する場所に存在する必要があります。
|
HTTP/1.1 HTTP/2 |
高度なトラフィック管理（regex サポートを含む） |
任意の Google Cloud リージョンにあり、次の場所で実行されるバックエンド:
|
機能別の比較については、ロードバランサの機能のページをご覧ください。Traffic Director の機能の概要の詳細については、Traffic Director の機能のページをご覧ください。
ゲートウェイのデプロイと構成
ゲートウェイを選択する際の最後の考慮事項は、使用するデベロッパー エクスペリエンスとツールです。Google Cloud には、ゲートウェイを作成して管理するための複数の方法が用意されています。
Google Cloud CLI と Compute Engine API
Google Cloud のマネージド ロード バランシング プロダクトと Traffic Director は、Google Cloud CLI と Compute Engine API を使用して構成できます。gcloud CLI と API は、Google Cloud リソースを命令的にデプロイして構成するためのメカニズムを備えています。繰り返しのタスクを自動化するために、スクリプトを作成できます。
Google Cloud コンソール
Traffic Director と Google Cloud のマネージド ロードバランサを構成するには、Google Cloud コンソールを使用できます。
ゲートウェイ パターンを構成するには、Traffic Director のページとロード バランシングのページの両方が必要となる場合があります。
GKE とマルチクラスタ Ingress
GKE と GKE Enterprise ネットワーク コントローラは、コンテナ ネットワークとの統合をあらかじめ組み込むことを目的とした Cloud Load Balancing のデプロイもサポートしています。ゲートウェイをデプロイして構成するための Kubernetes スタイルの宣言インターフェースを備えています。GKE Ingress コントローラと複数クラスタ Ingress コントローラは、1 つのクラスタまたは複数の GKE クラスタにトラフィックを送信するための内部ロードバランサと外部ロードバランサを管理します。Ingress リソースは、GKE クラスタにデプロイされた Traffic Director で構成されたサービスを指すように構成することもできます。
ゲートウェイのアーキテクチャ パターン
このセクションでは、ゲートウェイのパターンの概要とアーキテクチャ図を示します。
最も一般的なパターンは、Google Cloud が管理するロードバランサをゲートウェイとして使用することです。
クライアントは、Google Cloud で管理され、ゲートウェイとして機能するロードバランサにトラフィックを送信します。
- ゲートウェイはポリシーを適用します。
ゲートウェイは、メッシュ内のサービスにトラフィックを送信します。
より高度なパターンには、2 つのレベルのゲートウェイが含まれます。ゲートウェイは次のように動作します。
クライアントは、Google Cloud で管理され、第 1 レベルのゲートウェイとして機能するロードバランサにトラフィックを送信します。
- ゲートウェイはポリシーを適用します。
ゲートウェイは、Traffic Director によって構成されたエッジプロキシ（またはエッジプロキシのプール）にトラフィックを送信します。このエッジプロキシは第 2 レベルのゲートウェイとして機能します。このレベルでは、次が行われます。
たとえば、あるチームが Google Cloud に着信する上り（内向き）トラフィックを担当し、別のチームがそのチームのメッシュに着信する上り（内向き）トラフィックを担当するという場合の懸念について、明確に分けて考えることができます。
Google Cloud が管理するロードバランサでサポートされていないポリシーを適用できます。
第 2 レベルのゲートウェイは、メッシュ内のサービスにトラフィックを送信します。
上り（内向き）パターンは、トラフィックがメッシュ内のサービスに到達すると終了します。以下のセクションでは、一般的なケースと高度なパターンの両方について説明します。
インターネットからの上り（内向き）トラフィックを有効にする
クライアントが Google Cloud の外部にあり、公共のインターネットから Google Cloud にアクセスする必要がある場合は、次のいずれかのロードバランサをゲートウェイとして使用できます。
このパターンでは、Google Cloud が管理するロードバランサがゲートウェイとして機能します。ゲートウェイは、メッシュ内のサービスに転送する前に上り（内向き）トラフィックを処理します。
たとえば、ゲートウェイとして外部アプリケーション ロードバランサを選択して、次の要素を使用します。
- 一般公開されておりルーティングか可能なグローバル エニーキャスト IP アドレス。レイテンシとネットワーク トラバーサルの費用を最小限に抑えます。
- メッシュへのトラフィックを保護する Google Cloud Armor と TLS 終端。
- ウェブと動画のコンテンツを配信する Cloud CDN。
- ホストベースとパスベースのルーティングなどのトラフィック管理機能。
適切なゲートウェイの選び方については、メッシュ用のゲートウェイの選択をご覧ください。
VPC と接続されたオンプレミス ネットワークのクライアントからの上り（内向き）トラフィックを有効にする
クライアントが VPC ネットワーク内にある場合、またはオンプレミスにありプライベート接続（Cloud VPN や Cloud Interconnect など）で Google Cloud サービスにアクセスできる場合は、次のロードバランサのいずれかをゲートウェイとして使用できます。
このパターンでは、Google Cloud が管理するロードバランサがゲートウェイとして機能します。ゲートウェイは、メッシュ内のサービスに転送する前に上り（内向き）トラフィックを処理します。
たとえば、ゲートウェイとして内部アプリケーション ロードバランサを選択すると、次の機能を使用できます。
- プライベートなアドレス指定が可能な IP アドレス
- TLS 終端によるメッシュの保護
- 重み付けに基づくトラフィック分割などの高度なトラフィック管理機能
- バックエンドとしての NEG
適切なゲートウェイの選び方については、メッシュ用のゲートウェイの選択をご覧ください。
メッシュのエッジで第 2 レベルのゲートウェイを使用して上り（内向き）トラフィックを処理する
必要に応じて、さらにゲートウェイを追加する、より高度なパターンを検討できます。
このゲートウェイは、Google Cloud が管理するロードバランサの背後にある Traffic Director で構成されたエッジプロキシ（またはプロキシのプール）です。Compute Engine VM（マネージド インスタンス グループ）または GKE サービスのプールを使用して、この第 2 レベルのゲートウェイをプロジェクトでホストできます。
このパターンはより高度ですが、次のようなメリットがあります。
Google Cloud が管理するロードバランサでは、初期状態で一連のポリシーが適用されます。たとえば、外部アプリケーション ロードバランサを使用している場合は、Google Cloud Armor による保護が適用されます。
Traffic Director によって構成されたエッジプロキシでは、さらに別のポリシーセットが適用されます。その中には、Google Cloud が管理するロードバランサでは提供されないものがあります。これらのポリシーには、HTTP ヘッダーに適用される正規表現と重み付けに基づいたトラフィック分割を使用する高度なトラフィック管理が含まれます。
このパターンは、組織構造を反映するように設定できます。例:
あるチームが Google Cloud への上り（内向き）トラフィックの処理を担当し、別のチームがそのチームのメッシュへの上り（内向き）トラフィックの処理を担当する場合があります。
複数のチームが 1 つの共有 VPC でサービスを提供し、各チームが独自のサービス プロジェクトを所有している場合は、各チームはこのパターンを使用してそれぞれのメッシュ内でポリシーを管理、適用できます。各チームは、単一の IP アドレスとポートのペアで到達可能な Traffic Director で構成されたゲートウェイを公開できます。その後、チームは、チームのメッシュへの上り（内向き）トラフィックに適用されるポリシーを個別に定義して管理できます。
このパターンは、ロードバランサが Traffic Director で構成されたゲートウェイをホストするバックエンドにトラフィックを送信できる限り、Google Cloud が管理するロードバランサを使用して実装できます。
上り（内向き）トラフィックにサービス ルーティング API を使用する
サービス ルーティング API は、Ingress ゲートウェイとして機能する Envoy プロキシのトラフィック管理とセキュリティを構成するための Gateway リソースを提供し、外部クライアントがサービス メッシュ（north-south）に接続できるようにします。詳細については、サービス ルーティングの概要と Ingress ゲートウェイを設定するをご覧ください。
次のステップ
- コードをサービスのエンドポイントとして実行する VM とコンテナをグループ化するには、Traffic Director サービス ディスカバリをご覧ください。
- 共有 VPC で Traffic Director を使用するには、マルチクラスタ サービス メッシュを設定するをご覧ください。
- Traffic Director の詳細については、Traffic Director の概要をご覧ください。