Google PCNE: ネットワーク オブザーバビリティ、信頼性、トラブルシューティング — 学習ガイド

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

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

概要

Google Cloudにおけるネットワークオブザーバビリティとは、VPC、ロードバランサ、ハイブリッド接続、サービスにわたる到達可能性、パフォーマンス、正確性を記述するネットワークシグナルの規律ある収集、相関付け、分析のことです。信頼性は、障害検出と安全な修復を考慮した設計から生まれます。第一級のテレメトリを実装し、データプレーンに触れる前にコントロールプレーンを検証し、必要な場合にのみパケットの証拠でドリルダウンし、ロールバックを自動化します。このセクションでは、Google Cloudのツールとパターンを使用して、変更時のリスクを最小限に抑えながら、問題を検出、診断、防止する方法について説明します。

フローログ、ロギング、モニタリング、メトリクス、SLO

VPC Flow Logsは、VPCファイアウォールの評価後、VM NICでサンプリングされ集約されたテレメトリを提供します。これらは完全なパケットキャプチャではなく、明示的な許可/拒否の証拠としてファイアウォールルールロギングを置き換えるものではありません。主要な制御項目：

• サンプリング：0.0–1.0。サンプリングレートを高くすると、ログ量と潜在的なコストが増加する代わりに、忠実度が向上します。
• 集約間隔：5秒–30分。間隔を短くすると、検出までの時間は短縮されますが、エントリ数が増加します。
• メタデータ：インスタンスとVPCのメタデータを含めるか除外するか。より豊富な分析のためには含め、機密属性を制限するためには除外します。

サブネットでの一般的な有効化方法：

undefined

永続的な分析とプロジェクト間の共有のために、ログシンクを使用してエクスポートします。

• SQL分析と長期的な傾向分析のためのBigQuery。
• SIEM/IDSへのほぼリアルタイムのパイプラインのためのPub/Sub。
• アーカイブのためのCloud Storage。

• BigQueryへのシンクの例：

undefined

ファイアウォールルールロギングは、許可/拒否の決定と一致したルールを記録することで、フローログを補完します。ブロックされたトラフィックを監視するには、ルールセットの下部近くにロギングを有効にしたすべて拒否のルールを追加します。

undefined

Cloud Loggingでは、構造化されたクエリ、リクエストログ、ヘルスチェックログ、NATログ、ロードバランサログとの相関付けが可能です。次のようなシグナルのために、ログベースのメトリクスを作成します。

• バックエンドタグへの拒否された接続の急増（許可リストの設定ミスの可能性）。
• ポートへの大量のSYN再送信（飽和またはブラックホールの可能性）。
• NATの「利用可能なポートがない」イベント（Cloud NATの枯渇）。

Cloud Monitoringはメトリクスを集約し、ダッシュボード、アラート、SLOを提供します。

• 注目すべきメトリクス：ロードバランサの5xxレート、バックエンドのレイテンシ、インスタンスNICのバイト/パケット、Cloud NATの割り当て済み/使用済み/オーバーフローポート、Cloud RouterのBGPセッションステータス、VPNトンネルのパケットドロップ、Interconnectのリンク使用率、パケット損失とレイテンシ。
• ダッシュボード：サービスごと、接続性ごとにダッシュボードを構築し、プロジェクト間で共有テンプレートを使用して一貫した運用を実現します。
• アラート：迅速なフィードバックが得られる症状アラート（エラーレート、レイテンシ、ドロップカウンター）を優先し、ユーザーへの影響が考えられる場合はページングを伴う原因アラート（BGPフラップ、リンクダウン）を使用します。
• SLO：ユーザー中心のSLO（例：グローバルHTTPの成功率とレイテンシ）と、高速および低速なバーンを特定するためのバーンレートアラートを定義します。正確なSLO評価のために、ログベースのメトリクスを介してリクエストログを分子/分母として使用します。

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

• 低いサンプリングレートや長い集約間隔は、マイクロバーストや短時間の障害を隠してしまいます。
• フローログにはファイアウォール適用前のドロップに対する可視性がありません。拒否の証拠についてはファイアウォールルールロギングに依存します。
• フィルタリングなしの過剰なロギングはコストを増加させ、調査を遅らせる可能性があります。データを賢くエクスポートし、パーティション分割します。

Network Intelligence Centerと高度な診断

Network Intelligence Center (NIC)は、プロアクティブで構造化された診断を提供します。

Connectivity Tests：

• ルート、ファイアウォールルール（階層型ポリシーを含む）、サービスアカウント/タグ、ロードバランサ、Cloud NAT、ハイブリッド接続にわたるコントロールプレーンの到達可能性を検証します。
• ルート診断は、選択されたネクストホップを計算し、ルートの欠落や非対称パスなどの設定ミスを報告します。
• ネットワークの変更前後で使用し、意図しない影響範囲（ブラスト半径）を検出します。これはコントロールプレーンをモデル化するものであり、データプレーンの品質を保証するものではありません。パケット/メトリクスの証拠と組み合わせて使用します。

Performance Dashboard：

• リージョン間およびインターネットの観測拠点へのパケット損失とレイテンシのGoogleマネージドビュー。マクロなイベント（リージョン全体またはパス全体の輻輳）とサービスローカルな問題を区別するのに役立ちます。

Network Topology：

• プロジェクト間、VPC間、ハイブリッド接続とトラフィック量（ログを活用）を可視化し、ホットスポット、予期しないピアリングパス、意図しない推移的な動作を特定します。

Firewall Insights：

• シャドウルール、未使用の許可ルール、過度に寛容なソース、ターゲットタグ/サービスアカウントが欠落しているルールを検出します。既知のフローを壊すことなく攻撃対象領域を削減するために、より厳格なルールを推奨します。

Network Analyzer：

• プロジェクトを横断した静的および動的な構成チェックにより、次のような状況を明らかにします。
  • ファイアウォールによってブロックされているヘルスチェック（GoogleのヘルスチェックソースIP範囲を許可することを忘れないでください）。
  • 間違ったリージョンにある、または名前付きポートが欠落しているロードバランサのバックエンド。
  • 限定公開のGoogleアクセスが無効になっており、外部IPを持たないインスタンスからのAPIアクセスをブロックしているサブネット。
  • 重要なプレフィックスをブラックホール化するルートや、VPN/Interconnect間の非対称ルーティング。

運用ガイダンス：

• ネットワーク変更のためのCI/CDにNICのチェックを組み込み、スケジュールされた周期で実行します。検出結果は信頼性の負債として扱い、リスク削減効果のある修正を優先します。

Packet Mirroring、ロードバランサ、ハイブリッドテレメトリ

Packet Mirroring:

• VM のトラフィックをコレクタ（アプライアンスまたはマネージド IDS）にミラーリングし、詳細な検査を行います。サブネット、ネットワークタグ、またはサービスアカウントでスコープを絞り、コストを管理するために必要なプロトコルに制限します。
• オーバーヘッドとトレードオフ: ミラーリングされたトラフィックのエグレスにはコストが発生します。過度なミラーリングはコレクタに負荷をかける可能性があります。本番環境で無差別にミラーリングしないでください。インシデント対応には、期間限定でスコープを狭く絞ったセッションを使用します。
• IDS との統合:
  • Cloud IDS は Packet Mirroring を活用して、マネージド型のアウトオブバンドの脅威検出を提供します。迅速な有効化とメンテナンス削減のために、こちらを優先的に使用します。
  • 特定のシグネチャやベンダーエコシステムが必要な場合は、サードパーティの IDS アプライアンスも引き続き有効な選択肢です。

ロードバランサのログとヘルスチェックの証拠:

• HTTP(S) ロードバランサのリクエストログには、メソッド、URL、バックエンド、レスポンスコード、レイテンシ、および X-Forwarded-For を介したクライアント IP が含まれます。traceroute は Google Front Ends (GFEs) で停止するため、これらのログをクライアントパスの分析に使用します。
• バックエンドサービスでロギングを有効にし、サンプリングを構成してコストと可視性のバランスを取ります。ヘルスチェックのロギングをオンにして、プローブの結果と失敗の理由を確認します。
• クライアントアクセスの制限: インスタンスにタグを付け、承認されたクライアント範囲と Google のヘルスチェック IP のみを許可するファイアウォールルールを作成することで、バックエンドで強制します。L7 の脅威緩和と段階的なロールアウトのためには、Cloud Armor のルールを適用する前にプレビューモードで使用します。

VPN と Interconnect のテレメトリ:

• Cloud VPN (HA VPN) のメトリクス: バイト数、ドロップ数、暗号化エラー、トンネルのアップタイム、BGP セッションの状態。パケットドロップ、頻繁な DPD イベント、BGP のフラップに対してアラートを設定します。
• スループットのスケーリング: 個別のピア IP にトンネルを追加してトラフィックを分散させ、ヘッドルームを監視します。Cloud Router 間でアクティブ/スタンバイ構成が必要な場合は、オンプレミスの MED 属性を使用してパス選択にバイアスをかけることを推奨します。
• Interconnect のメトリクス: リンクごとの使用率、CRC エラー、可用性。60〜70% を超える持続的な使用率やエラーの急増を監視します。予備のキャパシティと多様な回線を維持します。再送信やキューイングの指標とともに、レイテンシの増加を調査します。
• エッジ全体での飽和の兆候: TCP 再送信の増加、コード変更なしでの 99 パーセンタイルレイテンシの増加、NAT ポートのオーバーフローイベント、キュー占有率のアラートは、差し迫った影響の早期警告です。

トラブルシューティングの方法論、インシデント対応、およびプロアクティブな信頼性

DNSからアプリケーションまで、体系的なトラブルシューティングを行います。

1. 障害が発生しているユーザー ジャーニーと時間帯を特定し、リージョンとパス（LB経由のパブリック、VPC経由のプライベート、またはハイブリッド）に絞り込みます。
2. DNS:

• Cloud DNS のログ、dig の出力、ポリシーの動作で名前解決を検証します。スプリットホライズンによる競合を確認し、転送ポリシーが有効であることを確認します。
• TTL と最近の変更を確認します。古いキャッシュは障害のように見えることがあります。

3. ロードバランサとエッジ:

• リクエストログとヘルスチェックログを確認します。5xx の急増を、バックエンドの健全性やデプロイイベントと関連付けます。L7 の場合、traceroute よりもリクエストログを信頼します。
• アクセスが制限されている場合は、ファイアウォールルールでクライアントの許可リストと Google ヘルスチェックの IP を検証します。

4. ルーティングとファイアウォール:

• Connectivity Tests を使用して、コントロールプレーンを決定論的に評価します。有効なルートと階層型ファイアウォールポリシーを調査します。非対称ルーティングとシャドウルールを探します。
• 拒否されたパケットについては、ファイアウォールルールのロギングに依存します。調査中は、優先度スタックの下位に、ロギングが有効な deny-all ルールを追加することを検討します。

5. Google API への下り（Egress）:

• インスタンスに外部 IP がない場合は、Private Google Access や Cloud NAT を確認します。どちらかが欠けていると、断続的な障害や紛らわしいタイムアウトが発生します。

6. ハイブリッド:

• Cloud Router と VPN/Interconnect のメトリクスを調査します。BGP は up 状態でもルートがインストールされない場合、アトリビュートの優先設定が影響している可能性があります。MED/local-pref と ASN を確認します。パケットドロップとパス MTU の問題に注意します。

7. パケットの証拠:

• コントロールプレーンが正しく見えても症状が続く場合は、Packet Mirroring を限定的に使用して、影響を受けている VM やティアの近くで PCAP を収集します。SYN/SYN-ACK のタイミング、再送信、MTU ブラックホールのための MSS/DF ビットを確認します。

インシデント対応:

• 変更の安全性: タグやサービスアカウントへのスコープ指定、優先度の引き下げ、ルールの無効化によって変更を段階的に適用します。ロギングを有効にし、カナリアでテストします。L7 ポリシーの変更には Cloud Armor のプレビューモードを使用します。
• ロールバック: 逆の変更を事前に定義し、以前の設定をバージョン管理システムに保持し、該当する場合はアプリケーションのエッジで短命な機能フラグを使用します。
• インシデント後の分析: ログとメトリクスからタイムラインを構築し、寄与因子（例: 許可ルールが拒否ルールによってシャドウイングされた、NAT の枯渇）を分類し、検知のギャップを記録し、アラート、NIC チェック、ポリシーの強化などの安全策を追加します。

キャパシティプランニングとプロアクティブな信頼性:

• ヘッドルームの目標値を追跡する: VPN/Interconnect リンクで 30～50%、NAT ポート使用率が持続的に 60% 未満、LB バックエンドの CPU と QPS がオートスケーリングのトリガーを大幅に下回っている状態。
• 主要なリスクに対するログベースのメトリクスを構築する: 拒否の急増、NAT のオーバーフロー、BGP のフラップ数、5xx レート、LB バックエンドの接続エラーなど。高速および低速の両方のインシデントを捕捉するために、マルチウィンドウのバーンレートアラートを使用します。
• 合成モニタリング: パブリックエンドポイントには複数リージョンからの Uptime Checks を使用し、内部サービスにはテスト VM からのプライベートプローブを使用します。
• 予防的な改善: Firewall Insights を使用してファイアウォールルールを改善し、Network Analyzer の検出結果を解決し、ピークイベント中に Flow Log の集約間隔を短縮し、ログを BigQuery にエクスポートして定期的な異常検知を行います。

実践的な問題シナリオ

Contoso Games は、us-east1 と europe-west1 でグローバルな HTTP(S) 負荷分散されたゲーム API を運用しており、オンプレミスのデータセンターとは HA VPN で接続しています。ヨーロッパのユーザーから、最近のファイアウォール変更後、断続的なタイムアウトとレイテンシの増加が報告されています。インスタンスには外部 IP がなく、Google API にはプライベートにアクセスする必要があります。

アプローチ:

1. 時間帯と SLO への影響を特定する

• 根拠: 時間帯を特定することで、クエリを関連ログに限定し、調査をユーザーに影響を与えている SLO と整合させることができます。バーンレートアラートにより、europe-west1 での急な SLO 消費が確認されます。

2. Connectivity Tests でコントロールプレーンを検証する

• 根拠: 外部 HTTP(S) ロードバランサのフロントエンドから europe-west1 のバックエンドサービスまで、および影響を受けている VM から Private Google Access の VIP までのテストを作成します。テストにより、一部のバックエンドへのヘルスチェックをブロックしている階層型ファイアウォールポリシーと、あるサブネットで Private Google Access が設定されていないことが判明します。

3. ログを通じてエッジとバックエンドの健全性を確認する

• 根拠: ロードバランサのリクエストログを europe-west1 と response_code >= 500 でフィルタリングし、バックエンドエラーを特定します。ヘルスチェックログには、既知の Google ヘルスチェックソース IP からのプローブ失敗が示されています。これは、アプリケーションのリグレッションではなく、ファイアウォールが原因でバックエンドが不安定になっている（フラッピング）証拠となります。

4. スコープを限定した変更で健全性を回復し、安全性を確保する

• 根拠: ヘルスチェックのソース範囲を許可する、バックエンドタグをターゲットにした許可ルールを追加します。このルールでロギングを有効にします。アクセスは既知のクライアントに制限されているため、許可リストのファイアウォールルールに特定のクライアント IP 範囲とヘルスチェック範囲のみが含まれていることを確認します。新しいルールは最初は無効にしておき、低トラフィック時のカナリアリリース中に有効にして、影響範囲（ブラスト半径）を限定します。

5. Google API へのプライベートな下り（egress）を再確立する

• 根拠: 影響を受けているサブネットで Private Google Access を有効にし、外部 IP のないインスタンスが、VPN やサードパーティのファイアウォールを経由するヘアピン状態になることなく Google サービスに到達できるようにします。これにより、レイテンシが削減され、ボトルネックが解消されます。

6. ハイブリッド接続の飽和状態と MTU を確認する

• 根拠: HA VPN のメトリクスでパケットドロップと使用率を確認します。1つのトンネルでドロップの増加が見られます。別のオンプレミスピア IP に2つ目のトンネルを追加して容量を増やし、トラフィックを分散させます。VPN パスでの PMTU ブラックホールを防ぐため、有効な MTU と MSS クランプを確認します。

7. 不正が疑われるクライアントに対し、Cloud Armor のプレビューモードを使用する

• 根拠: リクエストログから、プローブ失敗の直前に少数のクライアント IP がトラフィックを急増させていることがわかります。Cloud Armor にプレビューモードで拒否ルールを追加し、適用前に、ブロックすることでバックエンドの負荷が軽減されることを検証し、意図しないユーザーへの影響を回避します。

8. Packet Mirroring を限定的に使用してデータプレーンの動作を確認する

• 根拠: 15分間、単一の不健康なバックエンド VM から Cloud IDS にトラフィックをミラーリングします。PCAP から、不正な IP からのバースト時に SYN バックログが枯渇していることが示され、Cloud Armor ポリシーの有用性とレート制限の必要性が裏付けられます。

9. インシデントをクローズし、システムを強化する

• 根拠: ヘルスチェックの許可ルールを有効にし、Private Google Access を確認し、VPN 容量を拡張し、検証済みの Cloud Armor ルールを適用した後、エラーレートがベースラインに戻ります。ヘルスチェック成功率、NAT ポート使用率、VPN ドロップ数、リージョンごとの 5xx のダッシュボードを追加します。バックエンドタグへのファイアウォール拒否に関するログベースのアラートと、SLO バーンレートアラートを作成します。インシデント、根本原因（階層型ファイアウォールの変更、不正なトラフィック、VPN の飽和）を記録し、変更前のチェックリストに NIC Analyzer と Firewall Insights のチェックを追加します。

この一連の流れは、安全で証拠に基づいたワークフローを示しています。コントロールプレーンを確認し、データプレーンを観察し、最小限で可逆的な変更を適用し、そしてアラートと自動チェックによって学びを組織に定着させる、というものです。

← GKE、コンテナ、アプリケーション ネットワーキング · すべてのドメイン · ネットワーク自動化、ガバナンス、コスト オペレーション →

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

Googleを閲覧 →