こんにちは!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卒新卒エンジニアのエントリーも心よりお待ちしております!