nginxリバースプロキシ編に続き、ConoHaのWordPressテンプレートのバックエンド側の設定を読みながら解説していきます。
…とその前に、ConoHa WordPressテンプレートの全体像について確認しておきます。

大雑把にまとめると、Web越しのリクエストを返すために動作するのはnginx, php-fpm, MySQLの3種類のプロセスです。
このうちnginxはキャッシュした結果を返すためのリバースプロキシと、キャッシュがなかったり期限が切れていたりするリクエストを捌くためのバックエンドサーバに分かれています。
またリクエストを返すときに直接は関与しませんが、システム全体が正しく動くよう各プロセスを監視するmonitという監視サーバも動いています。

これらを大雑把にまとめると下図のようになります。

ConoHaサーバ構成

このような感じで、キャッシュが残っているものはリバースプロキシから、キャッシュから返せなかった静的ファイルはバックエンドサーバから、さらにPHPだった場合はアプリケーションサーバーから、それぞれレスポンスが返されます。
なお煩雑になるためレスポンスを書き込みませんでしたが、リクエストの矢印の反対向きにデータが返っていきます。

前回記事で扱ったのがリバースプロキシの部分で、今回扱うのがバックエンドサーバ部分です。
アプリケーションサーバーとかプロセス監視については… 気が向いたらそのうち…

default.backend.conf

さて、バックエンドサーバーの設定は/etc/nginx/conf.d/default.backend.confに書かれています。

かなり短くまとまっていますね。
2行目のlistenと15行目のinclude以外には特筆する部分はなさそうです。

2行目にあるlistenでは、/var/run/nginx-backend.sockというソケットを使ってリクエストを待ち受けているのがわかります。
ところでdefault.confの方では

    proxy_pass http://backend;

といったように、ソケットではなくURLを使ってバックエンドサーバを参照していました。
これらを結びつけている設定は、最も上位の設定である/etc/nginx/nginx.confに書かれています。

    upstream backend {
        server unix:/var/run/nginx-backend.sock;
    }

upstreamは公式ドキュメントに書かれている通り、サーバーグループを定義するために(used to define groups of servers)使われる記法です。
現状はバックエンドが1台だけですが、例えばバックエンドを増やして負荷分散したり、物理サーバを分けてソケットではなくhttpでやりとりする必要が生じた場合にも、このbackendブロックを設定するだけで実現できるようになっているわけですね。

wp-singlesite

さて、15行目のincludeではwp-singlesiteを参照していますので、こちらの設定も覗いていきましょう。
ちなみに16行目に別のincludeがコメントアウトされていますが、15行目をコメントアウトして16行目のincludeを有効にすることで、サブディレクトリでのWordPressマルチサイト運用が可能になります。
パスを弄らずに済む分サブドメインでのマルチサイトの方が色々簡単だとは思いますが、覚えておいて損はないでしょう。

長いですが大半がコメントアウトですので、動いている部分だけ抜き出して読んでいきます。

    include /etc/nginx/drop;

1行目、これはdefault.confにもあった、見られたくないものを見ようとするリクエストを弾く設定ですね。
リバースプロキシを通らずここに到達することはないはずなので処理が被っているような気がしますが、念のためということでしょうか…?

# This order might seem weird - this is attempted to match last if rules below fail.
location / {
    try_files $uri $uri/ /index.php?$args;
}

24-27行目、これはリクエストURIをそのまま試して、ダメだった場合は/を末尾に付加したもので試し、それでもダメならindex.phpに引数を渡したものでも試してみる、という設定のようです。
コメントにもありますが、前回も書いたとおり前方一致のマッチング順序は正規表現のマッチングより後になるため、このlocationは「最後に」マッチングされます。
普通はマッチングする順に書いたほうが直感的なので、確かに風変わり(weird)に感じる記述ですね。

29-30行目はコメントに書いてあるとおり、wp-adminへのアクセスを/終わりに揃えるだけなので飛ばします。

location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
    include /etc/nginx/expires;
    log_not_found off;
}

この部分は静的ファイルを返しています。
expiresは前回の方で載せたため省略します。静的ファイルの種類に応じてキャッシュ期限を変える設定ですね。

31行目からがphpファイルに対する処理の定義になります。

# Pass all .php files onto a php-fpm/php-fcgi server.
location ~ \.php$ {
    #limit_req zone=method;
 
    try_files $uri =404;
 
    expires        off;
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    fastcgi_pass   phpfpm;

長いので途中まで。
コメントに書いてあるとおり、全ての.phpファイルはphp-fpmに流しています。
mod-phpで直接phpを実行できるapacheと違い、nginxはあくまで静的コンテンツ配信サーバーのため、アプリケーションサーバは別立てになっているわけですね。
ちなみに、ここで書かれているfastcgi_passは直接phpfpmのプロセスを参照しているわけではなく、nginx.confに記載されている

    upstream phpfpm {
        server unix:/var/run/php-fpm.sock;
    }

によってUnixドメインソケットを参照しています。
backendの時と同様、並列化や別サーバ化などがしやすいように設定が切り分けられているわけですね。

fastcgi_params

46行目以降はfastcgiの設定がごちゃっと書かれています。
大して説明することもないので省きますが、さり気なく48行目でincludeが書かれているのには注意が必要です。
とはいえこれも中身は名前の通り、ひたすらfastcgiへのパラメタが羅列されているだけとなっています。

nginx.conf

最後に、本来最初に上げておくべきだった/etc/nginx/nginx.confについて軽く触れておきます。
そもそも一番最初にnginxが読み込む設定はこいつで、他の設定についてはここからincludeの連鎖によって読み込まれます。

長いですが、これまた基本的な設定ばかりなので解説するところは少なそうですね。

とりあえず2行目、

worker_processes  2;

という記述から、nginxのプロセスは同時に2つ立ち上がることがわかります。
一瞬リバースプロキシとバックエンドで2つなのかと思いましたが、特にそういう区別はなさそうです。
1リクエストを1プロセスで処理するapacheと違って、nginxはイベントドリブンのため少数のプロセスでリクエストが捌けることが伺えます。

一気に飛ばして88行目から。

    upstream backend {
        server unix:/var/run/nginx-backend.sock;
    }
 
    upstream phpfpm {
        server unix:/var/run/php-fpm.sock;
    }

default.backend.confの説明でも触れましたが、リバースプロキシとバックエンドサーバ、バックエンドサーバとアプリケーションサーバを繋ぐ部分はUpstreamディテクティブを使って抽象化されています。
これによって負荷増大に応じたスケーリングをすることが容易にできるようになっていますね。

    include /etc/nginx/conf.d/*.conf;

最後に、この記述によって/etc/nginx/conf.d以下の.conf終わりのファイルを読み込んでいます。
つまりここまでで解説してきたdefault.confやdefault.backend.confはここから読み出されているわけですね。
この設定から、新しく設定を増やす場合は.conf終わりのファイルを置けばよいし、逆にバックアップなど読みだしてほしくないけど同じディレクトリに置いておきたい場合は.backなどとファイル名末尾を変えてしまえば良いことがわかります。

以上、ざっくりとではありましたがnginxの設定について目を通してみました。
WordPressを普通に使っている限りはそこまで触ることはありませんが、例えばIPアドレスでのアクセスをドメイン名URLに転送する場合や、PHPMyAdminなどWordPress以外のアプリケーションを置いてURLによって振り分ける場合などに、どこの設定に何が書かれているかを抑えておくと弄りやすいのではないかと思います。
では、次回以降もよろしくお願いします。