ある企業が、Amazon EKS でマイクロサービスを運用しており、特定のサービスへのトラフィックが急増したときに、そのサービスの Kubernetes Pod 数を自動的にスケールアウトさせたい。CPU 使用率や カスタムメトリクス（リクエストキュー長等）に基づいてスケールしたい。最も適切な方法はどれか。

正解: A

KEDA（Kubernetes Event-driven Autoscaling）は HPA を拡張して外部のイベントソース（CloudWatch メトリクス、SQS キュー長、Kafka オフセット等）に基づいて Pod のスケールを制御できる。AWS CloudWatch のカスタムメトリクスにも対応しており、リクエストキュー長などのビジネスメトリクスでのスケーリングが可能。CPU/メモリ以外のメトリクスでのスケールが必要な場合のデファクトスタンダード。選択肢CのKubernetes HPA は CPU・メモリ使用率には標準対応しているが、カスタムメトリクスや外部メトリクスには Custom Metrics API または External Metrics API のアダプターが必要で、KEDA はそれを簡単に実装できるラッパーである。CPU のみで十分な場合は HPA で良いが、カスタムメトリクス要件があるため KEDA が適切。選択肢BのEKS ノード数の固定増加は動的なスケーリングではなく、過剰プロビジョニングとなりコスト効率が悪い。選択肢DのAuto Scaling グループでのノードスケールは Pod のスケールとは異なる概念で、Pod 数の制御には HPA/KEDA が必要。