網元AMIの内部を分析してみた

このサイトは網元AMIを使って、Amazon Web Services(AWS)上で動作しています。
その辺のことは、以前の記事を見ていただければと思います。

何が理由か分からないのですが、ブログで画像がアップロード出来ないという問題が発生してしまい、網元AMIを使うのを止めようかとも考えたのですが、そもそも網元AMIの構成をちゃんと知らずに使っているのは問題だなぁと思い、調べてみました。

網元AMIの全体構成

Amimoto ami

網元AMIの構成は上図のようになっています。
WebサーバとしてNginxが使われていること、PHPはphp-fpm上で動作していること、データベースはMySQL互換のPerconaが使われているのがポイントです。

また、EC2で動作しているのはもちろんとして、Nephila clavataという初期導入済のプラグインを使って、画像などのアップロードファイルはS3から配信されるようになっています。
データベースのデータとアップロードファイルのバックアップ用に、網元AMIとは別にBackWPupプラグインを導入し、バックアップファイルもS3に置くようにしています。

網元AMIには、The WP Booster CDN Clientというプラグインも初期導入されており、静的ファイルをCDNから配信することも出来るのですが、別料金がかかるので、使っていません。(網元AMIの使用自体も、EC2やS3の料金とは別にかかる。)

Nginx+php-fpm

以前はWebサーバといえばApache一辺倒だったのですが、最近はNginxの採用も増えています(とかっていう表現だと、古い!って言われそうだけど。)。
Nginx単体ではPHPが動作しない(それはApacheだってそうだけど)ので、何かを組み合わせる必要があるのですが、網元AMIではphp-fpmを採用しています。
(php-fpmの利点は、PHPマニュアルの中にまとまっています。)

Nginxの設定ファイルは、/etc/nginx配下にあります。
nginx.confの冒頭部分を見ると下記のようになっており、実行ユーザがec2-userであることが分かります。

(ちなみに、今回の画像がアップロード出来なくなった件は、/var/lib/nginx/tmp配下のディレクトリがnginxユーザで出来ていたからで、これをec2-userに変えることで解決しました。)

user ec2-user ec2-user;
worker_processes  2;
worker_rlimit_nofile 10240;

WordPressのファイルは、/var/www/vhosts配下のディレクトリにあるのですが、それがどこで指定されているかというと、/etc/nginx/conf.d/default.confにあります。

server {
listen      80 default;
server_name _;
root        /var/www/vhosts/i-xxxxx;
index       index.html index.htm;
charset     utf-8;

access_log  /var/log/nginx/i-xxxxx.access.log  main;
error_log   /var/log/nginx/i-xxxxx.error.log;

default.confを全部見てみると、mobile-detectやphpmyadminの設定ファイルのincludeがコメントアウトされています。なかなか興味深い。

網元AMIでは、リバースプロキシCacheで表示速度を改善しています。
上記のdefault.confで定義されているのはフロント側の設定で、バックエンド側の設定は同じディレクトリにあるdefault.backend.confで定義されています。

Nginx Cache Controller

網元AMIには、Nginx Cache Controllerというプラグインが初期導入されています。
上記のとおり、リバースプロキシCacheを使っているので、記事の更新タイミング等でキャッシュクリアしないと、古いままのページが表示されてしまいます。

WordPressにログインした状態では、Adminバーに「Nginx Cache」というメニューが表示され、ここからキャッシュの削除ができます。

Nginx cache controller

また、プラグインの設定画面には、上図のような設定項目があります。
投稿公開時のキャッシュ削除は、デフォルトでは「表示中のページと単独投稿記事と単独固定ページ以外のキャッシュを削除」がONなのですが、このサイトで使っているテーマではそれでは不十分なため、「すべてのキャッシュを削除」に変更しています。

Percona

Amimoto percona

網元AMIの環境に入ってインストールされているパッケージを見てみると、MySQLじゃないんですね!代わりに入っているのはPercona

PerconaはMySQLの派生製品で、高負荷環境での安定稼働が出来るというのがメリット。
WordPressはもちろん、phpMyAdmin等からもMySQLと同様の操作が可能になっています。

まとめ

まだまだ分析する箇所はありそうですが、今回の問題は解決したので、一応この辺で。
自分で同じような環境を作ることは出来そうなので、網元AMIの使用はやめようかなと考えたこともあるのですが、調べてみると色々と工夫が行き届いている様子。
有料とはいえ大した金額ではないので、引き続き使用していこうと考えています。

この記事を書いた人

井上 研一

株式会社ビビンコ代表取締役、ITエンジニア/経済産業省推進資格ITコーディネータ。AI・IoTに強いITコーディネータとして活動。2018年、株式会社ビビンコを北九州市に創業。IoTソリューションの開発・導入や、画像認識モデルを活用したアプリの開発などを行っている。近著に「使ってわかった AWSのAI」、「ワトソンで体感する人工知能」。日本全国でセミナー・研修講師としての登壇も多数。