このページは Cloud Translation API によって翻訳されました。

移行の概要

このページでは、グローバル外部アプリケーションロードバランサと従来のアプリケーションロードバランサの違いの概要と、既存の従来のアプリケーションロードバランサリソースをグローバル外部アプリケーションロードバランサに移行する方法の詳細な概要について説明します。

グローバル外部アプリケーションロードバランサの高度なトラフィック管理機能を利用するには、従来のアプリケーションロードバランサのリソースをグローバル外部アプリケーションロードバランサインフラストラクチャに移行することをおすすめします。

従来のアプリケーションロードバランサとグローバル外部アプリケーションロードバランサを比較する

リソースを移行する前に、従来のアプリケーションロードバランサとグローバル外部アプリケーションロードバランサの違いを理解してください。

機能の違い

次の機能は、グローバル外部アプリケーションロードバランサではサポートされていません。これらは、従来のアプリケーションロードバランサでのみ使用できます。

スタンダードネットワークティア
GKE Ingress コントローラ

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 に変更して移行を完了します。

ロードバランサのバックエンドサービスを移行します。

バックエンドサービスごとに次の手順を繰り返します。
1. 移行用にバックエンドサービスを準備します。
  
  グローバル外部アプリケーションロードバランサインフラストラクチャを介してトラフィックを送信する前に、バックエンドサービスの状態を PREPARE に設定します。これにより、グローバル外部アプリケーションロードバランサのインフラストラクチャネットワークトラフィックを処理するようにバックエンドサービスが準備されます。バックエンドサービスがグローバル外部アプリケーションロードバランサインフラストラクチャを介してトラフィックを送信できるようになるまでには、しばらく時間（約 6 分）かかります。
2. 省略可: 準備したバックエンドサービスをテストします。
  
  バックエンドサービスが PREPARE 状態になったら、その状態を TEST_BY_PERCENTAGE に設定し、グローバル外部アプリケーションロードバランサインフラストラクチャへの従来のアプリケーションロードバランサネットワークトラフィックの割合を設定します。
  
  このステージは省略可能ですが、バックエンドサービスを移行する前にトラフィックをテストすることをおすすめします。小さな割合の値から始めて、リソースのログをモニタリングします。バックエンドサービスが想定どおりに動作する場合は、割合を徐々に 100% に増やします。
  
  TEST_BY_PERCENTAGE 状態では、グローバル外部アプリケーションロードバランサインフラストラクチャの追加機能を使用できません。
3. 従来のアプリケーションロードバランサのすべてのネットワークトラフィックを、準備されたバックエンドサービスに送信します。
  
  バックエンドサービスのテストが成功したら、その状態を TEST_ALL_TRAFFIC に設定し、従来のアプリケーションロードバランサのすべてのネットワークトラフィックを準備したバックエンドサービスに送信します。バックエンドサービスがネットワークトラフィックを処理できるようになるまでに、しばらく時間（約 6 分）がかかります。
  
  TEST_ALL_TRAFFIC 状態では、グローバル外部アプリケーションロードバランサインフラストラクチャの追加機能を使用できません。
4. 移行されたバックエンドサービスのロードバランシングスキームを EXTERNAL_MANAGED に変更します。
  
  グローバル外部アプリケーションロードバランサインフラストラクチャで準備したバックエンドサービスをテストしたら、ロードバランシングスキームを EXTERNAL_MANAGED に変更します。バックエンドサービスが完全に移行されるまでには、しばらく時間（約 6 分）がかかります。バックエンドサービスのロードバランシングスキームが EXTERNAL_MANAGED に変更されると、グローバル外部アプリケーションロードバランサインフラストラクチャの高度な機能を使用できます。
ロードバランサのバックエンドバケットを移行します。バックエンドバケットにはロードバランシングスキームがないため、転送ルールレベルでこの操作を行います。

バケットごとに次の手順を繰り返します。
1. 移行用にバックエンドバケットを準備します。
  
  グローバル外部アプリケーションロードバランサインフラストラクチャを介してトラフィックを送信する前に、バックエンドバケットの状態を PREPARE に設定し、しばらく待ちます（約 6 分）。
2. 省略可: 準備したバックエンドサービスをテストします。
  
  バックエンドバケットが PREPARE 状態になったら、その状態を TEST_BY_PERCENTAGE に設定し、グローバル外部アプリケーションロードバランサインフラストラクチャへの従来のアプリケーションロードバランサネットワークトラフィックの割合を設定します。
3. 従来のアプリケーションロードバランサのすべてのネットワークトラフィックを、準備されたバックエンドバケットに送信します。
  
  バックエンドバケットの状態を 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 に変更します。
バックエンドバケットをロールバックします。
1. バックエンドバケットの移行状態を TEST_ALL_TRAFFIC に設定し、しばらく待ちます（約 6 分）。
2. 省略可: トラフィックを減らすには、バックエンドバケットの移行状態を TEST_BY_PERCENTAGE に設定し、トラフィックの割合を設定します。
3. バックエンドバケットの移行ステータスを PREPARE に設定します。
4. バックエンドバケットを移行前の状態に戻します。
バックエンドサービスをロールバックします。
1. バックエンドサービスの移行状態を TEST_ALL_TRAFFIC に設定し、しばらく待ちます（約 6 分）。
2. 省略可: トラフィックを減らすには、バックエンドサービスの移行状態を TEST_BY_PERCENTAGE に設定し、トラフィックの割合を設定します。
3. バックエンドサービスの移行状態を PREPARE に設定します。
4. バックエンドサービスを移行前の状態に戻します。

詳細な手順については、移行されたリソースを従来のアプリケーションロードバランサにロールバックするをご覧ください。

移行プロセスを追跡する

リソースの移行中に、次の項目を表示してロードバランシングスキームを確認できます。

グローバル外部アプリケーションロードバランサのロギングとモニタリングのダッシュボード。詳細については、グローバル外部アプリケーションロードバランサのロギングとモニタリングをご覧ください。
次の HTTP リクエストヘッダーとレスポンスヘッダーの値:
- X-External-Managed-Migration-Scheme-Override: このリクエストヘッダーは、値に基づいてリクエストを転送します。ヘッダー値が EXTERNAL の場合、リクエストは従来のアプリケーションロードバランサインフラストラクチャに転送されます。値が EXTERNAL_MANAGED の場合、リクエストはグローバル外部アプリケーションロードバランサインフラストラクチャを介して転送されます。
  
  このヘッダーを使用して、特定のロードバランサフリートにリクエストを転送します。
- X-External-Managed-Migration-Selected-Scheme: このリクエストヘッダーとレスポンスヘッダーは、リクエストのルーティングに使用されるロードバランシングスキームをバックエンドとクライアントに通知します。ヘッダーはクライアントに返され、お客様のバックエンドに渡されます。
  
  リクエストが従来のアプリケーションロードバランサインフラストラクチャ経由で転送される場合、値は EXTERNAL です。リクエストがグローバル外部アプリケーションロードバランサインフラストラクチャ経由で転送される場合、値は EXTERNAL_MANAGED です。