はじめに
Railsアプリ「TaskLink」をAWS上で運用していたところ、CloudWatchからディスク使用率超過のアラームメールが届きました。
今回は実際に行った
- CloudWatchアラーム確認
- Linuxでの容量調査
- EBS容量拡張
- ファイルシステム拡張
- CloudWatch復旧確認
までの流れをまとめます。
発生したアラーム
CloudWatchから以下のメールが届きました。
tasklink-disk-usage-80
Threshold: 80%
Current Usage: 81%
ディスク使用率が80%を超えたためアラーム状態になっていました。
まずはサーバーへログイン
ssh -i ~/.ssh/tasklink-key.pem ubuntu@xxx.xxx.xxx.xxx
容量を確認します。
df -h
結果
Filesystem Size Used Avail Use% Mounted on
/dev/root 6.7G 5.3G 1.4G 81% /
確かにルートパーティションが80%を超えていました。
容量を消費している場所を調査
まずは大まかに確認。
sudo du -xhd1 / | sort -hr
結果
5.3G /
3.6G /usr
939M /var
605M /home
特に異常なログ肥大化は見られず、システムパッケージやRuby環境が容量を使用していることが分かりました。
EBSを拡張
AWSコンソールから
EC2
↓
Volumes
↓
対象ボリューム
↓
Modify Volume
を選択。
容量を
8GB
↓
20GB
へ変更しました。
OS側でパーティションを拡張
まず状態確認。
lsblk
結果
nvme0n1 20G
└─nvme0n1p1 6.9G
EBSは20GBになっていますが、パーティションはまだ6.9GBのままでした。
パーティション拡張
sudo growpart /dev/nvme0n1 1
結果
CHANGED: partition=1
ファイルシステム拡張
sudo resize2fs /dev/nvme0n1p1
実行後に再確認。
df -h
結果
Filesystem Size Used Avail Use% Mounted on
/dev/root 19G 5.3G 13G 30% /
無事に容量が拡張されました。
CloudWatchアラーム復旧
数分後、CloudWatchアラームは自動的に
ALARM
↓
OK
へ復帰しました。
使用率も
81%
↓
30%
まで改善されました。
学んだこと
今回の対応を通じて、
- CloudWatchによる監視
- Linuxでの容量調査
- EBSオンライン拡張
- パーティション拡張
- ファイルシステム拡張
を実際に経験できました。
アプリ開発だけでなく、運用・監視・障害対応もエンジニアにとって重要なスキルだと実感しました。
まとめ
今回実施した流れ
CloudWatchアラーム発報
↓
df -h
↓
du で原因調査
↓
EBS 8GB → 20GB
↓
growpart
↓
resize2fs
↓
CloudWatch復旧確認
本番環境では「障害が起きないようにすること」だけでなく、「障害を検知して素早く復旧すること」も重要だと学びました。