App Engine のカスタム ドメインを Cloud Load Balancing に移行する

このガイドでは、Cloud Load Balancing を使用して App Engine アプリ用の新しいパブリック エンドポイントを設定する方法について説明します。

Cloud Load Balancing では、カスタム ドメイン エンドポイントをフロントエンド サービスとして構成し、サーバーレス ネットワーク エンドポイント グループ（NEG）を使用して App Engine アプリをバックエンド サービスとして構成します。Cloud Load Balancing フロントエンド サービスのエンドポイントへのトラフィックは、アプリの dispatch.yaml ファイルで定義されるすべてのルーティング ルールを含め、以前と同じ方法でルーティングされます。

次の図は、アプリの変更内容を示しています。

Cloud Load Balancing に移行することで、Cloud Storage から静的コンテンツを提供する、または Cloud Run や Google Kubernetes Engine などの他のコンピューティング プラットフォームで実行するサービスを追加するなど、ドメインに到達する際にトラフィックがどのように処理されるかを柔軟に判断できます。

また、App Engine では利用できない次のような Google Cloud の主要機能にもアクセスできます。

• Google Cloud Armor、高度な DDoS 対策、IP ベースと位置情報ベースのアクセス制御、ウェブ アプリケーション ファイアウォール ルールなどでセキュリティを強化します。
• Cloud CDN を使用したキャッシュによるコンテンツ配信。
• SSL ポリシー、アプリが受け入れる SSL 機能と TLS バージョンを管理します。

このガイドでは、カスタム ドメインを使用する App Engine サービスから受信されるリクエストを Cloud Load Balancing フロントエンド サービスにシフトするための次のような設定手順を説明します。

1. 必要な権限があることを確認する
2. Google マネージド証明書を作成する
3. Cloud Load Balancing の構成
4. ロードバランサをテストする
5. ドメインをロードバランサに接続する
6. App Engine のカスタム ドメイン マッピングを削除する
7. Cloud Load Balancing を使用したアクセスのみを許可するように上り（内向き）制御を設定する

始める前に

カスタム ドメインが App Engine の設定で構成されている App Engine アプリを入手します。

権限を構成

このガイドの説明に従って操作するには、プロジェクト内に Google マネージド証明書、サーバーレス NEG、外部 HTTP(S) ロードバランサを作成する必要があります。そのためにはプロジェクトのオーナーまたは編集者であるか、次の IAM ロールが必要です。

Google マネージド SSL 証明書を作成する

Google マネージド SSL 証明書（ドキュメントでは TLS 証明書ともいう）を使用すると、Google Cloud で証明書を自動的に取得、管理、更新できます。既存の App Engine サービスのダウンタイムを発生させずに Cloud Load Balancing フロントエンドに移行するには、Certificate Manager を使用して、DNS 認証と Google マネージド証明書を作成する必要があります。

Cloud Load Balancing のドキュメントには、Google マネージド SSL 証明書の作成と同様の手順が記載されていますが、この手順ではロードバランサの承認を使用します。これには数時間かかる可能性のある App Engine サービスのダウンタイムが必要です。詳細については、Google マネージド証明書のドメイン認証をご覧ください。

アプリのダウンタイムを回避するには、このページの手順を行ってください。

DNS 認証 の作成

1. 次のコマンドを実行して、Certificate Manager で DNS 認証を作成します。

   gcloud certificate-manager dns-authorizations create AUTHORIZATION_NAME \
       --domain="DOMAIN_NAME"
   gcloud certificate-manager dns-authorizations describe AUTHORIZATION_NAME
   

   以下を置き換えます。

   • AUTHORIZATION_NAME は、この DNS 認証を説明する一意の名前です。
   • DOMAIN_NAME は、この DNS 認証を作成する App Engine カスタム ドメイン名です。

2. gcloud コマンドから返される CNAME をメモします。これを、次の手順で DNS レコードを更新する際に使用する必要があります。

DNS 構成に CNAME レコードを追加する

Cloud DNS と別のサードパーティ DNS ソリューションのどちらを使用するかに応じて、ユースケースに適した手順を行います。

DNS 認証を参照する Google マネージド証明書を作成する

前の手順で作成した DNS 認証を参照する Google マネージド証明書を作成するには、次のコマンドを実行します。

1. Google マネージド証明書を作成します。

   gcloud certificate-manager certificates create CERTIFICATE_NAME \
   --domains=DOMAIN_NAME --dns-authorizations=AUTHORIZATION_NAME
   

   以下を置き換えます。

   • CERTIFICATE_NAME は、証明書を説明する一意の名前です。
   • DOMAIN_NAME は、App Engine カスタム ドメイン名です。
   • AUTHORIZATION_NAME は、以前に作成した DNS 認証の名前です。

2. 証明書が有効になっていることを確認します。

   次のコマンドを使用して、証明書をロードバランサにデプロイする前に、証明書自体が有効であることを確認します。証明書の状態が ACTIVE に変わるまでに数時間かかることがあります。

   gcloud certificate-manager certificates describe CERTIFICATE_NAME
   

   CERTIFICATE_NAME は、以前に作成した Google マネージド証明書の名前に置き換えます。

   gcloud ツールは次のような出力を返します。

   certificatePem: myPEM
   createTime: '2021-10-20T12:19:53.370778666Z'
   expireTime: '2022-05-07T05:03:49Z'
   managed:
     authorizationAttemptInfo:
     - domain: example.com
       state: AUTHORIZED
     dnsAuthorizations:
     - projects/my-project/locations/global/dnsAuthorizations/myAuth
     domains:
     - example.com
     state: ACTIVE
   name: projects/myProject/locations/global/certificates/myCert
   scope: myScope
   sanDnsnames:
   - example.com
   updateTime: '2021-10-20T12:19:55.083385630Z'
   

   これとは異なる出力を gcloud ツールが返す場合は、Certificate Manager のトラブルシューティングをご覧ください。

CertificateMap を作成する

1. 証明書マップ を作成する

   gcloud certificate-manager maps create CERTIFICATE_MAP_NAME
   

   CERTIFICATE_MAP_NAME は、証明書マップを説明する一意の名前に置き換えます。

2. 証明書マップエントリを作成し、前述の証明書と証明書マップに関連付けます。

   gcloud certificate-manager maps entries create CERTIFICATE_MAP_ENTRY_NAME \
       --map=CERTIFICATE_MAP_NAME \
       --certificates=CERTIFICATE_NAME \
       --set-primary
   

   以下を置き換えます。

   • CERTIFICATE_MAP_ENTRY_NAME は、この証明書マップエントリを説明する一意の名前です。
   • CERTIFICATE_MAP_NAME は、この証明書マップエントリの接続先である証明書マップの名前です。
   • CERTIFICATE_NAME は、この証明書マップエントリに関連付ける証明書の名前です。

   ドメイン名が指定されていない場合は、--set-primary フラグを追加して、証明書がデフォルトの証明書として使用されるようにします。

3. 証明書マップが有効であることを確認します。

   次のコマンドを使用して、対応する証明書マップをターゲット プロキシに添付する前に、証明書マップエントリがアクティブであることを確認します。

   gcloud certificate-manager maps entries describe CERTIFICATE_MAP_ENTRY_NAME \
       --map=CERTIFICATE_MAP_NAME
   

   以下を置き換えます。

   • CERTIFICATE_MAP_ENTRY_NAME は、以前の証明書マップエントリ名です。
   • CERTIFICATE_MAP_NAME は、この証明書マップエントリの接続先である証明書マップ名です。

   gcloud ツールは次のような出力を返します。

   createTime: '2021-09-06T10:01:56.229472109Z'
   name: projects/my-project/locations/global/certificateMaps/myCertMap/certificateMapEntries/myCertMapEntry
   state: ACTIVE
   updateTime: '2021-09-06T10:01:58.277031787Z'
   

Certificate Manager の詳しい使用方法については、Certificate Manager の仕組みをご覧ください。

Cloud Load Balancing の構成

Google マネージド証明書を取得した後は、App Engine カスタム ドメインを Cloud Load Balancing フロントエンド サービスに置き換えることができます。

次の図は、単一のバックエンド サービスとサーバーレス NEG を使用する HTTPS ロードバランサを示しています。

転送ルールは、外部 IP アドレスからの受信リクエストをターゲット HTTPS プロキシにルーティングして転送します。HTTPS ロードバランサは URL マップを使用してリクエストを転送します。転送先のバックエンド サービスには App Engine サービス用のサーバーレス NEG が含まれています。

外部 IP アドレスを予約

Cloud Load Balancing を構成する前に、ユーザーがロードバランサに到達できるように、グローバル静的外部 IP アドレスを設定する必要があります。

App Engine のバックエンド サービスを構成する

ロードバランサ用のバックエンド エンドポイントのグループを指定するには、ネットワーク エンドポイント グループ（NEG）が使用されます。App Engine サービスを参照するバックエンドを指定するには、サーバーレス NEG を構成した後、Cloud Load Balancing でバックエンド サービス、ルーティング ルール、フロントエンド サービスを構成します。

1. App Engine アプリ用のサーバーレス NEG を次のように作成します。

   gcloud compute network-endpoint-groups create APP_ENGINE_NEG \
   --network-endpoint-type=serverless \
   --app-engine-app \
   --region=APP_ENGINE_REGION
   

   以下を置き換えます。

   • APP_ENGINE_NEG は、ネットワーク エンドポイント グループの名前です。
   • APP_ENGINE_REGION は、App Engine で設定されたリージョンです。

   デフォルトのルーティングを使用するには、特定の App Engine サービスへの転送ではなく、上記の --app-engine-app フラグを追加します。デフォルト ルーティングを使用すると、リクエストはデフォルト サービス（https://PROJECT_ID.REGION_ID.r.appspot.com）に送信され、それ以外の場合は dispatch.yaml ファイルで定義したすべてのルーティング ルールに従います。これは、App Engine を使って構成されるカスタム ドメインと同じ動作です。

2. バックエンド サービスを作成します。

   gcloud compute backend-services create APP_ENGINE_BACKEND \
     --global \
     --load-balancing-scheme=EXTERNAL_MANAGED
   

   APP_ENGINE_BACKEND は、作成するバックエンド サービスの名前に置き換えます。

3. サーバーレス NEG を App Engine バックエンド サービスに追加します。

   gcloud compute backend-services add-backend APP_ENGINE_BACKEND \
   --global --network-endpoint-group=APP_ENGINE_NEG \
   --network-endpoint-group-region=APP_ENGINE_REGION
   

   以下を置き換えます。

   • APP_ENGINE_BACKEND は、以前のバックエンド サービスの名前です。
   • APP_ENGINE_NEG は、ネットワーク エンドポイント グループの名前です。
   • APP_ENGINE_REGION は、App Engine で設定されたリージョンです。

4. 受信リクエストをバックエンド サービスに転送するための URL マップを作成します。

   gcloud compute url-maps create URL_MAP_NAME \
         --default-service APP_ENGINE_BACKEND
   

   以下を置き換えます。

   • URL_MAP_NAME は、バックエンド サービスへの URL のマッピングを定義する URL マップリソースの一意の名前です。
   • APP_ENGINE_BACKEND は、以前のバックエンド サービスの名前です。

5. URL マップにリクエストをルーティングするターゲット HTTPS プロキシを作成します。

   gcloud compute target-https-proxies create TARGET_HTTPS_PROXY_NAME \
         --certificate-map=CERTIFICATE_MAP_NAME \
         --url-map=URL_MAP_NAME
   

   以下を置き換えます。

   • TARGET_HTTPS_PROXY_NAME は、HTTPS プロキシを記述するために選択する一意の名前です。
   • CERTIFICATE_MAP_NAME は、証明書マップエントリおよび関連する証明書を参照する証明書マップの名前です。
   • URL_MAP_NAME は、以前の URL マップの名前です。

6. 受信リクエストをプロキシに転送する転送ルールを作成します。

   gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \
         --load-balancing-scheme=EXTERNAL_MANAGED \
         --network-tier=PREMIUM \
         --address=EXTERNAL_IP \
         --target-https-proxy=TARGET_HTTPS_PROXY_NAME \
         --global \
         --ports=443
   

   以下を置き換えます。

   • HTTPS_FORWARDING_RULE_NAME は、HTTPS ネットワークにネットワーク トラフィックを転送するための転送ルールを記述する一意の名前です。
   • TARGET_HTTPS_PROXY_NAME は、以前の HTTPS プロキシの名前です。
   • EXTERNAL_IP は、以前に作成した IPv4 アドレスの名前です。

ロードバランサをテストする

ロードバランサを構成したので、ドメインを移行する前に、ロードバランサの IP アドレスへのトラフィックの送信を開始して、テストできるようになりました。

1. Google Cloud Console の [ロード バランシング] ページに移動します。
   [ロード バランシング] に移動
2. 作成したロードバランサをクリックします。
3. ロードバランサの IP アドレスをメモします。

4. HTTPS ロードバランサの場合は、ウェブブラウザを使用して https://IP_ADDRESS に移動し、ロードバランサをテストします。IP_ADDRESS は、ロードバランサの IP アドレス（30.90.80.100 など）に置き換えます。

   • 結果に問題があり、Google マネージド証明書を使用している場合は、証明書は ACTIVE であり、またその証明書マップが ACTIVE であることを確認してください。
   • テストに自己署名証明書を使用した場合、ブラウザに警告が表示されます。自己署名証明書を受け付けるためには、ブラウザで明示的に設定する必要があります。警告は無視してクリックし、実際のページを表示してください。

   その他の構成オプションについては、サーバーレス プラットフォームを使用してグローバル外部 HTTP(S) ロードバランサを設定するをご覧ください。

ドメインをロードバランサに接続する

ロードバランサが作成されたら、ロードバランサに関連付けられた IP アドレスをメモします（例: 30.90.80.100）。ドメイン登録サービスを使用して A レコードを作成し、ドメインがロードバランサを参照するようにします。SSL 証明書に複数のドメインを追加する場合は、それぞれについて A レコードを追加して、すべてがロードバランサの IP アドレスを指すようにする必要があります。たとえば、www.example.com と example.com に A レコードを作成するには、次のようにします。

NAME                  TYPE     DATA
www                   A        30.90.80.100
@                     A        30.90.80.100

DNS プロバイダとして Cloud DNS を使用する場合は、レコードの追加、変更、削除をご覧ください。

App Engine のカスタム ドメイン マッピングを削除する

Google Cloud コンソールの場合:

1. App Engine の [設定] ページの [カスタム ドメイン] タブに移動します。

   [カスタム ドメイン] に移動

2. カスタム ドメイン名を選択し、[削除] をクリックします。

あるいは、gcloud コマンドまたは Admin API を使用してカスタム ドメインを削除することもできます。

Cloud Load Balancing を使用したアクセスのみを許可するように上り（内向き）制御を設定する

ロードバランサをテストした後は、Cloud Load Balancing からのトラフィックのみを受け入れるように App Engine アプリを更新することをおすすめします。internal-and-cloud-load-balancing 上り（内向き）制御を構成する方法については、上り（内向き）設定をご覧ください。