このページでは、グローバル外部アプリケーション ロードバランサと従来のアプリケーション ロードバランサの違いの概要について説明します。
グローバル外部アプリケーション ロードバランサの高度なトラフィック管理機能を使用するには、従来のアプリケーション ロードバランサのリソースをグローバル外部アプリケーション ロードバランサ インフラストラクチャに移行します。このドキュメントでは、従来のアプリケーション ロードバランサの既存のリソースをグローバル外部アプリケーション ロードバランサに移行する方法についても詳しく説明します。
従来のアプリケーション ロードバランサとグローバル外部アプリケーション ロードバランサを比較する
リソースを移行する前に、従来のアプリケーション ロードバランサとグローバル外部アプリケーション ロードバランサの違いを理解してください。
機能の違い
次の機能は、グローバル外部アプリケーション ロードバランサではサポートされていません。これらは、従来のアプリケーション ロードバランサでのみ使用できます。
- スタンダード ネットワーク ティア
-
GKE クラスタにグローバル外部アプリケーション ロードバランサをデプロイするには、代わりに GKE Gateway Controller を使用します。設定手順については、ゲートウェイのデプロイをご覧ください。
データプレーンの違い
次の表に、従来のアプリケーション ロードバランサとグローバル外部アプリケーション ロードバランサのデータプレーンの違いを示します。これらの違いは、ロードバランサが一部の一般的なイベントに応答する方法に影響します。
イベント | 従来のアプリケーション ロードバランサのレスポンス | グローバル外部アプリケーション ロードバランサのレスポンス |
ステータス / エラーコード | ||
すべてのバックエンドが正常ではありません | HTTP 502 を返す | HTTP 503 を返す |
リクエストで禁止された SSL 暗号が使用されている | HTTP 502 を返す | HTTP 503 を返す |
バックエンドによって早期アップストリーム接続がリセットされる | HTTP 502 を返す | HTTP 503 を返す |
接続アップグレードの失敗(例: WebSocket へのアップグレード中) | HTTP 400 を返す | HTTP 403 を返す |
ヘッダーが大きすぎる | HTTP 413 を返す | HTTP 431 を返す |
割り当てと上限 | ||
URL マップの構成 | URL マップの構成の上限は、2 つのロードバランサ間で大きく異なります。詳細については、割り当て: URL マップのドキュメントをご覧ください。 | |
ヘッダー処理 | ||
リクエストで、本文のないカスタム HTTP メソッドを使用する | バックエンドに送信されるリクエストに Transfer Encoding: Chunked ヘッダーを追加する |
バックエンドに送信されるリクエストに Content-Length: 0 ヘッダーを追加する |
バックエンドに送信されるリクエストに追加された X-Forwarded-For ヘッダーの形式 |
IP 間の区切り文字に , を使用する |
IP 間の区切り文字に「, 」を使用する(カンマの後にスペースなし) |
ヘッダーケースの保持 | ヘッダーのケースが保持される | すべてのヘッダーキーが小文字に変換される |
同じ名前のヘッダーの繰り返し | 許可 | RFC 7230 で許可されているように、同じ名前のヘッダーは値をカンマで区切ってつなげることで 1 つのヘッダーに結合できます。 |
(HTTP/1.1 のみ)無効なヘッダー名(例: ヘッダーでサポートされていない文字が含まれている) | 許可(HTTP/1.1 の場合) | HTTP 502 を返す(HTTP/1.1 の場合) |
(HTTP/1.1 のみ)リクエストに Content-Length ヘッダーが繰り返されている(ただし同じ) |
許可(HTTP/1.1 の場合) | HTTP 502 を返す(HTTP/1.1 の場合) |
(HTTP/1.1 のみ)ヘッダー内の複数のホスト | 2 つ以上のホストが追加され、最初のホストが有効な場合、ヘッダーは受け入れられます。 | 複数のホストが追加され、いずれかが無効な場合、ロードバランサは HTTP 502 を返します。 |
(HTTP/1.1 のみ) Connection: Keep-Alive ヘッダー |
デフォルトでバックエンドに送信されるリクエストに Keep-Alive header を追加します。 |
デフォルトでこのヘッダーを追加しない |
リクエスト処理 | ||
リクエストにはバックスラッシュが含まれている | URL は変更されていない | スラッシュに変換する |
リクエストに重複するスラッシュがある | スラッシュを未結合のままにする | 結合スラッシュ |
リクエストパスの「#」 | 許可 | HTTP 400 を返す |
(HTTP/1.1 のみ)リクエストパスに無効な文字が含まれている(例: \\x7f\\x7f) | 許可(HTTP/1.1 の場合) | HTTP 502 を返す(HTTP/1.1 の場合) |
トラフィック分散(URL マップ構成) | ||
クライアント リクエストにポート番号が含まれている | URL マップでポートを使用してホストを構成している場合でも、ポート番号は無視されます。ホスト名のみが考慮されます。たとえば、example.com:5000 のリクエストは example.com のバックエンド サービスと照合されます。 |
ホスト名とポート番号の両方が考慮されます。たとえば、example.com:5000 のリクエストは example.com:5000 のバックエンド サービスと照合されます。一致するものがない場合は、デフォルトのバックエンド サービスが使用されます。 |
違いとサポートされている機能の詳細については、ロードバランサの機能の比較とアプリケーション ロードバランサの概要をご覧ください。
従来のアプリケーション ロードバランサからグローバル外部アプリケーション ロードバランサに移行する
グローバル外部アプリケーション ロードバランサに移行するには、ロード バランシング リソース(特にバックエンド サービスと転送ルール)のロード バランシング スキームを EXTERNAL
から EXTERNAL_MANAGED
に変更します。これを行うには、一連の移行手順を実施します。この手順では、実際に移行を完了する前に、新しいロード バランシング スキームでネットワーク トラフィックの一部をテストできます。リソースの移行中は、従来のアプリケーション ロードバランサ インフラストラクチャまたはグローバル外部アプリケーション ロードバランサ インフラストラクチャのいずれに送信されるリクエストの割合を制御します。
次の図は、移行前と移行後のロード バランシング リソースのロード バランシング スキームを示しています。
前の図で次の点に注意してください。
- リソースが移行される前は、すべてのリクエストで従来のアプリケーション ロードバランサ インフラストラクチャが使用されています。
- リソースの移行中、一部のリクエストはグローバル外部アプリケーション ロードバランサ インフラストラクチャに送信され、残りのリクエストは従来のアプリケーション ロードバランサ インフラストラクチャに送信されます。
- リソースの移行が完了すると、すべてのリクエストでグローバル外部アプリケーション ロードバランサのインフラストラクチャが使用されます。
円滑に移行できるように、従来のアプリケーション ロードバランサの次のリソースを指示された順序で移行します。
ロードバランサの転送ルールに関連付けられているすべてのバックエンド サービスを移行します。
ロードバランサの転送ルールに関連付けられているすべてのバックエンド バケットを移行します。バックエンド バケットにはロード バランシング スキームがないため、転送ルールレベルでこの操作を行います。
ロードバランサの転送ルールを移行します。
転送ルールを移行できるのは、転送ルールに関連付けられているすべてのバックエンド サービスとバックエンド バケットがすでに移行されている場合のみです。
移行の段階
リソースを移行するには、リソースを別の状態に設定してから、ロード バランシング スキームを EXTERNAL_MANAGED
に変更します。
PREPARE
: リソースをこの状態に設定して、移行の準備をします。TEST_BY_PERCENTAGE
: 準備されたリソースをテストするには、リソースをこの状態に設定して、ネットワーク トラフィックの一部を送信します。このステージは省略可能です。TEST_ALL_TRAFFIC
: リソースをこの状態に設定すると、従来のアプリケーション ロードバランサ インフラストラクチャではなく、グローバル外部アプリケーション ロードバランサ インフラストラクチャを介してすべてのネットワーク トラフィックがリソースに送信されます。
移行プロセス
ダウンタイムを回避するため、リソースを従来のアプリケーション ロードバランサ インフラストラクチャからグローバル外部アプリケーション ロードバランサ インフラストラクチャに特定の順序で移行し、ロード バランシング スキームを EXTERNAL
から EXTERNAL_MANAGED
に変更して移行を完了します。
ロードバランサのバックエンド サービスを移行します。
各バックエンド サービスに対して以下の手順を繰り返します。
移行用にバックエンド サービスを準備します。
グローバル外部アプリケーション ロードバランサ インフラストラクチャを介してトラフィックを送信する前に、バックエンド サービスの状態を
PREPARE
に設定します。これにより、グローバル外部アプリケーション ロードバランサのインフラストラクチャ ネットワーク トラフィックを処理するようにバックエンド サービスが準備されます。バックエンド サービスがグローバル外部アプリケーション ロードバランサ インフラストラクチャを介してトラフィックを送信できるようになるまでに少し時間がかかります(約 6 分)。省略可: 準備したバックエンド サービスをテストします。
バックエンド サービスが
PREPARE
状態になったら、その状態をTEST_BY_PERCENTAGE
に設定し、グローバル外部アプリケーション ロードバランサ インフラストラクチャと従来のアプリケーション ロードバランサ ネットワーク トラフィックとの割合を設定します。このステージは省略可能ですが、バックエンド サービスを移行する前にトラフィックをテストすることをおすすめします。小さい割合から始めて、リソースのログをモニタリングします。バックエンド サービスが想定どおりに動作する場合は、割合を徐々に増やし、最終的に 100% にします。
TEST_BY_PERCENTAGE
状態では、グローバル外部アプリケーション ロードバランサ インフラストラクチャの追加機能を使用できません。従来のアプリケーション ロードバランサのすべてのネットワーク トラフィックを準備されたバックエンド サービスに送信します。
バックエンド サービスのテストが成功したら、その状態を
TEST_ALL_TRAFFIC
に設定し、従来のアプリケーション ロードバランサのすべてのネットワーク トラフィックを準備されたバックエンド サービスに送信します。バックエンド サービスがネットワーク トラフィックを処理できるようになるまでに、少し時間がかかります(約 6 分)。TEST_ALL_TRAFFIC
状態では、グローバル外部アプリケーション ロードバランサ インフラストラクチャの追加機能を使用できません。移行されたバックエンド サービスのロード バランシング スキームを
EXTERNAL_MANAGED
に変更します。グローバル外部アプリケーション ロードバランサ インフラストラクチャで準備したバックエンド サービスをテストしたら、ロード バランシング スキームを
EXTERNAL_MANAGED
に変更します。バックエンド サービスが完全に移行されるまでに少し時間がかかります(約 6 分)。バックエンド サービスのロード バランシング スキームがEXTERNAL_MANAGED
に変更されると、グローバル外部アプリケーション ロードバランサ インフラストラクチャの高度な機能を使用できます。
ロードバランサのバックエンド バケットを移行します。バックエンド バケットにはロード バランシング スキームがないため、転送ルールレベルでこの操作を行います。
バケットごとに次の手順を繰り返します。
移行用にバックエンド バケットを準備します。
グローバル外部アプリケーション ロードバランサ インフラストラクチャを介してトラフィックを送信する前に、バックエンド バケットの状態を
PREPARE
に設定し、しばらく待ちます(約 6 分)。省略可: 準備したバックエンド サービスをテストします。
バックエンド バケットが
PREPARE
状態になったら、その状態をTEST_BY_PERCENTAGE
に設定し、グローバル外部アプリケーション ロードバランサ インフラストラクチャと従来のアプリケーション ロードバランサ ネットワーク トラフィックとの割合を設定します。従来のアプリケーション ロードバランサのすべてのネットワーク トラフィックを準備されたバックエンド バケットに送信します。
バックエンド バケットの状態を
TEST_ALL_TRAFFIC
に設定し、従来のアプリケーション ロードバランサのすべてのネットワーク トラフィックをバケットに送信します。バックエンド バケットがネットワーク トラフィックを処理できるようになるまでに、少し時間がかかります(約 6 分)。TEST_ALL_TRAFFIC
状態では、グローバル外部アプリケーション ロードバランサ インフラストラクチャの追加機能を使用できません。
転送ルールを移行します。
転送ルールごとに、転送ルールのロード バランシング スキームを
EXTERNAL_MANAGED
に変更し、しばらく待ちます(約 6 分)。転送ルールのロード バランシング スキームがEXTERNAL_MANAGED
に変更されると、グローバル外部アプリケーション ロードバランサ インフラストラクチャの高度な機能を使用できます。
詳細な手順については、従来のアプリケーション ロードバランサからリソースを移行するをご覧ください。
次の図は、移行のさまざまな状態にある従来のアプリケーション ロードバランサのリソースを示しています。
リソースを移行した後、従来のアプリケーション ロードバランサにロールバックする場合は、移行から 90 日以内にロード バランシング スキームを変更してください。90 日間の猶予期間が経過したリソースはロールバックできません。
セッション アフィニティを使用する
セッション アフィニティを使用する従来のアプリケーション ロードバランサのバックエンド サービスを移行する場合は、次の注意事項を考慮してください。
TEST_BY_PERCENTAGE
に値を設定すると、従来のアプリケーション ロードバランサをターゲットとする一部のトラフィックがグローバル外部アプリケーション ロードバランサにリダイレクトされます。これにより、クライアント IP アフィニティが失われます。移行率を変更すると(たとえば 10% 増やすと)、次のリクエストでアフィニティが再確立されるまで、同じ割合のクライアント IP アドレス(この例では 10%)のセッション アフィニティが破棄されます。TEST_BY_PERCENTAGE
に値を設定すると、セッション Cookie のない一部のトラフィックがグローバル外部アプリケーション ロードバランサにリダイレクトされます。セッション Cookie を含むすべてのトラフィックは、Cookie を生成したロードバランサ フリートにリダイレクトされます。TEST_BY_PERCENTAGE
の値を 0% に設定するか、未設定のままにするか、バックエンド サービスをPREPARE
状態に設定すると、グローバル外部アプリケーション ロードバランサに転送される既存の Cookie がすべて無効になります。バックエンド サービスのロード バランシング スキームを
EXTERNAL_MANAGED
に変更すると、従来のアプリケーション ロードバランサ フリートによって生成されたすべての Cookie が無効になります。これにより、グローバル外部アプリケーション ロードバランサを使用するアプリケーションに問題がある場合、トラフィックをロールバックできます。たとえば、クライアントが従来のアプリケーション ロードバランサ フリートから Cookie を提示しても、バックエンド サービス スキームがEXTERNAL_MANAGED
の場合、クライアントの Cookie は使用されません。グローバル外部アプリケーション ロードバランサは Cookie を無視し、新しい Cookie を作成します。
移行されたリソースをロールバックする
リソースを移行した後、グローバル外部アプリケーション ロードバランサ インフラストラクチャから従来のアプリケーション ロードバランサ インフラストラクチャにロールバックする場合は、ロード バランシング スキームを変更してから 90 日以内に行う必要があります。
バックエンド サービスを EXTERNAL
スキームにロールバックするには、転送ルールをロールバックする必要があります。転送ルールを EXTERNAL
スキームにロールバックするために、バックエンド サービスをロールバックする必要はありません。
リソースをロールバックする手順は次のとおりです。
- リソースに構成されているグローバル外部アプリケーション ロードバランサの新しい高度なトラフィック管理機能を削除します。
転送ルールをロールバックします。
転送ルールのロード バランシング スキームを
EXTERNAL_MANAGED
からEXTERNAL
に変更します。バックエンド バケットをロールバックします。
- バックエンド バケットの移行状態を
TEST_ALL_TRAFFIC
に設定し、しばらく待ちます(約 6 分)。 - 省略可: トラフィックを減らすには、バックエンド バケットの移行状態を
TEST_BY_PERCENTAGE
に設定し、トラフィックの割合を設定します。 - バックエンド バケットの移行ステータスを
PREPARE
に設定します。 - バックエンド バケットを移行前の状態に戻します。
- バックエンド バケットの移行状態を
バックエンド サービスをロールバックします。
- バックエンド サービスの移行状態を
TEST_ALL_TRAFFIC
に設定し、しばらく待ちます(約 6 分)。 - 省略可: トラフィックを減らすには、バックエンド サービスの移行状態を
TEST_BY_PERCENTAGE
に設定し、トラフィックの割合を設定します。 - バックエンド サービスの移行状態を
PREPARE
に設定します。 - バックエンド サービスを移行前の状態に戻します。
- バックエンド サービスの移行状態を
詳細な手順については、移行されたリソースを従来のアプリケーション ロードバランサにロールバックするをご覧ください。
移行プロセスを追跡する
リソースの移行中に、次のものを表示してロード バランシング スキームを確認できます。
グローバル外部アプリケーション ロードバランサのロギングとモニタリングのダッシュボード。詳細については、グローバル外部アプリケーション ロードバランサのロギングとモニタリングをご覧ください。
次の HTTP リクエスト ヘッダーとレスポンス ヘッダーの値:
X-External-Managed-Migration-Scheme-Override
: このリクエスト ヘッダーは、値に基づいてリクエストを転送します。ヘッダー値がEXTERNAL
の場合、リクエストは従来のアプリケーション ロードバランサ インフラストラクチャに転送されます。値がEXTERNAL_MANAGED
の場合、リクエストはグローバル外部アプリケーション ロードバランサ インフラストラクチャを介して転送されます。このヘッダーを使用して、特定のロードバランサ フリートにリクエストを転送します。
X-External-Managed-Migration-Selected-Scheme
: このリクエスト ヘッダーとレスポンス ヘッダーは、リクエストのルーティングに使用されるロード バランシング スキームをバックエンドとクライアントに通知します。ヘッダーはクライアントに返され、ユーザーのバックエンドに渡されます。リクエストが従来のアプリケーション ロードバランサ インフラストラクチャ経由で転送される場合、値は
EXTERNAL
です。リクエストがグローバル外部アプリケーション ロードバランサ インフラストラクチャを介して転送される場合、値はEXTERNAL_MANAGED
です。