このドキュメントでは、グローバル外部アプリケーション ロードバランサのリソースとバックエンドを IPv4 のみ（シングルスタック）から IPv4 と IPv6（デュアルスタック）に移行する方法について説明します。このドキュメントでは、IPv4 のみ（シングルスタック）は IPv4 アドレスのみを使用するリソースを指し、IPv4 と IPv6（デュアルスタック）は IPv4 アドレスと IPv6 アドレスの両方を使用するリソースを指します。
利点
ロードバランサをデュアルスタックに変換するメリットは次のとおりです。
IPv6 の主な利点は、はるかに大きな IP アドレスプールを割り振ることができることです。
すでに IPv4 のみのロードバランサを使用している多くのユーザーは、クラウド固有の方法で、IPv4 のみのリソースから IPv4 と IPv6（デュアルスタック）リソースに変換できます。
上り（内向き）IPv6 トラフィックを終端し、必要に応じて IPv4 または IPv6 接続を介してこのトラフィックをバックエンドにプロキシするようにロードバランサを構成できます。詳細については、IPv6 をご覧ください。
制限事項
サブネットの IP スタックタイプを IPv4 と IPv6（デュアルスタック）から IPv4 のみに更新することはできません。
バックエンド サービスで IP アドレス選択ポリシーを IPv6 のみとして構成しても、IPv4 のみのバックエンドを構成できます。ただし、このような構成では、バックエンドが異常になり、クライアントにレスポンス コード
503が返され、トラフィックがアップストリームに転送されません。ログの statusDetails HTTP 失敗メッセージにfailed_to_pick_backendが表示されます。バックエンド サービスの IP アドレス選択ポリシーを IPv6 のみに構成できますが、バックエンドの IP スタックタイプは常に IPv4 と IPv6（デュアルスタック）です。
IPv4 と IPv6（デュアルスタック）をサポートするのは、
GCE_VM_IP_PORTエンドポイントを使用する VM インスタンス グループ バックエンドとゾーン ネットワーク エンドポイント グループ（NEG）のみです。
始める前に
インスタンス グループまたはゾーン NEG バックエンドを使用して、IPv4 のみのスタックを持つ SSL プロキシまたは TCP プロキシのグローバル外部アプリケーション ロードバランサが設定されている必要があります。
グローバル外部アプリケーション ロードバランサの設定方法については、次のドキュメントをご覧ください。
変換するリソースを特定する
ロードバランサが関連付けられているリソースの名前をメモします。これらの名前は後で指定する必要があります。
すべてのサブネットを一覧表示するには、
gcloud compute networks subnets listコマンドを使用します。gcloud compute networks subnets list
デュアルスタックに変換する IPv4 アドレスのみを持つサブネットの名前をメモします。以下では、この名前を
SUBNETで表します。以下では、この VPC ネットワークをNETWORKで表します。すべてのバックエンド サービスを一覧表示するには、
gcloud beta compute backend-services listコマンドを使用します。gcloud beta compute backend-services list
デュアルスタックに変換するバックエンド サービスの名前をメモします。以下では、この名前を
BACKEND_SERVICEで表します。すべての URL マップを一覧表示するには、
gcloud beta compute url-maps listコマンドを使用します。gcloud beta compute url-maps list
ロードバランサに関連付けられている URL マップの名前をメモします。以下では、この名前を
URL_MAPで表します。ロードバランサがすでにある場合は、バックエンドの IP スタックタイプを確認するために、
gcloud compute instances listコマンドを使用します。gcloud compute instances list \ --format= \ "table( name, zone.basename(), networkInterfaces[].stackType.notnull().list(), networkInterfaces[].ipv6AccessConfigs[0].externalIpv6.notnull().list():label=EXTERNAL_IPV6, networkInterfaces[].ipv6Address.notnull().list():label=INTERNAL_IPV6)"すべての VM インスタンスとインスタンス テンプレートを一覧表示するには、
gcloud compute instances listコマンドとgcloud compute instance-templates listコマンドを使用します。gcloud compute instances list
gcloud compute instance-templates list
デュアルスタックに変換するインスタンスとインスタンス テンプレートの名前をメモします。以下では、これらの名前をそれぞれ
VM_INSTANCE、INSTANCE_TEMPLATESで表します。すべてのゾーン ネットワーク エンドポイント グループ（NEG）を一覧表示するには、
gcloud compute network-endpoint-groups listコマンドを使用します。gcloud compute network-endpoint-groups list
デュアルスタックに変換するゾーン NEG バックエンドの名前をメモします。以下では、この名前を
ZONAL_NEGで表します。すべてのターゲット プロキシを一覧表示するには、
gcloud compute target-http-proxies listコマンドを使用します。gcloud compute target-http-proxies list
ロードバランサに関連付けられているターゲット プロキシの名前をメモします。以下では、この名前を
TARGET_PROXYで表します。
シングルスタック バックエンドからデュアルスタック バックエンドに変換する
このセクションでは、IPv4 のみ（シングルスタック）アドレスを使用するリソースとバックエンドを IPv4 と IPv6（デュアルスタック）アドレスに変換する方法について説明します。
サブネットを更新する
デュアルスタック サブネットは、カスタムモード VPC ネットワークでのみサポートされます。自動モード VPC ネットワークや以前のネットワークではサポートされません。自動モードのネットワークは初期の試験運用には役立ちますが、ほとんどの本番環境にはカスタムモードの VPC が適しています。カスタムモードで VPC を使用することをおすすめします。
VPC の設定をデュアルスタックに更新する手順は次のとおりです。
自動モードの VPC ネットワークを使用している場合は、まず、自動モードの VPC ネットワークをカスタムモードに変換する必要があります。
IPv6 を有効にする方法については、サブネットのスタックタイプをデュアルスタックに変更するをご覧ください。
省略可: このネットワークのサブネットで内部 IPv6 アドレス範囲を構成する場合は、次の手順を完了します。
- [VPC ネットワーク ULA の内部 IPv6 範囲] で、[有効] を選択します。
[Allocate internal IPv6 range] で、[自動] または [手動] を選択します。
[手動] を選択した場合は、
fd20::/20の範囲内の/48の範囲を入力します。範囲が使用されている場合は、別の範囲を指定するように求めるプロンプトが表示されます。
VM インスタンスまたはテンプレートを更新する
VM が接続されているサブネットに IPv6 範囲が構成されている場合は、VM インスタンスに IPv6 アドレスを構成できます。IPv6 アドレスをサポートできるのは、次のバックエンドのみです。
- インスタンス グループ バックエンド: 1 つ以上のマネージドまたは非マネージド インスタンス グループ バックエンド。あるいは、マネージドと非マネージドの組み合わせ。
- ゾーン NEG: 1 つ以上の
GCE_VM_IP_PORTのゾーン NEG。
VM インスタンスを更新する
マネージド インスタンス グループまたは非マネージド インスタンス グループに属する VM インスタンスは編集できません。VM インスタンスをデュアルスタックに更新する手順は次のとおりです。
VM インスタンス テンプレートを更新する
既存のインスタンス テンプレートを更新することはできません。変更が必要な場合は、同様のプロパティを持つ別のテンプレートを作成します。VM インスタンス テンプレートをデュアルスタックに更新する手順は次のとおりです。
コンソール
Google Cloud コンソールで、[インスタンス テンプレート] ページに移動します。
- コピーして更新するインスタンス テンプレートをクリックします。
- [同様のものを作成] をクリックします。
- [詳細オプション] セクションを開きます。
- [ネットワーク タグ] に「
allow-health-check-ipv6」と入力します。 - [ネットワーク インターフェース] セクションで、[ネットワーク インターフェースを追加] をクリックします。
- [ネットワーク] リストで、カスタムモードの VPC ネットワークを選択します。
- [サブネットワーク] リストで、
SUBNETを選択します。 - [IP スタックタイプ] には、[IPv4 と IPv6（デュアルスタック）] を選択します。
- [作成] をクリックします。
ロードバランサに関連付けられたマネージド インスタンス グループ
MIGで基本のローリング アップデートを開始します。
ゾーン NEG を更新する
ゾーン NEG エンドポイントは編集できません。IPv4 エンドポイントを削除し、IPv4 アドレスと IPv6 アドレスの両方を持つ新しいデュアルスタック エンドポイントを作成する必要があります。
REGION_A リージョンにゾーン NEG（GCE_VM_IP_PORT タイプのエンドポイントを含む）を設定するには、まず GCP_NEG_ZONE ゾーンに VM を作成します。次に、VM ネットワーク エンドポイントをゾーン NEG に追加します。
VM を作成する
コンソール
Google Cloud コンソールで [VM インスタンス] ページに移動します。
[インスタンスを作成] をクリックします。
[名前] を
vm-a1に設定します。[リージョン] に
REGION_Aを選択し、[ゾーン] フィールドに任意の値を選択します。この手順では、このサブネットをGCP_NEG_ZONEで表しています。[ブートディスク] セクションで、ブートディスク オプションに Debian オペレーティング システムと 10（buster）バージョンが選択されていることを確認します。必要に応じてイメージを変更するには、[選択] をクリックします。
[詳細オプション] セクションを開き、次の変更を行います。
- [ネットワーキング] セクションを開きます。
- [ネットワーク タグ] フィールドに「
allow-health-check」と入力します。 - [ネットワーク インターフェース] セクションで、次の変更を行います。
- ネットワーク:
NETWORK - サブネット:
SUBNET - IP スタックタイプ: IPv4 と IPv6（デュアルスタック）
- ネットワーク:
- [完了] をクリックします。
[管理] をクリックします。[起動スクリプト] フィールドに、次のスクリプトの内容をコピーして貼り付けます。
#! /bin/bash apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://metadata.google.internal/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html systemctl restart apache2
[作成] をクリックします。
以下の手順を繰り返し、次の名前とゾーンの組み合わせを使用して、2 つ目の VM を作成します。
- 名前:
vm-a2、ゾーン:GCP_NEG_ZONE
- 名前:
gcloud
VM とそのゾーンの名前にこれらの組み合わせを使用して、次のコマンドを 2 回実行して VM を作成します。スクリプトの内容は両方の VM で同じです。
vm-a1のVM_NAMEと任意のGCP_NEG_ZONEゾーン。vm-a2のVM_NAMEと同じGCP_NEG_ZONEゾーン。gcloud compute instances create VM_NAME \ --zone=GCP_NEG_ZONE \ --stack-type=IPV4_IPV6 \ --image-family=debian-10 \ --image-project=debian-cloud \ --tags=allow-health-check \ --subnet=SUBNET \ --metadata=startup-script='#! /bin/bash apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://metadata.google.internal/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html systemctl restart apache2'
ゾーン NEG にエンドポイントを追加する
コンソール
ゾーン NEG にエンドポイントを追加します。
Google Cloud コンソールで、[ネットワーク エンドポイント グループ] ページに移動します。
[名前] リストで、ネットワーク エンドポイント グループの名前（
ZONAL_NEG）をクリックします。[ネットワーク エンドポイント グループの詳細] ページが表示されます。[このグループのネットワーク エンドポイント] セクションで、以前に作成した NEG エンドポイントを選択します。[エンドポイントを削除] をクリックします。
[このグループのネットワーク エンドポイント] セクションで [ネットワーク エンドポイントを追加] をクリックします。
VM インスタンスを選択します。
[ネットワーク インターフェース] セクションに、VM の名前、ゾーン、サブネットが表示されます。
[IPv4 アドレス] フィールドに、新しいネットワーク エンドポイントの IPv4 アドレスを入力します。
[IPv6 アドレス] フィールドに、新しいネットワーク エンドポイントの IPv6 アドレスを入力します。
ポートタイプを選択します。
- [デフォルト] を選択すると、エンドポイントはネットワーク エンドポイント グループのすべてのエンドポイントにデフォルト ポート
80を使用します。この例では、Apache サーバーがポート80でリクエストを配信しているため、これで十分です。 - [カスタム] を選択した場合は、使用するエンドポイントのポート番号を入力します。
- [デフォルト] を選択すると、エンドポイントはネットワーク エンドポイント グループのすべてのエンドポイントにデフォルト ポート
他のエンドポイントを追加するには、[ネットワーク エンドポイントを追加] をクリックし、前の手順を繰り返します。
すべてのエンドポイントを追加したら、[作成] をクリックします。
gcloud
エンドポイント（
GCE_VM_IP_PORTエンドポイント）をZONAL_NEGに追加します。gcloud compute network-endpoint-groups update ZONAL_NEG \ --zone=GCP_NEG_ZONE \ --add-endpoint='instance=vm-a1,ip=IPv4_ADDRESS, \ ipv6=IPv6_ADDRESS,port=80' \ --add-endpoint='instance=vm-a2,ip=IPv4_ADDRESS, \ ipv6=IPv6_ADDRESS,port=80'
次のように置き換えます。
IPv4_ADDRESS: ネットワーク エンドポイントの IPv4 アドレス。この IPv4 は、Compute Engine の VM（プライマリ IP またはエイリアス IP 範囲の一部）に属している必要があります。IP アドレスが指定されていない場合は、ネットワーク エンドポイント グループが属するネットワーク内の VM インスタンスのプライマリ IP アドレスが使用されます。
IPv6_ADDRESS: ネットワーク エンドポイントの IPv6 アドレス。この IPv6 アドレスは、ネットワーク エンドポイント グループが属するネットワーク内の VM インスタンス（外部 IPv6 アドレス）に属している必要があります。
IPv6 ヘルスチェックのファイアウォール ルールを作成する
ロードバランスされているインスタンスに適用され、Google Cloud ヘルスチェック システム（2600:2d00:1:b029::/64、2600:2d00:1:1::/64）からのトラフィックを許可する上り（内向き）ルールがあることを確認します。この例では、ターゲットタグ allow-health-check-ipv6 を使用して、ルールが適用される VM インスタンスを識別します。
このファイアウォール ルールがない場合は、デフォルトの上り（内向き）拒否ルールによってバックエンド インスタンスへの受信 IPv6 トラフィックがブロックされます。
コンソール
Google Cloud コンソールで [ファイアウォール ポリシー] ページに移動します。
IPv6 サブネット トラフィックを許可するには、もう一度 [ファイアウォール ルールを作成] をクリックして、次の情報を入力します。
- 名前:
fw-allow-lb-access-ipv6 - ネットワーク:
NETWORK - 優先度:
1000 - トラフィックの方向: 上り（内向き）
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ:
allow-health-check-ipv6 - ソースフィルタ: IPv6 範囲
- 送信元 IPv6 範囲:
2600:2d00:1:b029::/64,2600:2d00:1:1::/64 - プロトコルとポート: すべて許可
- 名前:
[作成] をクリックします。
gcloud
fw-allow-lb-access-ipv6ファイアウォール ルールを作成して、サブネットとの通信を許可します。gcloud compute firewall-rules create fw-allow-lb-access-ipv6 \ --network=NETWORK \ --action=allow \ --direction=ingress \ --target-tags=allow-health-check-ipv6 \ --source-ranges=2600:2d00:1:b029::/64,2600:2d00:1:1::/64 \ --rules=all
IPv6 用に新しいバックエンド サービスと転送ルールを作成する
このセクションでは、IPv6 用に新しいバックエンド サービスと転送ルールを作成する手順について説明します。
BACKEND_SERVICE と BACKEND_SERVICE_IPV6 の両方でトラフィックを処理できます。トラフィックの中断を回避するには、IP アドレス選択ポリシーを Prefer IPv6 に設定して、新しいバックエンド サービスを作成します。新しいバックエンド サービスを作成したら、トラフィックを新しい IPv6 バックエンド サービスに転送できます。
コンソール
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
ロードバランサの名前をクリックします。
[編集] をクリックします。
バックエンド サービス構成する:
- [バックエンドの構成] をクリックします。
- [バックエンド サービス] フィールドで、[バックエンド サービスを作成] を選択します。
- [名前] を BACKEND_SERVICE_IPV6 に設定します。
- [バックエンド タイプ] で [インターネット ネットワーク エンドポイント グループ] を選択します。
- [IP アドレス選択ポリシー] リストで、[IPv6 優先] を選択します。
- [プロトコル] フィールドで、[HTTP] を選択します。
- [新しいバックエンド] パネルで、次の操作を行います。
- [ネットワーク エンドポイント グループ] リストで、ZONAL_NEG を選択します。
- [最大 RPS] に「
10」と入力します。
- [ヘルスチェック] リストで、HTTP ヘルスチェックを選択します。
- [完了] をクリックします。
IPv6 フロントエンドを構成する:
- [フロントエンドの構成] をクリックします。
- [フロントエンド IP とポートの追加] をクリックします。
- [名前] フィールドに、転送ルールの名前を入力します。
- [プロトコル] フィールドで
HTTPを選択します。 - [IP バージョン] を
IPv6に設定します。 - [完了] をクリックします。
- [更新] をクリックします。
ルーティング ルールを構成する
- [ルーティング ルール] をクリックします。
- [詳細なホストとパスのルール] をクリックします。
- [更新] をクリックします。
gcloud
ヘルスチェックを作成します。
gcloud compute health-checks create http HEALTH_CHECK \ --port 80
HTTP トラフィックのバックエンド サービスを作成します。
gcloud beta compute backend-services create BACKEND_SERVICE_IPV6 \ --load-balancing-scheme=EXTERNAL_MANAGED \ --protocol=HTTP \ --ip-address-selection-policy=PREFER_IPV6 \ --health-checks=HEALTH_CHECK \ --global
バックエンドとしてゾーン NEG をバックエンド サービスに追加します。
gcloud beta compute backend-services add-backend BACKEND_SERVICE_IPV6 \ --network-endpoint-group=ZONAL_NEG \ --max-rate-per-endpoint=10 \ --global
ユーザーがロードバランサに接続する際に使用する外部 IPv6 アドレスを予約します。
gcloud compute addresses create lb-ipv6-1 \ --ip-version=IPV6 \ --network-tier=PREMIUM \ --global
バックエンド サービスの転送ルールを作成します。転送ルールを作成するときは、サブネット内の外部 IP アドレスを指定します。
gcloud beta compute forwarding-rules create FORWARDING_RULE_IPV6 \ --load-balancing-scheme=EXTERNAL_MANAGED \ --network-tier=PREMIUM \ --address=lb-ipv6-1 \ --global \ --target-https-proxy=TARGET_PROXY \ --ports=443
トラフィックを新しい IPv6 バックエンド サービスに転送する
URL マップを更新して、クライアント トラフィックの一部を新しい IPv6 バックエンド サービスに転送します。
BACKEND_SERVICE_IPV6
次のコマンドを使用して URL マップを編集します。
gcloud compute url-maps edit URL_MAP \ --global表示されたテキスト エディタで
routeRuleを追加し、BACKEND_SERVICE_IPV6に転送する IPv6 トラフィックの割合をweightedBackendServicesアクションに指定します。defaultService: global/backendServices/BACKEND_SERVICE hostRules: - hosts: - '*' pathMatcher: matcher1 name: URL_MAP pathMatchers: - defaultService: global/backendServices/BACKEND_SERVICE name: matcher1 routeRules: - matchRules: - prefixMatch: '' priority: 1 routeAction: weightedBackendServices: - backendService: global/backendServices/BACKEND_SERVICE weight: 95 - backendService: global/backendServices/BACKEND_SERVICE_IPV6 weight: 5
IPv6 に段階的に移行するには、URL マップを編集して、新しいバックエンド サービス BACKEND_SERVICE_IPV6 の重み付けの割合を段階的に増やしていきます（割合が 100% になるまでこの操作を繰り返します）。
IP アドレス選択ポリシーを構成する
この手順は省略可能です。リソースとバックエンドをデュアルスタックに変換したら、IP アドレス選択ポリシーを使用して、Google Front End（GFE）からバックエンドに送信されるトラフィックの種類を指定します。
IP_ADDRESS_SELECTION_POLICY を次のいずれかの値に置き換えます。
| IP アドレス選択ポリシー | 説明 |
|---|---|
| IPv4 のみ | クライアントから GFE へのトラフィックに関係なく、バックエンド サービスのバックエンドに IPv4 トラフィックのみを送信します。バックエンドのヘルスチェックには、IPv4 ヘルスチェックのみが使用されます。 |
| IPv6 優先 | バックエンドで IPv4 接続よりも IPv6 接続を優先します（IPv6 アドレスを持つ正常なバックエンドがある場合）。 ヘルスチェックは、バックエンドの IPv6 接続と IPv4 接続を定期的にモニタリングします。GFE は最初に IPv6 接続を試みます。IPv6 接続が切断された場合や遅い場合、GFE は Happy Eyeballs を使用してフォールバックし、IPv4 に接続します。 IPv6 接続または IPv4 接続のいずれかが正常でない場合でも、バックエンドは正常と見なされ、GFE は両方の接続を試行できます。最終的に、使用する接続が Happy Eyeballs によって選択されます。 |
| IPv6 のみ | クライアントからプロキシへのトラフィックに関係なく、バックエンド サービスのバックエンドに IPv6 トラフィックのみを送信します。バックエンドのヘルスチェックには、IPv6 ヘルスチェックのみが使用されます。 バックエンド トラフィック タイプが IP アドレス選択ポリシーと一致しているかどうかを確認するために特別な検証操作を行う必要はありません。たとえば、IPV4 バックエンドがあり、IP アドレス選択ポリシーとして |
コンソール
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
ロードバランサの名前をクリックします。
[編集] をクリックします。
[バックエンドの構成] をクリックします。
[バックエンド サービス] フィールドで、BACKEND_SERVICE_IPV6 を選択します。
[バックエンド タイプ] は、[ゾーン ネットワーク エンドポイント グループ] または [インスタンス グループ] にする必要があります。
[IP アドレス選択ポリシー] リストで、IP_ADDRESS_SELECTION_POLICY を選択します。
[完了] をクリックします。
gcloud
バックエンド サービスを更新します。
gcloud beta compute backend-services update BACKEND_SERVICE_IPV6 \ --load-balancing-scheme=EXTERNAL_MANAGED \ --protocol=HTTP \ --ip-address-selection-policy=IP_ADDRESS_SELECTION_POLICY \ --global
ロードバランサのテスト
必要なリソースがすべてデュアルスタックに更新されていることを検証する必要があります。すべてのリソースを更新すると、トラフィックがバックエンドに自動的に転送されるはずです。ログを確認して、変換が完了したことを確認します。
ロードバランサをテストして、移行が成功し、受信トラフィックが想定どおりにバックエンドに到達していることを確認します。
ロードバランサの外部 IP アドレスを調べる
コンソール
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
ロードバランサの名前をクリックします。
[フロントエンド] セクションに、2 つのロードバランサ IP アドレスが表示されます。この手順では、IPv4 アドレスを IP_ADDRESS_IPV4、IPv6 アドレスを IP_ADDRESS_IPV6 で表しています。
[バックエンド] セクションで IP アドレス選択ポリシーが
Prefer IPv6の場合、バックエンドに 2 つのヘルスチェック ステータスが表示されます。
インスタンスにトラフィックを送信する
この例では、curl コマンドからのリクエストがバックエンドにランダムに分散されます。
すべてのバックエンド VM が応答するまで、次のコマンドを数回繰り返します。
curl http://IP_ADDRESS_IPV4
curl http://IP_ADDRESS_IPV6
たとえば、IPv6 アドレスが
[fd20:1db0:b882:802:0:46:0:0]:80の場合、コマンドは次のようになります。curl http://[fd20:1db0:b882:802:0:46:0:0]
ログを調べる
すべてのログエントリは、バックエンドの宛先 IPv4 アドレスと宛先 IPv6 アドレスをキャプチャします。デュアルスタックをサポートしているため、バックエンドで使用される IP アドレスを確認することが重要です。
トラフィックが IPv6 に送信されているか、IPv4 にフォールバックされているかどうかは、ログを表示することで確認できます。
HttpRequest には、バックエンドに関連付けられた backend_ip アドレスが含まれています。ログを調べて、backend_ip の宛先 IPv4 アドレスと宛先 IPv6 アドレスを比較することで、使用されている IP アドレスを確認できます。