CPU とメモリの消費量が少ない Amazon Elastic Compute Cloud (Amazon EC2) インスタンスについて、低速、応答しない、またはアクセスできない問題を解決したいと考えています。
簡単な説明
外部サービス、ディスクスラッシング、またはネットワーク接続の問題により、Amazon EC2 インスタンスが低速になったり、応答しなくなったりする場合があります。低速または応答しない Amazon EC2 インスタンスを解決するには、以下のいずれかの方法を使用します:
- IOPS の要件を見積もり、ボリュームを変更する。
- ボリュームワークロードの分散方法を変更する。
開始する前に、[バーストバランス] メトリクスを確認します:
- Amazon EC2 コンソールを開きます。
- ナビゲーションペインで [インスタンス] を選択し、インスタンスを選択します。
- [ストレージ] タブで、ルートデバイスの [ボリューム ID] を選択します。
- EBS ボリュームの [モニタリング] タブを選択し、[バーストバランス] メトリクスを見つけます。バーストバランスが 0% の場合、すべてのバーストクレジットが使用されており、ベースラインのパフォーマンスレベルを超えてボリュームがバーストできないことを示しています。
注: 以下の解決策では、汎用 (gp2) ルートボリュームの I/O バーストクレジットが枯渇して Amazon EC2 インスタンスが遅くなる問題を解決する手順を示します。ほとんどの AWS リージョンでは、gp2 がルートボリュームのデフォルトのストレージドライブです。詳細については、「Amazon EBS ボリュームの種類」を参照してください。
解決策
IOPS の要件を見積もり、ボリュームを変更する
- Amazon CloudWatch のルート Amazon Elastic Block Store (Amazon EBS) ボリュームの VolumeReadOps と VolumeWriteOps を表示します。詳細については、「Search for available metrics」を参照してください。
- Cloudwatch の Sum 統計を使用して、VolumeReadOps と VolumeWriteOps のピークレベルを特定し、それらを合計します。例えば、VolumeReadOps のピークレベルが 737,000 で、VolumeWriteOps が 199,000 の場合、合計は 936,000 になります。
- 合計を測定期間の秒数で割ります。例えば、合計が 936,000 で、測定期間が 5 分 (300 秒) の場合、936,000 を 300 で割ります。必要な推定 IOPS は 3,120 です。
- [ボリュームタイプ]、[サイズ]、[IOPS]、または [スループット] を変更して、負荷に対応できるようにします。詳細については、「Modify an EBS volume using Elastic Volumes」を参照してください。
注: ボリュームを gp2 から gp3 に変更すると、そのボリュームはより低コストでより高いパフォーマンスを発揮します。また、プロビジョンド IOPS SSD (io1) ボリュームでは、ボリュームサイズを増やすことなく必要な IOPS 数を指定できます。詳細については、「Provisioned IOPS SSD ボリューム」を参照してください。gp2 ボリュームと io1 ボリュームのコスト比較については、Amazon EBS の料金を参照してください。
ワークロードの分散方法を変更する
1 つのインスタンスに複数のアプリケーションがある場合、それらのアプリケーションはルート Amazon EBS ボリュームの IOPS をめぐって競合します。ワークロードが増えるにつれて、IOPS の需要も高まります。インスタンスのパフォーマンスを向上させるには、次のアクションを実行してください:
- アプリケーションに、追加のルート以外の Amazon EBS ボリュームを使用する。
- ルートボリュームはオペレーティングシステム (OS) にのみ使用する。
ボリュームサイズとワークロードの分散を変更した際にインスタンスへの接続で問題が発生する場合は、「インスタンスへの接続に関するトラブルシューティング」を参照してください。
関連情報
I/O の特性とモニタリング
Amazon EBS プロビジョンド IOPS ボリュームのパフォーマンスを最適化するにはどうすればよいですか?
Amazon EBS ボリュームの料金はどのように請求書で計算されますか?