WordPressでディスク容量がMAXになりカテゴリが表示されなくなった話

wordpress

こんにちは!Hajimariの新卒エンジニアの市川(@shu_chikanne)です。

2020年4月1日に新卒エンジニア2期生としてジョインしました!

普段は、自社プロダクトであるスタートアップ向けマッチングサイト構築パッケージPIECE(https://crowd.itpropartners.com/piece/)の開発や受託開発をしたり、新卒採用関係の業務を行っています!


今回はタイトルにもある通り、WordPressでディスク容量がMAXになったことでカテゴリが表示されなくなった話をしていきたいと思います。

業務の関係上、スクショ等は掲載できないのでご了承ください(><)

今考えても恐ろしい出来事でした・・・

 

 

経緯

発端は6月10日の17時頃。

クライアントから恐ろしい連絡が飛んできました。内容は以下の2つ。

  • ワードプレスのカテゴリーとタグが全てリセットされてしまったこと

  • それに伴いURLが変わってしまったこと このWordPressのサイトは広告の配信先として利用しており、URLが変わることで広告元のURLがデッドリンクになってしまいます。


つまり、「大量の広告のリンク先が表示されず、広告経由の収益が出ない状態」となっていたのです。


同時接続数が100前後のサイトのため、常時100人近くのユーザーがサイトを閲覧していることになります。

そんなサイトのURLがデッドリンクになったと聞いて、本気で冷や汗を書きました。

もういっそのこと、全てを忘れて眠りにつきたい。。。


嘆いていても、原因を見つけて修正しないことにはこの状態は解消されません。


原因調査

ここからはなぜその状態になったのか、原因調査の段階に入ります。

まずはメモリの確認をします。

$ free -m
             total       used       free     shared    buffers     cached
Mem:          7986       4550       3436         37        142        902
-/+ buffers/cache:       3505       4481
Swap:         2047         14       2033

ふむ、問題なし。

先輩エンジニアからディスク容量はどうなの?と聞かれたので、確認してみると、、、

$ df -h
 ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         3.9G   60K  3.9G    1% /dev
tmpfs            3.9G     0  3.9G    0% /dev/shm
/dev/xvda1        30G   30G   0G   100% /
[ichikawa@ip-172-31-16-13 ~]$

100%!!! はじめてみた!!!


そう、原因はディスク容量が100%になっていたことでした。

ひとまずAWSコンソール上からディスク容量を増やします。(ちなみに一回増やすと減らせません)

そしてターミナル上で以下のコマンドを叩きます。

$ sudo growpart /dev/xvda1

$ sudo resize2fs /dev/xvda1


確認してみます。

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        3.9G   60K  3.9G   1% /dev
tmpfs           3.9G     0  3.9G   0% /dev/shm
/dev/xvda1       99G   30G   69G  30% /

しっかり増えてますね。
今回は30G→100Gまでディスク容量を増やしました。

WordPressの管理サイトを確認しに行った所、カテゴリとタグが正常に表示されるようになっていました。
良かった!!!

なぜディスク容量が100%になっていたのか

duコマンドでどのディレクトリの容量が大きいのか確認してみます。

$ du -sh /*
7.0M    /bin
50M /boot
4.0K    /cgroup
60K /dev
11M /etc
408K    /home
93M /lib
21M /lib64
4.0K    /local
16K /lost+found
4.0K    /media
4.0K    /mnt
43M /opt
107M    /root
8.0K    /run
12M /sbin
4.0K    /selinux
4.0K    /srv
2.1G    /swap
1.1G    /swapfile1
0   /sys
8.0K    /tmp
1.3G    /usr
24.9G   /var


なにやらvar配下がとても大きくなっているようです。

var配下も確認してみます。

$ cd /var
$ du -sh ./*
4.0K    ./account
105M    ./cache
124K    ./db
8.0K    ./empty
4.0K    ./games
12K ./kerberos
2.4G    ./lib
4.0K    ./local
16K ./lock
14.8G   ./log
0   ./mail
4.0K    ./nis
4.0K    ./opt
4.0K    ./preserve
132K    ./run
1.8M    ./spool
0   ./swap
4.0K    ./tmp
6.7G    ./www
4.0K    ./yp

logディレクトリがとても大きいことが判明しました。

そしてlogディレクトリを調べていると、Apacheアクセスログのログローテーションを設定していないことが判明。

(そりゃあディスク容量の大きくなるわ。。。)


ログローテーションの設定をし後日確認してみた所、/var/logディレクトリのディスク容量が14.8G→696Mまで減っていました。

再発防止策として、AWSの構成の見直しやディスク容量・メモリ・CPU等の監視を行っていく予定です。(ここらへんも今後記事にしていきたいと思います!)

最後に

Hajimariでは、Laravel、vue.js、Nuxt.jsで開発に挑戦したいエンジニア・デザイナーを絶賛募集中です!

そして、22卒新卒エンジニアのエントリーも心よりお待ちしております!

www.wantedly.com

www.wantedly.com