これまでプレビュー版として提供されていた「従来のアプリケーションロードバランサからグローバル外部アプリケーションロードバランサへの移行機能」が、2025/5/19 に一般提供（GA）となりました。
今回は、この移行機能の概要や、そもそもいつ移行するべきか、実際の移行手順と確認ポイントなどについて紹介していきます。

移行機能とは

今回 GA となった移行機能は、従来のアプリケーションロードバランサ（以下、従来の ALB）を利用している場合に、より高度な機能を備えているグローバル外部アプリケーションロードバランサ（以下、グローバル外部 ALB）へ、各リソースをスムーズに移行してくれるものです。

これまでは、グローバル外部 ALB のメリットを享受したくても、既存の環境からの切り替えには手間やリスクが伴いました。
しかし、この移行機能を使うことで、既存の IP アドレスや SSL 証明書を維持したまま、段階的に新しいインフラストラクチャへと移行を進めることが可能になります。

従来の ALB とグローバル外部 ALB の違い

基盤アーキテクチャはどちらも Google Front End (GFE) 上に実装されており、基本的な機能は両方とも備わっています。
ただ、グローバル外部 ALB は Envoy プロキシが統合されているため、以下で挙げる高度なトラフィック管理を実現しています。
その他にもよりグローバルに特化した機能がサポートされています。

  • 高度なトラフィック管理に対応
  • プレミアム ネットワークティア上のグローバル エニーキャスト外部 IP アドレス
  • 複数のリージョンのバックエンドにアクセス可能

なお、以下の機能は従来の ALB でのみ使用できます。

  • スタンダード ネットワークティア
  • GKE Ingress Controller（グローバル外部 ALB では、代わりに GKE Gateway Controller を使用可）

データプレーンの違いについては、公式ドキュメントに詳しく記載されていますので併せてご覧ください。

移行プロセス

この移行プロセスは、単にメタデータのフラグを変更するだけではなく、ロードバランシングスキームを既存のリソースで使われている EXTERNAL から EXTERNAL_MANAGED を使用するように再構成するものです。
バックエンドサービスやバックエンドバケットといったリソースごとに個別の移行ステップが存在し、転送ルール全体を切り替える前に、これらのコンポーネントを新しいインフラストラクチャ上でテストすることができます。
モジュール性や段階的なリスク管理が考えられており、利用者が安心できる設計ですね。

移行前から移行完了までのプロセスを図解すると以下のようなイメージです。

では、マネジメントコンソールから実際にやってみましょう。

1. 準備

移行対象となる従来の ALB のページへアクセスします。
このように大々的な案内も出ていますね。

ロードバランサ名の下にある「移行」タブに移動します。

すると、このロードバランサの各リソースの移行状況が一覧で表示されます。
移行前なので、未開始のところにバックエンドサービスと転送ルールの 2 つのリソースがある状態です。

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

まず初めにバックエンドサービスを移行します。バックエンドサービスを先に移行しないと転送ルールの移行はできません。
先程の画面の対象リソースから「移行を管理」を選択します。

画面右側に以下が表示されます。まずは「準備」を行う必要があるため、そのまま保存します。
ここでは EXTERNAL_MANAGED スキームのリソースが内部で用意されますが、トラフィックはまだ EXTERNAL スキームに送られます。

少しすると、対象リソースが「テスト準備完了」へ移動されたことを確認できます。
この後の工程でも同様に、段階的に移行を行っていきます。

再び「移行を管理」を選択します。次の段階では、先程作成された EXTERNAL_MANAGED スキームのリソースのテストを行います。
テストを行うトラフィックの割合をこちらで決めるか、全てのトラフィックでテストを行うかを選択できます。
今回は全てのトラフィックでテストを行う方法としました。

完了すると、対象リソースが「すべてのトラフィックをテスト中」へ移動されましたね。
EXTERNAL_MANAGED スキームが使用されているとはいえ、まだテスト段階のため、グローバル外部 ALB の機能は使えません。

再び「移行を管理」を選択し、「移行」を選択して保存します。
画面上にある通り、変更してから 90 日以内であれば移行したリソースのロールバックが可能です。

対象リソースが「移行済み」へ移動されると、バックエンドサービスの移行が完了です。
この時点で、バックエンドサービスに関連するグローバル外部 ALB の機能が利用できるようになります。

3. 転送ルールの移行

最後に転送ルールを移行します。これまでと同様に、対象リソースから「移行の管理」を選択し、順番に行っていきましょう。
ほとんど同じ手順だったので説明は省きます。

※バックエンドバケットを使用している場合
バックエンドバケットにはロードバランシングスキームがないため、転送ルールの移行を行うことで更新が可能です。

転送ルールの移行ができたら、全ての移行プロセスが完了です！
最終的に以下のような表示になっていると思います。赤枠部分が確認ポイントです。

ページを更新すると、従来の ALB と表示されていた部分が、グローバル外部 ALB に変わりました。

同時に「移行」タブが消えていました。ここからロールバックを行いたい場合は CLI で行う必要があります。
具体的なロールバック手順は公式ドキュメントを参照してください。
移行されたリソースを従来のアプリケーション ロードバランサにロールバックする

移行に伴う注意点

バックエンドサービスでセッションアフィニティを使用している場合、以下の点に注意してください。

  • トラフィックのテストによる影響
    • トラフィックがグローバル外部 ALB へリダイレクトされる際にクライアント IP アフィニティが一時的に失われます。トラフィックの割合を変更した場合も同様です。
    • この設定によりセッション Cookie のないトラフィックもグローバル外部 ALB へリダイレクトされます。一方、セッション Cookie を持つトラフィックは、その Cookie を発行した元のロードバランサに引き続き振り分けられます。
  • Cookie が無効になるケース
    • 「トラフィックのテスト」の割合を 0% に設定する、未設定のままにする、またはバックエンドサービスを「準備」状態にすると、グローバル外部 ALB へ転送される既存の Cookie はすべて無効になります。
    • バックエンドサービスのロードバランシングスキームを EXTERNAL_MANAGED に変更すると、従来の ALB によって生成されたすべての Cookie が無効になります。この場合、グローバル外部 ALB は新たな Cookie を作成します。

おわりに

今回は、従来の ALB からグローバル外部 ALB への移行機能についてでした。
GA された機能で、かつダウンタイムが発生しない移行プロセスとなっているため、本番環境でも行いやすい点が魅力に感じますね。
ただ、現状従来の ALB が利用できなくなるような状況ではないため、移行は必須というわけではありません。
グローバル外部 ALB のユースケースに合致した際には検討しましょう！

参考
グローバル外部アプリケーション ロードバランサへの移行
従来のグローバル外部アプリケーションロードバランサからの移行