忙しい人は結論だけ読めばOK
本番サーバーにSSHできなくなったから再起動してみるか
EC2サーバーで運用しているサーバーが急にSSHできなくなりました。デプロイ作業時にSSHする必要があったため、SSHしてみると、SSHコマンドが「返事がない、ただの屍のようだ」状態になっていることに気づきました。
(※20−30分放置するとエラーが返ってきます)
経験上、メモリリーク等々でメモリが100%になるとSSHできなくなることは何度か経験していたのですが、サービス自体は正常に動いている模様。まあ、サーバーを再起動すればメモリが開放されますし、大抵SSHできるようになることは知っていたので、メンテナンスのお知らせを出して今回も再起動のボタンをポチッ
あれれ、おかしいな動かない。しかもSSHできなくて手の施しようがない詰んだ
再起動したらサービスが心停止しました。しかもサーバーにSSHできないので我々はただただ目の前のAWSコンソールに映るサーバーのステータスチェックを見守るのみです。心の中はステータスがお通夜モードに突入!
最悪AMIを取得してサーバーを立て直すかと考えましたが、Docker( ECS )ではないので万が一のことがあるとサーバー環境構築含め、かなり時間がかかってしまいます。嫌な汗が出てきます。
メモリはアラートが出てないし再起動で解消されるはずだからメモリじゃない。じゃあ何だと悩んでいたところもう1つの可能性にたどり着きました。
EBS(ストレージ)のディスク使用率が100%になっていたのです。そこで、まずボリュームサイズを増やすことにしました。でもですね、追加したボリュームはSSHしてマウントしてシステムにここにストレージがあると認識させないといけないんですよ普通は。
でも、SSHできない
詰んだ
ザオラルを唱える
再起動したらもしかしてボリュームサイズの変更を自動で認識してサーバーに新しくアタッチしてくれるのではないか? AWSはすごいからきっとそういうことをしてくれるんじゃないか?という一抹の望みを込めてザオラル(再起動)ボタンをコンソールから押します。
祈る
懸命に祈りましょう。祈りが届けばサーバーは答えてくれる。日頃の行いがいいので私の祈りは届きました。なんとサーバー再起動でストレージサイズを大きくしたEBSをサーバー側が自動で認識してくれたのです。ありがとう。ちなみにストレージを圧迫した犯人は溜まりに溜まったログファイルでした。あるある過ぎて逆にビックリ。
結論
急にSSHができない原因は大抵この2つ
- サーバーのメモリが100%になる
- ディスク利用率が100%になる
メモリの場合、サービスの応答速度が遅くなるので気づきやすいのですが、ディスク利用率の場合、サービスは普段どおりに動いたりします。
後者の場合、メモリ問題と勘違いしてサーバー再起動すると私のケースのようにSSHできなくてサービスの復旧が困難になるパターンがあります。ですから、
メモリとディスク容量は最低限、再起動を行う前に確認しておきましょう。はじめからディスク容量と気づいていたらボリュームを増やして再起動するだけで問題は解決していました。(再起動でなんとかなるのはAWSのおかげ。Amazon社に足を向けて寝れない)
また最悪ケースに備えてAMIも再起動前に取っておくと後の障害対応時の復旧が早くなるかもしれません。
SSHできない、何もできないから、とりあえず再起動は辞めましょう。
おまけ
ログの削除に便利なcronで動かせるコマンドを置いておきます。
0 7 * * * /bin/find /var/www/app/log -name '*log*' -mtime +60 -delete
「findコマンドを使って logディレクトリ以下にあるlogという名前が含まれるファイルのうち、60日以上更新がないものを削除する。」というコマンドをcronで毎朝7時に起動するという設定です。