Auto Scalingを使用していて、かなりうまく機能していますが、今朝何かが起こりました。インスタンスの1つのCPU使用率が何らかの理由で約％0であったため、同じアベイラビリティーゾーン内の残りのインスタンスに％100のCPU使用率が発生し、すべてのインスタンスの平均CPU使用率が約％70であったため、スケールアップしませんでした。一方、％80がヒットすると、トリガーは新しいインスタンスを開始する必要があります。ELBインスタンスのヘルスチェックも使用されますが、この％0インスタンスは正常でした。
そのようなインスタンスを削除するように自動スケーリングを構成することは可能ですか？チェックアップ用にカスタムcronジョブを設定する必要はありません。
そのようなインスタンスを削除するように自動スケーリングを構成することは可能ですか？
はい、以下を参照してください-あなたのコメントによると、あなたはすでにこれを正しく行っています。
チェックアップ用にカスタムcronジョブを設定する必要はありません。
構成が明らかに正しいことを考えると（ Auto ScalingやELBのそれぞれの問題を意味します）、未使用のインスタンスをアクティブにシャットダウンしたり、 as-set-instance-healthを促進したりすることで、カスタムソリューションを回避することはできません。以下の私の最初の回答ですでに示唆されているように-前者はELBに対する部族交配の回答によって示唆されています-不健康なインスタンスはOOSを取得し、ELBからも自動的に削除されます。これはあなたの状況に対処しているようです：
5分ごとに起動されるcronジョブを実行して、ELB内のすべてのサーバーをスキャンし、5分以上稼働していて異常であるかどうかを確認します。見つかったら、シャットダウンします。「デッド」インスタンスがELBでスタックし、自動スケーリングアクションをトリガーする監視メトリックを破棄するという問題があり、cronjobによって問題が解決されました。
ELBインスタンスのヘルスチェックも使用されますが、この％0インスタンスは正常でした。
どのヘルスインジケーターを参照していて、インスタンスが順番にヘルスであるとどのように結論付けましたか？
AutoscalingとELBは正常なインスタンスを異なる方法で測定することを理解することが重要です。不健全なインスタンスに反応しない、Autoscalingに対するalighafourの応答を参照してください。
ELBはアプリケーション層でチェックし、自動スケーリングはマシン層でチェックします。
この違いは、リンクされた質問ELBに対するAWSチームの回答でさらに詳しく説明されています-不健康なインスタンスがOOSになり、ELBから自動的に削除されます（実際には逆の問題に対処します）。
自動スケーリングはインスタンスの正常性を調べています。データがインスタンスが正常でないことを示している場合、インスタンスを停止します。その時点でELBから取り出して、インスタンスをシャットダウンします。
一方、ELBは、ファイルを読み込んだり、ポートに接続したりして、アプリケーションのヘルスチェックを実行します。アプリケーションがこれらのチェックの特定の数に失敗した場合、インスタンスは実行を継続しますが、ELBは新しいトラフィックを送信しません。ELBは引き続きヘルスチェックを実行します。アプリケーションインスタンスが再び正常になると、ELBはそのインスタンスへのトラフィックのルーティングを開始します。ELBは、ELB登録からインスタンスを削除しません。再び正常になるまで、トラフィックの送信を停止します。[強調鉱山]
前述のシナリオが実際にあなたの経験に当てはまるようです。ELBヘルスチェックが失敗したため、ELBはインスタンスへのトラフィックの送信を停止しましたが、AutoScalingヘルスチェックはインスタンス自体に問題を認識しませんでした。これは、たとえば、ELBヘルスチェックがApacheで提供されるWebページをプローブし、何らかの理由（Apacheのクラッシュなど）で応答しない場合に発生する可能性があります。
「現在のスケーリングレベルの維持内でのElasticLoadBalancingのヘルスチェックの作成」セクションで概説されているように、EC2ヘルスステータスとELBヘルスステータスの両方に基づいてヘルス決定を行うようにAutoScalingポリシーを設定する必要があります。
デフォルトでは、AutoScalingはすべてのAuto-Scaling管理対象インスタンスにAmazonEC2ヘルスステータスを使用します。Elastic Load Balancerのヘルスチェックも使用するには、グループのHealthCheckTypeプロパティをELBに設定します。
% as-update-autoscaling-group myGroup –-health-check-type ELB
この構成が適切に行われると、ELBヘルスチェックも失敗するとすぐにインスタンスは異常であると見なされ、それに応じて置き換えられます。
1つのAutoScalingグループに複数のトリガーを設定することは可能ですか？
残念ながらそうではありません。たとえば、テンプレートで複数のトリガーを設定する方法に対するAWSチームの応答を参照してください。
残念ながら、Auto ScalingサービスではAutoScalingグループごとに1つのトリガーしか許可されていないため、現時点では、テンプレート内の同じグループに対して複数のトリガーを使用することはサポートされていません。
別のアプローチは、「現在のスケーリングレベルの維持」内の「カスタムヘルスチェック」セクションで説明されているように、as-set-instance-healthを介してカスタムソリューションを実装することです。
独自のヘルスチェックシステムがある場合は、それをAutoScalingと統合できます。SetInstanceHealthを使用して、インスタンスのヘルス情報をシステムからAutoScalingに直接送信します。