投稿日：
更新日：

Cloud Run Domain Mapping から撤退する

Authors

目次


はじめに

Cloud Run には標準で *.run.app というドメインが付与されますが、サービスとして公開する際には独自のカスタムドメインを割り当てたいケースがほとんどです。 Cloud Run ではカスタムドメインを割り当てるための機能として Domain Mapping と呼ばれる仕組みを提供しています。

Domain Mapping は非常に手軽に利用できる一方で、レイテンシの問題や証明書管理の柔軟性等、本番運用においていくつか懸念となる点も存在します。

今回のブログでは、Cloud Run Domain Mapping の仕組みと、撤退するに至った理由、また移行時のダウンタイムを最小限に抑えるマイグレーション戦略について紹介したいと思います。

Cloud Run Domain Mapping

Cloud Run Domain Mapping は Cloud Run Service にカスタムドメインを直接マッピングする機能です。 （Cloud Run Job では利用できません。）

主要な機能として以下が提供されています。

  • 任意のカスタムドメインを Cloud Run Service に接続する
  • 自動的に HTTPS（SSL/TLS）証明書が設定される（例：Google Managed Certificate）
  • リクエストを Cloud Run Service にセキュアにルーティングする

Cloud Run Domain Mapping を設定すると、以下のフローでリクエストが処理されます。

  1. ユーザがカスタムドメイン（例：service.example.com）にアクセス
  2. DNS が ghs.googlehosted.com に解決される（CNAME レコード設定が必要）
  3. Google Cloud のエッジサーバが SNI（Server Name Indication） でドメイン名を識別
  4. 内部マッピングテーブルを参照して該当する Cloud Run Service へルーティング
domain-mapping-request-flow.png

ここで注意しておくべき点は、Cloud Run Domain Mapping は A レコードを直接 Cloud DNS に登録するわけではない ということです。 あくまで Google が管理する ghs.googlehosted.com というエントリポイントに対してエイリアスを貼る形で動作します。

課題と撤退理由

手軽さが魅力の Domain Mapping ですが、以下の理由から利用を停止し、Global External HTTPS Load Balancer（GCLB）構成へ移行することにしました。

1. レイテンシ増大

カスタムドメインを使用すると通信が ghs.googlehosted.com を経由しますが、これをホスティングするサーバのロケーションによっては大きなレイテンシが発生します。

特に asia-northeast1 や us-east4 で Cloud Run を運用している場合でも、Domain Mapping を経由すると通信が一度アメリカを経由して戻ってくるような挙動（ヘアピンルーティング）になるケースが報告されています。 これにより、日本国内からのアクセスであっても通信遅延が数倍になることがあります。

通常の GCLB を使用した場合、Google の強力なエッジネットワーク（Premium Network Tier）を利用して最寄りのエッジから Google 内部ネットワークに入れるため、このような遅延は発生しません。

2. 機能制限

Cloud Run Domain Mapping はあくまでドメインをマッピングするだけのシンプルな機能で、現在も Preview（本番非推奨） となっています。 そのため、GCLB で提供されているような高度な機能は利用できず、本番環境での利用には制約があります。

  • Cloud Armor が使えない：セキュリティ対策として IP 制限や WAF を適用できない
  • Cloud CDN が使えない：静的コンテンツのキャッシュができない
  • 柔軟なルーティングができない：マルチリージョン振り分けや、パスベース（/api 等）のルーティングができない
  • TLS バージョンの制御不可：TLS 1.0/1.1 を無効化できない（GCLB や Firebase Hosting は可能）
  • 証明書の制限：自己管理証明書やワイルドカード証明書（*.example.com）は利用できない

将来的な拡張性やセキュリティ要件を考慮すると、最初から GCLB + Serverless NEG の構成にしておく方がメリットが大きいです。

External Global HTTPS Load Balancer + Serverless NEG への移行

ここからは、実際に本番環境え運用している Cloud Run Domain Mapping を External Global HTTPS Load Balancer + Serverless NEG 構成へ移行する方法について紹介します。

移行における最大の課題はダウンタイムをいかに最小限に抑えるかという点です。 通常、ドメインの切り替えや証明書の発行には時間がかかるため、単純に切り替えると証明書エラー（発行・適用）や名前解決エラーが発生する時間帯が生まれてしまいます。

今回はワイルドカード証明書（Self-managed Certificate）を事前に用意することで、ダウンタイムを最小限に抑えた移行作業を試みます。

移行後の構成は以下のようになります。

gclb-serverless-neg-architecture.png

Certificate Manager の Certificate Map を利用し、事前に用意したワイルドカード証明書と、後から発行する Google マネージド証明書を柔軟に切り替えます。

ダウンタイムを考慮した移行戦略

Cloud Run Domain Mapping から GCLB への移行において、注意すべき点は 証明書の切り替え です。

Cloud Run Domain Mapping では Google マネージド証明書が自動的にプロビジョニングされ利用されています。 GCLB 構成へ移行する際にも同様にマネージド証明書を利用したいところですが、マネージド証明書の発行（プロビジョニング）には DNS が GCLB の IP を向いている必要があり、プロパゲーションを考慮すると最大 72 時間掛かることもあります。

Newly updated DNS A and AAAA records can take a significant amount of time to be fully propagated. Sometimes propagation across the internet takes up to 72 hours worldwide, although it typically takes a few hours.

マネージド証明書の発行にはドメイン検証が必要であり、これは Google 側がインターネット上の複数の場所から DNS レコードを確認し、GCLB の IP を向いているかをチェックすることで行われます。 DNS 切り替え直後は、キャッシュの影響等により世界中の DNS サーバへの伝播に時間がかかる場合があるため、Google 側での検証が完了する（証明書が ACTIVE になる）までにタイムラグが発生します。

そのため、単純に切り替えてしまうと証明書が発行されるまでの間、HTTPS 通信ができずサービス停止が発生することになります。

この問題を回避してダウンタイムを最小限に抑えるために、以下の流れで移行作業を実施します。

  1. ワイルドカード証明書の準備：事前にドメインに対するワイルドカード証明書（Self-managed）を用意して GCLB にアタッチする
  2. ダミードメインでの検証：本番ドメインの前に、ダミードメイン（例：dummy-service.example.com）を使って GCLB とワイルドカード証明書の動作確認を行う
  3. 本番ドメインの切り替え：ワイルドカード証明書が有効な状態で DNS を切り替えることで、即座に HTTPS 通信を可能にする
  4. マネージド証明書への移行：DNS 切り替え後にバックグラウンドでマネージド証明書を発行し、完了次第そちらに切り替える

移行手順

cloudrun-configuration-migration.png

前提の確認

以下の Cloud Run Domain Mapping を利用する Cloud Run Service を例に移行手順をまとめます。

  • A レコード：domain-mapping-migration.example.com
  • CNAME レコード：ghs.googlehosted.com
cloudrun.tf
dns.tf

動作確認用の curl 結果：

移行先 Cloud Run Service の定義

同じく Cloud Run Service を定義します。

ここでは、旧 Cloud Run Service（Domain Mapping を利用する Cloud Run Service）と区別するために v2 タグを切ってデプロイしておきます。

cloudrun.tf

GCLB / Serverless NEG / 証明書の準備

以下の構成を参考に External Global HTTPS Load Balancer + Serverless NEG を準備します。

ここで、Self-managed Certificate を利用してワイルドカード証明書（*.example.com）を事前に発行し、GCLB にアタッチします。 Self-managed 証明書の発行元は問いません。CyberTrust 等の商用認証局で取得したものでも、Let's Encrypt 等で発行した無料の証明書でも利用可能です。

今回は Secret Manager にワイルドカード証明書を事前にアップロードしておき、それを利用する方法を紹介しますが、実際の環境に合わせて読み込み方法は変更してください。

secret_manager.tf
  • ダミー A レコード：dummy-domain-mapping-migration.example.com
load_balancer.tf
dns.tf

この状態で、ダミードメインに対する Certificate Map Entry が ACTIVE になっていることを確認します。 ワイルドカード証明書を使っているため、ドメイン検証なしで即座に ACTIVE になるはずです。

また、この時点では正規ドメインに対する Certificate Map Entry のステータスは PENDING となります。 これは Certificate Manager がドメインと証明書の整合性を検証する際、正規ドメイン（domain-mapping-migration.example.com）の DNS がまだ Cloud Run Domain Mapping を向いており、GCLB（Certificate Map）との紐付けが確認できないためです。

この段階でワイルドカード証明書自体は有効であるため、DNS さえ切り替われば即座に通信可能な状態となります。

ドメイン証明書ステータス
dummy-domain-mapping-migration.example.comACTIVE
domain-mapping-migration.example.comPENDING

動作確認用の curl 結果：

DNS 切り替え

Cloud Run Domain Mapping で利用しているカスタムドメインと同じ A レコードを重複して発行することはできません。 これは Cloud DNS 上で同じドメイン名に対して CNAME レコード（Domain Mapping 用）と A レコード（GCLB 用）を共存させることができないためです。

そのため、Domain Mapping の削除と A レコードの追加は同時に実施する 必要があります。

  1. Domain Mapping の削除：google_cloud_run_domain_mapping リソースと、それに対応する DNS レコード（CNAME ghs.googlehosted.com）を削除する
dns.tf
  1. A レコードの追加：GCLB の IP アドレス（google_compute_global_forwarding_rule で払い出された IP）に向けた A レコードを追加する
dns.tf

この間、DNS キャッシュが残っているクライアントは旧 Cloud Run Service へ、新しいレコードを引いたクライアントは移行先の Cloud Run Service へアクセスします。 新構成側の Cloud Run Service は既にワイルドカード証明書で待ち受けているため、どちらに転送されても正しくレスポンスを返すことができます。 これによりダウンタイムを最小限に抑えた移行が実現します。

Certificate Map が正規ドメイン（domain-mapping-migration.example.com）で有効になっていることを確認します。

ドメイン証明書ステータス
dummy-domain-mapping-migration.example.comACTIVE
domain-mapping-migration.example.comACTIVE

ダミー A レコードの削除

証明書の検証用に追加したダミー A レコードと Certificate Map Entry を削除しておきます。

dns.tf
load_balancer.tf

これでユーザは正規ドメイン（domain-mapping-migration.example.com）のみを介して、新構成の Cloud Run Service にアクセスするようになります。

Google マネージド証明書への移行

切り替えが完了し、トラフィックが GCLB に流れるようになったら、運用負荷を下げるために Google マネージド証明書へ移行します。

なお、今後も Self-managed 証明書を利用する場合は、以降の作業を実施する必要はありません。

DNS が既に GCLB を向いているため、Google マネージド証明書のドメイン検証は自動的に完了します。

load_balancer.tf

Google マネージド証明書のステータスが AUTHORIZING → AUTHORIZED になるのを待ちます。 前述の通り、これには最大数時間 〜 72 時間掛かりますがユーザには影響しません。

発行中

発行済み

ワイルドカード証明書の削除

Google マネージド証明書の証明書ステータスが ACTIVE になったことを確認したら、数日様子を見てワイルドカード証明書を Certificate Map Entry から外します。

load_balancer.tf

これで移行は完了となります。

移行作業時の注意点

TTL の設定

切り替え前には DNS レコードの TTL を短く（例：60 秒）設定しておくと、移行時のプロパゲーションがスムーズになります。

ロールバック

万が一新構成側の Cloud Run Service で問題が発生した場合、即座に旧環境の Domain Mapping を再作成できるように準備しておくことが重要です。

ただし、Domain Mapping の再作成には証明書発行の待ち時間が発生する可能性があるため、慎重に行う必要があります。

証明書の監視

Google マネージド証明書がなかなか ACTIVE にならない場合は、DNS 設定（CAA レコード等）に問題がないか確認します。

まとめ

今回のブログでは、Cloud Run Domain Mapping の仕組みと課題、そして External Global HTTPS Load Balancer（GCLB）への移行戦略について紹介しました。

Cloud Run Domain Mapping は手軽にカスタムドメインを利用できる便利な機能ですが、プレビュー段階であることや、レイテンシ・機能制限といった課題があり、本番環境での本格的な運用には注意が必要です。特に日本国内からのアクセスにおいて、レイテンシの増大はユーザ体験に直結する重要な問題となり得ます。

GCLB + Serverless NEG 構成への移行は、これらの課題を解決し、Cloud Armor や Cloud CDN といった高度な機能を利用可能にするための有効な手段です。

移行に際しては、証明書の切り替えによるダウンタイムが最大の懸念事項となりますが、Certificate Manager とワイルドカード証明書（Self-managed）を組み合わせることで、ゼロダウンタイムでの移行を実現できます。 一時的にワイルドカード証明書を利用して DNS 切り替えを行い、その後に Google マネージド証明書へシームレスに移行するという手順を踏むことで、サービスを停止することなく安全に構成変更を行うことが可能です。

Cloud Run を利用したサービスの規模が大きくなり、より高い信頼性や機能性が求められるフェーズにおいては、Domain Mapping からの撤退、GCLB 構成への移行を検討するほうが無難でしょう。

参考・引用