こんにちは、メディア事業部の踊るエンジニアカッシーです。

突然ですが、SIMCHANGEというサービスをご存知でしょうか？日本最大級のSIMカード切り替えプラットフォームで、『最適なSIM会社の比較検討ができる！』と巷で噂のサービスです！（希望的観測含む。）

f:id:cassy1003:20180604103743j:plain

実はこのサービスも、ENECHANGEが運営しています。格安SIM/格安スマホを検討されている方は、是非一度覗いてみてください。

さて今回は、このSIMCHANGEを『仮想マシンKUSANAGI』に載せ替えたお話です。

KUSANAGIとは
SIMCHANGEのサーバー構成
KUSANAGI 構築
KUSANAGI for WordPress × Ruby on Rails
Wordpress内記事検索も高速化
あとがき

KUSANAGIとは

KUSANAGIは、プライム・ストラテジー社がオープンソースとして無償提供してくださっている世界最高速クラスのWordPress実行環境です。2017年11月には『KUSANAGI for Ruby on Rails』がリリースされ、Ruby on Railsにも対応したと発表されました。ここでは詳細な説明は割愛させていただきますが、KUSANAGIの実行速度や高速化の効果についてご興味のある方は、是非ググってみてください。導入事例や検証結果などが記事がたくさん出てくると思います。
一からWordPressのサイトを立ち上げる場合や単純なWordPressのページを移行するだけなら、簡単に高速化を実現できるようなので、検討の余地はあると思います。

SIMCHANGEのサーバー構成

SIMCHANGEは残念ながらWordPress単体のサイトではないのです。WordPressだけだったら、KUSANAGI移行がどれだけ楽だったか。
KUSANAGI移行の話の前に、SIMCHANGEのサーバー構成を簡単に図解しておきます。 f:id:cassy1003:20180605140330p:plain SIMCHANGEは、1台のEC2サーバーにWordPressとRuby on Railsが共存し、記事ページなどの静的コンテンツがWordPress、診断ページや会員ページなどの動的コンテンツがRuby on Railsで動作しいます。（WordPressのDBはMySQL、Ruby on RailsのDBはPostgreSQLを用いています。また、画像データなどはS3に保存しています。この辺りの話は、また別の機会に。）

今回は、このWordPressとRuby on Railsが共存しているEC2サーバーをKUSANAGIで構築し直しました。

KUSANAGI 構築

AWS用の仮想マシンイメージが無償で提供されています。利用方法や初期設定の方法に関しては、日本語のドキュメントもしっかりあるので、特に迷うことはないかと。

ちなみに、弊社の開発体制の話を少しすると、サーバーの用意やこの辺りの設定はインフラエンジニアがやってくれます。弊社のインフラエンジニアは、ENECHANGEが提供する全てのサービスのインフラを横断的に見てくれていて、本当に頭が下がります。（インフラエンジニア igaharaさんの記事TerraformでVPC周りを作成する - ENECHANGE Developer Blogも、是非一読ください。）

KUSANAGIにおけるWordPressやRuby on Railsのプロビジョニング自体も、ドキュメントが用意されています。以下のコマンドを打って、あとはよしなに。

$ sudo kusanagi provision [WordPress用ディレクトリ]
$ sudo kusanagi provision --rails [Rails用ディレクトリ]

KUSANAGI for WordPress × Ruby on Rails

ここからが割と本題。どうやって既存のサービスから移行したのか。また、どのようにWordPressとRuby on Railsが共存しているのか。なかなか全く同じような構成でサービスを運用している方はいないと思いますが、参考になればと思います。

注意事項

既存のサービスを移行するにあたり、一番重要なことを初めてに書いておきます。

KUSANAGIが対応しているWordPress / PHP / Rails / Ruby / MySQL / PostgreSQLなどのバージョンを確認しましょう！

SIMCHANGEに導入した2018年2月の時点では、

KUSANAGI 8.2.1
WordPress 4.7.9
PHP 7.0 / PHP 5.6
Rails 5.1.5
Ruby 2.4.2

でした。まずは既存のサービスで、それぞれバージョンアップし、動作検証してから移行するのをオススメします。

ディレクトリ構造

SIMCHANGEのディレクトリ構造を簡単に書くと以下のような感じ。

~/simchange/
├─ .git
├─ rails/
└─ wordpress/

ディレクトリというか同一レポジトリの中に/railsと/wordpressがあります。しかし、KUSANAGIでは先ほど作ったように、Rails用ディレクトリとWordPress用ディレクトリが独立しています。 SIMCHANGEもこれを機に、RailsのコードとWordPressのコードをレポジトリ単位で分けようかとも考えたのですが、「今までのコミット履歴が消えるの嫌」とか「レポジトリ2つ管理するのめんどう」とか「KUSANAGIに引っ張られたくない」とか「開発環境は今までのままで、他のエンジニアが混乱しないようにしたい(これが大きい)」とか悩んだ結果...

~/
├─ kusanagi_rails/
├─ kusanagi_wordpress/
└─ simchange/
   ├─ .git
   ├─ rails/
   └─ wordpress/

というディレクトリ構造にしました。これまで通りgit管理されているのは/simchangeのみで、そこにrails/もwordpress/も入っています。なので、開発時は今までと何も変わることはなくsimchange/のレポジトリのみを触ればよいというわけです。
（kusanagi_rails/とkusanagi_wordpress/がKUSANAGIのプロビジョニングで作成したディレクトリです。）

KUSANAGIディレクトリの出番はデプロイ時だけ。

$ cp -apr simchange/rails/*  kusanagi_rails/
$ cp -apr simchange/wordpress/*  kusanagi_wordpress/DocumentRoot/

で終了です。細かい話をすると、本当はwp-config.phpはkusanagi_wordpress/直下のファイルを触る必要がありますし、rake db:migrateやrake assets:precompileなどは kusanagi_rails/以下で行う必要があるので、上記だけではないのですが。
SIMCHANGEではFabricを用いてデプロイを自動化し、このあたりはほとんど意識せずにリリース作業が行えるようにしています。

あと、後述のNginxの設定の際にも触れますが、WordPressとRailsの共存のために

$ ln -s kusanagi_rails/public  kusanagi_wordpress/DocumentRoot/public

RailsのpublicディレクトリのシンボリックリンクをWordPress側に貼っておきます。

Ruby on Rails × PostgreSQL × Puma

さて、SIMCHANGEでは前述の通り、Ruby on Rails × PostgreSQLで格安SIMの診断ページやユーザーのマイページを動かしています。 KUSANAGIでWordPress環境を構築した記事はググれば山ほど出てくるのですが、Ruby on Railsを構築した記事はあまり出てきません。まぁKUSANAGI for Ruby on Railsがリリースされてから、まだ半年ほどなので仕方ないですよね。
KUSANAGI環境でRuby on Rails × PostgreSQLを構築し、Pumaで起動するためにやったことを以下に書いておきます。ご参考になれば。

$ sudo kusanagi provision --rails kusanagi_rails
$ sudo kusanagi dbinit psql
$ sudo yum install postgresql-devel.x86_64

$ cd kusanagi_rails
$ bundle config build.pg --with-pg-config=/usr/pgsql-9.6/bin/pg_config
$ bundle install

// systemd でpumaを動かす
$ sudo vim /etc/systemd/system/puma.service
  [Unit]
  Description=Puma Application Server
  After=network.target

  [Service]
  Type=simple
  User=kusanagi
  WorkingDirectory=/home/kusanagi/kusanagi_rails
  Environment=RAILS_ENV=production
  ExecStart=/bin/bundle exec puma -C /home/kusanagi/etc/puma/puma.rb
  TimeoutSec=300
  Restart=always

  [Install]
  WantedBy=multi-user.target
$ sudo chmod +x /etc/systemd/system/puma.service
$ sudo systemctl enable puma
$ sudo systemctl start puma

// php7-fpm
$ sudo vim /etc/php7-fpm.d/www.conf
  env[SIMCHANGE_ENV] = production
$ sudo systemctl restart php7-fpm
$ sudo systemctl restart nginx

SIMCHANGEの場合、PostgreSQLは別のRDSで動いているので停止し、自動起動を無効にしておきます。

$ sudo systemctl stop PostgreSQL && systemctl disable PostgreSQL
$ sudo systemctl stop Pgpool-II && systemctl disable Pgpool-II

Nginx設定

全部書くと、もの凄い量になってしまうので、省略しながらポイントだけ。

// nginx.conf
http {
   ... 省略 ...
   include /etc/nginx/simchange.conf;
}

// simchange.conf
upstream rails {
    server unix:///home/kusanagi/run/puma.sock fail_timeout=0;
}
server {
    listen 80;
    server_name simchange.jp;
    ... 省略 ...
    include  /etc/nginx/kusanagi_wordpress;
    include  /etc/nginx/kusanagi_rails;
}

// kusanagi_wordpress
location / {
    try_files $uri $uri/ /public/$uri /index.php?$args;
}
... 省略 ...

// kusanagi_rails
location ~ "^/assets/.+\." {
    root        /home/kusanagi/kusanagi_rails/public;
    ... 省略 ...
    try_files $uri  @rails;
}
location ~ "^/([診断やmypageなどrailsのpathを正規表現で記載])" {
    ... 省略 ...
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP  $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_redirect off;
    proxy_pass http://rails;
}
location @rails {
    ... 省略 ...
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP  $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_redirect off;
    proxy_pass http://rails;
}

省略しすぎたかも。ポイントは、Railsにアクセスしたいpath（例えば、/tryや/mypageなど）を予め指定しておき、それをRailsが動いているPumaに振ること。upstream rails { }で、puma.rbで指定したPuma のソケットを指定しています。
また、kusanagi_wordpressのtry_files /public/$uriは、前述のWordPress側からRails側に貼ったシンボリックリンクを指しています。

S3のマウント

SIMCHANGEでは、画像データなどをS3に置いてます。S3のマウントのやり方などはググってもらって、他の記事を参考にしていただければと思いますが、KUSANAGI環境にマウントするにあたって注意点がひとつ。
httpd:wwwでマウントしましょう。 kusanagi:kusanagiでマウントした場合は、/etc/php7-fpm.d/www.confのuserとgroupを変更する必要があります。

Blue-Green Deployment

特別なことは何もしていませんが、サーバーの切り替え手順も記載しておきます。

これまで運用していたEC2サーバーとは別に、KUSANAGI環境のEC2サーバーを用意。
staging用のELBにぶら下げ、DBの向き先もstaging用に設定して、動作確認。
staging用のELBにぶら下げたまま、DBの向き先だけをproduction用に切り替え、動作確認。
production用のELBにぶら下げ、リリース！！

Wordpress内記事検索も高速化

ちなみにSIMCHANGEでは、この機会にMroongaを導入しました。
KUSANAGIはMroongaにも対応しています。 WordPressのプラグインから入れることも可能です。

$ sudo kusanagi addon install mroonga

あとがき

簡単にKUSANAGI対応についてまとめましたが、対応してから2ヶ月くらい経ってしまっているので、正直記憶が曖昧な箇所も。とりあえず、試行錯誤を繰り返した記憶だけはあります。 KUSANAGI対応もそうですが、各バージョンアップもなかなか大変で・・・。骨が折れる作業でしたが、こういった新しい技術の導入にチャレンジさせてもらえる環境に感謝です。

ENECHANGE Developer Blog

ENECHANGE開発者ブログ

KUSANAGI for Ruby on Rails × Wordpress