はじめに
こんにちは、最近Google Cloud勉強中のまるです。
Google Cloudを学んでいる方なら、一度は「ロードバランサ多すぎ問題」に悩まされたことがあるのではないでしょうか？
グローバルアプリケーションロードバランサ、リージョナルアプリケーションロードバランサ、インターナルネットワークパススルーロードバランサ…
Google Cloudのロードバランサは、構成や機能の違いから10種類(Classicを除く)に分かれます。
ちなみに、AWSでは3種類しかないそうです。(Classicを除く)
ドキュメントを読み進め、自分の中でうまく整理できたので、共有してみたいと思います。もし間違ってたら教えてください！
そもそもロードバランサとは？
まず、ロードバランサって何？という方のために、代表的な機能を2つ紹介します。
-
トラフィックの分散
名前の通りロードバランサは、クライアントからのリクエストを複数のサーバー（バックエンド）に振り分けて負荷を分散します。
これにより、一部のサーバーだけに負荷が集中することを防ぎ、安定したサービス提供が可能になります。 -
ヘルスチェック機能
ロードバランサは、バックエンドに対しヘルスチェック(probe)を送り続けます。
ヘルスチェックに対してあるサーバーが反応しなくなった場合、そのサーバーは正常でないとみなし、正常なサーバーにだけトラフィックを振り分けるようにします。
例えば、バックエンドと直接通信していてそのサーバーがダウンした場合、本来は手動で宛先の切り替えを行う必要があります。ただし、ロードバランサを間に挟むことで、マネージドに通信を継続することができます。
また、これらの機能に加えてCloud Armorと組み合わせてよりセキュアな通信を可能にしたり、Cloud LoggingやCloud Monitoringと組み合わせてログやパフォーマンスを可視化することができるなど、様々な恩恵があります。
各ロードバランサの違いについて
先ほど紹介した２つの機能はどのロードバランサも共通して持っているのですが、ロードバランサによって遅延の違いがあったり、Cloud Armorの機能が一部しかサポートされていなかったり、ロードバランサごとにサポートしているプロトコルなどもバラバラです。
各ロードバランサの詳しい比較はこちらの公式ドキュメントを参照してください。
https://cloud.google.com/load-balancing/docs/features?hl=ja
おさえるべき３つの軸
もちろん利用するロードバランサごとに仕様を調べることは最も重要ですが、そもそもなぜこんなにもロードバランサごとに仕様が異なるのでしょうか。
その理由は、「どこをみてトラフィックを振り分けるか、どのOSIレイヤーで動作するのか」 が大きく関わっています。
まず、Google Cloudのロードバランサは、大きく分けて以下の３種類に分類されます。
Application Load Balancer
Application Load Balancerはアプリケーション層（Layer7）までのHTTPヘッダーやパス、ホスト名などの情報を見ます。
それらを元に、どのバックエンドにトラフィックを振り分けるかを選択します。
また、各レイヤーのヘッダーには依存関係があり、上位ヘッダーの情報を確認するには、下位ヘッダーの情報を知る必要があります。
したがって、L7ヘッダーまでの情報を見たいときは非カプセル化に近い動作を行うことになります。このことからデータの中身をチェックして動作するCloud Armor(WAF)との相性もよく、提供されている機能も多いです。
Application Load Balancerは多くの情報を扱うためにロードバランサ側の処理がやや多くなりますが、その分柔軟なルーティングやセキュリティ制御が可能になります。
Network Proxy Load Balancer
このロードバランサはトランスポート層（Layer4）までのIPアドレスやポート番号など、低レイヤーの情報しか見ません。
それらの情報をもとに、どのバックエンドにトラフィックを振り分けるのかを判断します。
また、このロードバランサはクライアントとロードバランサ間でTCPコネクションを一度終端します。そして、再度ロードバランサとバックエンド間でTCPコネクションを張り直します。
やや動作レイヤーが中途半端なので、この後紹介するロードバランサやApplication Load Balancerの方が、使われることが多いようです。
Network Passthrough Load Balancer
こちらもNetwork Proxy Load BalancerとIPアドレスやポート番号など、L4までの情報を見てトラフィックを振り分けるという点では共通しています。
ただし大きな違いとして、このロードバランサはTCPコネクションをロードバランサで終端しません。クライアントからのトラフィックをバックエンドに横流しして、クライアントとバックエンド間でTCPコネクションを維持させます。
他のロードバランサに比べて低レイヤーで動作するため、ロードバランサ側の処理が少なく遅延も小さいです。
細かい話ですが、Network Passthrough Load Balancer でも、バックエンドで SSL/TLS を終端させれば、SSL/TLSで暗号化されたトラフィックをそのまま通すことは可能です。
また、TCP/UDP をサポートしているため、TCP 上で動作する HTTP を使うことも技術的には可能です（ただし、Application Load BalancerのようなL7制御はできません）
各ロードバランサをみていただけた通り、どこまでパケットを見るのか、どのレイヤーで動作するかが違います。そのためサポートしているプロトコルや、機能にまで違いが波及しています。
違いについてわからなくなった場合、まずはここを思い出すと良いでしょう。
残り２つの分類軸
ここからロードバランサがGoogle Cloud内部か外部どちらから通信を受け付けているのか。
つまり、"送信元はどこか"という観点で、先ほどの３つのロードバランサそれぞれ対して２通りあり、計６通りに分類されます。
さらにトラフィックを分散させる際のバックエンドが１つのリージョン内にあるのか、複数リージョンに存在するのか。
つまり"宛先はどうあるか"という観点から、１つのリージョン内の場合はリージョナル、複数リージョンにまたがる場合はグローバル(内部の場合はクロスリージョナル)に分類されます。
さっきの６つに対してそれぞれ２通りの計12種類に分類されるのです。
と言いたいのですが、Passthrough Network Load Balancerにはリージョナルしか存在しません。
したがって計10種類になります。
この理由に関してはPassthrough型は低遅延が売りの設計なので、遅延が大きくならざるを得ないグローバルな使用は設計思想に反するからではないのか、と推測しています。
引用元：https://cloud.google.com/load-balancing/images/lb-product-tree.svg
グローバル・クロスリージョナルについての補足
内部ロードバランサのバックエンドが複数リージョンにまたがるとき、グローバルではなくクロスリージョナルと呼ばれています。実は、若干挙動が異なります。
グローバルの場合、世界各地に存在するPoPというGoogleのエッジ拠点にAnycast IPを広告します。それにより、クライアントからできるだけ近いところでトラフィックを処理します。
イメージとしては世界各地にロードバランサを配置し、クライアントに近いところのロードバランサがトラフィックを処理するという感覚に近いと思います。
クロスリージョナルの場合、内部からの通信なので世界各地にIPを配置する必要はないです。普通のリージョナル内部ロードバランサと同じように単一のIPに対して通信が行われ、複数リージョンのバックエンドに振り分けられます。
おわりに
沢山あったロードバランサたちも以下の３つの観点から分類ができました。
- どのレイヤーで動作するのか
- トラフィックの送信元が外部か内部か
- トラフィックの宛先が単一リージョンか、複数リージョンか、
特に動作レイヤーの違いが多くの仕様の違いをもたらしているところはおさえておきたいポイントだと思います。
ここまで読んでくださってありがとうございました！
ロードバランサの内部構造に興味があるので、いつか深堀して記事を書いてみたいなと思っています。