負荷分散のオプション
アプリケーションに送信されるトラフィックの種類に応じて、利用できる外部負荷分散のオプションが決まります。次の表に、オプションをまとめます。
| オプション | 説明 | トラフィック フロー | 範囲 |
|---|---|---|---|
| HTTP(S) 負荷分散 | HTTP(S) トラフィックと、URL マッピングや SSL オフロードなどの高度な機能をサポートします。 特定のポート上の HTTP 以外のトラフィックにおける TCP プロキシ負荷分散または SSL プロキシ負荷分散。 |
TCP または SSL（TLS）セッションは、Google ネットワーク エッジの Google Front End（GFE）で終了し、トラフィックはバックエンドにプロキシされます。 | グローバル |
| ネットワーク負荷分散 | 任意のポートを使用して TCP / UDP トラフィックがロードバランサを通過するようにします。 | Google の Maglev テクノロジーを使用して提供され、バックエンドにトラフィックを配信します。 | リージョン |
内部ロードバランサと Traffic Director はユーザー向けのトラフィックをサポートしていないため、この記事では対象としません。
グローバル負荷分散ではこのサービスティアが必要になるため、この記事の測定では Network Service Tiers のプレミアム ティアを使用します。
レイテンシの測定
あるドイツのユーザーが us-central1 でホストされているウェブサイトにアクセスしている場合、レイテンシをテストするには次の方法を使用します。
- ping: ICMP ping はサーバーの到達可能性を測定する一般的な方法ですが、エンドユーザーのレイテンシを測定するものではありません。詳細については、HTTP(S) 負荷分散のその他のレイテンシ効果をご覧ください。
- Curl: 最初のバイトまでの時間（TTFB）を測定します。サーバーに
curlコマンドを繰り返し発行します。
結果を比較する際には、ファイバー リンク上のレイテンシは、距離とファイバー内の光の速度（約 200,000 km/秒、124,724 マイル/秒）によって制約されることに注意してください。
ドイツのフランクフルトと、アイオワ州カウンシル ブラフス（us-central1 リージョン）との距離は約 7,500 km です。これらのロケーション間にまっすぐなファイバーがある場合、ラウンドトリップ レイテンシは次のとおりです。
7,500 km * 2 / 200,000 km/s * 1000 ms/s = 75 milliseconds (ms)
光ファイバー ケーブルは、ユーザーとデータセンターの間で直接的につながっているわけではありません。ファイバー ケーブル上の光は、その経路に沿ってアクティブおよびパッシブ機器を通過します。観察されたレイテンシは理想値の約 1.5 倍、すなわち 112.5 ミリ秒であり、ほぼ理想的な構成を示します。
レイテンシの比較
このセクションでは、次の構成での負荷分散を比較します。
- 負荷分散なし
- ネットワーク負荷分散
- HTTP(S) 負荷分散または TCP プロキシ負荷分散
このシナリオでは、アプリケーションは、HTTP ウェブサーバーのリージョンのマネージド インスタンス グループで構成されます。アプリケーションは中央データベースへのレイテンシの少ない呼び出しに依存しているため、ウェブサーバーは 1 か所でホストされなければなりません。アプリケーションは us-central1 リージョンにデプロイされ、ユーザーは世界中に分散しています。このシナリオでドイツのユーザーが観測するレイテンシは、世界中のユーザーが経験する可能性がある内容を示しています。
負荷分散なし
ユーザーが HTTP リクエストを行うと、負荷分散が構成されていない限り、トラフィックはユーザーのネットワークから Compute Engine でホストされている仮想マシン（VM）に直接流れます。プレミアム ティアの場合、トラフィックはユーザーの場所に近いエッジ拠点（PoP）で Google のネットワークに入ります。スタンダード ティアの場合、ユーザー トラフィックは宛先リージョンに近い PoP で Google のネットワークに入ります。詳細については、Network Service Tiers のドキュメントをご覧ください。
次の表は、ドイツのユーザーが負荷分散のないシステムのレイテンシをテストした結果を示しています。
| メソッド | 結果 | 最小レイテンシ |
|---|---|---|
| VM の IP アドレスを ping します（レスポンスはウェブサーバーから直接取得されます）。 |
ping -c 5 compute-engine-vm PING compute-engine-vm (xxx.xxx.xxx.xxx) 56(84) bytes of data. 64 bytes from compute-engine-vm (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=56 time=111 ms 64 bytes from compute-engine-vm (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=56 time=110 ms [...] --- compute-engine-vm ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4004ms rtt min/avg/max/mdev = 110.818/110.944/111.265/0.451 ms |
110 ms |
| TTFB |
for ((i=0; i < 500; i++)); do curl -w /
"%{time_starttransfer}\n" -o /dev/null -s compute-engine-vm; done
0.230 0.230 0.231 0.231 0.230 [...] 0.232 0.231 0.231 |
230 ms |
最初の 500 リクエストの次のグラフが示すように、TTFB レイテンシは安定しています。
VM IP アドレスに ping を実行すると、レスポンスはウェブサーバーから直接返されます。ウェブサーバーからのレスポンス時間は、ネットワーク レイテンシ（TTFB）と比較した場合ごくわずかです。これは、HTTP リクエストごとに新しい TCP 接続が開かれるためです。次の図に示すように、HTTP レスポンスを送信するには、最初に 3 方向の handshake が必要です。そのため、観測するレイテンシは ping のレイテンシの約 2 倍になります。
ネットワーク負荷分散
ネットワーク ロードバランサの場合、ユーザー リクエストは最も近いエッジ PoP（プレミアム ティア）で Google ネットワークに入ります。プロジェクトの VM が配置されているリージョンでは、トラフィックは最初にネットワーク ロードバランサを通過し、変更が加わることなくターゲット バックエンド VM に転送されます。ネットワーク ロードバランサは、安定したハッシュ アルゴリズムに基づいてトラフィックを分散します。このアルゴリズムでは、送信元ポート、宛先ポート、IP アドレス、プロトコルを組み合わせて使用します。VM はロードバランサ IP をリッスンし、変更されていないトラフィックを受け入れます。
次の表は、ドイツのユーザーがネットワーク負荷分散オプションのレイテンシをテストしたときの結果を示しています。
| メソッド | 結果 | 最小レイテンシ |
|---|---|---|
| ネットワーク ロードバランサに ping を実行する |
ping -c 5 net-lb PING net-lb (xxx.xxx.xxx.xxx) 56(84) bytes of data. 64 bytes from net-lb (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=44 time=110 ms 64 bytes from net-lb (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=44 time=110 ms [...] 64 bytes from net-lb (xxx.xxx.xxx.xxx): icmp_seq=5 ttl=44 time=110 ms --- net-lb ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4007ms rtt min/avg/max/mdev = 110.658/110.705/110.756/0.299 ms |
110 ms |
| TTFB |
for ((i=0; i < 500; i++)); do curl -w /
"%{time_starttransfer}\n" -o /dev/null -s net-lb
0.231 0.232 0.230 0.230 0.232 [...] 0.232 0.231 |
230 ms |
負荷分散はリージョン内で行われ、トラフィックが転送されるだけであるため、ロードバランサがない場合と比べてレイテンシに大きな影響はありません。
外部ロード バランシング
HTTP(S) 負荷分散の場合、GFE はトラフィックをプロキシします。これらの GFE は、Google のグローバル ネットワークのエッジにあります。GFE は TCP セッションを終了し、トラフィックを処理できる最も近いリージョンのバックエンドに接続します。
次の表は、ドイツのユーザーが HTTP 負荷分散オプションのレイテンシをテストしたときの結果を示しています。
| メソッド | 結果 | 最小レイテンシ |
|---|---|---|
| HTTP(S) 負荷分散の ping |
ping -c 5 http-lb PING http-lb (xxx.xxx.xxx.xxx) 56(84) bytes of data. 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=56 time=1.22 ms 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=56 time=1.20 ms 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=3 ttl=56 time=1.16 ms 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=4 ttl=56 time=1.17 ms 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=5 ttl=56 time=1.20 ms --- http-lb ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4005ms rtt min/avg/max/mdev = 1.163/1.195/1.229/0.039 ms |
1 ms |
| TTFB |
for ((i=0; i < 500; i++)); do curl -w /
"%{time_starttransfer}\n" -o /dev/null -s http-lb; done
0.309 0.230 0.229 0.233 0.230 [...] 0.123 0.124 0.126 |
123 ms |
HTTP 負荷分散の結果は大きく異なります。HTTP(S) 負荷分散に対して ping を行う場合、ラウンドトリップ レイテンシは 1 ミリ秒をわずかに超えます。この結果は、ユーザーと同じ都市にある、最も近い GFE へのレイテンシを表します。この結果では、us-central1 リージョンでホストされているアプリケーションにアクセスしようとしたときに実際にユーザーが体験するレイテンシが反映されません。ご使用のアプリケーション通信プロトコル（HTTP）と異なるプロトコル（ICMP）を使用した実験によって、誤解を招く可能性があります。
TTFB を測定する場合、最初のリクエストは同様のレスポンス レイテンシを示します。次のグラフに示すように、一部のリクエストは低い最小レイテンシ（123 ミリ秒）を達成しています。
クライアントと VM 間の 2 回のラウンド トリップには、直線的なファイバーであっても 123 ミリ秒を超える時間を要しています。GFE がトラフィックをプロキシするため、レイテンシは短くなります。GFE はバックエンド VM への永続的な接続を維持します。したがって、特定の GFE から特定のバックエンドへの最初のリクエストだけが、3-way handshake を必要とします。
各ロケーションには複数の GFE があります。レイテンシ グラフを見ると、トラフィックが各 GFE とバックエンドのペアに初めて到達するときに、複数の変動するスパイクを確認できます。次に、GFE はそのバックエンドへの新しい接続を確立する必要があります。これらのスパイクは、さまざまなリクエスト ハッシュを反映しています。後続のリクエストでは、レイテンシは短くなります。
これらのシナリオは、本番環境でユーザーが経験する可能性のあるレイテンシの短縮を示しています。次の表に結果をまとめます。
| オプション | Ping | TTFB |
|---|---|---|
| 負荷分散なし | ウェブサーバーに 110 ms | 230 ms |
| ネットワーク負荷分散 | インリージョン ネットワーク ロードバランサに 110 ms | 230 ms |
| HTTP(S) 負荷分散 | 最も近い GFE まで 1 ms | 123 ms |
正常なアプリケーションが特定のリージョンのユーザーにサービスを提供する場合、そのリージョン内の GFE は、すべての処理バックエンドに対して永続的な接続を維持します。このため、ユーザーがアプリケーションのバックエンドから離れている場合、その地域のユーザーは最初の HTTP リクエストのレイテンシが短くなります。ユーザーがアプリケーション バックエンドの近くにいる場合、そのユーザーはレイテンシが改善したことを把握できません。
最新のブラウザはサービスへの永続的な接続を維持しているため、ページリンクのクリックなど、後続のリクエストではレイテンシの改善はありません。これは、コマンドラインから発行される curl コマンドとは異なります。
HTTP(S) 負荷分散のその他のレイテンシ効果
HTTP(S) 負荷分散で観察できる追加の影響は、トラフィック パターンによって異なります。
HTTP(S) ロード バランシングでは、レスポンスが完了する前に必要なラウンド トリップが少ないため、ネットワーク ロード バランシングよりも複雑なアセットのレイテンシが少なくなります。たとえば、ドイツのユーザーが 10 MB のファイルを繰り返しダウンロードして同じ接続のレイテンシを測定した場合、ネットワーク ロード バランシングの平均のレイテンシは 1,911 ミリ秒です。HTTP(S) ロード バランシングでは、平均レイテンシは 1,341 ミリ秒です。そのため、リクエストごとに約 5 回のラウンド トリップが削減されます。GFE とサービス バックエンド間の永続的な接続により、TCP スロースタートの影響が軽減されます。
HTTP(S) ロード バランシングは、TLS handshake によって追加されるレイテンシ（通常、1～2 回の追加ラウンドトリップ）を大幅に削減します。これは、HTTP(S) ロード バランシングで SSL オフロードが使用され、エッジ PoP のレイテンシのみが関連するためです。ドイツのユーザーの場合、観測される最小レイテンシは、HTTP(S) ロード バランシングで 201 ミリ秒、ネットワーク ロード バランシングを介した HTTP(S) で 525 ミリ秒です。
HTTP(S) ロード バランシングを使用すると、ユーザー向けのセッションを HTTP/2 に自動的にアップグレードできます。HTTP/2 では、バイナリ プロトコル、ヘッダー圧縮、接続多重化の改善により、必要なパケット数を減らすことができます。これらの改善により、観測されるレイテンシを、HTTP(S) ロード バランシングに切り替えることで観測されるものよりもさらに短縮できます。HTTP/2 は、SSL / TLS を使用する現在のブラウザでサポートされています。ドイツのユーザーにとって、HTTPS の代わりに HTTP/2 を使用すると、最小レイテンシが 201 ミリ秒から 145 ミリ秒にさらに短縮されました。
HTTP(S) 負荷分散の最適化
外部 HTTP(S) ロードバランサを使用して、アプリケーションのレイテンシを次のように最適化できます。
提供するトラフィックの一部がキャッシュに保存できる場合は、Cloud CDN と統合できます。Cloud CDN は、Google のネットワーク エッジで直接アセットを提供することで、レイテンシを短縮します。Cloud CDN では、HTTP(S) ロード バランシングのその他のレイテンシ効果で説明されている HTTP/2 の TCP 最適化と HTTP 最適化も使用されます。
任意の CDN パートナーを Google Cloud と併用できます。Google の CDN Interconnect パートナーのいずれかを使用することで、下り（外向き）料金の割引を受けることができます。
コンテンツが静的な場合は、HTTP(S) 負荷分散を介して Cloud Storage から直接コンテンツを提供することで、ウェブサーバーの負荷を軽減できます。このオプションは、Cloud CDN と組み合わせて使用します。
ユーザーに近い複数のリージョンにウェブサーバーを配置すると、ロードバランサが自動的に最も近いリージョンにユーザーを誘導するため、レイテンシーを減らすことができます。ただし、アプリケーションの一部が集中管理されている場合は、リージョン間の往復を抑えるようにアプリケーションを設計します。
アプリケーション内のレイテンシを短縮するには、VM 間で通信するすべてのリモート プロシージャ コール（RPC）を調べます。このレイテンシは通常、アプリケーションが階層間またはサービス間で通信する場合に発生します。Cloud Trace などのツールを使用すると、アプリケーションの処理リクエストに起因するレイテンシを短縮できます。
TCP プロキシ負荷分散と SSL プロキシ負荷分散は GFE に基づいているため、レイテンシに及ぼす影響は HTTP(S) 負荷分散で観察されるものと同じになります。HTTP(S) 負荷分散には TCP プロキシ負荷分散や SSL プロキシ負荷分散よりも多くの機能があるため、HTTP(S) トラフィックには HTTP(S) 負荷分散を使用することをおすすめします。
次のステップ
ほとんどのユーザーの近くにアプリケーションをデプロイすることをおすすめします。Google Cloud でのさまざまなロード バランシング オプションの詳細については、次のドキュメントをご覧ください。