日: 2023年9月7日

巷では静的コンテンツは劇的にレスポンスが速いと耳にするサーバーnginxへと乗り換えてみるのもありかなと、実験的にApache環境からの入れ替えを行ってみました。

その忘備録的な感想です。

■たしかに速いかも

なにせApacheしか経験が無かったのでまるっきりわからないところからのスタート。

しかもサイトそのものはいつでも元に戻せるように温存したまま限られた時間での移行という条件だったのです。

そもそもサーバーなんてやること同じなのだから設定も大差ないでしょ、などとタカをくくっていたらえらいギャップに悩まされることになりました。

■単純なHTTML構成のページは効果的

導入そのものはすごく簡単。先人の知恵をたくさん拝借できるので多少いびつな構成であっても困る事なく導入ができました。

そして、単純なWEBページについてはレスポンスが体感できるほど早くなった（そもそものApacheの設定が遅すぎたというのもありますが）

なんだ簡単じゃないか、と一瞬思ったわけなのですよ。幸せだったのはそのほんの一瞬。

■バーチャルホストは書く場所が違うだけ

Apacheではアクセスされたホスト名にあわせて処理内容を変えることができるようバーチャルホストで運営しているわけですが、通常だと /etc/apache/sites-available/ などに設定を書き溜めますよね。

nginxではどこに書いたら良いのだろう、たいして考え方は変わらないよね？と思っていたらありました。

/etc/nginx/cond.d/ 以下にバーチャルホストごとに分けて書けばおおもとの設定ファイルからすべて読み取ってくれるので問題なし。

極論すればバーチャルホストの設定は書いておく場所が違うだけ、と言えなくもない。

■PHPが動かない

今回、管理下の複数のサーバー（Ｕbuntu数台とCentOS）で同時に実験したわけなのです。

まっさきに外部非公開サーバーで問題が出てきたわけですが、php構成のページが急に消えたと。

そうです。経験のある方はすでに感づいてらっしゃるでしょうがApacheと違ってphp-fpmを導入してあげないと動いてくれない。nginxでphpページを表示するならphp-fpmを呼んであげるという考え方にしないといけないわけです。

設定そのものは特段難しくもなく、まずはphp-fpmを追加でインストールして、設定ファイルにどうやって呼び出すか（fastcgi 127.0.0.1:9000とか.sockとかなんとか）を追記してあげることでOKです。Apacheからしたら最初は「なんで機能を有効にするのに外を呼ぶの？」ってな感じでした。有効無効ってな感じとはぜんぜん違ったわけですね。

■Apacheからの乗り換えはパーミッションに注意

導入時点で前提がフラフラしているのがトラブルの原因ですが、nginxへの移行で時間がかかるならApacheへすぐ戻せるようにしておこうというのが一番ネック。

既存のページ構造には手を加えない前提なので、なにかサーバーを換えることでトラブルが出るならサーバー側の設定で吸収できるようにしなくちゃいけない。

単純な話ですが、サーバーが変わるということはサイトのファイルをアクセスするユーザーが変化するわけで。

たとえばサイトの権限が www-dataとか wwwグループとかいった具合に将来を見据えて最初から汎用的に設定している場合は楽なわけですよ。

ところが、長年の環境を引きずっていると場当たり的に apache:apache なんて権限になっているフォルダやファイルが大量にあったり。

もちろんnginxからはデフォルトでは nginx:nginx という権限でアクセスしますから、権限設定によってはここではじかれてしまいます。

ここでは非常に迷いましたが、本来であれば将来を見据えて apacheと設定されている権限の部分をすべてwww-dataなどと汎用的に書き換えてしまうのがベストかと考えます。

あるいは、そこそこ余裕のあるハード構成であればリバースプロクシ設定でnginxの後段でApacheに処理してもらうというサーバー構成にするのもトラブル原因を最小にできて良いかと思います。

ただし今回は一時的な試行でなおかつ既存サイトに手を入れないという前提を守るために本来は禁じ手であろうnginx側の動作権限をuser apache;と書き換えることでしのぐことにしました（変更先：/etc/nginx/nginx.conf）

上記にあわせてphp-fpm側の設定も listen.owner = apache、 listen.group = apacheと変更しておく必要もあるでしょう（変更先/etc/php-fpm.d/www.conf）

あくまでもApacheと同時には動かさないという前提であるがゆえにできる手抜きかなと思いますが、こういう手抜きをすると後々トラブルシュートしないといけなくなったときに原因が特定できずに大変だろうなと思います。

でも楽に動いてくれます。手抜き効果はすごい！

■WordPressがめちゃくちゃ遅い

さて、nginxへの切り替えから２日、やたらとレスポンスが遅くなったものがありました。

もともとチープなサーバーで近々リプレースを予定しているハード構成で動かしているものなのでApache運用でももっさりしていたWordPressなわけですが、nginxに切り替えてから劇的に遅くなり単純にダッシュボードを見ているだけでもjetpackから「サーバーがダウンしています」なんて通知が頻繁にくるように。

ダウンと言ってもそのまま固まってしまうような重症ではないので単純にリソース不足なのでしょう。

もともとMySQLがネックになっていることは自覚していましたのでまずは /etc/my.cnf を見つめて設定を切り詰めていきます。

が、しかしあまり改善するべき点が見つからず改善効果もみられない。そもそもが切り詰めたあとだったのでむしろ動作が窮屈だったのではなかろうかという設定具合。

どうやらその他のところにもなにやら問題がありそうな気配です。
もう一度 /etc/php-fpm.d/www.conf の設定をじっくり見ながら、

pm = dynamic
pm.max_children = 30
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10
pm.max_requests = 50

あわせて、/etc/nginx.conf の側でも

sendfile on;
tcp_nopush on;
tcp_nodelay on;
server_tokens off;
keepalive_requests 100;
keepalive_timeout 10;

fastcgi_buffers 8 64k;
fastcgi_buffer_size 64k;
fastcgi_connect_timeout 60;
fastcgi_send_timeout 60;
fastcgi_read_timeout 300;
client_max_body_size 200m;

といった具合に追記修正して少しは軽くなったかな？と淡い期待を込めてphp-fpmとnginxを再起動すると、おお！素晴らしい、ちゃんと軽くなった。

■変更した甲斐があり軽くなりました！

少なくとも重すぎてダウンしているという通知が来ることはなくなり、Apache上よりもはるかに軽く作業ができるようになりました。さすがnginxというところか。

これで一時的にはなんとか運用継続できるようになったわけですが、近いうちにどうせサーバーのリプレース作業があるわけでその時にはもう少し実用的な構成を要求したいなあ。得意な戦術はなに？と問われたら迷わず「物量戦」と答えたい派なので。

—
消えちゃった動画や写真データの復元は
安心安全な『株式会社パソコントラブル救助隊』へ。
https://hqsecure.net/