負荷分散によるアプリケーション レイテンシの最適化

このドキュメントでは、負荷分散のオプションについて説明し、Google Cloud Platform(GCP)上で特定のロードバランサを選択することで、どのような影響がエンドツーエンドのレイテンシに及ぶかについて示します。

負荷分散のオプション

アプリケーションに送信されるトラフィックの種類に応じて、負荷分散のオプションがいくつかあります。次の表に、オプションをまとめます。

オプション 説明 トラフィック フロー 範囲
HTTP、HTTPS、TCP、および SSL 負荷分散 HTTP(S) トラフィックと、URL マッピングや SSL オフロードなどの高度な機能を提供します。
特定のポート上の HTTP 以外のトラフィックに対する TCP プロキシまたは SSL プロキシをサポートします。
TCP または SSL(TLS)セッションは、Google のネットワーク エッジにおける Google フロントエンド(GFE)で終了し、トラフィックはバックエンドにプロキシされます。 グローバル
ネットワーク負荷分散 任意のポートを経由する TCP/UDP トラフィックがロードバランサを通過できるようにします。 Google の Maglev テクノロジーを使用して提供され、バックエンドにトラフィックを配信します。 リージョン

内部ロードバランサはユーザー向けのトラフィックをサポートしていないため、この記事の対象外です。

グローバル負荷分散はこのサービス層を使用してのみ利用できるため、この記事のすべての測定はプレミアム ネットワーク サービス層を使用して実行されました。

レイテンシの測定

us-central1 でホストされているウェブサイトにアクセスする際に、あるドイツのユーザーが次の方法を使用してレイテンシをテストしました。

結果を比較する際には、ファイバー リンク上のレイテンシは、主に距離とファイバー内の光の速度(約 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 リクエストを行うと、トラフィックはユーザーのネットワークから Google Compute Engine でホストされている仮想マシン(VM)に直接流れます。トラフィックは、ユーザーのロケーションに近いエッジポイント(POP)で Google のネットワークに入ります。

負荷分散なしのアーキテクチャ

次の表は、ドイツのユーザーが負荷分散のないシステムのレイテンシをテストした結果を示しています。

メソッド 結果 最小レイテンシ
VM の IP アドレスを ping します(レスポンスはウェブサーバーから直接取得されます)。

[user@germany ~]$ ping -c 5 gce-vm
PING gce-vm (xxx.xxx.xxx.xxx) 56(84) bytes of data.
64 bytes from gce-vm (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=56 time=111 ms
64 bytes from gce-vm (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=56 time=110 ms
[...]
--- gce-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

[user@germany ~]$ for ((i=0;i<500;i++)); do curl -w  /
    "%{time_total}\n" -o /dev/null -s gce-vm; done
0.230
0.230
0.231
0.231
0.230
[...]
0.232
0.231
0.231
l10n-attrs-original-order="do,curl,-w,-o,-s,done">
230 ms

最初の 500 リクエストの次のグラフが示すように、TTFB レイテンシは非常に安定しています。

VM へのレイテンシ(ms)のグラフ

VM IP アドレスに ping を実行すると、レスポンスはウェブサーバーから直接取得されます。ネットワーク レイテンシ(TTFB)と比較して、ウェブサーバーは最小限の時間しか消費しません。この違いは、次の図に示すように、HTTP リクエストごとに新しい TCP 接続が開かれ、HTTP レスポンスが送信される前に最初の 3 方向のハンドシェイクが必要なためです。したがって、ドイツのユーザーが観測するレイテンシは、ping のレイテンシの約 2 倍です。

クライアント/サーバーの HTTP リクエスト図

ネットワーク負荷分散

ネットワーク ロード バランサを使用すると、ユーザー リクエストは引き続き最寄りのエッジ POP で Google ネットワークに入ります。プロジェクトの VM が配置されているリージョンでは、トラフィックは最初に Maglev ロードバランサを通過し、変更が加わることなくターゲット バックエンド VM に転送されます。Maglev ロードバランサは、送信元ポートと送信先ポート、IP アドレス、プロトコルの組み合わせを使用する安定したハッシュ アルゴリズムに基づいてトラフィックを配信します。VM はロードバランサ IP をリッスンし、変更されていないトラフィックを受け入れます。

ネットワーク負荷分散を備えたアーキテクチャ

次の表は、ドイツのユーザーがネットワーク負荷分散オプションのレイテンシをテストしたときの結果を示しています。

メソッド 結果 最小レイテンシ
ネットワーク ロードバランサに ping を実行する

[user@germany ~]$ 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

[user@germany ~]$ for ((i=0;i<500;i++)); do curl -w /
    "%{time_total}\n" -o /dev/null -s net-lb
0.231
0.232
0.230
0.230
0.232
[...]
0.232
0.231
l10n-attrs-original-order="do,curl,-w,-o,-s,net-lb">
230 ms

負荷分散はインリージョンで発生し、トラフィックは単に転送されるだけなので、no-load-balancer オプションと比較してレイテンシに大きな影響はありません。

HTTP(S) / TCP / SSL プロキシの負荷分散

HTTP 負荷分散を使用すると、通常は Google のグローバル ネットワークのエッジに位置する GFE 経由でトラフィックがプロキシされます。GFE は TCP セッションを終了し、トラフィックを処理する容量を持つ最も近いリージョンのバックエンドに接続します。

HTTP 負荷分散のシナリオ図

次の表は、ドイツのユーザーが HTTP 負荷分散オプションのレイテンシをテストしたときの結果を示しています。

メソッド 結果 最小レイテンシ
HTTP ロードバランサに ping を実行する

[user@germany ~]$ $ 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

[user@germany ~]$ for ((i=0;i<500;i++)); do curl -w /
    "%{time_total}\n" -o /dev/null -s http-lb; done
0.309
0.230
0.229
0.233
0.230
[...]
0.123
0.124
0.126
l10n-attrs-original-order="do,curl,-w,-o,-s,done">
123 ms

HTTP 負荷分散の結果は大きく異なります。HTTP ロードバランサに ping を実行すると、ラウンドトリップ レイテンシは 1 ミリ秒をわずかに上回ります。ただし、この結果は、最も近い GFE へのレイテンシを表します。この例では、GFE はユーザーと同じ都市に位置します。この結果は、us- central1 リージョンでホストされているアプリケーションにユーザーがアクセスしようとしたときに実際に発生するレイテンシとは関係ありません。これは、ご使用のアプリケーション通信プロトコル(HTTP)と異なるプロトコル(ICMP)を使用した実験が誤解を招く可能性があることを示しています。

TTFB を測定する場合、最初のリクエストは、ほぼ同じレスポンス レイテンシを示します。次のグラフに示すように、リクエストの過程で、追加のリクエストでは最小レイテンシが 123 ミリ秒に短縮されます。

HTTP ロードバランサへのレイテンシ(ms)のグラフ

しかしながら、クライアントと VM の間の 2 回のラウンドトリップは、完全に直線的なファイバーであっても 123 ミリ秒以上かかることが予想されます。レイテンシが短くなるのは、トラフィックが GFE によってプロキシされるため、バックエンド VM への永続的な接続が維持されるからです。したがって、特定の GFE から特定のバックエンドへの最初のリクエストだけが、3 方向のハンドシェイクを必要とします。

GFE による初期 HTTP リクエストの図

それぞれの場所に複数の GFE があります。レイテンシ グラフには、異なるリクエスト ハッシュを反映して、トラフィックが最初に各 GFE バックエンド ペアに到達すると早い段階で変動するスパイクが数多く表示されます。すべての GFE が到達した後は、後続のリクエストではレイテンシが短くなります。

GFE による後続の HTTP リクエストの図

これらのシナリオは、本番環境でユーザーが経験する可能性のあるレイテンシの短縮を示しています。次の表に結果をまとめます。

オプション 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) 負荷分散は HTTP ネットワーク負荷分散よりも複雑なアセットのレイテンシが短くなります。たとえば、ドイツのユーザーが同じ接続を使用して 10 MB のファイルを繰り返しダウンロードしてレイテンシを測定した場合、ネットワーク負荷分散の平均レイテンシは 1911 ミリ秒(HTTP 負荷分散の場合は 1341 ミリ秒)でした。これは、リクエストあたり約 5 回の往復が節約されたことになります。この短縮は、GFE とサービスを提供するバックエンド間の永続的な接続において、TCP Slow Start の影響が軽減されるためです。

  • HTTP(S) 負荷分散は、TLS ハンドシェイクによって追加されるレイテンシ(通常、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 と統合できます。クラウド CDN は、Google のネットワーク エッジで直接アセットを配信することでレイテンシを削減します。Cloud CDN は、HTTP(S) 負荷分散のその他のレイテンシ効果で説明した TCP と HTTP の最適化(HTTP/2)も利用します。

  • 任意の 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 でアプリケーションを設計する場合、大部分のユーザーに近接するようにアプリケーションをデプロイし、使用に最適な構成を選択することをおすすめします。GCP での負荷分散のさまざまな機能について詳しくは、次のページを参照してください。

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Compute Engine ドキュメント