ホーム
お役立ち
Google Service
Google Cloud （GCP）の多彩なロードバランサーを一挙に紹介！

Google Cloud （GCP）の多彩なロードバランサーを一挙に紹介！

Cloud
コンテナ
ロードバランサー

公開年月日: 2022.05.08

更新年月日: 2024.09.26

本記事は、2021年9月16日に開催された Google の公式イベント「オープンクラウドサミット」において、 Google Cloud のカスタマーエンジニアである有賀征爾氏が講演された「 Google Cloud の多彩なロードバランサーを一気にご紹介」のレポート記事となります。

今回は、 Google Cloud （GCP）に搭載されている多彩なロードバランサーの分類や構成、機能などについて、それぞれ具体的に解説します。実際の構成を図でわかりやすく示していますので、ぜひ最後までご覧ください。

なお、本記事内で使用している画像に関しては、オープンクラウドサミット「 Google Cloud の多彩なロードバランサーを一気にご紹介」を出典元として参照しております。

それでは、早速内容を見ていきましょう。

ロードバランサーの分類

まずは Google Cloud （GCP）のロードバランサーについて、どのような分類ができるのかをご説明します。

下図は Google Cloud （GCP）の各種設定を行うためのクラウドコンソールであり、実際にロードバランサーを作成するときはこの画面が表示されます。

ここからは、複数の観点でロードバランサーの分類を見ていきましょう。

レイヤによる分類

上図左側の「 HTTP（S）負荷分散」となっている部分はレイヤ7（以降 L7 と記載）のロードバランサーを作成する入口になります。一方、画面の中央と右側にある「 TCP 負荷分散」と「 UDP 負荷分散」はレイヤ4（以降 L4 と記載）のロードバランサーを作成する入口です。プロキシとパススルーに関しては後ほどご説明します。

そして、この分類を表にしたものが下図です。細かい分類が記載されていますが、まずは Google Cloud （GCP）でロードバランサーを作る際には、大きく分けて L7 と L4 のロードバランサーを作成する入口がそれぞれ存在することを理解しておきましょう。

負荷分散の対象による分類

まずは、外部負荷分散と内部負荷分散について簡単にご説明します。外部負荷分散はインターネットからのトラフィックを受けて Google Cloud （GCP）のバックエンドにトラフィックを負荷分散するものです。

一方、内部負荷分散は Google Cloud （GCP）のネットワーク内で発生するトラフィックを負荷分散するものです。また、オンプレミス環境のサーバーをバックエンドとして Google Cloud （GCP）内の VM からトラフィックを負荷分散するような仕組みも内部負荷分散として位置付けられます。

これを踏まえて、先ほどの図を外部負荷分散と内部負荷分散に分けると以下のようになります。外部負荷分散では外部 HTTP（S）負荷分散、 TCP/SSL プロキシ負荷分散、外部 TCP/UDP ネットワーク負荷分散の3つがあり、内部負荷分散では内部 HTTP（S）負荷分散と内部 TCP/UDP 負荷分散の2つがあります。

リージョンバックエンドによる分類

リージョンバックエンドには2つの種類が存在し、マルチリージョンバックエンドとシングルリージョンバックエンドに分けられます。マルチリージョンバックエンドの場合は、複数のバックエンドを持つことができ、クライアントの位置に応じて一番近いバックエンドにリクエストを流すことができます。一方、シングルマルチリージョンバックエンドの場合は、1つのバックエンドしか持つことはできません。

このリージョンバックエンドの観点から、ロードバランサーの種類をマッピングしたものが下図です。外部 HTTP（S）負荷分散と TCP/SSL プロキシ負荷分散はマルチリージョンバックエンドに対応しており、残りの3つはシングルリージョンバックエンドになります。

マルチリージョンバックエンドのメリットは、1つの IP アドレスでグローバルにロードバランサーを作成できることです。全世界から同じ IP アドレスにアクセスした場合でも、そのクライアントに一番近いバックエンドに負荷分散することが可能になります。

プロキシとパススルーによる分類

ロードバランサーには、プロキシ型とパススルー型という分類があります。プロキシ型はクライアントから届いたリクエストをロードバランサーで受け取り、そのロードバランサーが別のセッションとしてバックエンドに通信を行います。そのため、ロードバランサーにリクエストが届く前後で送信元と送信先が変わる、という特徴を持っています。

一方、パススルー型はクライアントから届いたリクエストをそのままバックエンドに届ける形になります。そのため、ロードバランサーにリクエストが届く前後で送信元と送信先が変わることはありません。

この分類をもとにロードバランサーの種類をマッピングすると以下の通りです。プロキシ型とパススルー型で、それぞれ対応するロードバランサーが異なることがわかります。

プロキシ

まとめ

ここまで、ロードバランサーを分類するための4つの考え方をご紹介しました。すべての要素を1枚の図で表したものが以下になります。

ALL

そして、これをツリー状にわかりやすく示したものが下図です。各ポイントごとに枝分かれしていき、最終的に利用するロードバランサーが決まります。

ツリー

また、実際の作成画面で見ると以下のようになっています。外部または内部、リージョンバックエンドなどの要素を加味して作成を進めていく形になります。

このように、ロードバランサーの分類には多くの考え方があります。自社がロードバランサーを使う目的や用途に応じて、多角的な観点から最適なものを選択することが大切です。

ロードバランサーの構成

次にロードバランサーの構成をご説明します。タイプごとに分けて、それぞれ詳しく見ていきましょう。

外部（プロキシ型）の負荷分散

Google Cloud （GCP）のロードバランサーでは、「 Tier-1 エッジ」というところに負荷分散用のインフラストラクチャが用意されています。このインフラストラクチャを Google のサービスと Google Cloud （GCP）のお客様用のサービスに共用しているイメージになります。

クライアントから届いたリクエストは、一旦 Maglev と呼ばれるロードバランサーで負荷分散され、 GFE （Google Front End）で終端されます。そして、必要なバックエンドにルーティングされて、最終的にお客様のバックエンドにリクエストが到達します。

この外部（プロキシ型）の負荷分散のデータモデルを図で表したものが以下になります。下図に示した通り、インターネットからファイアウォールまで複数のコンポーネントに分かれています。

参考までに、外部（プロキシ型）の負荷分散を設定する画面を掲載します。 Google Cloud （GCP）のクラウドコンソール上で直感的かつ簡単に設定を行うことができます。

また、主に外部 HTTP（S）の負荷分散用になりますが、バックエンドの種類を下図で示しています。様々なバックエンドに対応していることをご理解いただけると思います。

これらのバックエンドをロードバランサーのバックエンドとして指定する際に利用されるのが NEG です。 NEG とはネットワークエンドポイントグループの略称であり、論理的なエンドポイントをまとめた概念的なものだとイメージしてください。エンドポイントを抽象化して、ロードバランサーのバックエンドとして使えるようにする役割を持っています。

neg

ここで、ゾーン NEG について、もう少し深掘りしてご説明します。例えば、下図の左側のように VM 単位でバックエンドを指定してしまうと、ロードバランサーからは VM 1 や VM 2 しか見えなくなり、適切なロードバランスを実行することが難しくなります。しかし、下図の右側のように、 NEG を使ってコンテナ一つ一つを指定することで、5つのコンテナに対して適切に負荷分散を実行できるようになります。

ゾーンneg

外部（パススルー型）の負荷分散

次に、外部（パススルー型）の負荷分散についてご説明します。パススルー型はプロキシ型よりもシンプルな構成となっており、 Maglev を通ったリクエストがそのままロードバランサーに到達します。

データモデルもプロキシ型と比較してシンプルであり、ターゲットプロキシや URL マップは存在せず、コンポーネントの数は少なくなっています。

内部（プロキシ型）の負荷分散

ここまでは外部負荷分散についてご説明しましたが、ここから先は内部負荷分散の構成をご紹介します。まずはプロキシ型ですが、基本的な考え方は外部（プロキシ型）の負荷分散と同じです。

データモデルも外部（プロキシ型）の負荷分散と変わらず、 IP アドレスが外部なのか、または内部なのかの違いだけになります。

内部（パススルー型）の負荷分散

内部（パススルー型）の負荷分散の構成は、外部（パススルー型）の負荷分散と変わりませんが、内部（パススルー型）の負荷分散の場合、実体としてのロードバランサーは存在せず、 VPC を構成する SDN の機能がその役割を担っています。

内部（パススルー型）の負荷分散のデータモデルは以下の通りであり、非常にシンプルな形で構成されています。外部（パススルー型）の負荷分散と同じデータモデルです。

ロードバランサーの機能

ここからは、各ロードバランサーの機能を具体的にご紹介します。

URL のルーティング・書き換え・リダイレクト

外部 HTTP（S）負荷分散と内部 HTTP（S）負荷分散では、バックエンドに手を入れず、ロードバランサーでインテリジェントなルーティングを実現できます。これにより、簡単な A/B テストやカナリアリリースを行うことが可能になります。

より高度なルーティング

内部 HTTP（S）負荷分散においては、前項でご説明したものよりもさらに高度なルーティングが用意されています。例えば、フォールトインジェクションやトラフィック分割、失敗したリクエストの再試行、外れ値検出などが挙げられます。

Identity-Aware Proxy （IAP）

アプリケーションに認証を追加する場合、本来はアプリケーション自体に手を加える必要がありますが、 Identity-Aware Proxy （IAP）を使うことで認証部分をロードバランサーで完結することができ、認証が終わったリクエストのみをバックエンドに送ることが可能です。

認証には、 Google アカウントや OAuth 、 SAML 、 OIDC などの一般的な認証プロトコルを網羅しているため、既存の認証 DB をそのまま利用して認証できる点も大きなメリットとなっています。

iap

内部 TCP/UDP 負荷分散と Multi-NIC VM による構成

昨今、内部ロードバランサーの機能としてよく使われているのが、内部 TCP/UDP 負荷分散と Multi-NIC VM による構成です。これにより、仮想ファイアウォールアプライアンスなどの統合時に高い可用性を実現できます。クライアント VM やサーバー VM はアプライアンスを意識する必要はなく、 TCP/UDP だけでなく、 ICMP や ESP GRE などもサポートしています。