インフラストラクチャ上級クイズ
関連ドキュメント: インフラストラクチャ上級
多肢選択問題
1. blue/green deployment における NLB weighted target groups の主な目的は何ですか?
- A) より少ない load balancer を使用してコストを削減するため
- B) cluster バージョン間の traffic distribution を制御するため
- C) SSL termination の性能を向上させるため
- D) health check の必要性をなくすため
答えを表示
答え: B) cluster バージョン間の traffic distribution を制御するため
解説: NLB weighted target groups により、blue(現在)cluster と green(新規)cluster の間で traffic を段階的に移行できます。重み(例: 90:10、50:50、0:100)を調整することで、operator は制御された rollout を実行し、問題が検出された場合にすばやく rollback できます。
2. single-zone EKS cluster 戦略では、data nodes を 1 つの Availability Zone のみにデプロイすることがあるのはなぜですか?
- A) Cross-AZ data transfer costs を削減するため
- B) DNS 設定を簡素化するため
- C) 複数の subnet の使用を避けるため
- D) persistent volume の必要性をなくすため
答えを表示
答え: A) Cross-AZ data transfer costs を削減するため
解説: AWS では Cross-AZ data transfer にコストが発生します。local storage を持つ data-intensive workload(database など)では、すべての replica を単一の AZ に保持することでこれらのコストをなくしつつ、durability には application-level replication に依存します。
3. Pod が異なる zone または node に分散されることを保証する Kubernetes 機能は何ですか?
- A) PodAffinity
- B) TopologySpreadConstraints
- C) ResourceQuota
- D) LimitRange
答えを表示
答え: B) TopologySpreadConstraints
解説: TopologySpreadConstraints は、Pod が topology domain(zone、node、region)全体にどのように分散されるかを制御します。高可用性のために均等な分散を保証し、maxSkew、topologyKey、whenUnsatisfiable パラメータで設定できます。
4. Route53 weighted routing は NLB weighted target groups とどのように異なりますか?
- A) Route53 は DNS level で動作し、NLB は connection level で動作する
- B) Route53 は等しい重みのみをサポートする
- C) NLB は health check をサポートしない
- D) Route53 には VPC peering が必要である
答えを表示
答え: A) Route53 は DNS level で動作し、NLB は connection level で動作する
解説: Route53 weighted routing は DNS 解決時に traffic を分散します。一方、NLB weighted target groups は connection level で分散します。DNS-based routing には TTL の考慮事項がありますが、NLB はより即時的な traffic shifting を提供します。
5. 3-AZ deployment における TopologySpreadConstraints の推奨 maxSkew 値は何ですか?
- A) 0
- B) 1
- C) 3
- D) 10
答えを表示
答え: B) 1
解説:maxSkew を 1 にすると、topology domain 間の Pod 数の差が最大 1 になるように、Pod が均等に分散されます。これにより、node に resource constraints がある場合でも scheduling の柔軟性を保ちながら、良好なバランスを実現できます。
6. blue/green cluster architecture では、cluster 間で何を共有すべきですか?
- A) Worker nodes
- B) External DNS and load balancer
- C) etcd storage
- D) Kubernetes API server
答えを表示
答え: B) External DNS and load balancer
解説: Blue/green cluster は、DNS record や load balancer などの外部 infrastructure を共有する別々の EKS cluster です。これにより、client-facing endpoint を変更せずに cluster 間で traffic を移行できます。
7. TopologySpreadConstraints で whenUnsatisfiable: DoNotSchedule が設定されている場合、何が起こりますか?
- A) Pod は constraint に関係なくどこにでも schedule される
- B) constraint を満たせない場合、Pod は pending のままになる
- C) Pod は自動的に削除される
- D) constraint は無視される
答えを表示
答え: B) constraint を満たせない場合、Pod は pending のままになる
解説:DoNotSchedule は、spread constraint に違反する場合に Pod の scheduling を防ぎます。これにより topology requirements への厳密な準拠が保証されますが、cluster topology が constraint をサポートしない場合、Pod が pending になる可能性があります。
8. blue/green cluster 間の automated failover には、health check とともにどの AWS service を使用できますか?
- A) AWS Config
- B) Route53 health checks with failover routing
- C) AWS Inspector
- D) AWS Trusted Advisor
答えを表示
答え: B) Route53 health checks with failover routing
解説: Route53 health checks は endpoint の可用性を継続的に監視し、failover routing policy を使用して healthy cluster に traffic を自動的に切り替えることができます。これにより、手動介入なしで automated disaster recovery が可能になります。
9. NLB cross-zone load balancing を使用する際の重要な考慮事項は何ですか?
- A) 常に無料である
- B) 追加の data transfer charges が発生する可能性がある
- C) VPC peering が必要である
- D) TCP protocol でのみ動作する
答えを表示
答え: B) 追加の data transfer charges が発生する可能性がある
解説: cross-zone load balancing が有効な場合、NLB は有効化されたすべての AZ 内のすべての registered target に traffic を均等に分散します。その結果、Cross-AZ data transfer charges が発生する可能性があります。multi-AZ deployment を設計する際には、このコストを考慮してください。
10. zonal cluster deployment(a-zone blue、c-zone green)における主な利点は何ですか?
- A) networking complexity の低減
- B) failure isolation と独立した upgrade paths
- C) compute costs の削減
- D) 自動 data replication
答えを表示
答え: B) failure isolation と独立した upgrade paths
解説: zonal cluster は failure domain isolation を提供します。つまり、1 つの zone での問題がもう一方の cluster に影響しません。これにより、独立した upgrade testing と段階的な rollout も可能になり、Kubernetes version upgrade 時のリスクを低減できます。