AWS側の目線から理解する、Google Cloud ロードバランサの世界

はじめに

お久しぶりです、iselegantです。

今回はAWSアーキテクトの目線から、多様なGoogle Cloud Load Balancingの世界を紹介してみたいと思います。

昨今、担当業務やプロジェクトによってはAWSのみならずGoogle Cloudを活用したり、マルチクラウドとして両方扱うエンジニアの方も多くなってきたのではないでしょうか? 特に、SI企業に所属する人においては、担当プロジェクトや業務、お客様が変われば利用するクラウドサービスも変わる、なんてこともよくあると思います。 私もその道を辿ってきた一人です。

現在ではクラウドサービス間においてもある程度のコモディティ化が進んでおり、ある一つのクラウドサービスに精通すると、他のクラウドサービス利用時におけるメンタルモデルが出来上がり、システムを構築する際に前提の知識や経験が大いに役立つはずです。特にAWSはサービスの幅が広く、他のクラウドに携わる際に求められるスキルのベースラインとなるでしょう。

ただ、コモディティ化が進むとはいえ、やはりクラウド毎にサービスの特色や大きな仕様の違いは存在します。 ことGoogle Cloudに関してですが、全体像の理解がなかなか難しいサービスのひとつがロードバランサ(Cloud Load Balancing)といっても過言ではないでしょう。 もちろん、初手からGoogle Cloudを担当するエンジニアも、このCloud Load Balancingの全体像を理解するのはなかなかの鬼門なのでは?と筆者は考えています。 その理由は、ロードバランサ自体の種類の多さです。AWS側とロードバランサと対比しながら見ていきましょう。

AWSのロードバランサに関するサービス概要を程度理解されていることが前提として話を進めます

AWSにおけるロードバランサ

AWSは、ロードバランサに関するサービスとして全部で4種類提供しています。

Classic Load Balancer (CLB) はEC2 Classic向けの名残を受けて残存しているため、昨今では積極的に利用はされていません (利用自体は可能です) 。 加えて、Gateway Load Balancer (GWLB) は、主にサードパーティのセキュリティ製品にパケットを透過的に流す等のユースケースで用いられることが多く、少々用途が特殊です。

以上より、通常の業務向けコンピューティングワークロードに対して負荷分散機能を提供する、という意味では、Application Load Balancer (ALB) とNetwork Load Balancer (NLB) の2種類が主に利用されているといえます。

Google Cloudにおけるロードバランサ

一方、同様の目的で利用されるGoogleのロードバランサはというと・・・

なんと10種類もあります!

※今回はシンプルにロードバランサの全体像を解説するため、従来型ロードバランサに関する話は割愛させていただきます。

AWSとは異なり、なぜGoogle CloudではこんなにもLoad Balancingサービスが豊富なのでしょうか。 また、どのようにこれらのロードバランサに関する使い分けを理解しながら、ロードバランサのサービス全体像を把握するとよいのでしょうか

今回のブログでは、これを紐解いて、Google Cloudのロードバランサに対する理解を深めることが目的です。

AWSGoogle Cloudにおけるネットワークの思想の違い

Google Cloud ロードバランサを理解するために、まず、AWSGoogle Cloudのネットワークに関する思想を簡単におさらいしていきます。

こちらをご覧ください。

これは、AWSGoogle CloudそれぞれのVPCに関する仕様です。 AWSVPCがリージョンに閉じた形で作られるのに対し、Google CloudではVPCを複数リージョンに横断して定義することが可能です。 当然ながら、どちらのクラウドも、VPC内は直接通信が可能です。つまりGoogle Cloudの場合は、たとえリージョンをまたがっていても同じVPC内であれば同一ネットワーク内として通信できるわけです。

このように、Google Cloudでは、はじめからグローバルレディなネットワーキングの思想でサービス提供されていることが特徴です。後述するロードバランサの仕様に関しても、このグローバルレディな特性を色濃く受けています。

Google Cloud のロードバランサを理解する

Google Cloudが前提とするVPCネットワークの考え方を理解したところで、ここからはステップバイステップでロードバランサの全体像を理解していきます。 

※本ブログでは、ユースケースに併せてロードバランサをどう選択するか、というよりは「そもそもGoogle Cloudのロードバランサの全体像というものをどのように理解するか」、というアプローチで解説しています。

Webアプリケーション向け通信用途か、その他ネットワーク通信用途か

AWS同様、Google Cloudのロードバランサの種別はアプリケーションロードバランサとネットワークロードバランサに大別されます。

OSI参照モデルのレイヤー7でリクエストを受け取るか、レイヤ3ー/4で受け取るか、の違いですね。 話を簡単にするために、まずはアプリケーションロードバランサ (HTTP/HTTPS) に話を絞ってお話ししていきます。

外部向けか、内部向けか

Google Cloudでは、インターネットからの通信を受け付ける外部向けのロードバランサと、VPC内でのみ利用する内部向けロードバランサを明確に区別されます。

構成図で表現すると、次のような感じになります。

余談ですが、AWSにおいても、ロードバランサのスキームとして、内部向けとインターネット向けが存在します。 しかし、ドキュメント上におけるロードバランサの特徴においては、内部向けとインターネット向けに対して、ロードバランサの種別単位として、明確に区別していません。そのため、ロードバランサの種別という意味では、これらを一つとして表現しているようです。

一方、Google Cloudでは外部向けと内部向けで異なるロードバランサの種別である、と明確に分けて表現しており、この点が、Google Cloudのロードバランサは多様であると感じる一つの背景でしょう。

グローバルか、リージョナルか

先程、クラウドの思想で述べた通り、Google Cloudはサービス当初からグローバルスケールなビジネスに適用できることを前提としたネットワーク仕様となっています。 そのため、ロードバランサに関しても、グローバルレベルなのか、リージョナルか、といった観点で区別されます。

グローバルロードバランサを作成すると、言葉の通り、それらの設定がグローバル上のリソースに配置されます。 具体的には、エッジPoPと呼ばれる「インターネット側からGoogle Cloud内のネットワークに接続するための拠点」に配置されているサーバリソースに対してその設定が同期されます。 一方、リージョナルロードバランサに関しては、当然ながらその設定は特定のリージョン内に限定されます。

リージョナルは最近新しく出来たレイヤーで、例えばビジネス上のコンプライアンス要件としてクラウドのリソースをすべて特定の国内に配置しなければならないケースなどに応えることができるようになっています。

先程の外部向け or 内部向けと組み合わせると、次のような感じになります。

さて、ここで「内部向けかつグローバル」なロードバランサとはどういうものでしょうか? 再度おさらいですが、Google Cloudはグローバルを前提としたVPCネットワーク構造となっています。 そのため、「内部向けかつグローバル」というと、このVPC内で自由にリージョンをまたがるような、次のようなロードバランサとなるわけですね。

一方、「内部向けかつグローバル」なロードバランサの実体は、リージョンに配置されています。 Google Cloudではロードバランサの実体がある場所に「グローバル」と名前を与えています。そのため、このケースではグローバルとは呼ばず、「クロスリージョナル」という形でサービスが定義されています。

ここまでの流れをまとめると、アプリケーションロードバランサは次のような種別で整理できます。

ちなみに、AWSにおいて、グローバルにまたがるロードバランサは存在しません。なぜなら、ロードバランサのサービス自体がリージョン、正確に言えば、複数の同一リージョン内のAZに紐づくサービスだからです。 仮にグローバルな負荷分散機能を実装したい場合、Amazon Route 53の位置情報ルーティングレイテンシーベースルーティング等と組み合わせて実現することになります。

(1/16追記) AWSに関しては、Route53以外にもAWS Global Acceleratorを活用することで、リージョン間での処理振り分けが可能です。

ネットワークロードバランサに関して

さて、ここまではアプリケーションロードバランサ (HTTP/HTTPS) の話でした。 次はネットワークロードバランサ (TCP) の話です。

基本的には考え方は同じで、先程のアプリケーションロードバランサと同じように、ネットワークロードバランサも、外部向け or 内部向け、グローバル or リージョナルの区分で理解しておけばOKです。

先程のアプリケーションロードバランサに関する種類の考え方が理解出来れていれば、スムーズに理解できるのではないでしょうか。


プロキシ型か、パススルー型か

さて、これまで述べてきたロードバランサは、実はプロキシ型と呼ばれるものです。 プロキシ型ロードバランサとはなんでしょうか?その名の通り、プロキシのように、ロードバランサが一旦通信のリクエストを受け付けるものです。なので、バックエンドからすると、送信元のIPアドレスはロードバランサになるわけですね。

こうすることで、ロードバランサ側に様々な仕事を任せることができます。 ヘッダーを書き換えたり、TLS証明書を付与してSSL処理をターミネートしたり、などなど。 これらの機能に関しては、Google Cloudのドキュメントにて丁寧に整理されています。

一方、要件によっては、バックエンドとしては、明示的にクライアント側から直接リクエストを受け取りたいケースもあります。例えば、オンプレミス側のFrom IPアドレスを厳密にバックエンド側で制限したいケースや、クライアント〜バックエンドでSSL通信したいケースなどです。

そこで用意されているのが、パススルー型というもの。 プロキシ型と異なり、ロードバランサはクライアントの通信をそのまま通過させます。 まとめると次のようになります。

パススルー型ロードバランサは負荷分散のみを司り、その他には関与しません。そのため、当然ながらFrom IPアドレスはクライアントになります。また、SSLコネクションの終端にもなりません。 なので、プロキシ型ネットワークロードバランサはTCP/SSLプロキシ型パススルー型ネットワークロードバランサはTCP/UDP、などとドキュメント上では表現されていたりします。

パススルー型はなぜリージョナルのみ提供されているのか

このパススルー型ですが、リージョナルなリソースとして提供されています。なぜでしょうか? ここからはネットワークの一般的な知識をもとに、筆者にてその理由を推察してみます (あくまで筆者の理解です) 。

パススルー型のロードバランサでは、DSR (Direct Server Return) と呼ばれる技術が活用されています。 これは、パケットがパススルー型ロードバランサを通過する時、宛先のMACアドレスを自身宛から、バックエンド宛に書き換えることにより、そのままパケットを転送する技術です。

MACアドレスを書き換えるということは、MACアドレス書き換え後にそのフレームをバックエンドに転送するためには、ロードバランサの送信元NICとバックエンドが同一サブネット上に存在する必要があります。そうしないと、MACアドレスを書き換えても宛先に到達できません。

ところで、前述した通り、Google Cloudのサブネットはリージョン単位でした。仮にロードバランサのリージョンがバックエンドのリージョンと異なると、それぞれ所属するサブネットも異なるはずです。そのため、MACアドレスを書き換えても、直接バックエンド側にフレームを転送できません。以上の理由から、パススルー型のロードバランサは必然的にリージョナルなリソースとして提供されているものと推察されます。

※もし誤りがあれば、優しく指摘してください。

(1/16修正) ご参考までですが、AWS NLBに関してもDSRと同様に、バックエンドからはクライアントからリクエストがきているような動きとなります。しかし、内部的ではNLBを通過するため、正確に述べればDSRではありません

Google Cloud ロードバランサに関するまとめ

これまでの話をまとめましょう。

  • アプリケーション型とネットワーク型に大別
  • 外部 or 内部、グローバル or リージョンで区別
  • 内部かつグローバルはクロスリージョナル
  • ネットワーク型は更にプロキシ型とパススルー型に分類
  • パススルー型はいずれもリージョナルのみ。外部向けと内部向けが存在

一枚絵でまとめると、次のようになります。

いかがでしたでしょうか。 Google Cloudのロードバランサに正面から向き合うとその数の多さになかなか圧倒されるかと思うのですが、 順を追ってポイントを理解していくことで、クラウドのサービス思想から、ロードバランサが多様であることの合理性についても、納得がいくのではないでしょうか。

今回ブログで執筆した考え方をある程度理解しておくと、きっとGoogle Cloudのロードバランサと仲良くなれると思います。

では、また!

(1/16補足) 「クロスリージョナルx内部」に関する図の吹き出しが「クロスリージョナルx外部」となっていたため、修正しました。