Google PCNE: ロード バランシング、Cloud CDN、グローバル トラフィック管理 — 学習ガイド

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

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

概要

このセクションでは、Google Cloud Load Balancing、Cloud CDN、およびグローバル トラフィック管理が連携して、回復力、パフォーマンス、安全性に優れたサービスを提供する方法について説明します。ロードバランサ ファミリーと選択、プロキシとパススルーの動作の違い、バックエンドとルーティングのコンポーネント、フェイルオーバーと容量管理、Cloud CDN のキャッシングとオリジン保護、エニーキャストとクロスリージョン設計、DNS ステアリングとヘルスチェック、オブザーバビリティ、そして堅牢なグローバル エントリポイントの設計パターンについて解説します。

ロードバランサ ファミリー、選択、データプレーンの動作

Google Cloud は、それぞれ異なるスコープ、プロトコル、データプレーン特性を持つ外部ロードバランサと内部ロードバランサを提供します。適切なものを選択することで、プロトコルの要件、地理的要件、および運用上の制御を整合させることができます。

• 外部プロキシ L7 (グローバル): HTTP(S) および gRPC 用の External Application Load Balancer。TLS を終端し、L7 ポリシーを適用し、URL マップ、Cloud CDN、Cloud Armor、リクエスト/レスポンス機能、およびエニーキャスト IPv4/IPv6 をサポートします。高度なルーティング、セキュリティ、キャッシングを必要とするインターネット向けの Web API/サイトに最適です。

• 外部プロキシ L4.5: External TCP Proxy Load Balancer (グローバル) と External UDP Proxy Load Balancer (リージョン) は、クライアント接続を終端し、バックエンドにプロキシします。グローバル VIP と L4 機能 (TLS ポリシー、TCP のヘッダーによるクライアント IP の保持) が必要で、L7 ルーティングが不要な場合に使用します。

• 外部パススルー L3/L4 (リージョン): External Network Load Balancer は、接続を終端せずにパケットを転送します。レイテンシが最も低く、最もシンプルです。TCP/UDP/ESP/ICMP をサポートします。リフトアンドシフト、異種混合のバックエンド、またはプロキシ終端を許容できないプロトコルに適しています。従来の NLB はターゲット プールを使用しますが、新しいリージョン パススルー NLB はバックエンド サービスを使用します。

• 内部プロキシ (リージョン): Internal HTTP(S) Load Balancer (L7) と Internal TCP Proxy Load Balancer (L4.5) は、VPC 内で終端とプロキシを行い、マイクロサービスのノースサウス トラフィックやサービス間通信に使用されます。ホスト/パス ルーティング (HTTP)、アプリケーション経由のクライアントへの mTLS、およびサービスごとのセキュリティ ポリシーをサポートします。

• 内部パススルー (リージョン): Internal TCP/UDP Load Balancer は、プライベート RFC1918 アドレスを介してバックエンドに接続を分散し、クライアント IP を保持し、MAGLEV ハッシュを使用します。ゾーンアウェアな分散と低オーバーヘッドを必要とするイーストウエスト サービス (データベース、カスタム プロトコル) に最適です。

レイヤーと終端のトレードオフ:

• プロキシ L7/4.5 は、追加のホップとヘッダー/NAT 変更の可能性というコストと引き換えに、高度なルーティング、TLS オフロード、オブザーバビリティ、Cloud Armor/CDN、およびクロスリージョン フェイルオーバーを提供します。パブリック エントリポイントやサービスメッシュに適しています。
• パススルー L3/L4 は、クライアント IP をエンドツーエンドで保持し、レイテンシを最小限に抑えますが、L7 機能はなく、オブザーバビリティのフックも少なくなります。セッションの動作はハッシュベースで、ヘルスチェックはよりシンプルです。

スコープと IP ファミリー:

• グローバル エニーキャスト VIP は、External Application LB と External TCP Proxy LB で利用でき、どこからでも到達可能な単一の IPv4/IPv6 アドレスを提供します。リージョン LB はリージョンのユニキャスト VIP を使用します。パブリック サービスを IPv6 に対応させるには、IPv6 アドレスを持つ外部グローバル ロードバランサを構成することで実現します。

選択基準のハイライト:

• ホスト/パス ルーティング、リダイレクト、Cloud CDN、Cloud Armor、または gRPC が必要な場合: External Application LB
• L7 なしのグローバル TCP が必要な場合: External TCP Proxy LB
• プロキシを好まないプロトコル (例: 一部のレガシー UDP/TFTP): 外部または内部パススルー
• HTTP ルーティングを使用するプライベートなサービス間通信: Internal HTTP(S) LB
• VPC 内トラフィックのコスト/ホップを最小限に抑えたい場合: 内部パススルー

バックエンドサービス、ルーティングオブジェクト、ヘルス、トラフィックのスティッキネス

コアなデータプレーンオブジェクト:

• バックエンドサービス: バックエンド (インスタンスグループ、ゾーナルNEG、ハイブリッドNEG、サーバーレスNEG)、ヘルスチェック、バランシングモード、キャパシティ、セッションアフィニティ、タイムアウト、フェイルオーバーポリシーを定義します。プロキシLBと新しいパススルーLBに必要です。
• ターゲットプール: クラシック外部NLB用のレガシーな構成要素。リフトアンドシフト時の単純なTCP/UDP分散や異種VMに適しています。
• 名前付きポート: インスタンスグループ上のキーで、論理名 (例: http) をポート番号にマッピングします。バックエンドサービスやURLマップから参照されます。グループメンバー間で一貫性を確保してください。

ヘルスチェックとフェイルオーバー:

• タイプ: HTTP(S)、HTTP/2、gRPC、TCP、SSL。OSの到達可能性だけでなく、実際のサービスの準備状況を検証するチェックを選択してください。
• スコープ: ヘルスチェックはリージョン単位です。各バックエンドは、そのサービス提供リージョンをスコープとするヘルスチェックを持つべきです。
• フェイルオーバーポリシー: バックエンドサービスはプライマリとフェイルオーバーのバックエンドを指定できます。プライマリが異常な場合、またはキャパシティが不足した場合 (failover-on-capacityが有効でしきい値を満たした場合) にトラフィックはフェイルオーバーします。サンダリングハードを避けるために、ドレイニングとキャパシティ予約を検討してください。

URLマップとルーティング:

• URLマップは、外部または内部HTTP(S) LBにアタッチされ、ホストルールとパス照合を定義します。
• デフォルトサービス: どのルールにも一致しないリクエストに対するキャッチオールバックエンドです。設定されていない場合、404が返されます。
• リダイレクトとリライト: URLマップのアクションを使用して、ルーティング前にHTTPSリダイレクト、正規ホストリダイレクト、またはパスリライトを実行します。

例: HTTPSリダイレクトとデフォルトバックエンドを持つ最小限のURLマップ

• example.comのホストルールを作成し、HTTPをHTTPSにリダイレクトし、/staticをCDNが有効なバックエンドバケットにルーティングし、デフォルトでリージョンのバックエンドサービスにルーティングします。

セッションアフィニティとドレイニング:

• アフィニティのオプションはLBのタイプに依存します。一般的なオプション:
  • なし: ステートレスに最適で、負荷分散を最大化します。
  • クライアントIP: L4/L7にわたって送信元IPでスティッキーになります。複数のプロトコル (例: HTTPとTFTP) が同じバックエンドに共にスティッキーである必要がある場合に使用します。
  • 生成されたCookie (L7のみ): LBがバックエンドへの永続化のためにCookieを設定します。NAT越しのクライアントに対しては、クライアントIPよりも分散が向上します。
• トレードオフ: アフィニティはホットスポットを引き起こし、オートスケーリングを複雑にする可能性があります。可能な限りステートレスを優先してください。
• コネクションドレイニング: スケールインやバックエンドの削除時に、LBはドレイニングタイムアウトを尊重し、既存の接続が正常に終了できるようにします。リセットを防ぐために、予想される最長のリクエストに合わせてドレイン時間を調整してください。

キャパシティとオートスケーリング:

• バランシングモード: 使用率 (例: CPU)、RPS、または接続数に基づきます。各バックエンドはキャパシティをアドバタイズし、飽和状態になるとLBは負荷を軽減するかフェイルオーバーします。
• オートスケーリング: マネージドインスタンスグループはシグナル (CPU、カスタムメトリクス) に基づいてスケールします。LBのキャパシティが不足すると、スケールアウトの遅延が503エラーを引き起こす可能性があります。日中のトラフィックに対しては、最小レプリカ数や予測オートスケーリングによって事前にウォームアップしてください。
• フェイルオーバーとオーバーフロー: failover-on-capacityを適切な閾値で有効にすると、スムーズなリージョン間のオーバーフローが可能になります。

バックエンドでのセキュリティ:

• インスタンスタグまたはサービスアカウントをターゲットとするファイアウォールルールを使用して、バックエンドへのアクセスを制限します。内部クライアントからの直接アクセスが必要な場合は、Googleロードバランサとヘルスチェックの送信元範囲、および承認されたクライアント範囲からのトラフィックのみを許可します。

例: クライアントとヘルスチェックをバックエンドタグ付きグループに制限する

• インスタンスにapplicationタグを付けます。
• クライアントのCIDRとGoogleヘルスチェックの範囲から、applicationタグをターゲットとするtcp:80のイングレス許可ルールを作成します。
• デフォルトで拒否する設定は、ドロップされたトラフィックをログに表示させるために推奨されます。

Cloud CDN、キャッシュポリシー、オリジン保護

Cloud CDN は外部アプリケーション ロードバランサと統合し、エッジ POP でレスポンスをキャッシュすることで、レイテンシを削減し、オリジンのキャパシティをオフロードします。

キャッシュモードと TTL:

• オリジンヘッダーを使用: オリジンの Cache-Control と Expires を尊重します。正確性のために推奨されます。
• キャッシュを強制: 設定されたデフォルト TTL ですべてのレスポンスをキャッシュし、オプションで静的コンテンツのオリジンヘッダーを上書きまたは無視します。動的データのキャッシュを避けるために慎重に使用してください。
• キャッシュをバイパス: 決してキャッシュしてはならないパスに役立ちます。

キャッシュキー:

• キーのフィールドには、プロトコル、ホスト、パス、クエリパラメータ、ヘッダー、Cookie が含まれます。必要に応じて、クエリストリングポリシー（すべて含める、選択したものを含める、無視する）、ヘッダーと Cookie の選択的インクルード、デバイスセグメンテーションを設定します。
• ヒット率を最大化するためにキーは最小限に保ち、表現が変わるフィールドでのみ変化させます。

署名付きリクエスト:

• 署名付き URL: 有効期限とパススコープを持つ HMAC または RSA 署名を付与し、特定のリソースへの時間制限付きアクセスを許可します。オブジェクトごとの認可を持つアクセラレータとしての CDN に適しています。
• 署名付き Cookie: Cookie を使用して一連のパスを認可します。サイト全体のゲート付きコンテンツに役立ちます。
• キーをローテーションし、短い有効期限を強制することで、リプレイリスクを低減します。

圧縮と正確性:

• リクエストに Via ヘッダーが含まれている場合でも、オリジンは圧縮を行う必要があります。オリジンが「圧縮をサポートしている」にもかかわらず CDN が非圧縮オブジェクトを配信する場合、Via が存在する場合にオリジンが圧縮するように設定されていることを確認してください。

オリジンのセキュリティ:

• エッジプロキシからオリジンへは、最新の TLS ポリシーで HTTPS を使用します。
• オリジンへの到達可能性を制限する: Google ロードバランサとヘルスチェックのソース範囲、および既知のプライベートプロデューサーからのトラフィックのみを許可するバックエンドのファイアウォールルールを設定します。バックエンドインスタンスは、任意のパブリックイングレスを受け入れるべきではありません。
• L7 DDoS/WAF、レート制限、脅威検出のために Cloud Armor と組み合わせます。誤検知を軽減するために、新しいルールにはプレビューモードを使用します。
• TTL の有効期限が切れる前にパージする必要がある場合は、キャッシュ無効化 API を使用して意図的にコンテンツを無効化します。動的コンテンツには、短い TTL と再検証（ETag/If-None-Match）を推奨します。

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

• 広すぎるキャッシュキーはキャッシュを無駄にし、ヒット率を低下させます。狭すぎるキーは誤ったバリアントを配信するリスクがあります。
• 動的データを強制的にキャッシュすると、パーソナライズされたコンテンツが漏洩する可能性があります。
• 署名付き URL/Cookie はエッジでのアクセスを保護しますが、オリジンへのバイパスはネットワークポリシーによって拒否されなければなりません。

グローバルなトラフィック管理、DNSステアリング、可観測性、および回復性のあるエントリポイント

エニーキャストのフロントドアとリージョン間のフェイルオーバー:

• External Application LBとexternal TCP Proxy LBは、グローバルエニーキャストVIPを使用して、クライアントを最も近いGoogleエッジに誘導します。トラフィックはその後、最も正常で最も近く、容量のあるバックエンドにプロキシされます。シームレスなフェイルオーバーとオーバーフローを実現するために、一貫したヘルスチェックと容量設定を持つ複数のバックエンドリージョンを構成します。
• コールドスタートのペナルティを避けるために、セカンダリリージョンに容量を事前にプロビジョニングします。オートスケーラーの最小/最大値をLBの容量しきい値と調整します。

リージョン内の内部トラフィック管理:

• Internal HTTP(S) LBとinternal passthrough LBはリージョン単位です。リージョン内でのゾーンの多様性を考慮して設計し、必要に応じて、Private Service Connectを備えた個別のLBを使用するか、サービス対応クライアントがリージョンエンドポイントを選択するようにして、マルチリージョン構成にします。
• 通信するサービスを同じリージョンとVPCに配置することで、東西間のレイテンシを低く保ちます。コストと運用のシンプルさを最小限に抑えるために、単一のVPCまたはピアリングされたVPCでRFC1918アドレッシングを使用します。

Cloud DNSのルーティングポリシーとヘルスチェック:

• ポリシー: 加重ラウンドロビン（トラフィック分割）、位置情報（ユーザーを最も近いリージョンのVIPに送信）、フェイルオーバー（プライマリ/バックアップ）。ビジネスルールを満たすためにポリシーを組み合わせます。
• ヘルスチェック: ステアリングで使用されるA/AAAAレコードにDNSヘルスチェック（HTTP/HTTPS/TCP）をアタッチし、異常なエンドポイントが除外されるようにします。リゾルバのキャッシュ（TTL）が反応を遅らせることを考慮し、ステアリング対象のレコードのTTLを低く保つことで、DNSルックアップの増加と引き換えにフェイルオーバーの応答性を向上させます。
• トラフィックステアリング: 加重ポリシーを使用して、移行を段階的に実施したり、リージョン間で負荷をシフトしたりします。split-horizon DNSを使用する場合を除き、インターネットからプライベートアドレスへのステアリングは避けてください。

可観測性と診断:

• ロードバランサのロギング: すべてのLBでロギングを有効にします。HTTP(S)ログには、リクエストメソッド/URI、レイテンシ、キャッシュヒット/ミス、バックエンドサービス、URLマップルール、TLS詳細、レスポンスコードが含まれます。TCP/UDPログは、接続メタデータとヘルスプローブのステータスを提供します。
• メトリクス: バックエンドの正常性、使用率、RPS、接続数、レイテンシ、キャッシュヒット率、4xx/5xxレート、容量飽和度を監視します。急激な変化や持続的なしきい値超過に対してアラートを設定します。
• 一般的なHTTP(S)エラーパターン:
  • 404: URLマップに一致なし。ホスト/パスルールとデフォルトサービスを確認します。
  • 301/302: 意図的なリダイレクト。リダイレクトループを確認します。
  • 502: バックエンド接続またはプロトコルの不一致（例: HTTP/1.1 vs gRPC）。正常性とバックエンドプロトコルの設定を確認します。
  • 503: 正常なバックエンドまたは容量のあるバックエンドがない。ヘルスチェック、クォータ、オートスケーラーの動作を確認します。
• リクエストのトレース: アプリケーションによって伝播されるX-Forwarded-For、X-Forwarded-Proto、およびトレースIDを使用します。リクエストIDを使用して、LBログとバックエンドログを関連付けます。
• ファイアウォールインサイト: 許可ルールと拒否ルールでVPCファイアウォールロギングを有効にします。ドロップを明示的にログに記録するには、ロギングが有効な低優先度のdeny-allルールを追加します。

回復性のあるグローバルエントリポイントの設計:

• 複数のリージョンバックエンドを前面に配置したexternal Application LBで、単一のグローバルanycast VIPを使用します。サーバーレス/VM/コンテナのバックエンドを少なくとも2つのリージョンに配置します。リージョン間のフェイルオーバーとオーバーフローを有効にし、保守的なヘルスチェックを構成し、ワークロードに合わせてドレイニングとタイムアウトを調整します。
• Cloud Armorとクォータ制限ポリシーでエントリを保護します。静的およびキャッシュ可能な動的コンテンツにはCloud CDNを使用して、エッジでトラフィックの急増を吸収します。
• グローバルLBでデュアルスタックIPv4/IPv6を公開し、すべてのネットワークにサービスを提供します。厳格なクライアントアクセスには、正確なソース範囲とインスタンスタグまたはサービスアカウントを使用して、バックエンドのファイアウォールルールを適用します。

例: タグ付けされたバックエンドへのクライアントとヘルスチェックの範囲を制限するファイアウォールルール

• インスタンスにapplicationというタグを付けます。
• applicationをターゲットとし、source-ranges=203.0.113.0/24,198.51.100.0/24およびGoogleヘルスチェックの範囲からのtcp:443を許可する上り（ingress）ルールを作成します。
• 予期しないソースをキャプチャするために、ロギングが有効な低優先度のdeny-allルールが存在することを確認します。

実践的な問題シナリオ

Acme Retailは、グローバルなeコマースプラットフォームを立ち上げます。このプラットフォームは、us-east1とeurope-west1にまたがって、低レイテンシ、強力なセキュリティ、透過的なフェイルオーバーを必要とし、静的メディアを効率的に配信する必要があります。プライベートな管理者インターフェースには、本社オフィスとパートナーのCDNステージングネットワークからのみアクセスできるようにする必要があります。

1. フロントドアとバックエンド

• 公開ストアフロントのホスト名用に、デュアルスタックのanycast VIPとTLS証明書を持つexternal Application Load Balancerを作成します。
• us-east1とeurope-west1にあるリージョンマネージドインスタンスグループをそれぞれ指す2つのバックエンドサービスを定義します。ヘルスチェック（HTTPS）を有効にし、バランシングモードを使用率（utilization）に設定し、容量のしきい値を80%にします。理由: エニーキャストとマルチリージョンバックエンドの組み合わせにより、ユーザーは最も近いエッジに到達し、リージョンが異常または飽和状態になった場合にシームレスにフェイルオーバーできます。

2. URLマップ、ルーティング、リダイレクト

• 公開ストアフロントとプライベート管理者ホスト名用のホストルールを持つURLマップを構成します。/staticをCloud CDNが有効なバックエンドバケットにルーティングし、/apiと/をVMバックエンドにルーティングします。HTTPからHTTPSへのリダイレクトを追加します。理由: ホスト/パスルーティングにより、静的トラフィックと動的トラフィックが分離され、安全なアクセスが強制されます。

3. Cloud CDNポリシー

• /staticのバックエンドバケットに対して、キャッシュモードをオリジンヘッダーの使用に設定し、機能しないクエリパラメータを無視し、Accept-Encodingヘッダーのみを含むキャッシュキーを定義します。短いTTLで一般的な404エラーに対するネガティブキャッシュを有効にします。理由: コンテンツのセマンティクスを尊重し、ヒット率を最大化し、不適切なバリアントのキャッシュを回避します。

4. セッションアフィニティとドレイニング

• 公開ストアフロントには生成されたCookieによるアフィニティを設定し、静的アセットには設定しません。コネクションドレイニングを60秒に設定します。理由: Cookieはカートセッションを安定させつつ、広範な分散を可能にします。ドレイニングは、スケールインやフェイルオーバー中にユーザーに見えるエラーを防ぎます。

5. リージョン間のフェイルオーバーとオートスケーリング

• 90%のオーバーフローしきい値で容量に基づくフェイルオーバーを有効にし、超過分を他のリージョンにシフトします。リージョンごとに最小レプリカ数4、LBの使用率に合わせたCPUターゲットでMIGオートスケーリングを構成します。理由: 容量の崖（capacity cliff）を避け、LBとオートスケーラーの決定を調整してスムーズなスケーリングを実現します。

6. 管理者インターフェースの制限

• プライベート管理者ホスト名用に、VPC内からのみアクセス可能なinternal HTTP(S) Load Balancerを作成します。split-horizon Cloud DNSを公開し、内部クライアントはILBのVIPに解決され、外部クライアントはNXDOMAINを受け取るようにします。理由: 公開エンドポイントを公開することなく、管理者トラフィックをプライベートに保ち、制御します。

7. バックエンドのファイアウォールとオリジンのセキュリティ

• 管理者バックエンドとWebバックエンドにapplicationタグを付け、本社とステージングのCIDR、さらにGoogleロードバランサとヘルスチェックのソース範囲からのtcp:443を許可するルールを追加します。より低い優先度でロギング付きのdeny-allルールを追加します。理由: 意図したクライアントとGoogleインフラストラクチャのみがバックエンドに到達できるようにし、ドロップされたトラフィックの可視性を提供します。

8. Cloud Armor

• マネージドWAFルールと、/apiのバーストに対するプレビューモードのレート制限を含むセキュリティポリシーを適用します。理由: L7保護と段階的な適用により、チューニング中のリスクを低減します。

9. Cloud DNSステアリングとヘルスチェック

• 公開ストアフロントのホスト名に対して、ALBのanycast VIPを指すAレコードとAAAAレコードを公開します。ブルー/グリーンカナリア展開のために、指定されたカナリアホスト名に加重ポリシーを作成し、トラフィックの5%をeurope-west1のみのALBに、95%をグローバル展開に分割します。カナリアが異常な場合に除外するためにHTTPSヘルスチェックをアタッチし、TTLを20秒に設定します。理由: DNSベースのカナリアにより、正常性を認識した除外と迅速な収束を伴う段階的な公開が可能になります。

10. 可観測性

• LBとCDNのログを有効にし、分析のためにBigQueryにエクスポートします。5xxレート、バックエンド容量、ヘルスチェックの失敗、CDNヒット率に対してアラートを設定します。URLマップテストとリクエストログを使用してルーティングエラーを診断し、502/503の急増を調べてバックエンドの飽和やプロトコルの不一致を検査します。理由: プロアクティブな監視と迅速な診断により、MTTRを最小限に抑え、ユーザーエクスペリエンスを維持します。

← ハイブリッド接続、Cloud Router、BGP · すべてのドメイン · Cloud DNS、サービス ディスカバリ、ハイブリッド名前解決 →

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

Googleを閲覧 →