ゾーン DNS を使用するようにプロジェクトを更新する

このドキュメントでは、既存のプロジェクトをグローバル DNS からゾーン DNS に移行する方法について説明します。ゾーン DNS は、ゾーン内の停止を分離することで信頼性を強化し、インスタンスの作成や自動修復などの重要なサービスの中断を防ぎます。

始める前に

• まだ設定していない場合は、認証を設定します。認証では、 Cloud de Confiance by S3NS サービスと API にアクセスするための ID が確認されます。ローカル開発環境からコードまたはサンプルを実行するには、次のいずれかのオプションを選択して Compute Engine に対する認証を行います。

  Select the tab for how you plan to use the samples on this page:

  Console

  When you use the Cloud de Confiance console to access Cloud de Confiance by S3NS services and APIs, you don't need to set up authentication.

  gcloud

  1. Google Cloud CLI をインストールし、連携 ID を使用して gcloud CLI にログインします。 ログイン後、次のコマンドを実行して Google Cloud CLI を初期化します。

     gcloud init

  2. Set a default region and zone.

  REST

  このページの REST API サンプルをローカル開発環境で使用するには、gcloud CLI に指定した認証情報を使用します。

  Google Cloud CLI をインストールし、連携 ID を使用して gcloud CLI にログインします。 ログイン後、次のコマンドを実行して Google Cloud CLI を初期化します。

  gcloud init

  詳細については、 Cloud de Confiance 認証ドキュメントの REST を使用して認証するをご覧ください。

必要なロール

ゾーン DNS を使用するようにプロジェクトを移行するための権限を取得するには、次の IAM ロールを付与するよう管理者に依頼してください。

• ゾーン DNS を使用するようにプロジェクトを移行する: プロジェクトのプロジェクト編集者（roles/resourcemanager.projectEditor）
• プロジェクト内のゾーン DNS に VM を移行する: プロジェクトの Compute インスタンス管理者（v1）（roles/compute.instanceAdmin.v1）
• VM でサービス アカウントが使用されている場合: サービス アカウントまたはプロジェクトのサービス アカウント ユーザー（roles/iam.serviceAccountUser）

ロールの付与について詳しくは、プロジェクト、フォルダ、組織へのアクセス権を管理するをご覧ください。

これらの事前定義ロールには、ゾーン DNS を使用するようにプロジェクトを移行するために必要な権限が含まれています。必要とされる正確な権限については、「必要な権限」セクションを開いてご確認ください。

カスタムロールや他の事前定義ロールを使用して、これらの権限を取得することもできます。

プロジェクトをゾーン DNS に移行する

ゾーン DNS を使用するようにプロジェクトを移行するには、次のタスクを完了します。

1. プロジェクトでグローバル DNS をデフォルトで使用しているかどうかを確認する
2. クエリ分析を使用してプロジェクトの移行の準備状況を判断する
3. ゾーン DNS と互換性のあるプロジェクトを移行する
4. 互換性のないクエリを修正する
5. グローバル DNS ログをモニタリングして、移行の準備状況を確認する
6. 残りのプロジェクトをゾーン DNS に移行する
7. ゾーン DNS の変更がプロジェクトに影響しているかどうかを確認する

プロジェクトでグローバル DNS をデフォルトで使用しているかどうかを確認する

プロジェクトを調べて、グローバル DNS からゾーン DNS に移行する必要があるかどうかを確認します。移行する必要があるのは、プロジェクト内で作成された内部 DNS 名のデフォルトとしてグローバル DNS が構成されているプロジェクトのみです。

gcloud compute project-info describe --project=PROJECT_ID --flatten="vmDnsSetting"

GET https://compute.s3nsapis.fr/compute/v1/projects/PROJECT_ID?fields=id,name,vmDnsSetting

クエリ分析を使用してプロジェクトの移行準備状況を判断する

コードを変更したり、グローバル DNS の使用方法を変更したりせずにプロジェクトをゾーン DNS に移行できるかどうかを評価するため、 Cloud de Confiance by S3NS は DNS クエリ履歴を分析します。この分析では、ゾーン DNS とのプロジェクトの互換性を示す次の指標が提供されます。

• zonal_dns_ready（互換性のあるクエリ）: この指標は、ゾーン DNS を使用して正常に解決できる 100 日間のクエリの合計数を表します。

• zonal_dns_risky（互換性のないクエリ）: この指標は、ゾーン DNS を使用して解決できないクエリの合計数を表します。これらのクエリには通常、リージョン間通信や、ゾーン解決が失敗するその他のシナリオが含まれます。この指標の値がゼロ以外の場合、プロジェクトは移行の準備ができていません。ゾーン DNS に切り替える前に、これらの互換性のないクエリに対処する必要があります。

これらの指標を表示するには、 Cloud de Confiance コンソールの Metrics Explorer を使用します。

1. Cloud de Confiance コンソールで leaderboard [Metrics Explorer] ページに移動します。

   [Metrics Explorer] に移動

   検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] の結果を選択します。

2. [指標を選択] フィールドがあるツールバー右側で、[コードエディタ]、[MQL] または [PromQL] をクリックします。

3. クエリの入力フィールドに「PromQL クエリ」という名前がない場合は、[言語] で [PromQL] を選択します。

4. クエリの入力フィールドに、次のテキストをそのまま入力します。

   increase({"compute.googleapis.com/global_dns/request_count", monitored_resource="compute.googleapis.com/Location"}[1d])
   

5. [クエリを実行] ボタンをクリックします。

   Cloud de Confiance コンソールに、2 つの指標（zonal_dns_ready と zonal_dns_risky）と、期間中に実行された、各指標に該当するクエリの数のグラフが表示されます。

   

6. zonal_dns_risky 指標の値を確認します。

   • 値が 0 の場合、プロジェクトはゾーン DNS に移行できます。ゾーン DNS の準備ができているプロジェクトを移行するの説明に従って、プロジェクトを移行できます。
   • 上のスクリーンショットに示されているように、値がゼロ以外の数値（0.02k など）の場合、ゾーン DNS に移行した後に一部のクエリが機能しなくなる可能性があります。このプロジェクトは移行の準備ができていません。互換性のないクエリを修正するの手順に進みます。

ゾーン DNS と互換性のあるプロジェクトを移行する

ゾーン DNS に切り替える準備ができているプロジェクトを移行するには、次のいずれかのオプションを使用します。

• Cloud de Confiance コンソールで [ゾーン DNS を使用する] ボタンをクリックします。

  1. プロジェクトの [VM インスタンス] ページを表示したときに、プロジェクトを移行する準備ができている場合（ゾーン DNS クエリと互換性がある場合）は、バナーでゾーン DNS を使用することが推奨されます。この推奨は、プロジェクト内の内部 DNS の使用状況に基づいていますが、過去 30 日間の使用に限定されています。

     

     [ゾーン DNS を使用する] ボタンをクリックすると、ゾーン DNS を使用するようにプロジェクト メタデータが更新されます。

  2. 省略可: VM メタデータを表示してクエリを実行すると、メタデータの変更を確認できます。

• ゾーン DNS を使用するようにプロジェクトのメタデータを手動で変更します。

  1. プロジェクトの vmDnsSetting メタデータ エントリを設定して、インスタンスでゾーン DNS を有効にします。このメタデータ エントリを設定した後に検索パスを使用する場合、コンピューティング インスタンスにはゾーン DNS 名（VM_NAME.ZONE.c.PROJECT_ID.internal）でのみアクセスできます。VM は引き続き、ゾーンとグローバルの両方の検索パスを保持しますが、内部 DNS 名に ZONE が含まれていないグローバル DNS 名は機能しなくなります。この設定が有効な場合、同じリージョンと同じプロジェクト内のインスタンスのみがグローバル名を使用して相互にアクセスできます。

     コンソール

     1. プロジェクト レベルで設定を更新するには、Cloud de Confiance コンソールで Compute Engine の [メタデータ] ページに移動します。

        [カスタム メタデータ] ページに移動

     2. [edit 編集] をクリックします。

     3. 値が VmDnsSetting のキーが存在する場合は、その値を ZonalOnly に変更します。

     4. 値が VmDnsSetting のキーが存在しない場合は、add_box [項目を追加] をクリックします。

        • [キー] フィールドに「VmDnsSetting」と入力します。
        • [値] に「ZonalOnly」と入力します。

     5. カスタム メタデータ エントリの変更を終了するには、[保存] をクリックします。

     gcloud

     1. 現在のプロジェクトのメタデータ設定を更新するには、project-info add-metadata コマンドを使用します。

        gcloud compute project-info add-metadata \
            --metadata vmDnsSetting=ZonalOnly
        

     2. 省略可: プロジェクトのメタデータ設定を確認するには、次のコマンドを使用します。

        gcloud compute project-info describe --project=PROJECT_ID --flatten="vmDnsSetting"
        

        PROJECT_ID は、クエリするプロジェクトの名前に置き換えます。

     REST

     プロジェクト レベルでメタデータ設定を更新するには、projects.setCommonInstanceMetadata メソッドを使用して POST リクエストを作成します。

     1. 省略可: 楽観的ロックを実行するには、必要に応じてフィンガープリントを指定します。

        フィンガープリントとは、Compute Engine によって生成されるランダムな文字列です。フィンガープリントはリクエストのたびに変更され、一致しないフィンガープリントを指定するとリクエストが拒否されます。

        フィンガープリントを指定しない場合、整合性のチェックが行われず、projects.setCommonInstanceMetadata リクエストは成功します。instances.setMetadata メソッドを使用する場合は、常にフィンガープリントが必要です。

        プロジェクトの最新のフィンガープリントを取得するには、project.get メソッドを呼び出します。

        GET https://compute.s3nsapis.fr/compute/v1/projects/PROJECT_ID
        

        出力は次のようになります。

        {
         "name": "myproject",
         "commonInstanceMetadata": {
           "kind": "compute#metadata",
           "fingerprint": "FikclA7UBC0=",
           ...
         }
        }
        

     2. projects.setCommonInstanceMetadata メソッドに対して POST リクエストを作成して、メタデータの Key-Value ペアを設定します。

        POST https://compute.s3nsapis.fr/compute/v1/projects/PROJECT_ID/setCommonInstanceMetadata
        
        {
        "fingerprint": "FikclA7UBC0=",
        "items": [
          {
          "key": "vmDnsSetting",
          "value": "ZonalOnly"
          }
        ]
        }
        

        PROJECT_ID は、実際のプロジェクト ID に置き換えます。

  2. プロジェクトの vmDnsSetting メタデータ エントリを構成したら、そのプロジェクト内の各インスタンスの DHCP リースを更新します。リースを更新するには、インスタンスを再起動するか、リースが期限切れになるまで待つか、次のコマンドを実行します。

     Linux インスタンス

     sudo dhclient -v -r
     

     Windows インスタンス

     ipconfig /renew
     

  3. プロジェクトでゾーン DNS が使用されていることを確認する。

互換性のないクエリを修正する

移行の準備ができていないプロジェクトとは、過去 30 日間など、一定の期間内に互換性のない DNS クエリが少なくとも 1 回実行されたプロジェクトを意味します。互換性のないクエリには、次のような属性があります。

• 別のプロジェクトのコンピューティング インスタンスを呼び出す
• 別のリージョンのコンピューティング インスタンスを呼び出す

プロジェクトに互換性のないクエリがある場合、 Cloud de Confiance コンソールの [VM インスタンス] ページに次のバナーが表示されます。

互換性のないクエリをすべて修正するには、クエリでソース インスタンスのゾーン完全修飾ドメイン名（FQDN）を使用することをおすすめします。これにより、プロジェクトをゾーン DNS に移行した後もクエリの解決が中断されなくなります。

互換性のないクエリを解決するには、次の操作を行います。

1. ログ エクスプローラを使用して、プロジェクトのコンピューティング インスタンスのグローバル DNS の使用状況にアクセスしてクエリを実行します。

   [ログ エクスプローラ] に移動

2. プロジェクトを選択します。

3. リソースとログ名のフィルタを適用します。

   1. [リソース] をクリックします。
   2. [リソースの選択] ダイアログで [VM インスタンス] を選択し、[適用] をクリックします。
   3. [ログ名] をクリックします。

   4. [ログ名の選択] ダイアログで [gdnsusage] を選択し、[適用] をクリックします。

   別の方法として、クエリ フィールドに次のように入力することもできます。

      resource.type="gce_instance"
      log_name="projects/PROJECT_ID/logs/compute.googleapis.com%2Fgdnsusage"
     

4. [クエリ結果] ペインでは、各クエリに jsonPayload フィールドがあります。各 jsonPayload フィールドには次の情報が含まれています。

   • ソース VM 名、そのプロジェクト ID、ゾーン名。
   • 宛先 VM 名、そのプロジェクト ID、ゾーン名。

   • ゾーン DNS 名では解決できないグローバル DNS クエリの更新方法に関する情報を提供するデバッグ メッセージ。これらは移行をブロックするクエリとみなされ、デバッグと修正が必要になります。

     "To use Zonal DNS, update the Global DNS query sent from the source VM
     VM_NAME.c.PROJECT_ID.internal to the following zonal
     FQDN: VM_NAME.ZONE.c.PROJECT_ID.internal"
     

   • クエリ数。その日に送信元 VM が宛先 VM に送信する移行ブロッククエリの数を示します。

   次のスクリーンショットは、ログ エクスプローラ コンソール ページの jsonPayload フィールド情報を示しています。

   

5. 前の手順で取得した jsonPayload の情報を元に、どの FQDN でグローバル DNS クエリを手動で更新し、ゾーン DNS を使用するようにするのかを決定して、プロジェクトの移行準備を整えます。FQDN を更新して互換性を解決する最も一般的なユースケースは次のとおりです。

   • メタデータ サーバーからの内部 DNS 名: ゾーン DNS への移行直後に、返された DNS 名がゾーン FQDN に変更されるため、対応は必要ありません。DNS 名がキャッシュに保存されている場合は、もう一度呼び出すだけでキャッシュ値を更新できます。
   • 別のリージョンの VM へのアクセスに使用される内部 DNS 名: 異なるリージョンの VM に内部 DNS 名を使用するアプリケーションがある場合は、DHCP ポリシーまたは構成ファイルを変更して、別のリージョンのゾーンを含めることができます。
   • ハードコードされたグローバル FQDN: VM にハードコードされたグローバル FQDN 名を使用するアプリケーションがある場合は、内部 DNS 名またはゾーン FQDN を使用するようにアプリケーション内の呼び出しを更新できます。この変更を行うには、Terraform でコードまたは構成を変更します。
   • 共有 VPC ネットワークを使用するサービス プロジェクトの VM: 共有 VPC ネットワークを使用するサービス プロジェクトの VM の DNS 名を解決するには、VM のゾーン FQDN を使用する必要があります。

6. ゾーン DNS を使用するようにグローバル DNS クエリを更新したら、次の操作を行います。

   1. ログ エクスプローラ ページを使用して、グローバル DNS の使用状況を再度クエリします。ブロックしているグローバル DNS クエリをすべて修正すると、クエリ結果にデバッグログは表示されなくなります。

   2. モニタリング指標を再度確認して、互換性のない DNS クエリがすべて削除されているかどうかを確認します。

ログ エクスプローラでグローバル DNS ログを表示する

ログ エクスプローラには、ゾーン DNS と互換性がないクエリを含むプロジェクトのグローバル DNS ログが主に表示されます。これらのログは、移行前に問題のあるクエリを特定して分析する際に役立ちます。

これらの互換性のないクエリに対して、ログ エクスプローラで次の操作を行うことができます。

• ダッシュボードを作成する: 互換性のないグローバル DNS クエリのパターンを可視化し、アプリケーションの通信動作に関する分析情報を取得します。
• ログを集約する: 組織全体の DNS ログを分析して、幅広い傾向と改善の余地を特定します。

ゾーン DNS の変更がプロジェクトに影響しているかどうかを確認する

ゾーン DNS に移行した後は、アプリケーションとサービスが引き続き正しく動作していることを確認することが重要です。ゾーン DNS は内部 DNS 名の解決方法を変更するため、グローバル DNS 名に依存しているアプリケーションで問題が発生することがあります。

以降のセクションでは、潜在的な影響をチェックする方法と、その影響の解決方法について説明します。

1. コマンドライン インスタンスの通信

   タスク: gcloud CLI を使用して、別のインスタンスから 1 つのインスタンスに ping を実行します。

   gcloud compute ssh VM-A --command "ping VM-B"
   

   考えられるエラー: 「ホストを解決できませんでした」- VM-A が VM-B の IP アドレスを見つけられないことを意味します。

   解決策: VM-B に使用しているホスト名を、ゾーン名を含む完全修飾ドメイン名（FQDN）に更新します。ゾーン名は INSTANCE_NAME.ZONE.c.PROJECT_ID.internal です。

2. Compute Engine サービス内のインスタンス通信

   タスク: 内部 DNS 名を使用するマネージド インスタンス グループ（MIG）のヘルスチェックを使用している場合は、ヘルスチェックが成功しているかどうかを確認します。

   考えられるエラー: 「ヘルスチェックに失敗しました」- DNS 解決の問題により、ヘルスチェックがターゲットに到達できないことを示します。

   解決策: ヘルスチェックで、ゾーン名を含むターゲット インスタンスの FQDN が使用されていることを確認します。

3. アプリケーション固有のユースケース

   多くのアプリケーションは、次のようなタスクに内部 DNS を使用しています。

   • データベース（Cloud SQL など）への接続

   • メッセージ キュー（Pub/Sub など）とのやり取り

   • 考えられるエラー: アプリケーションによって異なりますが、次のようなエラーが発生する可能性があります。

     • 「SERVICE_NAME に接続できません」
     • 「接続がタイムアウトしました」
     • 「そのようなホストは認識されていません」

   • 解決策: アプリケーションの構成を確認して、サービスの参照時に FQDN（ゾーン名を含む）が使用されていることを確認します。

グローバル DNS を使用するように戻す

デフォルトの内部 DNS タイプをグローバル DNS に戻すと、ゾーン DNS への移行を元に戻すことができます。これは、組織、プロジェクト、インスタンス、またはコンテナのレベルで行うことができます。

プロジェクトでグローバル DNS を使用するように戻す

グローバル DNS を使用するようにプロジェクトを元に戻すには、次の手順を完了します。

1. プロジェクトのメタデータに vmDnsSetting=GlobalDefault を追加します。

   プロジェクト メタデータの値を設定する方法については、カスタム メタデータの設定と削除をご覧ください。

2. プロジェクト内のどのインスタンスでも、vmDnsSetting メタデータ値が ZonalOnly に設定されていないことを確認します。

   gcloud compute instances describe INSTANCE_NAME --flatten="metadata[]"
   

   INSTANCE_NAME は、確認するインスタンスの名前に置き換えます。

3. 各インスタンスの DHCP リースを更新します。リースを更新するには、インスタンスを再起動するか、リースが期限切れになるまで待つか、ゲスト オペレーティング システムで次のいずれかのコマンドを実行します。

   • Linux インスタンス: sudo dhclient -v -r
   • Windows Server インスタンス: ipconfig /renew

インスタンスでグローバル DNS を使用するように戻す

特定のインスタンスをグローバル DNS を使用するように戻すには、次の操作を行います。

1. インスタンスのメタデータを更新して、vmDnsSetting=GlobalDefault を追加します。

   コンピューティング インスタンスのメタデータ値を設定する方法については、カスタム メタデータの設定と削除をご覧ください。

2. DNS 構成を強制的に変更するには、次のいずれかのコマンドを使用してインスタンスのネットワークを再起動します。

   • Container-Optimized OS または Ubuntu の場合:

     sudo systemctl restart systemd-networkd
     

   • CentOS、RedHat EL、Fedora CoreOS、Rocky Linux の場合:

     sudo systemctl restart network
     

     または

     sudo systemctl restart NetworkManager.service
     

   • Debian の場合:

     sudo systemctl restart networking
     

   • nmcli が含まれる Linux システムの場合:

     sudo nmcli networking off
     sudo nmcli networking on
     

   • Windows の場合:

     ipconfig /renew
     

コンテナでグローバル DNS を使用するように戻す

アプリケーションまたはワークロードをコンテナ、Google Kubernetes Engine、または App Engine フレキシブル環境で実行する場合は、コンテナ設定内の DNS 構成が自動的には更新されず、コンテナの再起動が必要になることがあります。これらのコンテナアプリでゾーン DNS を無効にするには、次の手順を完了します。

1. コンテナと VM を保持するプロジェクトで、プロジェクト メタデータ設定 vmDnsSetting を GlobalDefault に設定します。

2. コンテナを再起動すると、DNS 設定が元の状態に戻ります。

グローバル DNS からゾーン DNS への移行プロセスのトラブルシューティングを行う

移行プロセスに問題が発生した場合は、トラブルシューティング ガイドをご覧ください。

次のステップ

• Cloud de Confiance by S3NS リソース階層で、組織、フォルダ、プロジェクト間の関係について確認する。
• Compute Engine の内部 DNS について詳しく学ぶ。