本記事は「 TTDC Advent Calendar 2024 」 23 日目の記事です
皆さんEC2使って開発してますか？
自分は単発的に使うことが多いので、好きなタイミングで適宜ON/OFFできる環境が気に入っています。
今回はEC2に接続出来ず、調査から復旧までだいぶ遠回りしたので戒めとして対応方法を残しておきたいと思います。
システム構成
AWSアカウントの配置です。一部のアカウントはOrgznizationsの管理下で運用されています。今回は管理アカウントの下にSandboxのOUがあり、その下に開発用のアカウントがある構成です。
Organization account
┗ sandbox_ou
┗ sandbox_account （開発環境）
EC2の接続は、SystemsManager経由でVSCodeで接続し、ローカルにはソースコードを置かないように運用しています。
SystemsManager経由での構築について今回は割愛します。他の方々が詳細を解説しているサイトが多いので参照してください。
EC2との接続は確立済みで運用中とします。（OSはLinux2023を使っています）
VSCodeからRemoteSSHで接続として動作しますので、構築後は環境側はあまり意識することなく便利に使えます。
ゆえに、接続できなくなった暁にはわらわらと調べることとなってしまいました。
ある日突然EC2へ接続出来なくなった
いつものように、EC2の電源を投入し、VSCodeから接続しに行ったのですが、以下のようなメッセージがでて接続できなくなりました。
（コンソールの一部抜粋です）
...
[16:39:15.191] > Connection closed by UNKNOWN port 65535
> プロセスが、存在しないパイプに書き込もうとしました。
[16:39:16.896] "install" terminal command done
[16:39:16.897] Install terminal quit with output: プロセスが、存在しないパイプに書き込もうとしました。
[16:39:16.897] Received install output: プロセスが、存在しないパイプに書き込もうとしました。
[16:39:16.898] Failed to parse remote port from server output
[16:39:16.901] Resolver error: Error:
...
この状況は初期設定をミスったかのようなエラーに見えました。
SSL関連のエラーもしくはAWSconfig関連の不具合か、設定ファイルに何らかの不具合が発生したと思って、AWS-SSOの接続かPEMキーなのかconfigなのか一通りチェックしましたが、原因分からずでした。
WEB検索しても、認証情報を確認するとかアクセスキー云々を見直せ的な情報にしか辿りつけず、ChatGPTに聞いても似たような回答で手に負えず。
認証関連のエラーの切り分けのため、管理コンソールからインスタンスの接続を試みてみました。管理コンソールより
EC2ダッシュボード＞インスタンス選択＞接続で管理コンソールよりセッションマネージャーが使えるか試してみました。
ここから、セッションマネージャーから接続してみようと試みるも、接続が出来ず・・・
（色々テンパっていたため、画面残せてませんが、セッションマネージャーからも応答がない）
Linuxインスタンスなので、接続が出来てもコンソール画面が出るだけです。
あれ？なぜ？となり焦りはじめたものの、SystemsManagerでマネージドノードの確認もしてみる事にしました。ノードの状態は 実行中 なもののPingステータスは 接続が失われました 状態で
エージェントのバージョン も他のインスタンスに比べると古いものが表示されているので、EC2は起動しているけど、しばらくの期間SystemsManagerからは疎通できてないように見受けられます。
困りつつ検索を続けると、接続できなくとも一部ログが見れるとのサイトを発見。早速試しました。アクション＞モニタリングとトラブルシューティング＞システムログを取得から現在のシステムログを見ることができます。
ここで原因が分かりました。ディスクスペースが無い・・・・
それはVSCodeのモジュール関連がダウンロードができないので、接続もできないということでした。なるほどとは思いましたが、さっさとこちらのログを確認すべきでした。（こちらも、スクショ残せてなかった・・・）
このシステムログですが若干のタイムラグがあるようです。起動直後だと表示されないこともあります。
ディスク容量が枯渇した場合でも、再起動で、一部テンポラリファイルが消えて接続できるようになるケースもあるようですが、自分の場合はダメでした。
下のシステムログは、正常に起動した場合のものです。
EBSの容量を変更
原因が分かりましたので、EBSの容量変更を実施して、パーテーションの認識作業に入ります。
作業前に、スナップショット等は取った方が良いとは思いますが、今回は、スナップショット取らずに作業しています（おすすめはできませんので、皆さんはスナップショットを取ってから実施しましょう）
インスタンスの電源を投入したままでも実施できるようですが、EC2の電源を落としてEBSの容量変更を実施しました。
EBSを他のインスタンスへアタッチし復旧する
以下のサイトの情報を元に、別なインスタンスへの接続を試みました。
ディスクフルになって接続できなくなった場合の対処方法 -
https://qiita.com/sakai00kou/items/a32f4143f2ddbb77cfa9
EBSを別のマシンにマウントして、余計なファイルを消したりといった操作は、上記を参考にしてもらうと良いです。
自分は、Linux2023のEBSをLinux2のインスタンスには上手くマウントできませんでした。OSは合せたほうが楽ができそうです。
＊ネタですが、自分の環境として別にLinux2のインスタンスも持っていたのですが、こちらもディスク容量がFullになっていてまさかの接続できず・・・、容量変更は2台実施する羽目に。。。何とも情けない
振り返る
無事EBSのリサイズと領域の再設定で、無事復旧に至りましたが、システムログにどのように残ってるのか含めて確認してみました。
Linux2023のログは以下のフォルダに入っているようです。
ls -lh /var/log
ログの検索も素人なのですが journal という新しい仕組みになっているそうです。
ディスク関連の表示を引っ張てみることにしました。
journalctlというコマンドを使うようです。ログの中から、diskに関連する項目を引っ張てみます。
journalctl | grep -i "disk"
ログの中から以下のメッセージを見つけました。完全にディスクが無くなった場合のログは残ってませんでしたが、ディスクスペースがなく、ログも停止していたようですね。
auditd[1275]: Audit daemon is low on disk space for logging
auditd[1275]: Audit daemon is suspending logging due to low disk space.
ログや調べを進めていくと、EC2のトラブルシュートについてはAWS公式ドキュメントに整理されていました。
先に見ておくべきという突っ込みは受けそうですが、知ってればバタバタせずにすんだ気がします。
AWS公式ドキュメントってハードルが高い印象でしたが、公式だけに読んでおくのは重要だなと改めて実感しました。
最後に
今回のケースでは、色々な複合要因と思い込みで手当たり次第に試して大分遠回りと回り道をすることになってしまいました。
まずはEC2のシステムログを確認してから対応していれば良かったと思います。
改めてAWSの公式ドキュメントを確認しましたが、トラブルシューティングについても整理されていました。
とっつきにくい印象の公式ドキュメントですが、早く解決できたなと思います。前はとても見にくい印象だったんですが、改善されていましたので、定期的に確認しようと思います。
教訓
- EC2ログ確認大事
- 公式ドキュメント読むべし
参考サイト
ディスクフルになって接続できなくなった場合の対処方法 -
https://qiita.com/sakai00kou/items/a32f4143f2ddbb77cfa9