WordPressで発生した「No space left on device」に対応

CloudWatch Logsメトリクスフィルターで「No space left on device」を検知

前回、WordPressにアクセスできなくなったときに、Nginxのエラーログに「write() to “/var/log/nginx/access.log” failed (28: No space left on device) while logging request」とエラーが出力されていました。
ディスク容量がなくなってアクセスできなくなったようです。

CloudWatch Logsのメトリクスフィルターで「No space left on device」文字列を検知してアラームからSNSでメール送信するように設定していました。

そしてアラームが届きましたので、逼迫しているディレクトリを確認しました。

Amazon Linux2で逼迫しているディレクトリを確認

AMIから起動したてのEC2インスタンスと比較してみました。

状況の確認(df)

まず状況を確認しました。

• 障害発生インスタンス

• 起動したてのインスタンス

EBSボリュームで設定している8GBを100%利用していました。

ディレクトリごとに確認(du)

次にディレクトリごとに確認してみました。

• 障害発生インスタンス

• 起動したてのインスタンス

/usrディレクトリでした。

• 障害発生インスタンス
  3.3G /usr/share/nginx

• 起動したてのインスタンス
  777M /usr/share/nginx

ということはNginxが使用しているディレクトリだろうと想定できました。
そしてディレクトリを調べていきましたところ、cacheディレクトリのデータで逼迫されていることがわかりました。

ElastiCache Memcachedを使用

W3 Total Cacheプラグインを使用しています。

WordPress W3 Total Cache のDatabaseCacheをAmazon ElastiCacheのmemcachedに格納する
以前設定して、コストとのトレードオフでやめてたのですが、検証目的でまた再開することにしました。

キャッシュの保存先をMemcachedにしてみて、状況を確認してみます。

最後までお読みいただきましてありがとうございました！

【PR】 「AWS認定資格試験テキスト＆問題集　AWS認定ソリューションアーキテクト - プロフェッショナル 改訂第2版」という本を書きました。

【PR】 「AWS認定資格試験テキスト AWS認定クラウドプラクティショナー 改訂第2版」という本を書きました。

【PR】 「ポケットスタディ AWS認定 デベロッパーアソシエイト」という本を書きました。

【PR】 「要点整理から攻略するAWS認定ソリューションアーキテクト-アソシエイト」という本を書きました。

【PR】 「AWSではじめるLinux入門ガイド」という本を書きました。

@yamamanx

開発ベンダー5年、ユーザ企業システム部門通算9年、ITインストラクター5年目でプロトタイプビルダーもやりだしたSoftware Engineerです。
質問はコメントかSNSなどからお気軽にどうぞ。
出来る限りなるべく答えます。

このブログの内容/発言の一切は個人の見解であり、所属する組織とは関係ありません。
このブログは経験したことなどの共有を目的としており、手順や結果などを保証するものではありません。
ご参考にされる際は、読者様自身のご判断にてご対応をお願いいたします。

また、勉強会やイベントのレポートは自分が気になったことをメモしたり、聞いて思ったことを書いていますので、登壇者の意見や発表内容ではありません。