Google PCNE: ハイブリッド接続、Cloud Router、BGP — 学習ガイド

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

こちらの一部です： Google Professional Cloud Network Engineer — 学習ガイド. 検証済みの解答で練習： Google試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Google Cloud のハイブリッド接続は、VPC ネットワークと、オンプレミスデータセンターや他のクラウドなどの外部ネットワークとの間で、プライベートで制御された通信を可能にします。中核となる構成要素は、HA VPN と Cloud VPN ゲートウェイ、動的ルーティングのための BGP を備えた Cloud Router、そして VLAN アタッチメントを備えた Interconnect です。設計では、決定論的なルーティング動作と障害ドメインの分離に従いつつ、帯域幅、レイテンシ、信頼性、運用の複雑さ、コストのバランスを取る必要があります。このセクションでは、設計と運用の理論的根拠、一般的な障害モード、体系的なトラブルシューティングについて説明します。

ハイブリッド接続: HA VPN、Cloud Router、Interconnect

HA VPN と Cloud VPN
- HA VPN は、IKEv2 をサポートし、動的ルーティング (eBGP) のために Cloud Router を必要とする、リージョン単位の高可用性 IPsec VPN です。HA VPN ゲートウェイには 2 つのインターフェースがあります。SLA と ECMP のためには、各インターフェースから個別のピアエンドポイントに対して 2 つのトンネルを構築します。
- Classic Cloud VPN は IKEv1 または IKEv2 と、静的またはルートベースのトンネルをサポートしますが、HA VPN の SLA はサポートしません。ピアが BGP を持たない場合や、ポリシーベースのセレクタを使用する必要がある場合にのみ使用してください。
- ピアゲートウェイは、リモートの VPN デバイス/IP です。HA VPN の場合、冗長性のために個別のインターフェースやデバイスをモデル化するために、1 つ以上のパブリック IP を持つピア VPN ゲートウェイを定義します。
- SLA 設計: HA VPN の 99.99% SLA の対象となるには、独立したオンプレミスデバイスまたはインターフェースにまたがって冗長トンネルをデプロイし、動的ルーティングを使用する必要があります。Classic VPN は SLA の保証対象外です。
- スループットのスケーリング: 単一の IPsec トンネルのスループットには限りがあります。複数のトンネルにまたがる ECMP を使用して、集約スループットを向上させます。これを実現するには、一意のピアパブリック IP 上で追加のトンネルを終端させます。
Cloud Router と BGP
- Cloud Router は、VPN トンネルまたは Interconnect の VLAN アタッチメントとの BGP セッションを確立し、ルートを動的に交換するリージョン単位のコントロールプレーンサービスです。
- 動的ルーティングモード (VPC レベル) は、学習した動적ルートがどこで使用可能か、またどの VPC サブネットルートがアドバタイズされるかを制御します。
  - Regional: 同じリージョン内でのみ動的ルートを学習し、使用/インポートします。
  - Global: すべてのリージョンにわたって動的ルートを学習し、使用/インポートします。すべての VPC サブネットルート (グローバル) をピアにアドバタイズします。
Dedicated Interconnect と Partner Interconnect
- Dedicated Interconnect は、コロケーション施設内で Google に直接接続する物理的な 10 Gbps または 100 Gbps の回線を提供します。クロスコネクトを有効にするために、LOA-CFA (Letter of Authorization – Connecting Facility Assignment) を取得します。Cloud Router に関連付けられたリージョン単位の L3 接続に 802.1Q タグをマッピングする VLAN アタッチメント (インターコネクトアタッチメント) を作成します。
- Partner Interconnect は、サービスプロバイダを介して論理的な接続を提供します。パートナーに VLAN アタッチメントをリクエストし、帯域幅はパートナーのエッジで提供されます。BGP のために、アタッチメントは引き続き Cloud Router に関連付けます。
- 冗長性と SLA: より高い SLA (例: 99.99%) を達成するには、同じリージョン内の 2 つのアタッチメントを、個別のエッジアベイラビリティドメイン (および該当する場合は個別の物理インターコネクト) に配置します。単一のアタッチメントやリンクでは SLA が低下します。Partner Interconnect の場合、全体的な SLA はパートナーにも依存します。
クロスコネクトと VLAN アタッチメント
- クロスコネクトは、ミートミールームにあるお客様のケージ/機器と Google のケージとの間の物理的なファイバー接続です。これを完了させるには、プロバイダに LOA-CFA を提示します。
- VLAN アタッチメントは、VPC リージョンへの論理的な L2 分界点です。各アタッチメントは以下のようになります。
  - Cloud Router を介して、ちょうど 1 つの VPC とリージョンに関連付けられます。
  - 冗長性と ECMP のためにペアで構成されます。
  - L3 トラフィックのみを伝送し、L2 拡張は行いません。

簡単な例:

アタッチメントまたは HA VPN ピア用に Cloud Router と BGP を作成する: gcloud compute routers create cr-us-east1 –region=us-east1 –network=my-vpc –asn=65010 gcloud compute routers add-bgp-peer cr-us-east1 –region=us-east1 –peer-name=onprem-peer1 –peer-asn=65020 –interface=if-1 –peer-ip-address=169.254.0.2 –advertise-mode=DEFAULT –enable-bfd

ルーティングとBGPの動作

動的ルーティングと静的ルーティング
- Cloud Routerによる動的ルーティングは、自動的なルート学習、コンバージェンス、ECMPを提供します。ネットワークが成長するにつれて拡張性があり、運用オーバーヘッドを削減します。
- 静的ルーティングは、ピアがBGPに対応していない場合や、範囲が限定された決定論的なパスに適しています。VPCでは、静的ルートには数値の優先度があり、同じプレフィックス長への静的ルートの中では値が小さいほど優先されます。
- VPCでのルート選択：
  - 最長プレフィックス一致が優先されます。
  - サブネットルートはカスタムルートで上書きできません。
  - プレフィックス長が同じ場合、静的ルートは最も低い優先度によって選択されます。動的ルートの中では、Cloud Routerはルートをインストールする前にすでに最適なパスを解決しています。システムのデフォルトルートは最も優先度が低くなります。
BGPセッション、アドバタイズ、インポート/エクスポート
- Cloud Routerは、デフォルトでVPCサブネットをエクスポートするか、カスタムのプレフィックスセットをエクスポートします。必要に応じて0.0.0.0/0をアドバタイズしたり、プレフィックスを集約したりできますが、そうするとポリシーが許可する場合にオンプレミスのトラフィックをクラウドに引き込むことになるため、意図的に設計してください。
- Cloud Routerは、許可されたオンプレミスのプレフィックスをインポートし、VPCの動的ルーティングモードに従って動的ルートとしてインストールします。
- ピアごとのアドバタイズされたルートの優先度により、オンプレミスルーターが一方のGoogleパスを他方より優先するようにバイアスをかけることができます。優先度の値が低いほど、ピアに対してより優先されるMEDに変換されます。
ASN、MED、アクティブ/スタンバイ
- パブリックASNが正当化される場合を除き、管理ドメインごとに一意のプライベートASNを使用します。同じプレフィックスに対して同じVPCにピアリングする複数のオンプレミスルーターの場合：
  - ECMPまたは一貫したベストパスを有効にするには、同じプレフィックスをアドバタイズするすべてのルーターで同じオンプレミスのリモートASNを使用します。リモートASNが異なると、Cloud Routerでの等コストパスのインストールが妨げられる可能性があります。
  - アクティブ/スタンバイ構成では、オンプレミス側からMED（値が低いほど優先）を操作するか、オンプレミスがプライマリを優先するようにCloud Routerのピアごとのアドバタイズされたルートの優先度を調整します。ASパスプリペンドは代替手段ですが、より粗いツールです。
マルチパス設計
- Cloud Routerは、HA VPNとInterconnectアタッチメントの両方で、複数の等価なBGPパスにわたるECMPをサポートします。等しい属性（ASパス長、MED、local-pref）と異なるネクストホップを確保してください。HA VPNの場合、トンネルを異なるピアIPで終端させます。Interconnectの場合、冗長なアタッチメントを使用します。

回復性、検出、下り（Egress）サービス

BFDと障害検出
- BFDは、HA VPNおよびInterconnect上のBGPセッションの障害検出を高速化します。安定性の要件に応じてサブ秒または数秒レベルの検出を実現するために、両側で互換性のある間隔でBFDを有効にします。IPsecトンネルでIKE DPDと組み合わせます。ピアデバイスがより頻繁な制御トラフィックを処理できることを確認してください。
- 非対称な検出に注意してください。積極的なBFDと輻輳したリンクがセッションをフラップさせる可能性があります。控えめなタイマーから始めて監視してください。
冗長なトポロジパターン
- HA VPN：リージョンごとに1つのHA VPNゲートウェイを使用し、2つの異なるオンプレミスデバイスまたはインターフェースにトンネルを終端させます。少なくとも4つのトンネル（インターフェースごとに2つ）とリージョンごとに1つのCloud Routerを構築します。ECMPを提供する場合は、リモートASNを一貫させてください。
- Interconnect：各リージョンで、異なるエッジアベイラビリティドメインにまたがる少なくとも2つのアタッチメントを使用します。Dedicated Interconnectの場合、可能であれば異なるエッジデバイスや施設にリンクをデプロイします。
Cloud NAT、外部アドレス、プライベートワークロードの下り（Egress）
- Cloud NATは、外部IPを持たないリソースのための、リージョン単位のマネージドな下り（Egress）サービスです。外部IPを持つインスタンスはSNATせず、直接下り通信を行います。プライベートワークロードをカバーするために、リージョン内のサブネットまたはすべてのサブネットを選択します。
- 同時接続数とエフェメラルポートに合わせてNAT IPプールをサイジングし、手動または自動のIP割り当てを選択します。診断のためにロギングを有効にします。
- Google APIにプライベートにアクセスするには：
  - VPC内：サブネットでPrivate Google Accessを有効にすると、外部IPを持たないVMがGoogleの仮想IP経由でGoogle APIにアクセスできます。
  - オンプレミスから：Google API用のPrivate Service ConnectエンドポイントとハイブリッドDNSを使用することで、オンプレミスのクライアントがプライベートなハイブリッドリンク経由でAPIの名前解決とアクセスを行い、インターネットを回避できます。
- デフォルトルートがサードパーティのファイアウォールを指しているが、プライベートワークロードがそれをバイパスしてGoogle APIにアクセスさせたい場合、Private Service Connectを使用するか、公開されているGoogle APIのIP範囲に対して、より優先度の高い静的ルートをデフォルトインターネットゲートウェイに向けてインストールし、サブネットでPrivate Google Accessを併用します。
ハイブリッドDNSの統合
- VPC内の名前解決にはCloud DNSプライベートゾーンを使用します。以下を使用してオンプレミスに拡張します：
  - 受信フォワーディング：オンプレミスのリゾルバが、VPCでホストされているプライベートゾーンについてCloud DNSに転送します。
  - 送信フォワーディング：VPCのリゾルバが、選択したドメインをオンプレミスのDNSに転送します。
  - Shared VPCやマルチプロジェクト環境でのVPC間の名前解決にはピアリングゾーンを使用します。
- プライベートAPIへの到達可能性を確保するには、APIホスト名をPrivate Service Connectエンドポイント、またはPrivate Google Accessを使用している場合は適切なGoogleプライベートVIPにマッピングするプライベートゾーンを作成し、DNSフォワーディングを介してそれらの名前がオンプレミスから解決可能であることを確認します。

計画とトラブルシューティング

帯域幅、レイテンシ、コストのトレードオフ
- VPN: デプロイが最も速く、固定コストが最も低い。トンネルあたりのスループットは限定的で、プライベートリンクと比較してビットあたりのCPU/暗号化オーバーヘッドが高く、通常はレイテンシも高い。
- Dedicated Interconnect: スループットが最も高く、ビットあたりのコストが最も低く、レイテンシが予測可能。固定コストとリードタイム（クロスコネクト、コロケーション）は高い。
- Partner Interconnect: 中間的な選択肢。プロバイダーのフットプリントを活用。SLAとレイテンシはパートナーのパスに依存する。
- レイテンシを最小化するために、アタッチメントとゲートウェイをワークロードに近いリージョンに配置する。Shared VPCを使用して、複数のサービスプロジェクトにサービスを提供しながら、ホストプロジェクトで接続を一元化する。
- トラフィックの対称性、インスペクション要件、障害ドメインを考慮する。オンプレミスのラストマイルやプロバイダーのパスにおける単一障害点を避ける。
トンネル、BGP、ルーティング問題の体系的な診断
1. トンネルの確立
  - IKEバージョンの互換性を確認する：HA VPNにはIKEv2が必要。ピアがIKEv1またはポリシーベースVPNのみをサポートしている場合は、Classic VPNを使用する。
  - 共有シークレット、プロポーザル（暗号化、DHグループ）、NAT-T、UDPポート500/4500の到達可能性を確認する。
  - ピアIPを確認し、各トンネルが冗長性のために個別のピアインターフェースを指していることを確認する。
2. BGPセッションの健全性
  - 両端のBGP状態を確認し、Cloud Routerのステータスを調べる。BFDが有効であるにもかかわらずセッションがフラップする場合は、タイマーを緩和する。
  - ASN設定を検証する。想定との不一致はECMPを妨げたり、意図しないベストパスの選択を引き起こしたりする可能性がある。
  - BGPセッションのIPアドレッシングが、トンネルまたはアタッチメントインターフェースで設定された正しいリンクローカルアドレスまたはRFC1918アドレスを使用していることを確認する。
3. ルートの交換と伝播
  - Cloud Routerのアドバタイズモード（DEFAULT vs CUSTOM）を確認する。想定されるサブネットまたは集約ルートがエクスポートされていることを確認する。
  - Cloud Routerで受信したルートを検査し、ASパス、MEDを評価する。アクティブ/スタンバイ構成を意図している場合は、MEDまたはアドバタイズされたルートの優先度がその意図を反映していることを確認する。
  - 学習したルートが必要な場所に表示されるように、VPCの動的ルーティングモード（REGIONAL vs GLOBAL）を確認する。サブネットルートは上書きできないことを覚えておく。
  - 競合する場合、静的ルートと動的ルートが同じプレフィックス長で一致すると、最も低い優先度を持つ静的ルートが優先される。意図しない場合は、重複する静的ルートを調整または削除する。
4. データプレーンの検証
  - VPC Flow LogsとCloud NATのログを使用して、下り（egress）パスとアドレス変換を確認する。VMがまだ外部IPで出ていく場合は、その外部IPを削除してNATを強制する。
  - Interconnectの場合、アタッチメントの運用状態を確認し、両方のアタッチメントが管理上有効化され、正しいCloud Routerに関連付けられていることを確認する。
  - ファイアウォールルールがBGPとアプリケーショントラフィックを許可していることを確認する。Googleのヘルスチェックのソース範囲がロードバランサーのバックエンドに到達できるように許可する必要があることを覚えておく。
5. Interconnect開通時の特記事項
  - コンソールまたはNOCの連絡先メールからLOA-CFAを取得する。BGPの立ち上げ前に、プロバイダーとクロスコネクトの光レベルとVLANタギングを確認する。

実践的な問題シナリオ

Contoso Manufacturing社は、オンプレミスの工場をオンラインに保ちながら、ERPワークロードをGoogle Cloudに移行しています。要件：20 Gbpsのプライベート接続とサブ秒単位のフェイルオーバー、一元化されたルーティング制御、Cloudへのアクティブ/スタンバイ構成のオンプレミス下り（egress）パス、パブリックインターネットを経由しないGoogle APIへのプライベートアクセス、そして最小限の運用オーバーヘッド。

アプローチ：

同じメトロエリア内の異なるエッジアベイラビリティドメインとファシリティにまたがって2つのDedicated Interconnectリンクをデプロイする。リージョンごとに2つのVLANアタッチメント（プライマリとセカンダリ）を作成し、リージョンCloud Routerに関連付ける。
- 根拠: Dedicated Interconnectは、要求される集約スループットと予測可能なレイテンシを提供します。冗長化されたリンクとアタッチメントは障害を分離し、より高いSLAの対象となります。複数のアタッチメントにより、ECMPとトラフィックロスなしのメンテナンスが可能になります。
リージョンごとに1つのCloud Routerを設定し、アタッチメントごとに1つ、合計2つのBGPピアを設定し、BFDを有効にする。
- 根拠: 単一のルーターは、複数のネクストホップに対するECMPをサポートしつつ、コントロールプレーンの管理を簡素化します。BFDは障害検出を数秒レベルに短縮し、ERPアプリケーションの収束RTOを改善します。
Googleとピアリングする両方の工場エッジルーターで同じオンプレミスリモートASNに統一し、それぞれから同一のプレフィックスをアドバタイズする。
- 根拠: リモートASNを一致させることで、Cloud Routerは等コストパスをインストールし、必要に応じて負荷分散を行うことができます。異なるASNを使用した場合、1セットのルートしかインストールされず、マルチパスが無効になる可能性があります。
オンプレミスからGoogleへはMEDを使用し、GoogleからオンプレミスへはCloud Routerのアドバタイズされたルートの優先度を使用して、アクティブ/スタンバイの優先順位を実装する。プライマリパスにはより低い値を設定する。
- 根拠: 両サイドでのポリシー設定により、決定論的な方向性が確保されます。つまり、工場はCloudに到達するためにプライマリのメトロを優先し、ContosoのVPCはリターントラフィックのためにプライマリの工場DCを優先します。これにより、意図しない非対称性を回避できます。
Shared VPCでGoogle API用のPrivate Service Connectを有効にし、APIホスト名をPSCエンドポイントにマッピングするプライベートDNSゾーンを作成する。オンプレミスのリゾルバがこれらの名前をプライベートに解決できるように、Cloud DNSのインバウンド転送を設定する。
- 根拠: PSCは、Google APIへのプライベートなVPC内アクセスを提供します。ハイブリッドDNSにより、これらのエンドポイントはInterconnect経由で工場から到達可能になり、ERPのサポートサービスのためのインターネットへの露出やファイアウォールへの依存を排除します。
VPNバックアップとして、各リージョンにHA VPNゲートウェイを追加し、それぞれ異なるオンプレミスデバイスへの2つのトンネルを構成する。BGPセッションでBFDを有効にし、ECMPを許可する。
- 根拠: Interconnectに障害が発生した場合、HA VPNがプライベートな到達可能性を維持します。デバイスごとのデュアルトンネルはSLAとスループットの継続性を維持し、BFDはフェイルオーバーを高速化します。
インターネットやGoogle以外の宛先へのプライベートワークロードの下り（egress）トラフィックのために、ERPサブネットにリージョンCloud NATを設定する。VMには外部IPを割り当てない。
- 根拠: Cloud NATは、VMの管理オーバーヘッドなしに変換をスケーリングし、プライベートアドレッシングを維持します。外部IPを削除することで、NATが使用されることが保証され、下り（egress）制御が簡素化されます。
段階的なテストでルーティングとフェイルオーバーを検証する：1つのアタッチメントを停止し、次に1つのオンプレミスルーターを停止し、その後リンクの劣化をシミュレートする。BGP、BFD、およびアプリケーションのSLOを監視する。フラップが発生した場合は、BFDタイマーを調整する。
- 根拠: 制御された障害注入により、設計が回復目標を満たしていることを検証し、本番環境での予期せぬ事態を防ぎます。タイマーの調整は、安定性と応答性のバランスをとります。