Scribble at 2024-03-26 20:01:35 Last modified: 2024-03-27 16:59:31

本日は某サイトのコンテンツを更新するために、朝から京都へ出張していた。大して雨は降っていなくて、自宅からは環状線で京橋まで行ってから京阪で三条へ着いて、そこからは徒歩である。思ったよりも早く着きすぎてしまったけれど、ゆっくり街中を見物しながら歩いたので、さほど問題はない。

作業そのものは、ファイルを幾つかアップロードするだけなので、サイトの表示確認をしながら、ものの３分くらいで終わる。それよりもクライアントに最終確認をお願いして撤収してよいかどうかの判断を仰ぐまでに１時間ほどかかったため、その間は局舎（そこからしかプロdクション・サーバにアクセスできないようになっている）で待つという状況であった。

そして、作業が終わったら、またゆっくり歩いて大阪に戻ろうとしていたのだが、そういうわけにもいかなくなった。どうやらコーポレート・サイトが落ちているらしく、会社に戻って AWS もしくはウェブ・サーバの様子を見ないといけない。いまどきの EC2 は自動で復旧する設定になっているはずだが、必ずしも再起動するだけでいいとは限らない原因でもサーバは落ちる。ということで、帰りは四条烏丸から阪急で梅田に戻って、そこから会社まで歩いて出社した。

まず初めに、ssh で EC2 インスタンスにアクセスしてみると、これはタイムアウトしてアクセスできない。ということなので、ウェブ・サーバの問題というよりもインスタンスが落ちているわけである。正確には、インスタンスは起動してはいるのだが、正常に動いていないらしい。ということで、ひとまずインスタンスを強制的に落としてから、暫く待った。EC2 インスタンスの場合、落としてからすぐに起動したり再起動させても、インスタンスが起動しないことも多いからだ。そして10分ていど待ってから再び起動させると、正常に立ち上がり、コーポレート・サイトも正常に表示されるようになった。

EC2 のトラブルシュート画面でログを取得してみると、"system.journal has a fill level at 75.x" といった journald の吐き出す情報（エラーではない）がたくさん出てくる。ローテーションしてるはずなのに、これ幾らでも溜め込むのかと不思議に思って journald の設定ファイルを見ると、ログについての制限がまるでなされていなかった。これでは、最小限の 20 GB くらいの容量で動かしているインスタンスのストレージを圧迫してしまうのは当然だろう。ということで、ログのサイズを 500 MB に制限することにした。

[追記：2024-03-27] AWS からメールでお知らせが届いた。"EC2 has detected degradation of the underlying hardware hosting your Amazon EC2 instance associated with your AWS account in the ap-northeast-3 region. Due to this degradation your instance could already be unreachable. We will stop your instance after 2024-03-27 20:00:00 UTC [28日の午前5時のこと]. Please take appropriate action before this time." ということで、EC2 のハードウェアに異常が起きたらしく、インスタンスの移行を促された。どのみち本日の20時にインスタンスが停止してしまうため、これは無条件にインスタンスを移行しないといけない。ただ、ルート・デバイス・タイプが EBS であるインスタンスは、インスタンスを「停止」してから「起動」するという手続きだけで、勝手に新しいハードウェアでインスタンスが起動するから楽である。これは、既に昨日の昼過ぎにやっていたから、その時点でインスタンスの移行は終わっていることになる。