なぜ「StatusCheckFailed_System」が 出たら、停止して起動 すると良いのか
2025.01.31こんにちは！Koty-Mousa 矢坂幸太郎 です！
私は アノテーション株式会社で、「クラスメソッドメンバーズ」のテクニカルサポートを担当しております。
様々なお客様からのご質問にお答えする中で、私がふと気になったことを調査しました。
StatusCheckFailed_System
ステータスチェックとは、EC2インスタンスが正しく動作しているかどうかを、AWSが自動的に調査し、問題を検出すると 該当の CloudWatch メトリクス が「1」になるものです。
ステータスチェックには3種類あり、システム・インスタンス・EBS それぞれのチェックがあります。
「StatusCheckFailed_System」は、AWSのシステム・基盤側で問題が検出された際に返されるチェックです。
具体的な原因として、AWSドキュメント[1]には次の記載があります
システムステータスチェックの失敗の原因となる問題の例を次に示します。
- ネットワーク接続の喪失
- システム電源の喪失
- 物理ホストのソフトウェアの問題
- ネットワーク到達可能性に影響する、物理ホスト上のハードウェアの問題
AWSドキュメントに、解消方法として次の記載があります。
AWSドキュメント[1]
システムステータスチェックが失敗した場合、AWS が問題を解決するのを待つか、自分で解決できるかを選択できます。
Amazon EBS でバックアップされたインスタンスの場合は、インスタンスを自分で停止および起動することができます。通常、インスタンスは新しいホストに移行されます。
AWSドキュメント[2]
インスタンスのステータスチェックに失敗するか、インスタンスでアプリケーションが想定通りに動作しておらず、インスタンスのルートボリュームが Amazon EBS である場合、インスタンスの停止と起動を行い、問題が解決するか試してみることができます。
「自分（お客様）で 停止して起動する」ことが、どうして解決につながるのでしょうか？
「起動」「停止」
まずは、「起動」と「停止」の仕組みを見てみましょう。
起動の仕組みは、ドキュメント[2]に次の記載があります。
インスタンスを起動すると、（中略）起動時に指定したインスタンスタイプによって、インスタンスのホストコンピュータのハードウェアが決定します。
要は、「起動」操作すると、AWSにより自動でサーバーが選択されて、インスタンスが起動するということです。
なお、このタイミングでサーバーが足りないと、キャパシティ不足・Insufficient Instance Capacity エラーが発生します。
参考：EC2 キャパシティ不足のエラー発生時の対応まとめ | DevelopersIO
停止の仕組みは、AWSドキュメントで直接的な記載を見つけられなかったものの、停止後に起動する場合の記載は次のようにありました。[3]
インスタンスを起動するとどうなるか
ほとんどの場合、基盤となる新しいホストコンピュータにインスタンスが移行します
停止すると、サーバの稼働が停止し、サーバの割り当てが解除されるとみられます。
つまり、停止してから起動（Stop/Start）すると どうなるか、
AWSドキュメント[4]には、次の記載があります。
インスタンスは新しいホストコンピュータに移動されます (ただし、場合によっては、インスタンスが現在のホストに残ることもあります) 。
停止して起動する
では、どうして 停止して起動すると 「StatusCheckFailed_System」の解決につながるのでしょうか。
ここまでの情報から考えてみましょう。
一旦、仮の状況を想像してみます。
まず、起動中の AWSシステム基盤に、何らかの問題が発生したとします。
先述 [1] の通り、電源やハードウェアの問題などです。
通常、「StatusCheckFailed_System」が返されます。
そして、停止して起動すると、
別のサーバーが選択され、今度は正常に動作するようになりました！
このように、停止して起動すると、別の基盤が選択されるため、問題が解決することがあります。
「再起動（reboot）」 を押せば良いのでは？
結論： 再起動 と 停止して起動 は異なる動作をします！
AWSドキュメント[4] には、再起動の場合
同じホストコンピュータで保持される
インスタンスの再起動は、オペレーティングシステムの再起動と同等です。
と記載があります。
つまり、停止して起動 とは違い、基盤は変更されません。
OS や アプリケーションの問題には効果的な可能性がありますが、システムステータスチェックが返される AWS基盤側の問題がある場合は、インスタンスは同じ基盤で動作を続けるため、解決しない可能性があります。
再起動 で問題が解決しない場合は、停止して起動 をお試しください。
Auto Recovery
ここまで 復旧方法をご案内しましたが、実は EC2ではデフォルトで、インスタンスの復旧をしてくれる機能が設定されています。
詳細は下記をご覧ください。
おしまい！ - AWS の仕組みは 奥深い
今回は、EC2 を 停止して再起動する 仕組みを確認しました。
最初は、「『再起動』を押せばいいじゃん」と思っていましたが、挙動が異なることを理解しました。
これからも、さまざまなAWSの仕組みを見て、皆様にお伝えしていきます！
Koty-Mousa 矢坂幸太郎 がお伝えしました！
[1] Amazon EC2 インスタンスのステータスチェック - Amazon Elastic Compute Cloud
[2] Amazon EC2 インスタンスの状態変更 - Amazon Elastic Compute Cloud（中略は筆者注）
[3] EC2 インスタンスの停止および開始の動作 - Amazon Elastic Compute Cloud
[4] Amazon EC2 インスタンスの状態変更 - Amazon Elastic Compute Cloud
The avatar, logo and name of "Koty-Mousa 矢坂幸太郎" and "Clamerus, dev. by Koty-Mousa" (include inconsistent/abbreviation spelling) are owned and copyrighted by Koty-Mousa (individually).
アノテーション株式会社について
アノテーション株式会社はクラスメソッドグループのオペレーション専門特化企業です。サポート・運用・開発保守・情シス・バックオフィスの専門チームが、最新 IT テクノロジー、高い技術力、蓄積されたノウハウをフル活用し、お客様の課題解決を行っています。当社は様々な職種でメンバーを募集しています。「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、アノテーション株式会社 採用サイトをぜひご覧ください。
