AWS EC2物理ホスト障害の対応と対策

仮想通貨自動売買ボットのEC2にTeraTermから接続できなくなった話

EC2インスタンス上で仮想通貨自動売買ボットの売買ログを見ようとしたんだけど、TeraTermから接続できなくなった話。

このbotは4か月くらい稼働させていて普段は問題なく動いているけど、今回初めて障害が発生したので記録として残しておく。

発生: TeraTermが突然繋がらなくなる

この自動売買botは売買の記録をEBSにログとして残しておく仕様なので、売買ログを確認しようとTeraTermで接続しようとしたところ接続ができなかった。

原因調査: コンソールでSystem Status Checkのfailedを発見

最初に確認したのはメール。System/Instance Status Checkの異常などを検知したらメールを送る設定にしているので一応確認してみた。

そしたらまさかの三日前にALARM発生 → メール送信されていた。

監視メトリクス: StatusCheckFailed(Instance+System統合値)、閾値1.0以上・1期間(60秒)で即ALARM

という仕組みは正常に機能していたけど、メール送信先アドレスが普段使わないアドレスで確認していなかったというのが今回の反省点。

とりあえず、コンソールに入って EC2 → インスタンス → 対象のインスタンス → ステータスとアラーム を確認。

今回はシステムステータスがエラーになっていた。つまり物理ホストに何か異常があったらしい。

参考

• システムステータス = 物理ホスト
• インスタンスステータス = OS

さらに、AWSからのメンテナンス通知(8/31にメンテナンス予定)との関連にも気づいた。

一次対応: rebootを試すも無効

とりあえずインスタンスの再起動を試すことにした。

再起動(reboot)は同一ホスト上での再起動なので改善なし。物理ホスト側の障害には効かない、ということを身をもって確認した形。

恒久対応: stop→startでホストを移行して復旧

続いてインスタンスの停止(stop)を実行。

システムステータスの異常解除を確認し、インスタンスの開始(start)

なお、stop→startは別の物理ホストへの引っ越しにあたるため、本来はパブリックIPが変わる可能性がある。今回はElastic IPを割り当て済みだったのでIPは変わらず、TeraTerm側の接続先設定はそのままで済んだ。Elastic IP未設定の場合は要注意。

システムステータスの異常解除を確認後、インスタンスの開始(start)を実行。

副次対応: ボットプロセス自体も落ちていたのでscreenで再起動

TeraTermで再接続後、セッションの有無を確認。

$ screen -ls
No Sockets found in /run/screen/S-ec2-user.

「No Sockets found」= セッションがそもそも存在しない。つまりボットの再起動が必要であることを確認した。

今回のstop→startは「物理ホストを移行するための再起動」なので、当然OSも起動し直される。EBS上のボットのコード・ログファイル自体は残るが、「今動いているプロセス」という状態は一切引き継がれない。

# 新しいscreenセッションを作成
screen -S fxbot

# その中でボット起動
cd ~
python3 xxxx.py

再発防止

①CloudWatchアラーム(StatusCheckFailed_System)+ ec2:recover で自動復旧を設定。さらに②systemd化でボット自体もクラッシュ時に自動再起動するよう改善した。

① CloudWatchアラーム(StatusCheckFailed_System)

1. AWSコンソール → CloudWatch → 左メニュー「アラーム」→「アラームの作成」
2. 「メトリクスの選択」→ EC2 →「インスタンスごとのメトリクス」→ 対象インスタンスのStatusCheckFailed_Systemを選択
3. 条件: 「より大きいか、それと等しい」→ 1、「期間」を2データポイント/2分に設定
4. 「アクションの設定」→「EC2アクション」→「このインスタンスを復旧する」を選択(これがCLIでのec2:recoverに相当)
5. 通知も追加したかったので「通知」で既存のSNSトピック(GMO_trade_ALM)を選択
6. アラーム名を入力して作成

② pyスクリプトをsystemd化し、クラッシュ時に自動再起動するように改善

# 1. unitファイルを作成・編集(nanoというテキストエディタを使用)
sudo nano /etc/systemd/system/fxbot.service

# 2. 有効化・起動
sudo systemctl daemon-reload
sudo systemctl enable fxbot
sudo systemctl start fxbot

# 3. 確認
sudo systemctl status fxbot

最後に、メール自体に気づかなかった対策として、Power Automateでメール → Teamsに自動通知するように設定して完了。