はじめに
いつも、EC2インスタンスに対してSessionManagerで接続してアレコレやっています。
この前「とあるEC2インスタンスで動かしているwebアプリの挙動がおかしい（ログイン画面にアクセスしても500エラーが表示された）」上に、「SessionManagerを用いて対象EC2への接続を試みたものの、
セッションが次の理由で終了されました。 Plugin with name Standard_Stream not found. Step name: Standard_Stream
というエラーが出て接続ができない」ということがあったので、そのときの対応内容に関してざっくりとメモを残します
システムによって必要な情報が異なる箇所もあるので、以下はざっくりと書いています。
ググって見つかる方法より少しだけ丁寧めに書けているかな～とは思います。
こちらは社内に2023年4月頃に公開したメモを少しだけ整えたものです。
そもそも…なんでSessionManagerで接続しているの？
この方法での接続ですと、下記のようなセキュリティ面でのメリットがあります↓
- EC2に余計なポートを空ける必要が無い
- 鍵管理が不要
ただ、この方法…SessionManagerはEC2内でアプリが起動しているらしく、その起動分の容量がEC2に無いと接続できないらしいとのこと（受け売りコピペ）。
また、SessionMangerを用いるにははじめにインストール等の手間もかかるので、例えば「案件内で多数のEC2を扱っている」場合はなかなか難しいと思います。
今回の繋がらなくなった原因は？
容量不足 である ことが多いみたいです（ググったら大抵そんな理由だった）
今回実施した対応内容
1. （仕方なく）該当のEC2のセキュリティグループにて一時的にsshの穴を開ける
①対象のEC2のセキュリティグループのインバウンドルールを表示
②社内IPアドレスからのアクセスでsshを許可する
※EC2経由でアクセスする場合はEC2のセキュリティグループのsshを許可する
2. ローカルからツールを使ってsshでアクセスする
RLoginやPutty、Teratermなどを使ってアクセスしましょう。
3. 調査＆対処…容量を食っている部分を確認して、削除できるものがあれば削除する
①どこのボリュームに問題があるのか確認する ※使用率を確認する
df -h
②問題のあるボリュームに移動して各フォルダの容量を確認して使用量の高いフォルダを確認する
cd 【問題のあるボリューム】
du -sh ./*
※この作業を繰り返してフォルダを特定する
※容量が大きくなるフォルダの傾向とその対処法
▼ Docker関連
- Dockerの使用していないコンテナ・イメージを削除する
docker container prune
docker image prune
- Dockerの使用していないイメージ、コンテナ、ネットワークを削除する
docker system prune
- ボリュームも削除する場合は以下
docker system prune --volumes
▼ ログ
肥大化しやすいログがあるのなら要注意。
ログに対しては、圧縮や、古いファイルの削除等を実施する可能性があります。
- ファイルのサイズを変更する
truncate -s サイズ ファイルパス
（が、ログローテートなど管理方法・ルールを見直して、そもそものログ肥大化の再発を防止した方が良いでしょう…）
おわりに
作業中、対応内容3. の容量を食っている部分に関して「ほんとに削除していいのか？」と悩むことがありました。加えて、そもそものログ設計がしっかりしていたり、ログの管理ルールをしっかりしていれば防げるところもあったのかな～なんて。
ということで、今回の方法はあくまで暫定対応。はじめから良い設計ができていれば良いに越したことは無いでしょうが、起きてしまった際は良い機会だと思って設計・運用の見直しを実施したいですね。暫定対応だけ実施してその後放置→再発、が無いように！
より良い方法やツッコミ、その他もろもろ何かありましたら是非お気軽にコメント等くださいませ～！