PCNE#254(configure-network)
ある EC サイトでは、外部アプリケーション ロードバランサーの背後の Compute Engine インスタンスがランダムにヘルスチェックで失敗します。サーバーログには問題がなく、Cloud Logging のヘルスチェック プローブのソース IP からの 403 が記録されています。最も可能性が高い原因はどれですか。
正解：B
正解の根拠
Google Cloud のグローバル外部アプリケーション ロードバランサーは、ヘルスチェックを 35.191.0.0/16 と 130.211.0.0/22 のレンジから送信します。VPC ファイアウォールでこれらを許可していない場合、プローブが届かず UNHEALTHY となります。サーバーログには到達後の正常応答しか残らないことが多く、設定漏れに気付きにくい典型例です。
| LB タイプ | プローブ送信元 |
|---|---|
| Global External App LB | 35.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
コメント