MENU
会員登録（無料）
  1. ホーム
  2. 【PCNE】WEB問題集:ネットワークサービス構成編

【PCNE】WEB問題集:ネットワークサービス構成編

WEB問題集

PCNE#251(configure-network)
あるメディア企業は、世界中のユーザーに対して単一のエニーキャスト IP でコンテンツを配信し、HTTPS 終端、HTTP/2、URL パスに基づくマイクロサービス振り分け、Cloud CDN による静的アセットのキャッシュ、Cloud Armor による WAF 防御を一括で適用したいと考えています。バックエンドは複数リージョンのマネージドインスタンスグループです。最も適切なロードバランサーはどれですか。
ディスカッション 0

正解：C

正解の根拠

グローバル外部アプリケーション ロードバランサーは、単一のエニーキャスト VIP、URL マップによる L7 ルーティング、Cloud CDN、Cloud Armor、Google マネージド証明書を統合的に提供します。マルチリージョンのバックエンドへの自動的なトラフィック分散にも対応しており、本シナリオの全要件を満たします。

LB タイプレイヤURL マップCloud CDNCloud Armor
Global External App LBL7対応対応対応
Internal App LBL7対応非対応非対応 (edge は不可)
External Network LBL4 パススルー非対応非対応非対応
Proxy Network LBL4 プロキシ非対応非対応対応 (限定)

不正解の理由

  • A: Internal App LB は VPC 内部用途であり、世界中のユーザーに公開する用途には適合しません (ドキュメント記載)。
  • B: External Network LB は L4 パススルー型のため URL マップや Cloud CDN を利用できません。
  • D: Proxy Network LB は L4 までの制御であり URL ベースの L7 ルーティングをサポートしません。

参考: https://cloud.google.com/load-balancing/docs/application-load-balancer

参考：Google Cloud VPC ドキュメント

PCNE#252(configure-network)
ある SaaS チームは、外部アプリケーション ロードバランサーに対して Google マネージド SSL 証明書を発行しましたが、ステータスが PROVISIONING のままになり HTTPS フロントエンドが正常に動作しません。証明書には api.example.com を指定しています。最も可能性の高い原因はどれですか。
ディスカッション 0

正解：D

正解の根拠

Google マネージド SSL 証明書は、対象ドメインの DNS A/AAAA レコードが対象ロードバランサーの IP を指していることを確認してから発行されます。DNS が未設定または別 IP を指している場合、PROVISIONING のままステータスが進みません。バックエンドの健全性や URL マップは証明書発行プロセスとは独立しています。

プロビジョニングのチェックリスト

  1. HTTPS 転送ルールに証明書をアタッチする
  2. 対象ドメインの A/AAAA を LB の IP に向ける
  3. 最大 60 分待機し ACTIVE になることを確認する
  4. 必要に応じて `gcloud compute ssl-certificates describe` で domainStatus を確認
gcloud compute ssl-certificates describe api-cert 
  --global --format="value(managed.domainStatus)"
選択肢判定
A不正解
B不正解
C不正解
D正解

不正解の理由

  • A: バックエンドヘルスチェックの結果は証明書プロビジョニングと無関係です。
  • B: Google マネージド証明書は ACME ではなく内部メカニズムで検証されるため、Cloud Armor の影響は受けません。
  • C: 同上、URL マップに ACME 用ルートを明示する必要はありません。

参考: https://cloud.google.com/load-balancing/docs/ssl-certificates/google-managed-certs

参考：Google Cloud VPC ドキュメント

PCNE#253(configure-network)
ある金融機関は、社内 Web アプリを VPC 内部の複数マイクロサービスに振り分けるため、リージョン内部アプリケーション ロードバランサーを構築しています。クライアントは同一 VPC 内の GKE Pod です。L7 で /api/* を別のバックエンド サービスへ振り分けるためにはどのコンポーネントが必要ですか。
ディスカッション 0

正解：C

正解の根拠

アプリケーション ロードバランサーで L7 のパスベースルーティングを行う中核コンポーネントは URL マップです。パスマッチャー (`pathMatcher`) によりホスト/パスの条件で複数のバックエンド サービスに振り分けます。Internal App LB でも構成方法は External と同一で、グローバル/リージョン構成のみが異なります。

gcloud compute url-maps create internal-um 
  --default-service=default-bs --region=us-central1
gcloud compute url-maps add-path-matcher internal-um 
  --path-matcher-name=api-matcher 
  --default-service=default-bs 
  --path-rules="/api/*=api-bs" 
  --region=us-central1
選択肢判定
A不正解
B不正解
C正解
D不正解

不正解の理由

  • A: Cloud DNS はホスト名解決の層であり L7 パスの判定はできません。
  • B: ファイアウォールは L3/L4 制御で、URL パスでの分岐はサポートしません。
  • D: ターゲットプロキシは URL マップを参照する関連リソースで、単独ではパス分岐できません。

参考: https://cloud.google.com/load-balancing/docs/url-map-concepts

参考：Google Cloud VPC ドキュメント

PCNE#254(configure-network)
ある EC サイトでは、外部アプリケーション ロードバランサーの背後の Compute Engine インスタンスがランダムにヘルスチェックで失敗します。サーバーログには問題がなく、Cloud Logging のヘルスチェック プローブのソース IP からの 403 が記録されています。最も可能性が高い原因はどれですか。
ディスカッション 0

正解：B

正解の根拠

Google Cloud のグローバル外部アプリケーション ロードバランサーは、ヘルスチェックを 35.191.0.0/16 と 130.211.0.0/22 のレンジから送信します。VPC ファイアウォールでこれらを許可していない場合、プローブが届かず UNHEALTHY となります。サーバーログには到達後の正常応答しか残らないことが多く、設定漏れに気付きにくい典型例です。

LB タイププローブ送信元
Global External App LB35.191.0.0/16, 130.211.0.0/22
Regional Internal App LB (Envoy proxy-only)35.191.0.0/16 + proxy-only サブネット
Network LB (バックエンド サービス ベース)35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22

不正解の理由

  • A: 通常 Cloud Armor はバックエンド サービスに紐づき、プローブ自体は別経路で評価されません。
  • C: URL マップは SSL 証明書を直接参照しないためヘルスチェック失敗の原因になりません。
  • D: セッション アフィニティはクライアント分散の制御で、プローブの成否には影響しません。

参考: https://cloud.google.com/load-balancing/docs/health-check-concepts

参考：Google Cloud VPC ドキュメント

PCNE#255(configure-network)
あるオンラインストアでは、ログインユーザーごとのカート状態をバックエンドで保持するため、同一クライアントからのリクエストを可能な限り同じインスタンスへ送りたいと考えています。外部アプリケーション ロードバランサーで設定すべきセッション アフィニティはどれですか。
ディスカッション 0

正解：A

正解の根拠

HTTP(S) ベースのアプリケーション ロードバランサーで Cookie ベースのアフィニティを使う場合、`GENERATED_COOKIE` を選択するとロードバランサーが GCLB Cookie を発行し、同一ブラウザからのリクエストを同じバックエンドへ向けます。NAT 配下のクライアントが多い環境でも安定的にアフィニティが維持できます。

アフィニティ用途
NONEステートレス API、純粋分散
CLIENT_IP送信元 IP ベース、NAT に弱い
GENERATED_COOKIEHTTP 用、最も汎用
HEADER_FIELD任意ヘッダー値、API ゲートウェイ向け
HTTP_COOKIEアプリ提供の任意 Cookie

不正解の理由

  • B: NONE はアフィニティを保持しないためカート状態が散逸します。
  • C: External App LB では CLIENT_IP_PORT_PROTO はサポートされません (Network LB の概念です)。
  • D: ホストヘッダーはクライアントごとに変わらないため分散の偏りを生みます。

参考: https://cloud.google.com/load-balancing/docs/backend-service#session_affinity

参考：Google Cloud VPC ドキュメント

前のページ
次のページ