G-gen の佐々木です。当記事では、従来の Application Load Balancer（classic Application Load Balancer）リソースを、新しい Application Load Balancer であるグローバル外部 Application Load Balancer に安全に移行する方法を解説します。

前提知識

外部 Application Load Balancer の基本については、以下の記事をご一読ください。

blog.g-gen.co.jp

Application Load Balancer の比較

基本的な違い

従来の Application Load Balancer（classic Application Load Balancer）と新型であるグローバル外部 Application Load Balancer は、どちらも Google Front End（GFE）と呼ばれる Google 管理のインフラストラクチャ上で動作するマネージドなロードバランサー機能です。

グローバル外部 Application Load Balancer ではデータプレーンに OSS の Envoy プロキシを採用しており、このデータプレーンの違いによって、従来型と比べてイベントに対する応答などが異なる場合があります。

たとえば、ロードバランサーのバックエンドにあるサービスのステータスがすべて正常ではない場合、従来の Application Load Balancer ではステータス502が返されますが、グローバル外部 Application Load Balancer ではステータス503が返されるようになっています。

以下のドキュメントにデータプレーンによる動作の違いがまとまっているため、従来型からの移行を行う場合は目を通しておきましょう。

参考 : Increasing Resiliency with Load Balancers

グローバル外部 Application Load Balancer でサポートされる機能

グローバル外部 Application Load Balancer は以下のような機能を利用することができます。

ホスト、パス、ヘッダー、リクエストパラメータなどに基づくトラフィックのインテリジェントなルーティング
リクエストベース、レスポンスベースのアクション（リダイレクト、ヘッダー変換など）の実行
リクエストミラーリングなどの高度な負荷分散アルゴリズム

機能の詳細については、以下のドキュメントをご一読ください。

参考 : Traffic management overview for global external Application Load Balancer

グローバル外部 Application Load Balancer ではサポートされない機能

グローバル外部 Application Load Balancer では利用できず、従来の Application Load Balancer でしか利用できない機能としては、以下のようなものがあります。

Standard ティアのネットワーク（リージョナルロードバランサー）
GKE Ingress Controller

これらを利用したい場合、従来の Application Load Balancer を引き続き使用します。

なお、GKE でグローバル外部 Application Load Balancer を利用したい場合は、Ingress の変わりに Gateway リソースを使用することができます。

参考 : Network Service Tiers overview
参考 : About the Gateway API

ただし、従来の Application Load Balancer は今後、機能アップデートがされなくなったり、廃止になる可能性がゼロではありません。可能な限り、新しいグローバル外部 Application Load Balancer の使用を検討したほうが望ましいといえます。

移行の手順

当記事で使用する環境

当記事は、以下の記事と同様の構成、つまり Cloud Run のフロントエンドとして Application Load Balancer を構成している環境を利用します。

blog.g-gen.co.jp

この環境では、バックエンドサービスに Cloud Armor のセキュリティポリシーを紐づけ、また Identity-Aware Proxy（IAP）による認証機能を利用できるようにしています。

ロードバランサーの移行により、これらの機能の紐づけが維持されるかどうかも確認してみます。

移行対象となる従来の（クラシック）Application Load Balancer

バックエンドサービスで Cloud Armor セキュリティポリシーと IAP を利用している

バックエンドサービスの移行

移行の準備

ロードバランサーの移行は Google Cloud コンソールと gcloud CLI で実施することができます。当記事では基本的にはコンソールから操作を行っていきます。

ロードバランサーの移行手順として、バックエンドサービスの移行と転送ルールの移行をそれぞれ行う必要があります。まずはバックエンドサービスの移行を行っていきます。

ロードバランサーの詳細画面にある「移行」タブから、対象バックエンドサービスの「移行を管理」を選択します。

「準備」にチェックがついているので、そのまま「保存」を選択します。

ロードバランサーの更新が行われ、バックエンドサービスのステータスが「テスト準備完了」となります。

移行のテスト

バックエンドサービスのステータスが「テスト準備完了」となっている状態で、「移行を管理」を再度選択します。

移行のテストは、「割合を指定してテスト」と「すべてのトラフィックをテスト」の2種類を選択することができます。

「割合を指定してテスト」では、任意の割合のトラフィックを新しいバックエンドサービスにルーティングすることで、従来のロードバランサーのバックエンドサービスで引き続きトラフィックを処理しつつ、一部のトラフィックのみで新しいバックエンドサービスのテストを行うことができます。

当記事では、10%のトラフィックを新しいバックエンドサービスにルーティングしてテストを行います。「割合を指定してテスト」にチェックを入れ、「テストの割合」に10を入力して「保存」を選択します。

ロードバランサーの更新が行われ、バックエンドサービスがテスト中の状態になります。新しいバックエンドサービス（EXTERNAL_MANAGED）に10%のトラフィックがルーティングされる状態になっています。

トラフィックの割合はテスト中に変更することができます。ここでは「すべてのトラフィックをテスト」に変更してみます。

新しいバックエンドサービスにすべてのトラフィックがルーティングされる状態になりました。

サービスの URL にアクセスしてみると、移行先のバックエンドサービスでも IAP による認証が機能していることがわかります。

新しいバックエンドサービスにルーティングされても IAP の認証画面が表示される

また、Cloud Armor のセキュリティポリシーが機能しているかどうかも確認してみます。

当記事の構成ではアクセス元の IP アドレスを制限していますが、許可されていない IP アドレスからサービスにアクセスすると、セキュリティポリシーによってアクセスが拒否されます。

移行の実施

トラフィックが新しいロードバランサーで正しく処理されていることを確認したら、バックエンドの移行を行います。

対象バックエンドサービスの「移行を管理」から、「移行」にチェックを入れて「保存」を選択します。

ロードバランサーが更新され、バックエンドサービスのステータスが「移行済み」になります。

バックエンドサービスが複数ある場合は、ここまでの手順を繰り返し行います。

バックエンドバケットの移行

ここまででバックエンドサービスの移行を行いましたが、ロードバランサーでバックエンドバケットを使用している場合、転送ルールの移行の前にバックエンドバケットの移行を行う必要があります。

2025年5月現在、バックエンドバケットの移行はコンソールから行うことができず、gcloud CLI を使用する必要があります。詳細なコマンドについては以下のドキュメントを参照してください。

参考 : Migrate resources from classic to global external Application Load Balancer - Migrate the backend bucket

転送ルールの移行

移行の準備

バックエンドサービス同様に、転送ルールでも「準備」→「テスト」→「移行」の流れで作業を行っていきます。

対象の転送ルールの「移行を管理」を選択します。

「準備」にチェックがついているので、そのまま「保存」を選択します。

移行のテスト

転送ルールのステータスが「テスト準備完了」になるので、再度「移行を管理」を選択します。

転送ルールのステータスが「テスト準備完了」になったら再度「移行を管理」を選択する

バックエンドサービスの移行と同様に、移行のテストは「割合を指定してテスト」と「すべてのトラフィックをテスト」の2種類を選択することができます。

当記事では、ここでは最初から「すべてのトラフィックをテスト」を選択してテストを行います。

転送ルールのステータスが「テスト中 / すべてのトラフィックをテスト中」になったら、サービスに対してアクセスしてみます。

転送ルールのステータスが「テスト中 / すべてのトラフィックをテスト中」になっている

バックエンドサービスのテスト時同様、サービスに正常にアクセスすることができ、かつ IAP や Cloud Armor が機能していることを確認します。

転送ルールの移行テスト中でも Cloud Armor のセキュリティポリシーが機能している

問題なければ、再度「移行を管理」を選択します。

「移行」にチェックを入れて「保存」を選択すると、転送ルールの移行が実施されます。

これでバックエンドサービスと転送ルールの両方が移行済みとなり、従来の Application Load Balancer からグローバル外部 Application Load Balancer への移行は完了となります。

移行後も Cloud Armor セキュリティポリシーや IAP の設定が維持されている

ロールバック

ロールバックの概要

移行から90日以内であれば、従来の Application Load Balancer へのロールバックを行うことができます。

ロールバックは移行とは逆の順番（「転送ルールのロールバック」→「バックエンドバケットのロールバック」→「バックエンドサービスのロールバック」）で行います。

参考 : Roll back migrated resources to classic Application Load Balancer

転送ルールのロールバック

2025年5月現在、転送ルールのロールバックは gcloud CLI で実施する必要があります。以下のコマンドでロールバックを行います。

# 転送ルールのロールバック
$ gcloud compute forwarding-rules update {転送ルールの名前} \
  --load-balancing-scheme=EXTERNAL \
  --global

バックエンドバケットのロールバック

バックエンドバケットがある場合は、こちらも gcloud CLI でロールバックを行う必要があります。

ロールバックは「テスト」→「移行」のステップで行います。詳細なコマンドは以下のドキュメントを参照してください。

参考 : Roll back migrated resources to classic Application Load Balancer - Roll back the backend bucket

バックエンドサービスのロールバック

バックエンドサービスのロールバックは「テスト」→「移行」の順に行います。

転送ルールのロールバックが完了していると、コンソールではバックエンドサービスで「元に戻す」が選択できるようになっています（gcloud CLI でもロールバック可能）。

コンソールからロールバックする場合、転送ルールのロールバック後にバックエンドサービスの「元に戻す」を選択する

まず、「元に戻す」から「すべてのトラフィックでテストする」にチェックが入っている状態で「保存」を選択します。この時点ではまだトラフィックの移行は行われず、移行後（ロールバック前）のバックエンドサービスにトラフィックがルーティングされています。

6分程度待ってから、バックエンドサービスの「移行を管理」を選択します。

ロールバック前に、トラフィックの割合を指定したテストを行います（※「すべてのトラフィックをテスト」では移行後のバックエンドサービスにトラフィックがルーティングされるため注意）。

テストの割合を指定するとき、指定する割合が移行後（ロールバック前）のバックエンドサービス にルーティングする割合である点に注意します。たとえば移行前（ロールバック後）のバックエンドサービスに10%のトラフィックをルーティングしたい場合は90を入力します。

注意点として、6分程度待つことなくテストや移行を実行すると、以下のエラーが発生してしまう場合があります。

Invalid value for field 'resource.externalManagedMigrationState': 'TEST_BY_PERCENTAGE'. External managed migration state cannot be change to TEST_BY_PERCENTAGE yet. Please allow at least 6 minutes for previous change to propagate.

ここからさらに6分程度待ち、バックエンドサービスが問題なく動作しているかを確認します。

その後、「移行を管理」からテストの割合を0に設定することで、移行前（ロールバック後）のバックエンドサービスにすべてのトラフィックをルーティングします。

この時点で、ロードバランサーの種類は従来の（クラシック）Application Load Balancer にロールバックされています。

しかし、この状態ではバックエンドサービスの移行状態が「テスト中」のままとなります。

このままでもロードバランサー全体の動作に影響はありませんが、gcloud CLI で移行状態を元に戻します。

まず、バックエンドサービスのステータスをテスト前の状態である「テスト準備完了」にします。

# バックエンド サービスの移行状態を「テスト準備完了」にする
$ gcloud compute backend-services update {バックエンド サービスの名前} \
  --external-managed-migration-state=PREPARE \
  --global

6分程待ってから、バックエンドサービスのステータスを移行作業を始める前の「未開始」に戻します。

# バックエンド サービスのステータスを「未開始」にする（移行前の状態）
$ gcloud compute backend-services update {バックエンド サービスの名前} \
  --clear-external-managed-migration-state \
  --global

これで、「移行」タブの情報がロードバランサーの移行を実施する前の状態に戻ります。