Cloud Load Balancing は、ユーザー トラフィックをアプリケーションの複数のインスタンスに分散するメカニズムを備えています。アプリケーション インスタンス全体に負荷を分散し、エンドユーザーに最適なアプリケーション パフォーマンスを実現します。このページでは、ロードバランサがアプリケーション向けに最適化されるようにするためのベスト プラクティスについて説明します。最適なパフォーマンスを確保するために、アプリケーションのトラフィック パターンのベンチマークを行うことをおすすめします。
バックエンドをクライアントの近くに配置する
ユーザーやクライアント アプリケーションがワークロード（ロードバランサのバックエンド）に近いほど、ネットワーク レイテンシは小さくなります。したがって、ユーザーのトラフィックが Google フロントエンドに到着することが想定される場所から最も近いリージョンにロードバランサのバックエンドを作成します。多くの場合、世界各地のクライアントで発生するレイテンシを最小限に抑えるため、複数のリージョンでバックエンドを実行する必要があります。
詳しくは次の記事をご覧ください。
Cloud CDN とキャッシュを有効にする
デフォルトのグローバル外部アプリケーション ロードバランサ構成の一部として、Cloud CDN とキャッシュを有効にします。詳細については、Cloud CDN をご覧ください。
Cloud CDN を有効にしてから、レスポンスがキャッシュに保存されるようになるまでに数分ほどかかることがあります。Cloud CDN がキャッシュに保存するのは、キャッシュに保存可能なコンテンツを含むレスポンスだけです。URL のレスポンスがキャッシュに保存されない場合は、その URL に対して返されたレスポンス ヘッダーと、バックエンドでキャッシュが構成される方法を確認します。詳細については、Cloud CDN のトラブルシューティングをご覧ください。
転送ルール プロトコルの選択
グローバル外部アプリケーション ロードバランサと従来のアプリケーション ロードバランサの場合は、IETF QUIC の上に構築されたインターネット プロトコルである HTTP/3 をおすすめします。HTTP/3 は、すべての主要なブラウザ、Android Cronet、iOS でデフォルトで有効になっています。アプリケーションで HTTP/3 を使用するには、ネットワークで UDP トラフィックがブロックされていないこと、レート制限されていないこと、また、グローバル外部アプリケーション ロードバランサで HTTP/3 が無効になっていないことを確認してください。古いブラウザやネットワーク ライブラリなど、HTTP/3 をまだサポートしていないクライアントに影響を及ぼすことはありません。詳細については、HTTP/3 QUIC をご覧ください。
リージョン外部アプリケーション ロードバランサの場合、HTTP/1.1、HTTPS、HTTP/2 がサポートされています。HTTPS と HTTP/2 の場合は、TLS の設定に事前のオーバーヘッドが必要です。
バックエンド サービス プロトコルの選択
バックエンド プロトコル（HTTP、HTTPS、HTTP/2）の選択は、アプリケーションのレイテンシとアプリケーションで使用可能なネットワーク帯域幅に影響します。たとえば、ロードバランサとバックエンド インスタンス間で HTTP/2 を使用するには、HTTP(S) の場合よりもインスタンスへの TCP 接続数を大幅に増やす必要があります。HTTP/2 では、HTTP(S) による接続数を減らすための最適化を提供する接続プールは使用できません。その結果、バックエンド接続がより頻繁に行われるため、バックエンドのレイテンシが高くなる可能性があります。
バックエンド サービス プロトコルは、転送中のトラフィックの暗号化方法にも影響します。外部 HTTP(S) ロードバランサを使用すると、Google Cloud VPC ネットワーク内のバックエンドに送信されるトラフィックはすべて自動的に暗号化されます。これをネットワーク レベルの自動暗号化と呼びます。ただし、ネットワーク レベルの自動暗号化は、インスタンス グループとゾーン NEG バックエンドとの通信にのみ使用できます。他のすべてのバックエンド タイプでは、HTTPS や HTTP/2 などの安全なプロトコル オプションを使用してバックエンド サービスとの通信を暗号化することをおすすめします。詳細については、ロードバランサからバックエンドへの暗号化をご覧ください。
推奨の接続時間
ネットワーク条件が変化して、バックエンドのセットが負荷に応じて変わる可能性があります。1 つのサービスに多くのトラフィックを生成するアプリケーションの場合、長時間実行される接続が常に最適な設定になるとは限りません。バックエンドへの単一の接続を無期限に使用するのではなく、最大接続存続時間（例えば 10 ～ 20 分）または最大リクエスト数（例えば 1,000 ～ 2,000 リクエスト）後に、新しいリクエストに新しい接続が使用されます。古い接続は、その接続を使用するアクティブなリクエストがすべて終了すると、切断されます。
これにより、クライアント アプリケーションはバックエンドの一連の変更（ロードバランサのプロキシや、クライアントへのサービス提供に必要なネットワーク最適化など）を利用できます。
バランシング モードの選択基準
パフォーマンスを向上させるには、新しいリクエストごとに最も応答性の高いバックエンドに基づいてバックエンド グループを選択します。これは、RATE バランシング モードを使用することで実現できます。この場合、最近のリクエストの平均レイテンシが最も低いバックエンド グループが選択されます。HTTP/2 と HTTP/3 の場合は、未処理のリクエストが最も少ないバックエンド グループが選択されます。
UTILIZATION バランシング モードはインスタンス グループ バックエンドにのみ適用され、インスタンス グループ内の VM インスタンスの使用率に基づいてトラフィックを分散します。
セッション アフィニティを構成する
同じエンドユーザーからのリクエストや同じエンドユーザーに関連するリクエストが、少なくとも短期間、同じバックエンドで処理されたほうが良い場合があります。これは、バックエンド サービスの設定であるセッション アフィニティを使用すると構成できます。セッション アフィニティは、クライアントからロードバランサのバックエンドへの新しい接続の分散を制御します。セッション アフィニティを使用すると、同じリソース（たとえば、同じユーザー アカウントや同じドキュメント）からのリクエストを同じバックエンドで処理できます。
セッション アフィニティは、バックエンドごとではなく、バックエンド サービス リソース全体に対して指定されます。ただし、URL マップは複数のバックエンド サービスを参照する場合があります。したがって、ロードバランサに 1 つのセッション アフィニティ タイプのみを使用する必要はありません。アプリケーションによっては、セッション アフィニティの設定が異なるバックエンド サービスを使用できます。たとえば、アプリケーションの一部が多くのユーザーに静的コンテンツを提供している場合、セッション アフィニティを使用するメリットはありません。その場合は Cloud CDN 対応のバックエンド サービスを使用して、キャッシュに保存されたレスポンスを処理します。
詳細については、セッション アフィニティをご覧ください。