実際にKUSANAGIで結構なアクセス数のサーバを運営してこれやってるよっていうこと

はじめに

KUSANAGI Advent Calendar 2016 四日目の記事です。@yousanといいます。
仕事でKUSANAGIを使ったサーバ構築、保守を行っています。
この記事では普段KUSANAGIでサーバを構築する際に実際に行っている作業について「これ結構やっといた方がイイですよ！」ということについて抜粋して書きます。

少し前になりますが、今回の記事よりもっと運用周りのお話しは下記の記事にまとめています。

WordPressで3000万PV/月のサイトをさくらのクラウドに構築した話
http://qiita.com/yousan/items/bf0bb0a2758f297585cc

サーバ規模

具体的な数字を上げると300万PV/月〜1000万/PVぐらいまでを一台のKUSANAGIホストでカバーしています。
KUSANAGI登場以前は自前で構築していましたが、KUSANAGIを使うことで簡単に構築する事ができるようになりました。
簡単に構築できる、というのがすごく利点ですね。

ディスクの追加

デフォルトのシステムディスク（さくら、GMOクラウド、AWSで確認しています）では20GBが割り当てられていますが、多くの環境でこれはすぐに一杯になっていまいます。
ですのでディスクを追加してkusanagiのプロビジョンで作成されたプロファイルを置き換えてしまいます。
ディスクは/mnt/example.comとしてドメインごとにマウントしています。
vdbなどのドライブレターは環境によって異なります。

$ export DOMAIN=example.com
# HDDの追加
# 電源を落としてハードディスクの追加
$ sudo fdisk -l /dev/vdb # 追加されたHDDのドライブレターの確認
$ sudo mkfs.ext4 /dev/vdb
$ sudo mkdir /mnt/$DOMAIN
$ sudo blkid # UUIDの確認
$ sudo emacs /etc/fstab
# UUID=0697edfxxxxxxxxxxxxxx /mnt/www.example.com             ext4 defaults        1 1
$ sudo mount -a
$ sudo mv ~kusanagi/$DOMAIN/* /mnt/$DOMAIN/

# 初回のものは削除
$ sudo -u kusanagi rmdir ~kusanagi/$DOMAIN

# シンボリックリンクを張っておく
$ sudo -u kusanagi ln -s /mnt/$DOMAIN ~kusanagi/

以上でディスクが追加されます。
wp-contentも追加ディスクの配下となるのでメディアなどのファイルが増えても大丈夫です。

HHVMのログ

「なんかサーバが動かなくなった！」ということが良くあるのですが（本当はあっちゃいけない）、原因を調べるとディスクが一杯になってることが多いです。
その中でもとくにHHVMのログで一杯になっていることが多いです。
このログファイルを先ほど増設したディスクに変更します。

# hhvmのログの吐き出し先を変更します。
sudo sed -i -e "s#hhvm.log.file = /var/log/hhvmd/error.log#hhvm.log.file = /mnt/$DOMAIN/log/hhvmd/error.log#g" /etc/hhvm/php.ini

# 追加したディスクにディレクトリを作成しておきます
sudo mkdir /mnt/${DOMAIN}/log/hhvmd
sudo chown kusanagi:kusanagi /mnt/${DOMAIN}/log/hhvmd

# エラーが書き出されているかチェックします
echo '<?php $a; aaaa(); if(){ ?>' > /mnt/${DOMAIN}/DocumentRoot/echo.php
sudo systemctl restart hhvm.service
curl -I -H "host:${DOMAIN}" http://127.0.0.1/echo.php
tail /mnt/${DOMAIN}/log/hhvmd/error.log
rm /mnt/${DOMAIN}/DocumentRoot/echo.php

# 既存のログディレクトリを削除し、シンボリックリンクとして互換性を確保します
sudo rm -rf /var/log/hhvmd/
sudo ln -s /mnt/${DOMAIN}/log/hhvmd  /var/log/hhvmd
sudo rm -rf /var/log/nginx/
sudo ln -s /mnt/${DOMAIN}/log/nginx  /var/log/nginx

シンボリックリンクを張っていますが、ログローテートの参照場所も変えておきます。

$ sudo sed -i -e "s#/var/log/hhvmd/\*log {#/mnt/$DOMAIN/log/hhvmd/\*log {#g" /etc/logrotate.d/hhvmd

# 手書きで変える場合には以下の通りです。
# /var/log/hhvmd/*log {
# /mnt/$DOMAIN/log/hhvmd/*log {

また以前にはログをそもそも出さないというという方法も行っていました。

sudo sed -i -e 's/hhvm.log.use_log_file = true/hhvm.log.use_log_file = false/g' /etc/hhvm/php.ini

ですが実際に運用してみるとHHVMが色々と吐き出すエラーについては障害発生時に追いかけることが多く、ログは取っておいた方が良いです。

MySQLのdatadir

MySQLのデータディレクトリについても同様に追加ディスクへ変更しておきます。

# サービスを止めて 保存先を移動する
sudo systemctl stop mysql.service
sudo mv /var/lib/mysql /mnt/$DOMAIN/
sudo sed -i -e "s#\[mysqld\]#\[mysqld\]\ndatadir = /mnt/$DOMAIN/mysql#g" /etc/my.cnf.d/server.cnf

多くの場合でスタンダードなwp-config.phpでのDB接続先、localhostではUNIXソケットファイルが見つからなくなります。
/var/lib/mysqlソケット通信が出来なくなるため接続先を127.0.0.1にしておきます。
(PHP-PDO-MySQLのクライアント側がデフォルトで参照するsockファイルはコンフィグで書き換えられるはずなのですが、うまくいかなかったのでこうしています）

wp-config.php

# wp-config.php
# /** MySQL のホスト名 */
# define('DB_HOST', '127.0.0.1');

$ sudo systemctl start mysql.service

以下のコマンドでdatadirがあるか確認しておきます

$ ps auxww | grep mysqld
root       813  0.0  0.0 115380   744 ?        S    Sep14   0:00 /bin/sh /usr/bin/mysqld_safe --datadir=/mnt/example.com/mysql --pid-file=/mnt/example.com/mysql/srv1.example.com.pid

キャッシュのログ問題について

KUSANAGIでデフォルトで入るキャッシュプラグインではエラーログが大量に吐かれます。

参考サイトを元にログを減らすようにしておきます。

wp-content/mu-plugins/kusanagi-core/modules/page-cache.php

if ( !is_null($data['type'] ) ) {
    $cache_db->insert( $cache_db->prefix . 'site_cache', $data, array( '%s', '%s', '%s', '%s', '%s', '%s', '%s', '%s', '%d', '%s', '%s' ) );
}

KUSANAGIでWordPressデータベースエラーが出る時の対処法
https://keikenchi.com/kusanagi-wordpress-db-error

また既にログが出てしまっている場合にはcut -cを使って各行の先頭文字を指定して確認すると捗ります。

$ cat error.log | cut -c-200 | less

HHVMの再起動について

KUSANAGIを使っているホストの一部ではHHVMが落ちてしまう症状が発生しています。
根本的な原因については未だに突き止められていなくて、一部ではカーネルからOOM Killerの報告が上がっていますが、無言でHHVMが死んでしまう事もあります。
対症療法てきな手段ですが2分おきに起動させるように設定しています。

crontab

$ sudo crontab -e
*/2 * * * * systemctl start hhvm.service

対症療法とはいえ、これでかなりの改善が見受けられました。
HHVMのバージョンなどによるバグを疑っていましたが、KUSANAGIではないホストでは発生していないため原因は不明です。テーマやプラグインの相性かな、と思っています。

テーマファイル

細かい所ですが、プラグインのThemeSwitcherで追加したテーマが見えない、というバグがあります。
WordPress標準のトランジェントというキャッシュ機構が問題で、次のコマンドでキャッシュクリアをすると良いです。

$ wp transient delete avaiable_themes
Success: Transient deleted.

詳しくは過去の記事を参照ください。

さくらのクラウドのKUSANAGIを利用したときにThemeSwitcherでテーマが読み込まれなかった件の対処
http://qiita.com/yousan/items/8cbc68c633a6ac7272bc

まとめ

KUSANAGIは使いやすいです。
今まで2日掛かっていた構築作業が1日で終わるようになりました。hhvmやPHP7など、「時間を掛けて調べれば出来るんだけど…」という作業をまとめてやってもらえるというのは非常にありがたいです。すごく重宝しています。
いつも恩恵を受けてばかりですが、今回の記事が誰かの役に立てれば幸いです。

明日は @jz5 さんです。