当ブログ「SSE Notes」の管理人hiroyamaですが普段はしがないサラリーマンをしている関係で、ブログのシステムトラブルなどあまり気にしてはいません。気になるのはGoogleアドセンスの広告収入ぐらいです。
今回、休日にたまたまメンテナンスのためWordpressのダッシュボードを開こうとしたところ、404エラーでhttps://hiroyama.info (グローバルIPでも)サイトが閲覧できません。
10分ほど様子見しても改善する様子もないため、障害切り分けしてみました。
AWS Lightsail インスタンスの障害切り分け
切り分けに決まった順番は有りませんが、上位から可能性を排除していきましょう。
AWSの障害発生状況を確認する
最近だとMicrosoft365系の障害でTeamsが停止した事例がありました。まずはAWSで障害出ていないか確認してみました。
一番便利なのはAWS障害情報(全リージョン) （@awsstatusjp_all）のTwitterアカウント。
あとはこちらの「AWS公式 Service Health Dashboard」です。かなり詳しく確認できます。
特にこの時点ではAWSでの障害は起きていないようです。
DNSの障害を確認する
DNSでブログサイトの固定IPアドレスを[hiroyama.info]に変換しているのですが、たまーにあるのが、この通信事業者のDNS障害。
変換前の当サイトの固定IPアドレスで接続できるか確認してみました。
こちらもアクセス不可でした。ここまで来るとAWS Lightsailで稼働している当ブログだけに起きている障害の模様。
AWS Lightsailのダッシュボードでインスタンス状況を確認する
AWS Lightsailのダッシュボードにアクセスし、サーバが止まっていないか確認しましたが、ステータス「実行中」でインスタンスは止まってはいないようです。
コマンドコンソール操作可能なSSHでアクセスしてみましょう。
「インスタンスに接続しています」のまま反応なし。サーバは稼働しているけど、動きが変ですね。
ちなみに正常に動作しているときは下のようなコマンドラインコントロールが表示されます。
AWS Lightsail パフォーマンスメトリクスを確認して見る
Windows PCで言うところのタスクマネージャですね。メトリクスでCPU使用率の状況が確認できます。
18時10分あたりからCPU使用率が急上昇。常に高い状況なら契約しているLightsailのスペック不足ですが、この場合は何らかのトラブルですね。何がCPU使用率の急上昇につながったのか？？
メトリクスではネットワークの状況も確認できるため、「受信ネットワークトラフィック」を確認してみました。どうやら外部から18:15前後に当サイトにデータが送られてきて、処理しきれなくなったようですね。
当ブログのような弱小サイトに攻撃仕掛けても意味無いのに・・・。運悪かったと思うしか無いですね。
AWS Lightsail インスタンスを復旧する
受信トラフィックは落ち着いてもCPU使用率が落ちないため、Lightsailのインスタンスを再起動してみます。
操作は簡単。停止ボタンを押すだけ。
1分ほどまって画面をリロードし、「開始」を押す。
2分ぐらいで起動してきます。
このあと当サイトのURL「https://hiroyama.info」にアクセスしたところ、無事にサイトが閲覧可能に戻りました。
メトリクスのCPU使用率も正常な範囲に戻りました。
コメント