リソースの使用率が高すぎたため、EC2 Linux インスタンスでインスタンスのステータスチェックが失敗しました。この解決方法を教えてください。

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

Amazon Elastic Compute Cloud (Amazon EC2) Linux インスタンスで、リソースの過剰使用が原因でインスタンスのステータスチェックに失敗しました。この解決方法を教えてください。

簡単な説明

使用率が高すぎるためにインスタンスがヘルスチェックに失敗する理由はいくつかあります。リソースの過剰使用が原因でヘルスチェックが失敗する最も一般的な理由を以下に 3 つ挙げます。

  • インスタンスの CPU 使用率が 100% 近くに達し、カーネルを実行するのに十分なコンピューティング性能がインスタンスに残っていなかった。
  • ルートデバイスが 100% いっぱいになっていて、他のプロセスの完了または開始を妨げています。
  • インスタンスで実行されているプロセスですべてのメモリが使用され、カーネルの実行が妨げられている。

解決方法

Amazon CloudWatch CPU 使用率メトリクスを確認する

インスタンスの CloudWatch メトリクスを確認します。CPU 使用率が 100% またはそれに近い場合は、次のオプションを使用してトラブルシューティングを行います。

  • インスタンスを再起動して、正常な状態に戻します。
    注意: インスタンスの CPU 要件が現在のインスタンスタイプで提供できるものよりも高い場合、再起動後に再度問題が発生します。
  • インスタンスを変更して CPU 要件を満たすインスタンスタイプにすることを検討してください。
  • インスタンスがバーストパフォーマンスインスタンス (T2、T3、または T3a) である場合は、インスタンスのメトリクスを一覧表示して CPUCreditBalance を確認します。CloudWatch コンソールまたは AWS Command Line Interface (AWS CLI) を使用して、メトリクスを一覧表示できます。
    クレジットバランスがゼロに近い場合、インスタンスの CPU でスロットリングが発生している可能性があります。クレジット指定がインスタンスで標準に設定されている場合、指定を無制限に変更できます。クレジット指定の変更については、「バーストパフォーマンスインスタンスのクレジット指定の変更」を参照してください。

注意: AWS CLI コマンドの実行時にエラーが表示される場合は、AWS CLI の最新バージョンを使用していることを確認してください

インスタンスのシステムログでエラーがないか確認する

システムログを確認して、No space left on device または Out of memory エラーがないかを確認します。

No space left on device エラー

インスタンスのシステムログに「OSError: [エラー 28] デバイス '/var/lib/' に残りのスペースがありません」のようなエラーが表示された場合、リストされたフォルダを含むファイルシステムがいっぱいです。(この例では、/var/lib がフォルダです。)

ファイルシステムの領域は、次のいずれかの方法を使用して解放できます。

方法 1: EC2 シリアルコンソールを使用する

Linux 用 EC2 シリアルコンソールを有効にした場合は、それを使用して、サポートされている Nitro ベースのインスタンスタイプのトラブルシューティングを行うことができます。シリアルコンソールは、起動の問題、ネットワーク設定、および SSH 設定の問題のトラブルシューティングに役立ちます。シリアルコンソールは、正常に動作するネットワーク接続を必要とすることなく、インスタンスに接続します。シリアルコンソールには、Amazon EC2 コンソールまたは AWS CLI を使用してアクセスできます。

シリアルコンソールを使用する前に、アカウントレベルでコンソールにアクセス権を付与します。その後、IAM ユーザーにアクセス権を付与する AWS Identity and Access Management (IAM) ポリシーを作成します。また、シリアルコンソールを使用するすべてのインスタンスには、少なくとも 1 名のパスワードベースユーザーを含める必要があります。インスタンスにアクセスできず、シリアルコンソールへのアクセスが設定されていない場合は、「方法 2: レスキューインスタンスを使用する」の手順に従ってください。Linux 用の EC2 シリアルコンソールの設定の詳細については、「EC2 シリアルコンソールへのアクセスを設定する」を参照してください。

方法 2: レスキューインスタンスを使用する

警告: インスタンスの停止と起動を行う前に、以下の点を理解しておいてください。

  • インスタンスが Instance Store-Backed である場合、またはデータを含むインスタンスストアボリュームがインスタンスにある場合、インスタンスを停止するとデータが失われます。詳細については、「インスタンスのルートデバイスタイプの判別」を参照してください。
  • インスタンスが Amazon EC2 Auto Scaling グループの一部である場合、インスタンスを停止するとインスタンスが終了することがあります。Amazon EMR、AWS CloudFormation、または AWS Elastic Beanstalk で起動されたインスタンスは、AWS Auto Scaling グループの一部である可能性があります。このシナリオでのインスタンスの終了は、Auto Scaling グループのインスタンスのスケールイン保護の設定に応じて異なります。インスタンスが Auto Scaling グループの一部である場合は、解決手順を開始する前に、一時的に Auto Scaling グループからインスタンスを削除してください。
  • インスタンスを停止および再開すると、インスタンスのパブリック IP アドレスが変更されます。インスタンスに外部トラフィックをルーティングするときは、パブリック IP アドレスではなく Elastic IP アドレスを使用することがベストプラクティスです。Amazon Route 53 を使用している場合は、パブリック IP が変更されたときに Route 53 DNS レコードを更新する必要がある場合があります。

1.    同じ Amazon マシンイメージ (AMI) を使用しかつ障害のあるインスタンスと同じアベイラビリティーゾーンで、Virtual Private Cloud (VPC) で新しい EC2 インスタンスを起動します。新しいインスタンスがレスキューインスタンスになります。

アクセス可能な既存のインスタンスが同じ AMI を使用し、障害のあるインスタンスと同じアベイラビリティーゾーンにある場合は、その既存のインスタンスを使用することもできます。

2.    障害が発生したインスタンスを停止します

3.    障害のあるインスタンスから Amazon Elastic Block Store (Amazon EBS) ルートボリュームの接続解除 (/dev/xvda または /dev/sda1) を行います。ルートボリュームのデバイス名 (/dev/xvda または /dev/sda1) を書き留めます。

4.    レスキューインスタンスに EBS ボリュームを、セカンダリデバイス (/dev/sdf) としてアタッチします。

5.    SSH を使用してレスキューインスタンスに接続します

6.    レスキューインスタンスにアタッチされた新しいボリュームのマウントポイントディレクトリ (/rescue) を作成します。

$ sudo mkdir /rescue

7.    ステップ 6 で作成したディレクトリにボリュームをマウントします。

$ sudo mount /dev/xvdf1 /rescue

注: デバイス (/dev/xvdf1) は、別のデバイス名でレスキューインスタンスにアタッチされている場合があります。lsblk コマンドを使用して、利用可能なディスクデバイスとそれらのマウントポイントを表示し、正しいデバイス名を確認してください。

8.    du-h コマンドを実行して、どのファイルが最も容量を占めているかを確認します。

du -h /rescue/var/lib

9.    必要に応じてファイルを削除し、追加のスペースを解放します。

10.    unmount コマンドを実行して、レスキューインスタンスからセカンダリデバイスをマウント解除します。

$ sudo umount /rescue

マウント解除のオペレーションが成功しない場合は、レスキューインスタンスを停止または再起動して、クリーンなマウント解除を取得する必要があります。

11.    レスキューインスタンスからセカンダリボリューム /dev/sdfデタッチします。次に、/dev/xvda (ルートボリューム) として元のインスタンスにアタッチします。

12.    EC2 インスタンスを起動し、インスタンスが応答していることを確認します。

メモリ不足エラー

インスタンスのシステムログに「メモリ不足: プロセスの終了」というエラーが表示された場合、インスタンスのメモリが不足しています。メモリが不足すると、カーネルには実行するのに十分なメモリがなくなり、メモリを解放するために他のプロセスが強制終了されます。

メモリ不足 (OOM) の問題を解決する方法の詳細については、メモリ不足: プロセスの終了を参照してください。