この問題はインスタンス内部設定特有の問題によって発生することがあります。インスタンスが無反応となった後のリカバリー方法は(EBS-backed か Instance-store backed か)によって異なります。

始めに、再起動がどのようにインスタンスに影響したかを見極めるため、インスタンスのコンソール出力を調査します。コンソール出力の情報からは、インスタンス障害の理由を理解するのに十分な情報が得られることがあります。

AWS Management Console から:

  1. インスタンスを選択します。
  2. [Instance Actions] メニューから [View System Log] を選択します。

Amazon EC2 API tools から:

  1. ec2-get-console-output コマンドを実行します。

コンソール出力から何が起きているかを判断することが出来ない場合には、下記の二つのインスタンス種別ごとのご案内をご覧ください。


Instance-store backed インスタンス

インスタンスリカバリー

一般的に、Instance-store ルートデバイスを使用して AMI から立ち上げたインスタンスが起動しなくなった場合、代替インスタンスを立ち上げる以外の選択肢はありません。このため、なにか修正を行ったら作業中のインスタンスのバックアップを bundling a custom AMI 作成しておくことが推奨されます。ブートプロセスの中でスクリプトをダウンロードして実行するような AMI を実行している場合であれば、コンソール出力で見られるエラーを修正するようにそのスクリプトを修正できるかもしれません。

データの復元

インスタンスストアのデータ復旧は、通常は不可能ですが、AWS サポート によってデータの一部を復旧できる可能性があります。ただし、そのインスタンスが終了されておらず、インスタンスを実行するハードウェアに問題がないことが条件です。データ復旧は確実にできるとは限らず、完了までに何日もかかることがあるため、AWS サポート によるデータ復旧以外にも適切なバックアップ方針をあらかじめ策定しておいてください。


EBS-Backed インスタンス

EBS-Backed インスタンスのリカバリーを始める前に、EBS-Backed インスタンスにおいても利用可能であるインスタンスストア (エフェメラルストアとも言います)を利用しているか確認しなくてはなりません。インスタンスストアに保存されているデータは失われるため、下記のリカバリー方法に進む前に、注意しなくてはなりません。必要であれば、プリアタッチされたインスタンスストアデータのリカバリーオプションの詳細について、上記の“インスタンスストアインスタンス” セクションをご参照ください。

インスタンスリカバリー

インスタンスが EBS-backed であれば stop/start を試みることが問題を解決することがあります。詳細については、 Stopping and Starting Instances をご覧ください。

正常に起動しない EBS-backed インスタンスのルートボリュームのエラーを調査し、問題を解決することが可能な場合があります。しかし、これはやや複雑な手順であり、システム管理の経験が無い場合にはお勧めいたしません。障害を起こしたインスタンスのコンソール出力を分析した後に、お客様が対処できたいくつかの例としては、そのボリュームに fsck を実行する、SELinux を無効化する(後述 “SELinux”の起動設定を変更後、元のインスタンスをStartする方法)、fstab ファイルのエラーを修正する、などがございます。

以下の手順でインスタンスの停止、起動を行います:

  1. 正しく起動しなくなったインスタンスを Stop (シャットダウンしないでください。)します。
  2. そのルート EBS ボリュームをデタッチします。
  3. (ルート以外の)任意のマウントポイントを使って、同じアベイラビリティゾーン内のインスタンスへそのボリュームをアタッチします。
  4. 旧ルートボリューム (アタッチしたボリューム)の設定を修正します。
  5. 再度そのボリュームを元のインスタンスの元のデバイスへとアタッチします。
  6. インスタンスを起動します。
  7. 必要に応じて Elastic IP アドレスを再度関連付けます。

IO の再有効化

場合によっては、安全のために EBS ボリュームの IO アクセスが無効化されることがあります。これに該当する場合は、次の手順に従ってください。

  1. 管理コンソールで、EBS ボリュームの一覧画面に移動します。ボリュームの IO が無効化されている場合は、Volume リストの Status Checks 列に Impaired と表示されます。
  2. コンソールから IO を再有効化するには、ボリューム詳細セクションの Enable Volume IO をクリックしてください。
  3. fsck や chkdsk などのツールを使用してデータの整合性を確認することをお勧めします。
  4. インスタンスが応答しない場合に、オペレーティングシステムによっては、IO を再開するとインスタンスがサービス状態に戻ることがあります。

データの復元

インスタンスが EBS-Backed であり、内部の設定などに関連して障害を起こしている場合(コンソール出力に手がかりがある場合があります。)で通常の再起動が成功しない場合、以下の手順によりデータ復旧、およびインスタンス自身の復旧が可能な場合があります。

  1. 正しく起動しなくなったインスタンスを Stop (シャットダウンしないでください。)します。
  2. そのルート EBS ボリュームをデタッチします。
  3. 同じアベイラビリティゾーン内に新しい代替インスタンス(以前にバンドルしたAMI から起動することをお勧めします。)を起動して、(ルート以外の)任意のマウントポイントを使って、そのボリュームをアタッチします。
  4. そのボリュームから代替インスタンスへとデータをコピーします。

追加のリソース

アーキテクチャの改善、ベストプラクティスの理解、障害に備えるためのたくさんのリソースが入手可能です。

  1. どのようにインスタンス障害に備えた設計を行うかについての詳細情報は AWS クラウドコンピューティング白書の Designing Fault-Tolerant Applications をご覧ください。
  2. 利用しているインスタンスのバックアップを bundling a custom AMI で作成しておくことが推奨されます。
  3. Amazon EC2 ユーザーガイドに耐障害性アプリケーションの概念についてのセクションがあります。

基盤となるホストで問題が発生すると、通常、インスタンスは「stopping」のままになります。インスタンスを強制停止することでこれに対処することが出来るかもしれません。これはEC2 コマンドラインツールや AWS Management Console を通じて行っていただけます。

コマンドラインツール

ec2-stop-instances [インスタンス ID] --force

AWS マネジメントコンソール

インスタンスを右クリックし、ドロップダウンリストから “Stop” を選択します。 (Forced Stop が行われる旨が表示されます。)

注:どちらの場合でも、二度強制停止を試みていただく必要があるかもしれません。

インスタンスを強制停止できない場合は、代替のインスタンスを開始できることがあります。詳しくは、インスタンスの停止に関するトラブルシューティングを参照してください。それでも問題を解決できない場合は、AWS フォーラムから、または AWS サポートケースをオープンしてお知らせください。迅速な問題解決のために、サポートへご連絡いただく際には、既に行った手順をお知らせ頂けますようお願いいたします。

インスタンスの “shutting down” 状態が正常な範囲を超えて長く続くと、そのインスタンスは Amazon EC2 サービス内の自動プロセスによりクリーンアップされます。インスタンスが「実行」状態ではない場合、インスタンス時間に対しては課金されません。

インスタンスが終了するまで待てない場合は、AWS フォーラムから、または AWS サポート ケースをオープンしてお知らせください。迅速な問題解決のために、サポートへご連絡いただく際には、既に行った手順をお知らせ頂けますようお願いいたします。


まずは無料で始める »

サインアップは簡単!サインアップは簡単!無料範囲内で対象製品を 12 ヵ月無料でお試しいただけます 。
AWS 無料利用枠の詳細はこちら ≫
AWS アカウント作成の流れはこちら »

日本担当チームへお問い合わせ

導入に関するご質問、お見積りなどご不明な点は、お気軽に日本担当チームまでご相談ください。