井上 研一 このサイトは網元AMIを使って、Amazon Web Services（AWS）上で動作しています。
その辺のことは、以前の記事を見ていただければと思います。
何が理由か分からないのですが、ブログで画像がアップロード出来ないという問題が発生してしまい、網元AMIを使うのを止めようかとも考えたのですが、そもそも網元AMIの構成をちゃんと知らずに使っているのは問題だなぁと思い、調べてみました。
網元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」というメニューが表示され、ここからキャッシュの削除ができます。
また、プラグインの設定画面には、上図のような設定項目があります。
投稿公開時のキャッシュ削除は、デフォルトでは「表示中のページと単独投稿記事と単独固定ページ以外のキャッシュを削除」がONなのですが、このサイトで使っているテーマではそれでは不十分なため、「すべてのキャッシュを削除」に変更しています。
Percona
網元AMIの環境に入ってインストールされているパッケージを見てみると、MySQLじゃないんですね！代わりに入っているのはPercona。
PerconaはMySQLの派生製品で、高負荷環境での安定稼働が出来るというのがメリット。
WordPressはもちろん、phpMyAdmin等からもMySQLと同様の操作が可能になっています。
まとめ
まだまだ分析する箇所はありそうですが、今回の問題は解決したので、一応この辺で。
自分で同じような環境を作ることは出来そうなので、網元AMIの使用はやめようかなと考えたこともあるのですが、調べてみると色々と工夫が行き届いている様子。
有料とはいえ大した金額ではないので、引き続き使用していこうと考えています。