#9 WebサーバーのベストプラクティスをNGINX中心で説明
WEBサーバーのベストプラクティスを説明していきます。
過去にiframeの代わりにapacheのrewriteを使っている設定があったり
apacheのrewriteだらけで、あきらかに不要と思っていても削除
するのが怖くてできないような設定を見かけました。
WEBサーバーの設定もバージョン管理しづらいのと変更しづらいので
できる限り最小の設定を心がける必要があります。
ただ単にバージョン管理ができるからだけではなく、エンジニアは自分が得意な
領域で設定したくなることがよくあります。
DBの得意な人はDBの機能を使いたがるし、nginxの設定が得意な人はnginxで
やってしまいます。同じくLinuxのIPtables, Firewalldしかり、他のエンジニア、
プログラマーができない事が優れていると勘違いしてそういう得意な分野で
誰もわからないようなブラックボックスの設定をしてしまいがちです。
本来は誰でもわかるようなサーバーサイドプログラミングでできるかぎり
機能を実装すべきです。
IPアドレスの制御をPHPなどのサーバーサイドプログラミング側で
制御するのかnginxの設定で制御するのか、LinuxのIPtablesの設定で
制御するのかWAF側で制御するのかですが、
この場合も特定のIPアドレスの許可、またはブロックは
サーバーサイドプログラミングで制御するのがベストかと思います。
ただ、国単位のアクセスを制御するとなると大量のIPアドレスを登録
しないといけないので、nginxのgeo関連のツールをインストール
した経験があります。
ただし、その設定をした場合もチーム全員に周知して、nginx.confの
設定ファイルもバージョンで管理すべきです。
nginx.confなどの設定ファイルは設定してから、後からリポジトリに
コミットする形なので忘れがちになりますが、nginx.confでの影響は
プログラミングよりも大きく、デバッグも難しいのでバージョン管理
はより徹底すべきかと思います。
ちなみにこの国ごとのアクセスを制御した設定をしてからの不具合は
ネット回線ベンダーが中国のIPアドレスを買収して日本にして日本からのアクセス
と認識するようになった場合、nginxの設定ではまだ中国でブロックの対象に
なっているという不具合があり、バイナリーファイルを更新して解決したという
事が起きました。
基本設定であるworker_process等などは色々変更しましたが、あまり効果が
なかったので、この設定で問題ないかと思います。
load_moduleでは先程のGEO関連の国単位でブロックするツールをインストールしています。
limit_req_zoneでは1秒に50アクセス、request以上はブロックするという設定をしています。
これはDDos攻撃というのを防ぐためですが、この設定でも不具合がでました。
1ページに50画像以上表示させると50以上から403が出るようになってしまいました。
その時は画像を削るなどの対応をして解決しましたが、やはり、初めは
なんでそんな不具合が起きたのか気づくのに時間がかかりました。
次にロードバランスの設定です。ここではmyserversのグループがいくつの
サーバーを保持しているかという設定です。
ここで上からどの振り分けにも該当しないアクセス、つまりデフォルトの
アクセスはmyserversにアクセスするように設定しています。
myserversとさきほどの192から始まる複数のサーバーが紐付いているので
負荷分散されるという事になります。
この時点でサーバーとポートを指定できるので、PHP,Goの場合は
直接php-fpmのポートやGoのポートを指定もできます。
TSVでロギングするように設定しています。
解析したい時にDBにいれやすいように思ったのですが、容量がおもすぎて
無理でした。
シェルを作成して毎週文をDBに入れるみたいな運用にすれば
いいかもですが、費用対効果が出ないので何もしてないです。
1つ目はgoaccessという解析ツールです。アクセスの全般的な解析はできますが、
特定のキーワード検索や国などで検索ができなかったので、今はその運用をしていません。
本来はできるのかも知れないですが、そんな要望もないので、放置しています。
2つ目はhttpsではなくてhttpのアクセスをリダイレクトしています。
その他にmmmzy.jpというサイトからのアクセスをブロックしています。
リファラーは書き換えることができるので、この設定はそこまで意味ないかと思います。
３つ目はwww2とexample.comにアクセスした場合、www.example.comに301リダイレクト
するように設定しています。移行時にこういった設定をしますが、
移行が終わればなるべく早く設定を削除すべきですが、削除はやはり、怖くて
できていません。
この画像はページキャッシュです。DBにアクセスもしないので済むので
負荷も軽くなる上、スピードも早くなりますが、データの変更がある場合は
キャッシュを毎回削除しないといけませんが、スピード改善の有効な方法の一つです。
この画像はSSLのセキュリティの設定でデフォルトよりもセキュリティが
高めに設定してあります。
クライアントや監査機関からチェックされる事があるので、このように
セキュリティが高い設定をしないといけない時があります。
この画像はブラウザキャッシュです。該当する拡張子で同じブラウザで同じURLを
アクセスすると２回目はキャッシュが効いてダウンロードしなくても済みます。
この設定では１年間キャッシュが有効に設定されてます。
apacheではなくnginxで説明したのは
これからWEBサーバーを構築する時はapacheよりもnginxだと思い
あえて比較するまでもないと思ったのでnginx中心に説明しました
細かい設定まで解説しすぎましたが、重要な点は
ロードバランサーなどで利用されるnginxはアクセスが集中する部分なので
設定や変更は最小限にして、バージョン管理は徹底するという所だと思います。
異論・反論があれば是非コメントしてもらえればと思います。
