この記事は 本番環境でやらかしちゃった人 Advent Calendar 2021 12日目の記事です。
はじめに
私は情報系の大学に通っている4年生です。
高校生の時に開発したバス時刻表アプリのサーバがうっかりデストロイされてしまった話をします。
バス時刻表アプリは以下のような環境で稼働していました。
本番サーバ:Azure Virtual Machines(1台)
アクティブユーザー:500人前後
契約形態:AzureStudents
※AzureStudentsは学生が加入できるプランで、100ドルのクレジットが貰えて、12ヶ月間Azureのサービスを利用することが出来ます。
事件は2021年6月15日に起きた
6月15日 ユーザーから「アプリが使えない」という連絡が来ました。
私は、障害の原因を確かめるために、サーバにSSH接続を試みましたがSSH接続が出来ませんでした。
恐らくSSH接続先のIPアドレスが間違っているのだろうと思い、インスタンスのIPアドレスを確認するためにAzureのページにアクセスしました。
インスタンスがない＼(^o^)／
Azureのインスタンス一覧にインスタンスがないのです。
インスタンスが無くなるなんて有り得ないから、Azureに障害が起きているのかな？
Azureの障害に違いない。そう思ってメールを確認してみた
マジ？？？？
嘘でしょ？
嘘であってほしい。
22年間生きてきましたが、こんな恐ろしいメールは見たことがありません。
たった1台の本番サーバがデストロイされてしまい、サービスが完全に停止してしまったのです。
死物狂いで復旧作業
サーバがデストロイされてしまいましたが、感傷に浸っている場合ではありません。
こうしている間にもサービスを利用できずに困っている人がいるのです。
平日はアクティブユーザーが多いため、1秒でも早く復旧する必要がありました。
当時の復旧作業の時系列はこんな感じです
13:00ごろ 全ユーザにプッシュ通知で障害発生の報告と謝罪を送信
13:05 AWSでEC2のインスタンスを作成
13:07 インスタンスのIPアドレスをDNSに設定(浸透させるために最優先で設定した)
13:10 サーバ構築 Nginx,SSLの設定などを行う
13:50 サービスのデータをサーバに転送
13:54 サービスの動作確認が完了
13:57 全ユーザにプッシュ通知で復旧の報告と謝罪を送信
このような感じで、1時間ほどでサービスを復旧させることができました。
過去最大の惨劇ではありましたが、最小限の被害に抑えられたと思っています。
惨劇はなぜ起こってしまったのか
- Azureが1ヶ月前に警告メールを送ってきてくれていたのに、ちゃんと見ていなかった
Azureは2021年6月15日に突然削除したわけではなく、1ヶ月前にこのようなメールを送ってくれていました。
こんな丁寧なメールを事前に送ってくれていたにも関わらず、しっかり確認していなかったので、100%私が悪いと思ってます(反省)
この時点で、サーバの移行をしていれば今回のデストロイ事件は起きていなかったはずです。
- サーバの移行を後回しにしていた
サーバをAWSかGCPに移行しようと思っていましたが、「まだ大丈夫だろう」と後回しにしていました。
- 流石にデータは消されないだろうと過信していた
AzureStudentsが終了してもインスタンスが停止されるだけで、一定期間内であれば課金すればすぐに再開できると思っていました。
現実はそんなに甘くなかった
二度と惨劇を起こさないためにどうしたのか
AzureStudentsなど特殊なプランで契約している場合は、契約の満了時期や内容についてきちんと把握しておく
VPSからのメールは必ず確認すること
ドキュメントを残しておく
サーバの構築方法などは全て文書化しておくことを強く推奨します。
Nginxの設定やPostgreSQLのインストール、SSL証明書の設定などあらゆるコマンドを全て文書化することで、サーバ構築を素早く安全に行えます。
さらに、ドキュメントを作ることで、自分の習熟が深まりますし、サーバをうっかり吹き飛ばしてもすぐに復旧できるという利点もあります。
最後に
サーバを吹き飛ばさないように行っている対策などがあればコメントなどで教えていただけると嬉しいです！