ある会社がAWS Elastic Beanstalkにアプリケーションをデプロイし、環境のAuto Scalingグループの希望するキャパシティを5つのEC2インスタンスに設定しました。デプロイ中にキャパシティが4つのインスタンスを下回ると、アプリケーションのパフォーマンスが低下します。この環境では、all-at-onceデプロイポリシーを使用しています。デプロイ中のパフォーマンス問題を防止するために、最も費用対効果の高い変更は何ですか？

「rolling with additional batch」デプロイポリシーは、既存のインスタンスを停止する前に新しいバッチのインスタンスを起動するため、デプロイ中に容量が減少するのを防ぎます。希望する容量が5つのインスタンスで、追加バッチサイズを1に設定すると、デプロイ中には一時的に6つのインスタンスが稼働し、パフォーマンス低下の原因となる容量不足を回避できます。 「希望する容量を6つのインスタンスに変更」は、デプロイ中の容量は増えますが、デプロイ時以外も常に1つ多いインスタンスが稼働するため、費用対効果が低いです。 「traffic splitting」は、新しいバージョンと古いバージョン間でトラフィックを分割し、徐々に新しいバージョンに移行しますが、評価時間1時間はデプロイ完了までの時間が長くなりすぎ、即座のパフォーマンス問題解決には不向きです。 「rolling」は、バッチごとにインスタンスを置き換えるため、デプロイ中に容量が減少し、パフォーマンス低下を引き起こす可能性があります。