私はt2.mediumをアーキテクチャのフロントサーバーとして使用しています。
通常、AWS自動スケーリングは「CPU使用率」を使用しますが、t2の場合は少しトリッキーです。 「CPU Credit Balance」が低い場合、t2.mediumの「CPU Utilization」は最大20%になる可能性があるため、自動スケーリングはアラートを検出しません。
T2インスタンスをスケーリングする方法はありますか?
updated:カスタムメトリックを使用しようとしています https://github.com/shtrihstr/cloudwatch
AWSが提供するCPUクレジットシステムに関するこの種の問題のために、アプリケーションが常にクレジットを消費するシナリオでは、T2インスタンスを絶対に回避する必要があります。アプリケーションが一貫した方法でCPUを集中的に使用する場合は、CPUとメモリの比率が同じであるC3/C4インスタンスを選択することをお勧めします(M4.largeと同等のt2.largeを除く)。
自動スケーリングが機能するのは、クラスターの容量が一貫しており、インスタンスの数に比例していると想定しているためです。これは、一部のシナリオでT2インスタンスを使用する場合には当てはまらない場合があります。一部のASGインスタンス(必ずしも起動日や自動スケーリングイベントなどが原因で、必ずしもすべてではない)がクレジットを使い果たすと、Cloudwatchに送信するTHOSE INSTANCESのすべてのメトリックがASGメトリックの一貫性を低下させ、それらを役に立たなくしますAutoscalingの適切な決定を行うため。
私のアプローチは、CPUクレジットが不足する前にスケーリングすることです。簡単な方法は、最小許容クレジット残高を定義することです。私にとって、これは50です。
これはCloudWatch内で実行できます。 'Create Alarm'、EC2 Metrics-> By Auto ScalingGroup。
CPUCreditBalance、最小50を選択します。これにより、平均バランスが許容範囲内であっても、ロードバランサーが循環から削除する前に単一のインスタンスが遅くなる可能性がある場合にアクションを実行できます。
通知または自動スケールを作成できます。