HTTP(S) 負荷分散の設定

このドキュメントは、HTTP(S) ロードバランサの設定の最初の手順です。このチュートリアルを始める前に、HTTP(S) 負荷分散のコンセプトについて十分に理解しておいてください。

Google Cloud Platform(GCP)の HTTP(S) 負荷分散は、インスタンスの HTTP(S) リクエストに対してグローバルな負荷分散を提供します。

グローバル負荷分散では、Network Service Tiers のうちプレミアム階層を使用する必要があります。

あるセットのインスタンスに一部の URL をルーティングし、別のインスタンスには別の URL をルーティングする URL ルールを構成できます。グループに十分な容量があり、リクエストに適している場合は、リクエストは常にユーザーに最も近いインスタンス グループに転送されます。最も近いグループに十分な容量がない場合、リクエストは十分な容量がある最も近いグループに送信されます。

HTTP(S) 負荷分散は、IPv4 アドレスと IPv6 アドレスのクライアント トラフィックに対応しています。クライアントの IPv6 リクエストは負荷分散層で終了し、IPv4 経由でバックエンドにプロキシされます。

HTTP リクエストは、ポート 80 またはポート 8080 に基づいて負荷分散を行えます。 HTTPS リクエストはポート 443 で負荷分散を行えます。

ロードバランサは HTTP/2 から HTTP/1.1 への変換層として機能します。これは、ウェブサーバーが HTTP/1.1 リクエストを常に確認し、これにレスポンスするが、ブラウザからのリクエストは、HTTP/1.0、HTTP/1.1、HTTP/2 のいずれかとなることを意味します。HTTP/2 サーバー push はサポートされていません。

始める前に

HTTP(S) 負荷分散はインスタンス グループを使用してインスタンスを分類します。負荷分散を使用する前にインスタンス グループについて理解しておく必要があります。

構成の例

早速、テスト用の実行ロードバランサを構築する場合、次の図により、HTTP ロードバランス サービスを使用した 3 つの異なるシナリオが示されます。これらのシナリオには HTTP(S) 負荷分散の実用的なコンテキストが用意され、特定のニーズに適合する負荷分散をセットアップする方法が示されます。

ロードバランサの構成と動作について詳しく説明します。

クロスリージョン負荷分散

クロスリージョン負荷分散の図

グローバル IP アドレスを使用することで、近い距離にいるユーザーにトラフィックがインテリジェントにルーティングされるようになります。たとえば、アジア、北米、欧州に十分な容量を持つインスタンスを設定しておけば、世界中のどのユーザーも、それぞれに最も近いバックエンドで自動的にトラフィックを受信できます。最も近いインスタンスに十分な容量がない場合は、リージョン間負荷分散によって、次に最も近いリージョンにトラフィックが転送されます。


コンテンツ ベースの負荷分散

コンテンツ ベースの負荷分散の図

コンテンツ ベースまたはコンテンツ対応の負荷分散では、HTTP(S) 負荷分散を使用して HTTP(S) URL ごとに異なるインスタンスにトラフィックを分散します。たとえば、動画コンテンツを処理するインスタンスと、それ以外の処理を行うインスタンスを設定できます。ロードバランサを設定して、example.com/video のトラフィックを動画サーバー、example.com/ のトラフィックをデフォルトのサーバーにそれぞれ振り分けることができます。

HTTP(S) 負荷分散は、Google Cloud Storage バケットにも使用できます。ロードバランサを設定したら、Cloud Storage バケットを追加できます。


統合されたロードバランサの作成

コンテンツ ベースの負荷分散とクロスリージョン負荷分散の表現

複数のバックエンド サービスとリージョンを使用することで、コンテンツ ベースの負荷分散とリージョン間負荷分散を相互に連携して利用できます。上記のシナリオとは別に、個々のニーズに適した負荷分散を構成できます。HTTP(S) 負荷分散のチュートリアルでは、コンテンツ ベースであると同時にクロスリージョンでもある負荷分散構成を生成する方法を説明します。


インターフェース

HTTP(S) 負荷分散サービスは、次のインターフェースを通じて構成および更新できます。

  • gcloud コマンドライン ツール: Cloud SDK に含まれているコマンドライン ツール。HTTP(S) 負荷分散のドキュメントでは、タスクの実行時にこのツールをよく利用します。ツールの完全な概要については、gcloud ツールガイドをご覧ください。負荷分散に関連するコマンドは、gcloud compute コマンド グループにあります。

    --help フラグを使用して、gcloud コマンドの詳細なヘルプを入手することもできます。

    gcloud compute http-health-checks create --help
    
  • Google Cloud Platform Console: 負荷分散タスクは、Google Cloud Platform Console から実行できます。

  • REST API: 負荷分散タスクはすべて、Google Cloud Load Balancing API を使用して実行できます。API リファレンス ドキュメントでは、使用できるリソースとメソッドについて説明しています。

注意点と制限事項

  • HTTP(S) 負荷分散は、HTTP/1.1 100 Continue レスポンスをサポートしています。
  • 負荷分散インスタンスが Google Cloud Platform から提供される公開オペレーティング システム イメージを実行している場合、オペレーティング システムのファイアウォール ルールは負荷分散トラフィックを許可するように自動的に設定されます。 カスタム イメージを使用している場合は、オペレーティング システムのファイアウォールを手動で構成する必要があります。このことは、HTTP(S) ロードバランサ構成の一環として作成する必要がある GCP ファイアウォール ルールとは別のものです。
  • 負荷分散ではインスタンスの同期が維持されません。Deployment Manager などを使用して独自のメカニズムをセットアップし、インスタンスに一貫した構成とデータを持たせるようにする必要があります。

トラブルシューティング

負荷分散されたトラフィックに元のクライアントのソースアドレスが含まれていない

ロードバランサからインスタンスへのトラフィックは、130.211.0.0/2235.191.0.0/16 の範囲の IP アドレスを持っています。負荷分散インスタンスのログを見ても、元のクライアントの送信元アドレスは記録されていません。この範囲の送信元アドレスが記録されます。

自分の Cloud Storage バケットでオブジェクトを表示すると権限エラーが発生する

負荷分散を通じてオブジェクトを提供するには、Cloud Storage オブジェクトが一般公開されている必要があります。一般読み取り可能になるように、提供するオブジェクトの権限を更新してください。

URL から予期した Cloud Storage オブジェクトが提供されない

提供される Cloud Storage オブジェクトは、URL マップとリクエストした URL に基づいて決まります。URL マップでリクエストパスがバックエンド バケットにマッピングしている場合、URL マップで指定されている Cloud Storage バケットにリクエストのフルパスが追加され、Cloud Storage オブジェクトが決まります。

たとえば、/static/*gs://[EXAMPLE_BUCKET] にマッピングしている場合、https://<GCLB IP or Host>/static/path/to/content.jpg へのリクエストにより gs://[EXAMPLE_BUCKET]/static/path/to/content.jpg の処理が試みられます。そのオブジェクトが存在しない場合は、オブジェクトの代わりに次のエラー メッセージが返されます。


NoSuchKey
The specified key does not exist.

圧縮が機能しない

HTTP(S) 負荷分散ではレスポンスそのものは圧縮や解凍はされませんが、gzipDEFLATE などのツールを使用して圧縮されたバックエンド サービスで生成されたレスポンスを処理させることはできます。

HTTP(S) 負荷分散で配信されるレスポンスが圧縮されるべきであるものの、圧縮されていない場合は、レスポンスの圧縮がインスタンス上のウェブサーバー ソフトウェアで実行されていることを確認します。デフォルトでは、一部のウェブサーバー ソフトウェアは、ヘッダー Via を含むリクエストの圧縮を自動的に無効にします。このヘッダーはリクエストがプロキシによって転送されたことを示します。HTTP(S) 負荷分散はプロキシであるため、HTTP の仕様の要求に従って Via ヘッダーがリクエストごとに追加されます。圧縮を有効にするには、ウェブサーバーのデフォルトの構成を変更し、リクエストに Via ヘッダーがある場合でもレスポンスを圧縮するように設定します。

nginx ウェブサーバー ソフトウェアを使用している場合は、nginx.conf 構成ファイルを変更して圧縮を有効にします。このファイルの場所は、nginx をインストールした場所によって異なります。多くの Linux ディストリビューションでは、このファイルは /etc/nginx/nginx.conf に保存されています。nginx 圧縮が HTTP(S) 負荷分散で機能するようにするには、nginx.conf の http セクションに次の 2 行を追加します。

gzip_proxied any;
gzip_vary on;

最初の行を追加すると、HTTP(S) 負荷分散などのプロキシから転送されたリクエストでも圧縮が有効になります。2 番目の行により、レスポンスに Vary: Accept-Encoding ヘッダーが追加されます。Vary: Accept-Encoding は、圧縮可能なリソースの圧縮バリアントと非圧縮バリアントに別々のキャッシュ エントリを維持するように、Cloud CDN などのキャッシュ プロキシに通知します。

nginx.conf を変更した後で新しい設定を使用するには、nginx を再起動する必要があります。多くの Linux ディストリビューションでは、sudo service nginx restart または /etc/init.d/nginx restart を実行して nginx を再起動します。

バックエンドに接続する HTTP/2 に関する問題のトラブルシューティング

フィールド resource.loadBalancingScheme の値が無効: 'EXTERNAL'

バックエンド サービスベースのネットワーク負荷分散は、まだサポートされていません。

この問題は、グローバル オプションを選択せずにバックエンド サービスを作成した場合に発生します。次のように gcloud コマンドを発行した場合、リージョンを指定するか、ロードバランサをグローバルとして指定するように求めるメッセージが表示されます。

gcloud beta compute backend-services create service-test \
    --health-checks=hc-test \
    --project=test1 \
    --protocol=http2

次のバックエンド サービスの場合:

- [service-test] choose a region or global:
[1] global
[2] region: [REGION_A_NAME]
[3] region: [REGION_B_NAME]
....
Please enter your numeric choice:

HTTP(S) ロードバランサの場合、バックエンド サービスはグローバルである必要があります。オプション 1 を選択するか、gcloud コマンドを --global オプションで発行してください。

gcloud beta compute backend-services create service-test \
    --health-checks=hc-test \
    --project=test \
    --protocol=http2 \
    --global

原因不明な 502 エラー

バックエンド インスタンスが正常で、HTTP/2 プロトコルをサポートしていることを確認します。 これを確認するには、HTTP/2 を使用してバックエンド インスタンスへの接続をテストします。VM が HTTP/2 仕様準拠の暗号スイートを使用していることを確認します。たとえば、特定の TLS 1.2 暗号スイートは HTTP/2 では使用できません。TLS 1.2 暗号スイートのブラックリストをご覧ください。

VM が HTTP/2 プロトコルを使用していることを確認したら、ファイアウォールの設定でヘルスチェッカーとロードバランサが通過できることを確認します。

ファイアウォールの設定に問題がない場合は、VM の正しいポートに接続するようにロードバランサを設定します。

HTTP/2 の制限事項

  • ロードバランサとインスタンスの間の接続に HTTP/2 を使用する場合は、HTTP(S) の場合よりもインスタンスへの TCP 接続数を大幅に増やす必要があります。HTTP/2 では、HTTP(S) などでの接続数を減らすための最適化を提供する接続プールは現在のところ使用できません。
  • ロードバランサとバックエンドの間の HTTP/2 では、以下はサポートされていません。
    • サーバー push
    • WebSocket

次のステップ