負荷分散のオプション
アプリケーションに送信されるトラフィックの種類に応じて、負荷分散のオプションがいくつかあります。次の表に、オプションをまとめます。
| オプション | 説明 | トラフィック フロー | 範囲 |
|---|---|---|---|
| HTTP、HTTPS、TCP、および SSL 負荷分散 | HTTP(S) トラフィック、URL マッピングや SSL オフロードなどの高度な機能をサポートしています。 特定のポート上の HTTP 以外のトラフィックに対する TCP プロキシまたは SSL プロキシをサポートします。 |
TCP または SSL（TLS）セッションは、Google ネットワーク エッジの Google Front End（GFE）で終了し、トラフィックはバックエンドにプロキシされます。 | グローバル |
| ネットワーク負荷分散 | 任意のポートを使用して TCP/UDP トラフィックがロードバランサを通過するようにします。 | Google の Maglev テクノロジーを使用して提供され、バックエンドにトラフィックを配信します。 | リージョン |
内部ロードバランサはユーザー向けのトラフィックをサポートしていないため、この記事の対象外です。
グローバル負荷分散はこのサービス層を使用してのみ利用できるため、この記事のすべての測定はプレミアム ネットワーク サービス層を使用して実行されました。
レイテンシの測定
us-central1 でホストされているウェブサイトにアクセスする際に、あるドイツのユーザーが次の方法を使用してレイテンシをテストしました。
- Ping: これはサーバーの到達可能性を測定する一般的な方法ですが、ICMP ping はエンドユーザーのレイテンシを正確に示すものではありません。詳細については、HTTP(S) 負荷分散のその他のレイテンシ効果をご覧ください。
- Time To First Byte（TTFB）: 最初の HTTP レスポンスまでの時間を測定する良い方法は、サーバーに
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 負荷分散または 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-way handshake が必要なためです。したがって、ドイツのユーザーが観測するレイテンシは、ping のレイテンシの約 2 倍です。
ネットワーク負荷分散
ネットワーク ロードバランサの場合、ユーザー リクエストは最も近いエッジ POP（プレミアム ティア）で Google ネットワークに入ります。プロジェクトの VM が配置されているリージョンでは、トラフィックは最初に Maglev ロードバランサを通過し、変更が加わることなくターゲット バックエンド VM に転送されます。Maglev ロードバランサは、安定したハッシュ アルゴリズムに基づいてトラフィックを分散します。このアルゴリズムでは、送信元ポート、宛先ポート、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 |
負荷分散がリージョン内で行われ、トラフィックが転送されるだけなので、no-load-balancer オプションと比べてレイテンシに大きな影響はありません。
HTTP(S) / TCP / SSL プロキシの負荷分散
HTTP 負荷分散を使用すると、通常は Google のグローバル ネットワークのエッジに位置する GFE 経由でトラフィックがプロキシされます。GFE は TCP セッションを終了し、トラフィックを処理する容量を持つ最も近いリージョンのバックエンドに接続します。
次の表は、ドイツのユーザーが HTTP 負荷分散オプションのレイテンシをテストしたときの結果を示しています。
| メソッド | 結果 | 最小レイテンシ |
|---|---|---|
| HTTP ロードバランサに 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 ロードバランサに ping を実行する場合、ラウンドトリップ レイテンシは 1 ミリ秒を少し超えます。ただしこの結果は、このケースのユーザーと同じ都市にある最も近い GFE までのレイテンシを表します。この結果は、us- central1 リージョンでホストされているアプリケーションにアクセスしようとしたときに実際に発生するレイテンシとは関係ありません。これは、ご使用のアプリケーション通信プロトコル（HTTP）と異なるプロトコル（ICMP）を使用した実験が誤解を招く可能性があることを示しています。
TTFB を測定する場合、最初のリクエストは、ほぼ同じレスポンス レイテンシを示します。次のグラフに示すように、リクエストの過程で、追加のリクエストでは最小レイテンシが 123 ミリ秒に短縮されます。
しかしながら、クライアントと VM の間の 2 回のラウンドトリップは、完全に直線的なファイバーであっても 123 ミリ秒以上かかることが予想されます。レイテンシが短くなるのは、トラフィックが GFE によってプロキシされるため、バックエンド VM への永続的な接続が維持されるからです。したがって、特定の GFE から特定のバックエンドへの最初のリクエストだけが、3-way handshake を必要とします。
それぞれの場所に複数の GFE があります。レイテンシ グラフを見ると、トラフィックが各 GFE とバックエンドのペアに初めて到達するときの早い段階で、複数の変動するスパイクを確認できます。これは、異なるリクエスト ハッシュを反映しています。すべての GFE が到達した後は、後続のリクエストではレイテンシが短くなります。
これらのシナリオは、本番環境でユーザーが経験する可能性のあるレイテンシの短縮を示しています。次の表に結果をまとめます。
| オプション | Ping | TTFB |
|---|---|---|
| 負荷分散なし | ウェブサーバーに 110 ms | 230 ms |
| ネットワーク負荷分散 | インリージョン ネットワーク ロードバランサに 110 ms | 230 ms |
| HTTP 負荷分散 | 最も近い GFE まで 1 ms | 123 ms |
健全なアプリケーションが特定のリージョンのユーザーに定期的にサービスを提供している場合、そのリージョンのすべての GFE は、通常、すべてのサービス バックエンドに対して持続的な接続を開く必要があります。したがって、そのリージョンのユーザーは、アプリケーションのバックエンドから遠い場合、最初の HTTP リクエストのレイテンシが大幅に短縮されます。ユーザーがアプリケーションのバックエンドに近い場合、近接しているためにレイテンシの改善は見られません。
ページリンクのクリックなどの後続のリクエストでは、コマンドラインから発行された curl コマンドとは異なり、最新のブラウザは再利用するサービスへの永続的な接続をすでに保持しているため、レイテンシの改善は見られません。
HTTP(S) 負荷分散のその他のレイテンシ効果
トラフィック パターンに依存する HTTP(S) 負荷分散には、他にもいくつかの影響が観察されます。
HTTP(S) 負荷分散では、レスポンスが完了する前に必要なラウンドトリップが少ないため、ネットワーク負荷分散よりも複雑なアセットのレイテンシが少なくなります。たとえば、ドイツのユーザーが 10 MB のファイルを繰り返しダウンロードして同じ接続でレイテンシを測定した場合、ネットワーク負荷分散の平均レイテンシは 1,911 ミリ秒でしたが、HTTP 負荷分散では 1,341 ミリ秒で、リクエストごとに約 5 回のラウンドトリップを節約できました。これは、GFE とサービス バックエンドの間の永続的な接続によって TCP Slow Start の効果が低下するためです。
HTTP(S) 負荷分散は、TLS handshake によって追加されるレイテンシ（通常、1～2 回の追加ラウンドトリップ）を大幅に削減します。この短縮は、HTTP(S) が SSL オフロードを使用し、エッジ POP へのレイテンシのみ関連するためです。ドイツのユーザーの場合、観察される最小レイテンシは、HTTP(S) 負荷分散を使用した場合は 201 ミリ秒であるのに対し、ネットワーク ロードバランサを介した HTTP(S) を使用した場合は 525 ミリ秒です。
また、HTTP(S) ロードバランサを使用すると、ユーザー向けのセッションを HTTP/2 に自動的にアップグレードできるため、バイナリ プロトコル、ヘッダー圧縮、接続多重化が改善されるので必要なパケット数を削減できます。これにより、HTTP 負荷分散だけに切り替えることで観測されたレイテンシよりも、観察されるレイテンシがさらに短縮される可能性があります。HTTP/2 は、SSL/TLS を使用している現在のブラウザと組み合わせて使用されます。ドイツのユーザーにとって、通常の HTTPS の代わりに HTTP/2 を使用すると、最小レイテンシが 201 ミリ秒から 145 ミリ秒にさらに短縮されました。
HTTP(S) 負荷分散の最適化
次のように、HTTP(S) ロードバランサを使用して、アプリケーションのレイテンシを最適化できます。
提供するトラフィックの一部をキャッシュに保存できる場合は、Google Cloud CDN と統合できます。Cloud CDN は、Google のネットワーク エッジで直接アセットを提供することで、レイテンシを短縮します。Cloud CDN では、HTTP(S) 負荷分散のその他のレイテンシ効果で説明されている HTTP/2 の TCP 最適化と HTTP 最適化も使用されます。
任意の CDN のパートナーを GCP と併用できます。Google の CDN Interconnect パートナーの 1 つを使用することで、下り（外向き）コストの割引のメリットが得られます。
コンテンツが静的な場合、HTTP/S ロードバランサ経由で Google Cloud Storage から直接コンテンツを配信することで、ウェブサーバーの負荷を軽減できます。このオプションは、前述の CDN オプションとシームレスに結合します。
HTTP(S)、SSL プロキシ、TCP プロキシの負荷分散により、ユーザーは自動的に最も近いリージョンに誘導されるため、ユーザーに近い複数のリージョンにウェブサーバーを配置することで、レイテンシを短縮できます。ただし、アプリケーションの一部が集中管理されている場合は、リージョン間の往復を最小限に抑えるようにアプリケーションを設計します。
アプリケーション内のレイテンシを短縮するには、VM 間で通信するすべてのリモート プロシージャ コール（RPC）を調べます。このレイテンシは通常、アプリケーションが階層間またはサービス間で通信する場合に発生します。Stackdriver Trace などのツールを使用すると、アプリケーションの処理リクエストによって生じるレイテンシを最小限に抑えることができます。
TCP プロキシと SSL プロキシも GFE に基づいているため、レイテンシに与える影響は HTTP 負荷分散と同じです。HTTP(S) 負荷分散には TCP/ SSL プロキシよりも多くの機能が含まれるため、常に HTTP(S) トラフィック向けの HTTP(S) 負荷分散を使用することを推奨します。
次のステップ
大多数のユーザーの近くにアプリケーションをデプロイし、使用に最適な構成を選択することをおすすめします。GCP のさまざまな負荷分散オプションの詳細については、次のドキュメントをご覧ください。