EC2 インスタンスが遅い、応答しない、またはアクセスできないが、CPU とメモリの消費量が高くない

最終更新日: 2020 年 9 月 22 日

Amazon Elastic Block Store (Amazon EBS) 汎用 SSD (gp2) ルートボリュームがある Amazon Elastic Compute Cloud (Amazon EC2) インスタンスへの接続に問題があります。CPU とメモリを完全に利用していなくても、接続が遅いかタイムアウトになります。

簡単な説明

この問題に関しては、インスタンスが依存する外部サービスの問題、ディスクスラッシング、ネットワーク接続の問題など、多くの原因が考えられます。この記事では、1 つの一般的な原因について説明します。gp2 ルートボリュームの I/O バーストクレジットが枯渇していることです。(ほとんどのリージョンで、gp2 はルートボリュームのデフォルトストレージドライブです。詳細については、Amazon EBS ボリュームタイプを参照してください。)

解決方法

I/O バーストのクレジットのバランスを確認する

  1. Amazon EC2 コンソールを開きます。
  2. ナビゲーションペインで [インスタンス] を選択して、インスタンスを選択します。
  3. 説明タブで、[ルートデバイス] リンク、[EBS ID] リンクを選択します。
  4. EBS ボリュームのモニタリングタブを選択し、バーストバランスメトリックを見つけます。バーストバランスが 0% の場合は、すべてのバーストクレジットが使用されており、ボリュームがそのベースラインパフォーマンスレベルを超えてバーストできないことを意味します。この問題を解決するには、次のいずれかの方法を使用します。

IOPS 要件を見積もり、次に、ロードをサポートするようにボリュームを変更する

  1. Amazon CloudWatch でルート EBS ボリュームの VolumeReadOps および VolumeWriteOps メトリクスを見つけます。詳細については、利用可能なメトリクスの検索を参照してください。
  2. CloudWatch Sum 統計を使用して、VolumeReadOps および VolumeWriteOps のピークレベルを取得します。次に、2 つの数値を加算します。例:
    VolumeReadOps
    = 737,000
    VolumeWriteOps
    = 199,000
    合計 = 936,000
  3. 必要な IOPS の数を見積もるには、前のステップの合計を測定間隔の秒数で割ります。例:
    測定間隔 = 5 分 (300 秒)
    936,000 / 300 = 3,120 IOPS

gp2 ボリュームのベースラインパフォーマンスは、ボリュームサイズの GiB あたり 3 IOPS で直線的にスケーリングします。つまり、パフォーマンスを改善するには、3,120 IOPS のボリュームを 1,040 GiB にスケールアップする必要があります (3,120 / 3 = 1,040)。

または、gp2 からプロビジョンド IOPS SSD (io1) にボリュームを変更します。io1 ボリュームでは、ボリュームサイズを増やすことなく、必要な IOPS の数を指定できます。io1 ボリュームを使用するタイミングの詳細については、プロビジョンド IOPS SSD (io1 および io2) ボリュームを参照してください。gp2 ボリュームと io1 ボリュームのコスト比較については、Amazon EBS 料金をご覧ください。

ワークロードの分散方法を変更する

EC2 インスタンスに複数のアプリケーションがある場合、それらのアプリケーションはルート EBS ボリュームの IOPS のために競合します。時間とともにワークロードが増加するにつれて、IOPS の需要は増加します。インスタンスのパフォーマンスを改善するには、アプリケーション向けの追加の非ルート EBS ボリュームを使用することを検討してください。また、オペレーティングシステムのみにルートボリュームを使用することも検討してください。

ボリュームサイズとワークロード分散を変更した後も EC2 インスタンスに接続できない場合は、インスタンスへの接続のトラブルシューティングを参照してください。