WebサーバーのベストプラクティスをNGINX中心で説明
WEBサーバーのベストプラクティスを説明していきます。
#9 WebサーバーのベストプラクティスをNGINX中心で説明【主張】 - YouTube
過去に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はアクセスが集中する部分なので設定や変更は最小限にして、バージョン管理は徹底するという所だと思います。
異論・反論があれば是非コメントしてもらえればと思います。
登録日：
更新日：