Web サーバーの障害が発生してから復活するまでについて

この記事ではどの VPS プロバイダを使用しているときに発生したのかについては言及しないし、 質問されても答える予定はない。

理由は自分が使用している VPS プロバイダの評判が落ちることにリスクを感じているためで、 読者の利益よりも私自身の利益の方を優先することにした。

個人的には稀にこういうことがあるのは仕方ないかなと思っている。安いし。

主な仕事はこのサイトを Nginx で配信する Web サーバーだが、ほかにもいくつか仕事をしている。

• 公開 git サーバーの git.tojo.tokyo へのリバースプロキシ
• 公開 CI サーバーの ci.tojo.tokyo へのリバースプロキシ
  • ※ Web へのデプロイは別の CI サーバーを使っている

なので、Web が見れなくなったのと同時に公開している git サーバーと CI サーバーも見えなくなってしまった。

他には Zabbix の agent が入っていたり、 Certbot がSSL証明書を取得をしていたり、 Nginx が新しいSSL証明書を使うように更新するために Cron がちょっとした仕事をしていたり、 ログのローテーションの設定を少し変えていたりするので、 同じ設定の Nginx を動かせばすぐに復旧できるという感じではない。 これらの設定は全部 Guix System で管理している。

• AM 04:32 VPS プロバイダから不穏なメールが届く
  • 特定サーバー(私のはWebサーバー)のノードに障害が発生しているので大規模な復旧作業を試みているという内容
  • 外形監視に Uptimerobot、 Zabbix でサーバーの監視をしているが、この時点で障害は観測されていなかった
  • 私は寝ていた
• AM 06:16 日本時間の午前6時、Web サーバーからの通信が途絶える
  • まず外形監視が失敗し、Uptimerobot から Down したと通知が来た
  • その後すぐに Zabbix からも Web サーバーの Zabbix agent が利用できないという通知が来た
  • 私はこの通知に気づくことなく寝ていた
    • 趣味で運用しているサーバーは私の睡眠と比較すると重要ではないため問題なし
• AM 06:57 VPS プロバイダから手動で復旧しようと思ったけど無理だったとのメールが届く
  • とても頑張ったけど無理だったとのこと
  • 二ヶ月分のインスタンス料金を補填してくれた
    • 二ヶ月分と聞くと凄そうだけど安いインスタンスなのでそうでもない
  • 同じ OS, IP アドレス割り当てでインスタンスをデプロイしてくれるとの通知
  • 私はまだ寝ていた
• AM 07:06 同一 OS, IP アドレスでインスタンスがデプロイされた
  • カスタムOSを使用していたため、OSインストール前の状態になっていた
  • IP アドレスが同一の状態でデプロイしてくれたのはありがたかった
    • IPアドレスを直書きしているファイヤーウォール周りの設定があるため
• 起床
  • 先にインスタンスがデプロイされたのを目にしたので、不正アクセスを心配した
  • メールや監視からの通知を遡って致命的な障害が起きたことに気づく
  • サーバーのことが気になりつつ午前の労働を開始
    • 朝は復旧作業をする時間がなかった
• お昼休み
  • 食事を手早く済ませて復旧作業を開始
  • ISO イメージを入れて Guix System のインストールをする
    • Web サーバーのスナップショットは取っていなかった
    • 他の Guix System のスナップショットはあったが、IP アドレスを変更したくなかったのでインストール作業を始める方がましだった
    • OS インストールは特に困難なく完了
  • ssh で Web サーバーに繋ぐ
    • FW の設定は、障害前から引きつがれていた
    • もともと特定のサーバーを経由してしか ssh アクセスできないようにしていたので楽だった
  • Guix の設定ファイル config.scm を scp にて配置
    • Web サーバーの設定ファイルを git 管理していてよかった
    • これが Web サーバーにしかない状態だと結構絶望的だった
  • sudo -i guix system reconrfigure <設定ファイルのパス> を実行して Web サーバーの設定を復旧
    • これで Web サーバーの設定は全て行なわれる
      • Guix System は最高
    • nginx は stop したまま(というよりエラーが起きて nginx は起動できていなかった)
  • サイトをデプロイする
    • 自前の CI サーバー(Laminar)から接続できるようになったため、サイトをデプロイした
  • Nginx を起動しようとしたが失敗
    • sudo herd start nginx としたが失敗した
      • /var/log/messages を確認したところ SSL 証明書がないとのこと
  • Certbot で Let's Encrypt の SSL 証明書を取得する
    • SSL 証明書関連の設定 Guix System で管理されているのでコマンドを打つだけ
    • ただし、Nginx を起動している必要があった(はず)なので、 #; で Nginx の個別の設定をコメントアウトして guix system reconfigure する
    • root で /var/lib/certbot/renew-certificates を実行し、成功
  • Nginx を再度起動し、成功
    • #; でコメントアウトした Nginx の設定を元に戻して guix system reconfigure を実行
    • Nginx が動きサイトが見れるようになる
• サイト復旧

という感じで、なんとかお昼休みに復旧作業を終えることができた。

障害が起きてインスタンスごと死亡したけど、Guix System を使っていたので楽に復旧できた。 まあ Ansible とかでもこういう構成管理はできるわけだが、 こういうのは OS がサポートしてくれていた方が楽だと思う。

諸事情あり現在ラップトップでは Debian を使用しているが、 Guix System の良さを再認識したのでパッケージ管理だけでも Guix を使うようにしてみようと思う。