Google PCA: ネットワーキング、ハイブリッド接続、トラフィックアーキテクチャ — 学習ガイド

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

概要

Google Cloud におけるネットワーキング、ハイブリッド接続、トラフィックアーキテクチャは、安全でスケーラブルな Virtual Private Cloud (VPC) の設計、信頼性の高いハイブリッド相互接続、インテリジェントなトラフィック管理、そして堅牢なオブザーバビリティを中心に展開されます。その目的は、明確なセグメンテーション、制御された下り（egress）、予測可能な障害モードを備えた、低レイテンシで回復性の高いサービスを提供することです。このセクションでは、主要な Google Cloud ネットワーキングサービス全体にわたる実践的な設計パターン、トレードオフ、および運用ガイダンスの概要を説明します。

VPC アーキテクチャとセグメンテーション

• アドレス計画とサブネット

  • カスタムモード VPC を使用して、サブネットの作成と IP アドレッシングを制御します。本番環境ではデフォルト VPC の使用を避けてください。
  • 重複しない RFC1918 ブロックを早期に割り当てます。将来の成長、高可用性トポロジ、ハイブリッド拡張を考慮してください。サービス（例: Private Service Connect エンドポイント）用およびピアリング/Interconnect 用に範囲を予約します。
  • 大規模なフラットネットワークよりも、機能ごとまたは環境ごとの小規模なサブネットを優先して、障害の爆発半径 (blast radius) を最小限に抑え、ファイアウォール設定を簡素化します。

• ルート

  • 各 VPC にはシステムルートテーブルがあります。ルートは最長プレフィックス一致、次に優先度によって評価されます。Google マネージドルートには、外部 IP が存在する場合のデフォルトインターネットルートやサブネットルートが含まれます。動的ルートは Cloud Router を介してオンプレミスと交換されます。
  • カスタム静的ルートの使用は控えめにし、回復力のため可能な限り動的ルーティングに依存します。意図的な制御として使用する場合を除き、ブラックホールルートは避けてください。

• ファイアウォールルール

  • VPC ファイアウォールはステートフルであり、優先度によって評価され、最後に暗黙の deny があります。ネットワークタグまたはサービスアカウントでターゲットを指定します。サービスアカウントによるターゲティングは、タグよりも強力なアイデンティティ保証を提供します。
  • 許可ルールを目的（ヘルスチェック、階層内、管理者）ごとに分離し、ソースのサービスアカウントまたは IP 範囲にスコープを限定します。
  • 重要なルールに対するファイアウォールの決定を Cloud Logging に記録し、フォレンジックおよびパフォーマンス分析に役立てます。

• 階層型ファイアウォールポリシーと組織のポリシー

  • 階層型ファイアウォールポリシーは組織またはフォルダレベルで適用され、VPC レベルのルールの前に評価されます。これらを使用して、プロジェクトが上書きできないグローバルなガードレール（例: 0.0.0.0/0 からの SSH を拒否）を設定します。事前ポリシーと事後ポリシーは柔軟性を提供しますが、上位レベルでの拒否は上書きできません。
  • 組織のポリシーの制約（例: 外部 IP 作成の制限、プロジェクトによる VPC ピアリング作成の禁止）で補完し、ガバナンスを強制します。

• 共有 VPC とセグメンテーション

  • 共有 VPC を使用して、ホストプロジェクトでネットワーキングを集中管理しつつ、サービスプロジェクトでワークロードを分離します。このパターンは、重複した下り（egress）パスを削減し、制御を標準化し、ハイブリッドトランジットを簡素化します。
  • 環境（本番、非本番）を別々のホストプロジェクトまたはフォルダに分離し、階層型ポリシーと個別のサブネットでセグメンテーションを強制します。NetOps チームのみがホストプロジェクトのリソースを管理できるように IAM を制限します。

• VPC ネットワークピアリング

  • ピアリングはプライベートで、スケーラブル、かつ低レイテンシですが、非推移的です。自律的なネットワークやサードパーティのマネージドサービスを接続するのに最適です。ピアリングでトランジットハブを構築することは避け、トランジットには Network Connectivity Center または集中管理型の共有 VPC を使用してください。
  • 制限事項: IP の重複は不可。特定のルート（例: デフォルトインターネットルート）や一部のサービスは伝播されません。設計時にはカスタムルートのインポート/エクスポートを理解しておく必要があります。

トレードオフと障害モード:

• IP 範囲が重複すると、ピアリングとハイブリッドルート交換がブロックされます。再ナンバリングまたは NAT で解決します。
• 過度に寛容なファイアウォールルールやヘルスチェックルールの欠落は、サービス停止や診断が困難な動作を引き起こします。
• 静的ルートは脆弱な依存関係を生み出します。フェイルオーバーには Cloud Router を優先してください。

トラフィック管理、DNS、エッジセキュリティ

• Cloud Load Balancing のパターン

  • 外部 HTTP(S) ロードバランサは、単一のエニーキャスト VIP を持つグローバルエニーキャストであり、リージョン間のフェイルオーバー、パスおよびホストベースのルーティング、CDN/Armor との統合機能を備えています。インターネット向けのウェブおよび API ワークロードに使用します。
  • 内部 HTTP(S) ロードバランサはリージョン単位であり、VPC 内または Private Service Connect を介したサービス間のトラフィックに使用します。
  • 外部/内部 TCP/UDP ネットワークロードバランサはリージョン単位の L4 です。非 HTTP プロトコルや、送信元 IP の維持が必要な場合に使用します。
  • バックエンドサービスとネットワークエンドポイントグループ (NEG): VM プールにはゾーンのインスタンスグループバックエンドを使用します。GKE、ハイブリッドバックエンド、または Cloud Run には、ゾーン、リージョン、またはサーバーレス NEG を使用します。トラフィッククラス、ヘルスプロファイル、または容量ポリシーごとに個別のバックエンドサービスを作成します。例: パスルーティングで異なるバックエンドサービスに振り分けることで、同じホスト名で新旧の API バージョンを提供し、両方をデプロイ可能かつ独立してスケーラブルに保ちます。

• ヘルスチェックとよくある落とし穴

  • ヘルスチェックはファイアウォールで許可する必要があります。外部 HTTP(S) ヘルスチェックの場合、バックエンドへの 130.211.0.0/22 および 35.191.0.0/16 からのアクセスを許可します。このルールがないと、バックエンドが異常とマークされ、オートスケーリングがロードバランサのシグナルに反応した場合に VM の再起動が頻発します。
  • ヘルスチェックのパスとポートをコンテナの readiness エンドポイントに合わせます。タイムアウトと閾値を設定し、高速なフェイルオーバーと誤検知のバランスを取ります。

• DNS アーキテクチャ

  • 権威ゾーンには Cloud DNS を使用します。内部名にはプライベートゾーンを、インターネット向けの名前にはパブリックゾーンを作成します。
  • スプリットホライズン DNS: 同一名のパブリックゾーンとプライベートゾーンを個別に作成することで、内部と外部で異なる応答を返します。これにより、プライベートサービスのホスト名と公開レコードを安全にサポートします。
  • 転送ゾーンとピアリングゾーン: DNS ポリシーとサーバーポリシーを使用してオンプレミス DNS と統合し、特定のドメインへのクエリを転送します。再帰ループを避けるために条件付き転送を使用します。
  • サービスディスカバリ: 環境ごと、サービスごとに一貫した命名規則を採用します。GKE の場合、Cloud DNS を使用したヘッドレスサービス、または内部 HTTP(S) ロードバランサとプライベート DNS 名を介したサービスエンドポイントのマッピングを検討します。

• エッジでのキャッシングと保護

  • Cloud CDN は、キャッシュ可能なコンテンツをエッジでオフロードし、オリジンへのレイテンシと下り（内向き）コストを削減します。キャッシュキー、TTL、ネガティブキャッシュを慎重に設定し、パーソナライズされたエンドポイントや動的なエンドポイントではキャッシュをバイパスします。
  • Cloud Armor は、WAF、レート制限、地理/IP ベースのアクセス制御を提供します。セキュリティポリシーをロードバランサにアタッチし、ルールヒットのログを監視します。一般的な CVE には事前設定されたルールを、アプリケーション固有の脅威にはカスタムシグネチャを使用します。
  • ロードバランサでの TLS 終端により、証明書管理が集中化されます。可能な場合は、証明書の自動プロビジョニングとマネージド更新を有効にします。

運用ガイダンス:

• バージョン管理された API: パスまたはホストベースのルーティングを実装してバックエンドサービスを分離し、各バージョンがブルーグリーンまたはカナリアパターンで独立してロールアウトできるようにします。
• トラフィックステアリングポリシーを介した A/B テストには、リクエストヘッダーと Cookie を使用します。ログ/メトリクスが正しいバックエンド ID と相関していることを常に検証してください。

ハイブリッド接続、プライベートアクセス、トランジット

• Cloud Router と BGP

  • Cloud Router は、Cloud VPN トンネルと Interconnect アタッチメントのために、BGP を介してオンプレミスと動的にルートを交換します。複数リージョンのスポーク接続が必要な場合は、VPC でグローバル動的ルーティングモードを使用します。
  • 必要なプレフィックスのみをアドバタイズし、ルートリークを防ぐためにフィルタリングします。プライマリ/バックアップパスを設計する際は、MED と優先度の相互作用を理解してください。

• Cloud VPN, Dedicated Interconnect, Partner Interconnect

  • HA VPN は、SLA に裏付けられた冗長な IPsec トンネルを提供し、Cloud Router を介した動的ルーティングをサポートします。中程度の帯域幅要件を持つ本番環境のハイブリッド接続に適しています。
  • Dedicated Interconnect は、1 つ以上のロケーションに物理的な 10/100 Gbps リンクを提供します。Partner Interconnect は、サービスプロバイダを介して同様の機能を提供します。高可用性を実現するには、別々のメトロロケーションまたは別々のエッジゾーンにある、少なくとも 2 つの多様なインターコネクトを使用します。
  • 冗長パスとフェイルオーバー: リージョンごとに 2 つの Cloud Router と 2 つのオンプレミスルーターにまたがる BGP を使用してアクティブ/アクティブを設計し、非対称ルーティングの耐性を検証します。
  • フェイルオーバーを定期的にテストし、目的のコンバージェンスを実現するために BFD タイマーとヘルスしきい値を調整します。
  • 障害モード: MTU の不一致は、フラグメンテーションとパフォーマンスの低下を引き起こします。Interconnect ではエンドツーエンドでジャンボフレームを確保してください。ルートフィルタの設定ミスは、サブネットをブラックホール化する可能性があります。シングルホームのパートナー回線は、一般的な単一障害点です。

• Cloud NAT, Private Google Access, Private Service Connect

  • Cloud NAT は、外部 IP を持たないプライベート VM からインターネットへの下り（egress）を可能にします。ポート枯渇を避けるために、ピーク時の接続数に合わせて NAT IP とポート割り当てのサイズを決定し、トラブルシューティングのためにロギングを有効にします。
  • Private Google Access は、プライベート VM が内部 IP を使用して Google API にアクセスできるようにします。VM アクセスのためにはサブネットで、ノードローカルの API アクセスのためには GKE ノードで有効にします。オンプレミスのクライアント向けには、Private Service Connect for Google APIs を使用して、Google API のフロントとなるプライベート VIP を公開します。
  • プロデューサー/コンシューマーサービス向けの Private Service Connect は、プロジェクト間または組織間のサービス公開用に、プライベートな内部 IP エンドポイントを提供します。プライベート DNS と組み合わせることで、ネットワークを公開することなくトラフィックを誘導できます。

• Network Connectivity Center (NCC) とトランジット

  • NCC は、スポークが VPC、HA VPN、または Interconnect アタッチメントであるハブアンドスポーク トポロジを可能にします。特にプロジェクトや組織をまたぐ場合に、中央のハブを使用してルート配布と複数 VPC のトランジットを簡素化します。
  • ガバナンスが許す場合は、組織内のトランジットには Shared VPC を優先的に使用します。柔軟なマルチドメインのトランジットや SD-WAN 統合が必要な場合は、NCC を使用します。
  • VPC Peering は推移的ではない（non-transitive）ことを理解し、トランジットに依存しないでください。NCC または一元化されたファイアウォール/ロードバランサ VPC がトランジットコアを形成します。

複数リージョンにまたがる選択肢、レイテンシ、下り（egress）コスト:

• RTT を最小化するために、コンピューティングをユーザーの近く、およびステートフルなバックエンドの近くに配置します。External HTTP(S) Load Balancing は、スマートなルーティングを備えたグローバルな上り（ingress）を提供しますが、データベースのレプリケーションレイテンシと一貫性は、依然としてアプリケーションの制約となります。
• ゾーン間のトラフィックはリージョン内でコストが発生します。リージョン間のレプリケーションは、下り（egress）料金とレイテンシを追加します。Cloud CDN を使用して、インターネットへの下り（egress）とオリジンの負荷を削減し、通信量の多いサービスは同じ場所に配置し続けます。
• ディザスタリカバリのためには、別のリージョンでのウォームスタンバイを、下り（egress）コストと運用の複雑さと比較検討します。データプレーンとコントロールプレーンがリージョン間の分離に耐えられる場合にのみ、リージョンにまたがるフェイルオーバーポリシーとヘルスチェックを備えたグローバルロードバランシングを使用します。

可観測性、信頼性オペレーション、およびコントロール

• ネットワークの可観測性

  • VPC フローログ: サブネットレベルで有効にし、サンプリングとメタデータのオプションを調整します。トラフィックのベースライン化、下り（egress）分析、脅威ハンティングに使用します。長期的な分析のために BigQuery にエクスポートします。
  • ファイアウォールルールロギング: 重要なルールで有効にし、許可および拒否されたトラフィックをキャプチャします。フローログと関連付けて設定ミスを検出します。
  • Connectivity Tests: 送信元と宛先のパスをモデル化して、到達可能性、ルート選択、ファイアウォール評価を検証します。CI/CD に統合して、デプロイ前に構成のドリフトを検出します。
  • ヘルスダッシュボード: ロードバランサのバックエンドヘルス、Cloud NAT のポート使用率、Cloud Router の BGP セッションステータス、Interconnect の使用率を監視します。逸脱時にアラートを発生させます。

• 信頼性パターンと一般的な障害モード

  • ゾーンの回復性: バックエンドを少なくとも2つのゾーンに分散させます。マネージドインスタンスグループまたは複数ゾーンの GKE ノードプールを使用します。ヘルスチェックとファイアウォールタグがすべてのゾーンに適用されることを検証します。
  • ルーティングの回復性: グローバル動的ルーティングと複数の Cloud Router を使用して、リージョンをまたぐ接続性を確保します。ブラックホールシナリオをテストし、モニタリングがルートの取り下げをカバーしていることを確認します。
  • DNS の回復性: Cloud DNS ではデフォルトで複数のネームサーバーをデプロイします。ハイブリッド環境では、フォワーダーが冗長であることを確認し、オンプレミスリゾルバの単一障害点を回避します。誤った側からルーティング不可能な応答を返すスプリットホライズンの設定ミスを防ぎます。
  • エッジでのセキュリティ: Cloud Armor のレート制限を適用して、オリジンをフラッド攻撃から保護します。これを怠ると、オートスケーリングの嵐とコストの急増を引き起こす可能性があります。

• コスト管理

  • リージョン間の呼び出しを最小限に抑え、VPC 内トラフィックには内部ロードバランシングを優先し、プロデューサー/コンシューマー間のトラフィックには PSC を検討して NAT の下り（egress）を回避します。
  • 静的および半静的なアセットには Cloud CDN を使用し、キャッシュ可能性を調整します。Interconnect の容量を適切に設定して、アイドル状態のヘッドルームに対する過払いを回避します。トラフィックデータを使用してコミットメントを適正なサイズにします。

オペレーションのスニペット:

• プライベートバックエンドへのロードバランサのヘルスチェックを許可する:
  • gcloud compute firewall-rules create allow-lb-hc –network=prod –action=ALLOW –direction=INGRESS –rules=tcp:80,tcp:443 –source-ranges=130.211.0.0/22,35.191.0.0/16 –target-service-accounts=backend-sa@project.iam.gserviceaccount.com
• サブネットで Private Google Access を有効にする:
  • gcloud compute networks subnets update app-subnet –region=us-central1 –enable-private-ip-google-access
• HA VPN 用の Cloud Router を作成する:
  • gcloud compute routers create cr-us-central1 –region=us-central1 –network=prod –asn=64514

実践的な問題シナリオ

Contoso Retail は、グローバルな e コマース API を立ち上げる計画です。要件は、ゼロダウンタイムでのバージョニング、バックオフィスシステムへの厳格なプライベート接続、アプリケーション VM にパブリック IP を持たせないことです。このソリューションは、DDoS 保護、エッジキャッシュ、および2つのデータセンターからの信頼性の高いハイブリッドアクセスを提供する必要があります。

アプローチ:

1. VPC とセグメンテーションの設計

• カスタムモードの共有 VPC ホストプロジェクトを作成し、2つのリージョンにまたがって階層ごと（ウェブ、API、データ）に専用のサブネットを設けます。理由: 共有 VPC はコントロールを一元化し、サービスプロジェクトはチームを分離します。階層ごとのサブネットは、最小権限のファイアウォール設定と、より小さな障害ドメインを可能にします。
• 組織レベルで階層型ファイアウォールポリシーを適用し、インターネットからのインバウンド SSH を拒否し、下り（egress）を許可された宛先に制限します。理由: グローバルなガードレールは、プロジェクトでの設定ミスのリスクを低減します。

2. パスベースのグローバルイングレスと API バージョニングの実装

• 単一のエニーキャスト IP と HTTPS 終端を持つ外部 HTTP(S) ロードバランサをデプロイします。URL マップを設定して、/v1/* と /v2/* を、リージョンごとのゾーン NEG をバックエンドとする別々のバックエンドサービスにルーティングします。理由: バックエンドサービスを分けることで、単一のホスト名と TLS の下で、各 API バージョンの独立したデプロイとロールバックが可能になります。
• Cloud Armor WAF とレート制限をアタッチし、キャッシュ可能なエンドポイント（例: 商品画像）に対して Cloud CDN を有効にします。理由: オリジンを保護し、レイテンシと下り（egress）コストを削減します。

3. バックエンドの到達可能性とヘルスの確保

• API インスタンスグループに対して、期待されるポートでロードバランサのヘルスチェックを許可するファイアウォールルールを作成します。理由: これがないとヘルスチェックが失敗し、インスタンスが非正常と見なされると、オートスケーラーがスラッシング（過剰なスケーリング動作）を起こす可能性があります。
• インスタンスをリージョンごとに2つのゾーンに分散させ、フラッピング（不安定な状態変化）を回避するためにヘルスチェックのしきい値を控えめに設定します。理由: ゾーンの多様性と安定したヘルス ポリシーが可用性を向上させます。

4. スプリットホライズンとサービスディスカバリによる DNS の構築

• contoso.com 用のパブリック Cloud DNS ゾーンと、内部専用レコード（例: db.internal.contoso.com）用に同じ名前のプライベートゾーンを作成します。理由: スプリットホライズンは、一貫した命名を維持しつつ、内部名が外部に漏洩するのを防ぎます。
• オンプレミスの corp.local クエリをエンタープライズ DNS に転送し、プライベートゾーンをアプリケーションプロジェクトにインポートするように DNS ポリシーを設定します。理由: 再帰ループなしでハイブリッド環境の境界を越えてシームレスな名前解決を実現します。

5. 冗長性を備えたハイブリッド接続の確立

• 各リージョンで、各データセンターに対して2つの HA VPN トンネルをプロビジョニングし、各ペアを別々の Cloud Router 上で BGP を使用して構成します。容量と SLA の要件がそれを正当化する場合は、別々のエッジゾーンに冗長なアタッチメントを持つ Partner Interconnect を追加します。理由: 複数の多様なパスがフェイルオーバーを提供し、BGP は高速な収束と動的なルート交換を可能にします。
• 共有 VPC でグローバル動的ルーティングを使用し、ルートフィルタを適用して、望ましくないオンプレミスのプレフィックスが伝播するのを防ぎます。理由: リージョン間で一貫したルーティングを確保しつつ、ルートリークのリスクを低減します。

6. Google API へのプライベートアクセスとアウトバウンドインターネットの提供

• アプリケーションサブネットで Private Google Access を有効にし、バッチジョブで使用される Google API 用に Private Service Connect エンドポイントを設定します。API 以外の必要なアウトバウンドの下り（egress）には Cloud NAT を使用します。理由: バックエンドはパブリック IP を持たないまま、必要なサービスに到達できます。PSC はプライベート DNS での名前解決を簡素化します。

7. トランジットとサードパーティ接続の一元化

• ホストプロジェクトに Network Connectivity Center ハブを作成し、HA VPN、Interconnect アタッチメント、および任意の SD-WAN スポークをアタッチします。理由: ハブアンドスポーク型のトランジットは、ピアリングメッシュと比較して、複数の VPC と外部ネットワーク間のルート配布を簡素化します。

8. 可観測性とガードレールの実装

• すべてのサブネットで適切なサンプリングレートの VPC フローログを有効にし、重要なルールでファイアウォールログを有効にし、BigQuery にエクスポートします。新しいファイアウォールやルートの変更を本番適用する前に、CI/CD で Connectivity Tests を使用します。理由: 深い可視性により、トラブルシューティング、キャパシティプランニング、監査可能性がサポートされます。
• Cloud Router の BGP セッション切断、Cloud NAT のポート枯渇、バックエンドヘルスの低下、Cloud Armor ルールのヒットに対してアラートを設定します。理由: 障害や攻撃の早期検出は MTTR を削減します。

9. パフォーマンスとコストの最適化

• ステートフルなサービスをコンピューティングと同じリージョンに配置し、静的コンテンツを Cloud CDN でエッジにキャッシュします。理由: RTT とリージョン間の下り（egress）を最小限に抑えます。
• 定期的にフローログを確認してゾーン間の過剰な通信を特定し、配置やサービスの境界を調整します。理由: 不要な下り（egress）とレイテンシを削減します。

この設計は、バージョニングされたルーティングによるグローバルで安全なイングレス、動的フェイルオーバーを備えた回復力のあるハイブリッド接続、必要なサービスへのプライベートアクセス、そして包括的な可観測性を実現し、同時にレイテンシと下り（egress）コストを管理します。

← データストレージ、データベース、分析アーキテクチャ · すべてのドメイン · セキュリティ、コンプライアンス、データ保護アーキテクチャ →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Googleを閲覧 →