CPU とメモリの消費量が高くないにもかかわらず、EC2 インスタンスが低速、応答性が悪い、あるいはアクセス不能となる原因を教えてください。

最終更新日: 2021 年 1 月 19 日

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. [ ストレージ ] タブで、ルートデバイスの [ボリューム 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 インスタンスに接続できない場合は、「インスタンスへの接続に関するトラブルシューティング」を参照してください。