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

リージョン ID

REGION_ID は、アプリの作成時に選択したリージョンに基づいて Google が割り当てる省略形のコードです。一部のリージョン ID は、一般的に使用されている国や州のコードと類似しているように見える場合がありますが、このコードは国または州に対応するものではありません。2020 年 2 月以降に作成されたアプリの場合、REGION_ID.r は App Engine の URL に含まれています。この日付より前に作成されたアプリの場合、URL のリージョン ID は省略可能です。

詳しくは、リージョン ID をご覧ください。

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

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

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

App Engine のカスタム ドメインを取得し、受信リクエストを Cloud Load Balancing フロントエンド サービスにシフトして、リクエストをバックエンドの App Engine サービスに分散します。

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 ロールが必要です。

タスク 必要なロール
Certificate Manager を使用して Google マネージド SSL 証明書を作成する Certificate Manager オーナーまたは Certificate Manager 編集者および Compute ロードバランサ管理者
カスタム ドメインの DNS レコードを更新する Cloud DNS 管理者（DNS ソリューションとして Cloud DNS を使用する場合）

別の DNS プロバイダを使用する場合は、カスタム ドメインの DNS レコードを追加および更新するための権限が必要です。
ロードバランサとネットワーク コンポーネントの作成 Compute ネットワーク管理者
NEG の作成と変更 Compute インスタンス管理者
SSL 証明書の作成と変更 Compute セキュリティ管理者
App Engine 設定でカスタム ドメインを削除する App Engine 管理者ロール、または appengine.applications.update 権限を含むロール

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 ソリューションのどちらを使用するかに応じて、ユースケースに適した手順を行います。

Cloud DNS

DNS 認証を作成するとき、gcloud コマンドは対応する CNAME レコードを返します。次のように、この CNAME レコードをターゲット ドメインの DNS ゾーンの DNS 構成に追加する必要があります。

  1. DNS レコード トランザクションを次のように開始します。

    gcloud dns record-sets transaction start --zone="DNS_ZONE_NAME"

    DNS_ZONE_NAME は、一般公開 DNS ゾーンの名前に置き換えます。Google Cloud を使用してドメインを管理し、そのドメインへのトラフィックを受信している場合は、一般公開 DNS ゾーンをすでに作成済みのはずです。一般公開 DNS ゾーンを表示するには、マネージド ゾーンのリストと説明をご覧ください。

  2. CNAME レコードをターゲット DNS ゾーンに追加します。

    gcloud dns record-sets transaction add CNAME_RECORD \
  --name="_acme-challenge.DOMAIN_NAME." \
  --ttl="30" \
  --type="CNAME" \
  --zone="DNS_ZONE_NAME"

    次のように置き換えます。

    • CNAME_RECORD は、対応する DNS 認証を作成した gcloud コマンドから返される CNAME レコードの完全な値です。
    • DOMAIN_NAME は、App Engine カスタム ドメイン名です。ターゲット ドメイン名の末尾にピリオドを含める必要があります。
    • DNS_ZONE_NAME は、前述のターゲット DNS ゾーンの名前です。

  3. 次のように DNS レコード トランザクションを実行して変更を保存します。

    gcloud dns record-sets transaction execute --zone="DNS_ZONE_NAME"

    DNS_ZONE_NAME は、前述のターゲット DNS ゾーンの名前に置き換えます。

その他の DNS ソリューション

前のセクションの名前（ホスト名）（_acme-challenge.DOMAIN_NAME）とデータ フィールドを使用して、ドメインの DNS 構成に CNAME レコードを追加します。サードパーティ 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 のトラブルシューティングをご覧ください。

証明書マップを作成する

  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 ロードバランサを示しています。

App Engine アプリにトラフィックを分散する

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

外部 IP アドレスを予約する

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

コンソール

  1. Google Cloud コンソールで [外部 IP アドレス] ページに移動します。

    [外部 IP アドレス] に移動

  2. [静的アドレスを予約] をクリックして、IPv4 アドレスを予約します。

  3. 静的アドレスの名前を割り当てます（例: appengine-external-ip）。

  4. ネットワーク階層を [プレミアム] に設定します。

  5. [IP バージョン] を IPv4 に設定します。

  6. [タイプ] で [グローバル] をオンにします。

  7. [予約] をクリックします。

gcloud

  1. 次のように外部 IP アドレス予約を作成します。

    gcloud compute addresses create EXTERNAL_IP \
    --network-tier=PREMIUM \
    --ip-version=IPV4 \
    --global

    EXTERNAL_IP は、作成するアドレスの名前です。

  2. 予約された IPv4 アドレスをメモします。

    gcloud compute addresses describe EXTERNAL_IP \
    --format="get(address)" \
    --global

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 は、HTTP プロキシにネットワーク トラフィックを転送するための転送ルールを表す一意の名前です。
    • TARGET_HTTPS_PROXY_NAME は、前述の HTTPS プロキシの名前です。
    • EXTERNAL_IP は、以前に作成した IPv4 アドレスの名前です。

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

ロードバランサの構成が完了した後は、ドメインを移行する前に、テストとしてロードバランサの IP アドレスにトラフィックを送信し始めることができます。

  1. Google Cloud コンソールの [ロード バランシング] ページに移動します。
    [ロード バランシング] に移動
  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 上り（内向き）制御を構成する方法については、上り（内向き）設定をご覧ください。