- 新しい順
- 投票が多い順
- コメントが多い順
Auto Scaling グループでインスタンス間の CPU 使用率に偏りがある場合の対策について回答します。
質問1：インスタンス間で CPU 使用率に偏りがある場合のベストプラクティス
-
クールダウン期間の調整： Auto Scaling グループのクールダウン期間を増やすことで、新しいインスタンスが起動してワークロードの処理を開始するまでの十分な時間を確保できます。これにより、スケーリングの決定が行われる前に、新しいインスタンスがワークロードを適切に処理できるようになります。
-
インスタンス保護の実装： 起動後の短期間、インスタンスに保護を設定することで、新しく起動したインスタンスがすぐに終了されることを防ぎ、ワークロードの処理を開始する時間を確保できます。
-
スケーリングメトリクスの見直し： 単純な CPU 使用率だけでなく、より適切なメトリクスを使用することを検討してください。例えば、複数のインスタンスの平均値ではなく、最大値や特定のパーセンタイルを使用することで、一部のインスタンスの高負荷を適切に検出できます。
-
ステップスケーリングの使用： ターゲットトラッキングの代わりにステップスケーリングを実装することで、異なるアラームしきい値に基づいてより細かいスケーリングアクションを定義でき、極端なスケーリングイベントの可能性を減らせます。
-
アプリケーションコードの最適化： 可能であれば、ワークロードをインスタンス間でより均等に分散するようにアプリケーションを設計することを検討してください。
質問2：ターゲットトラッキングスケーリングのターゲット CPU 使用率の推奨設定値
ターゲット CPU 使用率の設定は、アプリケーションの特性によって異なりますが、一般的には以下の考え方が有効です：
-
一般的な推奨値： 多くの場合、ターゲット CPU 使用率は 70〜80% に設定されます。これにより、リソースを効率的に使用しながら、突然の負荷増加に対応するための余裕を残すことができます。
-
アプリケーション特性に基づく調整：
- レスポンス時間が重要なアプリケーションでは、より低い値（50〜60%）を設定して、パフォーマンスの低下を防ぎます。
- バッチ処理のような非同期ワークロードでは、より高い値（80〜90%）を設定して、コスト効率を高めることができます。
-
モニタリングと調整： 初期設定後、実際のパフォーマンスを監視し、必要に応じて調整することが重要です。CloudWatch アラームを設定して、スケーリングポリシーが期待通りに機能しているかを確認してください。
-
スレッショルドの調整： CPU 使用率の偏りが大きい場合は、平均 CPU 使用率ではなく、最大 CPU 使用率や特定のパーセンタイルに基づいてスケーリングすることを検討してください。
バッチ処理によって一部のインスタンスだけが高負荷になる場合は、ステップスケーリングポリシーを使用して、より細かい制御を行うことが効果的かもしれません。また、CloudWatch アラームの設定を見直し、スケーリングの条件が適切に設定されているかを確認することも重要です。
Sources
Target-tracking-metric autoscaling policy causes thrashing | AWS re:Post
Application Auto Scaling examples using AWS CLI - AWS SDK Code Examples
Set scaling limits for your Auto Scaling group - Amazon EC2 Auto Scaling
スケーリングの設定値を再考するのではなく機能としてバッチ処理をAutoScalingグループ外のEC2 (そのほかサーバーリソース) に分離するのはいかがでしょうか？
AWSではバッチの実行機能としてAWS Batchなどがあるのでこういった機能を使いながら処理を行っていくのがよいと思います。
https://docs.aws.amazon.com/ja_jp/batch/latest/userguide/getting-started-ec2.html
https://docs.aws.amazon.com/ja_jp/batch/latest/userguide/scheduled-batch-job.html
https://qiita.com/ReQ_HY/items/e6b1fbb3124c379f0937
EventBridgeを使用すればバッチ処理を指定した時間に開始するといったことも可能なので24時間EC2を動かすよりもコストは低くなる想定です。
