PHPコンパイルによる高性能のFastCGIウェブサーバー構築とチューニングに関するお話し(1)

こんにちは。新規事業本部・金融グループの金（成奉）です。

　前回は高性能GIS専用のPostgreSQLデータベースサーバーの構築について話しましたが、今回はFastCGI基盤ウェブサーバーのPHPコンパイル構築、チューニング、設定などについてお話したいと思います。内容の範囲が広く、長文になっているため、３回に分けて投稿します。

　PHPは、ほとんどのモジュールがコンパイルされるような構成となっています。おまけにGIS関連のデータを扱うことのできるGEOSエクステンションの追加などにも触れています。

　ウェブサーバーは、ApacheとNginxになりますが、Nginxのコンパイル構築方法についても説明します。特にApacheでPHPを運用する際、最も効率よい構成はなんだろうと開発やインフラ担当の方はきっと悩んだことがあるかと思います。ApacheとPHPをどのような構成と設定で運用すれば、高いパフォーマンスで安定的にサーバーを運用できるかが、今回のメインテーマになります。またどのような構成が、PHPを使う上で一番パフォーマンスが出ているかのベンチマークについても触れます。

　なぜ、このようなお話をするかというと、サーバーのパフォーマンスと安定性は、ハードウェアも大事ですが、ミドルウェアやアプリケーションのコンパイル方法、設定、構成によって大きく左右されるからです。なので、今回は、PHPにかぎらず、チューニング方法、コンパイル方法、構成方法を中心に広範囲にわたってお話をしていきたいと思います。

環境及び制限等について

以下の作業や検証は、最新のCentOS6.5とLinuxのカーネル「2.6.32」バージョンで行った記録です。以下の操作と検証で同じ結果が出るという保証はありません。尚、ハードウェアの構成やネットワークの状況によって異なりますので、参考にしていただければ幸いです。検証環境は以下のようになります。

・さくらVPS
・Centos6.5
・3CPU/4G メモリ

作業場所とユーザー権限について

mkdir /opt/src
cd /opt/src

下のようなライブラリだけでコンパイルはできると思いますが、足りない場合は、追加インストールする必要があります。root権限で行います。

PHPバージョンについて

5.5.16

PHPの初期設定は、下のコンパイル・インストールの説明を参照してください。詳細については、バージョンによって内容が少し異なるため、以下のURLを参照しながら用途に合わせて設定します。 http://www.php.net/manual/ja/ini.core.php

PHPのコンパイル構築について

PHP実行バイナリは、コンパイル設定（./configure）によってスタティックまたはシェアド(Static/Shared)のバイナリを生成することができます。一般的にパフォーマンスはスタティックでコンパイルした方が良いと言われています。しかし、PHP本体にバグやセキュリティ脆弱性が発見された場合、すべてソースから再コンパイルする必要があります。シェアドでコンパイルした場合は、該当するライブラリー（Extension）のみコンパイルすることで対応できます。

PHP-5.5をビルドするとphp-cgi実行ファイルが生成されますが、今はデフォルトでFastCGI対応となっています。実行ファイルとしてphp-cli、php-fpmなどが生成されます。これらはコンパイル・オプションでサポートするSAPI（Server API）を追加してビルドすることで実行ファイルやモジュールのバイナリ（mod_phpなど）が異なります。PHPの歴史になりますが、初期バージョン（PHP/FI）も、FastCGI対応でビルドできるようになっていました。PHP3、PHP4になってからは、Apacheモジュール（mod_php）としての運用が主流となり、暫くの間、FastCGIがサポートされていなかった期間がありました。近年は、FastCGIでの運用が、世界の人々に支持され、新しくphp-fpmのSAPIが追加され、今後は、PHPはFastCGIでの運用が推奨されるようになっていくのではないかと考えています。

FastCGIでは、最初実行時に別のPHPプロセスを立ち上げてリクエストを待ち受ける状態になり、すべてのライブラリー（Extension）をメモリにロードし、リクエストを待ち受ける仕組みなので、コンパイル・オプションによるパフォーマンス差はそれほどありません。しかし、ApacheのMPM、PreforkモデルでApacheモジュール（mod_php）として運用する際、コンパイル・オプションのスタティックとシェアドとではパフォーマンスに差が大きく出ます。スタティック・オプションの方が10-30%程度早くなります。PHPをApacheのPreforkモデルで運用（mod_phpでの運用）する際は、アプリケーションで使用するPHPのExtensionを事前に決め、スタティック・オプションでコンパイル構築した環境での運用を強くお薦めします。FastCGIとして運用する場合は、コンパイル方法によるパフォーマンスの差はほとんどないため、柔軟にPHPのExtensionを、インストール・追加・変更できるシェアド・コンパイルの方がシステム運用上便利です。

ApacheのMPM（Multi-Proccessing Module）には、PreforkとWorkerがあります。ApacheのWorkerモデルではPHPモジュール（mod_php）は動作しません。ApacheサーバーをWorkerモデルで運用する際は、FastCGIで運用する必要があります。Nginxというウェブサーバーは、基本Workerモデルで動作します。このようにPHPをどのようなオプションでコンパイルするかの決定は、とても重要で、どのミドルウェアと構成するかによっても、システムの安定運用やパフォーマンスに大きく異なってきます。

PHPの運用構成について

Windowsサーバでの運用

IIS/FastCGI+PHPの構成が基本です。CGIとしても運用できますが、パフォーマンスに問題があるため、推奨できません。WindowsバージョンのApacheとPHPのバイナリも配布されていていて最近はとても安定してきましたので、小規模であればWindowsでも十分運用できるようになりました。ただし、Windowsでは、Unix/Linuxのカーネルオプションのように設定の変更ができないため、ある程度のアクセス制限を超えてしまうとApacheエラーのトラブルはまだあります。Java系のTomcatサーバも似たような現象があります。

Windows環境のApacheまたはTomcatをイントラネットで運用する際、500人規模の社内環境であれば、それほど問題ないですが、それ以上の場合には、OSレベルで弾かれるケースがあるため、WindowsサーバーのIISに変更するか、Unix/Linux基盤にシステム構成を変更した方が安定的に運用できます。理由は、パフォーマンスが落ちたからといってメモリやハードウェアを増設しても、Windowsのカーネル設定を変更することができないため、それ以上のパフォーマンスが見込めないからです。

Unix/Linuxでの運用

様々な運用方法と構成があります。一般的には「apache+mod_php」で運用するケースが一番多いでしょう。Internet上に多くのPHP構築マニュアルがありますが、ApacheでPHPを「Apache+mod_fcgid+php」構成で運用するのは、、個人的な意見としては推奨できません。呼び出されたCGIをメモリに常駐させる仕組みでメモリを多く消費してしまいます。mod_fcigdをFastCGIのように扱っている内容もよく見かけますが、mod_fcigdとmod_fastcgiは全く別物です。PHPを運用する際の構成については、下のような基本構成があり、それぞれ設定が異なります。

ApacheでPHPをFastCGIで運用する時には、fastcgiライブラリとmod_fastcgi（fastcgiライブラリも含まれて配布されています）をコンパイルしてApacheに組み込む必要があります。yumのレポジトリからダウンロードできるところもあります。私は、デフォルトのyumレポジトリ以外は、コンパイルして構築する方法を好みます。その方が、依存性などによる原因不明のトラブルがなくなり、よりシステムを安定的に運用できます。

実は、FastCGI本家で提供されている仕様は、20年程前に公開されてから全く変っていません。仕組みは、Javaのサブレッドと同じ仕組みだと思えば、理解し易くなると思います。まずこのFastCGIからダウンロードできるライブラリーのソースと仕様を少し理解していれば、PHPをFastCGIで運用するために設定する際、迷いや様々なインターネットの構築関連情報に振り回されなくなります。FastCGIの本家サイトが殆ど活動していなくなってから、FastCGIの設定について多すぎる情報が返って難しくしている感じがします。

Apache以外にもPHPを様々なサーバで利用できます。近年注目を浴びているNginxをお薦めします。JavaをFastCGIとして動作させることもでき、ほとんどの言語がサポートされています。Nginxで運用する構成は、最近PHPのSAPIに追加されたphp-fpmを利用するのが一般的で安定的に運用できます。php-fpmは設定でSocketまたはTCP/IPで運用できますが、Socketの方が少し早いです。しかし、注意しなければならないのは、sysctl.conf（カーネルパラメータ）を正しく設定しないとソケットがクラッシュしてしまいます。キュー制限（net.core.somaxconn）やファイル制限等を正しく設定すればハイ・パフォーマンスのPHP運用環境が構築できます。スケーラビリティを考えているのであれば、TCP/IPで簡単に設定して運用することも可能です。他にリバースプロキシーとキャッシュサーバ構成でPHPを複数台Webサーバに負荷分散させることもできます。今回の説明では、分散構成の構築の説明までは詳しくは触れませんが、以下のような構成が考えられますので参考にして頂ければと思います。

参考サイト

・FastCGI本家
　http://www.fastcgi.com/
・Nginxのアーキテクチャー
　http://www.aosabook.org/en/nginx.html

オープン系のPHP運用の基本構成

01. Apache-Prefork + mod_php
02. Apache-Prefork + mod_fastcgi + php-cgi
03. Apache-Prefork + mod_fastcgi + php-fpm
04. Apache-Worker + suphp(cgi) + php-cgi
05. Apache-Worker + mod_fastcgi + php-cgi
06. Apache-Worker + mod_fastcgi + php-fpm
07. Apache-Worker + mod_fcgid  + php-cgi
08. Apache-Worker + spawn-fcgi + mod_fastcgi + php-cgi
09. Nginx(Worker) + spawn-fcgi + php-cgi
10. Nginx(Worker) + php-fpm

注意１：5番のmod_fcigidは、一般的に言われているFastCGIとは異なります。
注意２：2番と3番の構成は推奨できません。ApacheのPHPモジュール（mod_php）とFastCGIを比較したベンチマークで、FastCGIが遅いと言っているサイトもありますが、この構成でベンチマークを行ったためです。
*注意３：php-fpmとspawn-fcgiには、FastCGIのプロセス管理機能があります。spawn-fcgiというのは、単体で各種言語のFastCGIを管理できるようにしたツールです。Unix/Linuxのプロセスというのは、それぞれの権限で実行されたりするため、セキュリティの意味でとても大事な機能になります。FastCGIライブラリーのソースで「fcgi_pm.c/fcgi_util.c」の内容を管理しやすくしたツールだと考えれば理解しやすくなります。他に「fcgi_buf.c/fcgi_protocol.c」というソースファイルもありますが、これらの内容を少し理解していれば、FastCGIのパフォーマンス・チューニングにとても役立ちます。ですので、php-fpmというのは、PHPのFastCGI（php-cgi）と、spawn-fcgi（管理機能なのユーティリティ）が一つにまとめられているバイナリであると考えれれば分かりやすくなります。同じ管理機能をPerl、RubyやPythonなど他のプログラミング言語で実装する際にも、spawn-fcgiを利用することでFastCGI環境での管理や運用がしやすいシステム構築ができます。つまりPHPをFastCGIで安全に運用する際に、FastCGIのプロセスを管理してくれるspawn-fcgiのようなツールとの組み合わせが必要であり、外部ツールを利用する時には「php-cgi + spawn-fcgi + mod_fastcgi」という構成になります。プロセスの管理機能等が、既に組み込まれている「php-fpm」だと「spawn-fcgi」は、不要になります。Apache環境では、「Apache-Worker + mod_fastcgi + php-fpm」という構成が、一番パフォーマンスのよい安定的に運用できるPHP環境になります。

推奨のPHP構成

①PHP言語のみの環境

Nginx(Worker) + php-fpm
Apache-Worker + mod_fastcgi + php-fpm

②PHP/Ruby/Perl/Pythonなど多言語運用環境

Nginx(Worker) + spawn-fcgi + php-cgi
Apache-Worker + spawn-fcgi + mod_fastcgi + php-cgi

複数台の運用構成例

• varnish：SSLに対応していないため、フロントエンドにpound（sslラッパー）を配置させます。
• フロントエンドにnginxの代わりにhaproxyなどもよく使われます。
• varnishとバックエンドの間にhaproxyを配置させる構成もあります。
• HTTPのPOST、セッション、クッキーなどを正しく設定して構築する必要があります。
• N: 数

1. pound <--> varnish <--> N * (apache + mod_php) 
2. nginx <--> N * (apache + mod_php)
3. pound <--> varnish <--> N * (apache + mod_fastcgi + php-cgi)
4. nginx <--> N * (apache + mod_fastcgi + php-cgi)
5. pound <--> varnish <--> N * (apache + mod_fastcgi+php-fpm)
6. nginx <--> N * (apache + mod_fastcgi+php-fpm)
7. pound <--> varnish <--> N * (nginx + php-fpm)
9. nginx <--> N * (nginx + php-fpm)

負荷分散システム構成の整理

①pound->varnish->haproxy->backend
②nginx->backend
③haproxy->backend

★まとめ★

ハイ・パフォーマンスのPHP運用環境構築のキーポイントは、コンパイルによるチューニング、カーネル・パラメータによるチューニング、キャッシング、負荷分散、PHP運用の基本構成、内部processingの高速化、内部networkの高速化などを総合的に適切に行うことにあります。より高速なデータアクセスと計算能力が必要とされる場合は、グリッドコンピューティング（Globusツールキット：標準ミドルウェア）構築という手段もありますが、リソースを無駄使いしないように開発現場でのデータベースやプログラミングの最適化も重要な要素となります。

長い説明になりましたが、結論は、PHPを利用する上で一番お薦めできる基本構成は以下の二つになります。

Nginx構成

　Nginx-Worker + php-fpm

Apache構成

　Apache-Worker + mod_fastcgi + php-fpm

FastCGI運用関連の設定について

　FastCGIはリクエストを待ち受けるプロセス数を、ダイナミック（dynamic）または固定（static）で設定できます。自分は、固定での設定を好みます。php-fpmは、このプロセスを管理するデーモンの役割をしています。「mod_fastcgi + php-cgi」という構成の場合も、FastCGIプロセス数の設定は、ダイナミックか固定で設定しますが、定期的にメンテナンスを行う必要がありました。このような管理機能をphp-fpmというSAPIが追加されサポートされるようになったことによって、無停止で安全にFastCGIのプロセスの自動管理ができるようになりました。

PHP関連のカーネル・パラメーター・チューニングについて

上でも触れたようにPHPをソケット設定のFastCGIで運用する場合は、カーネルパラメーターを変更する必要があります。関連するパラメータの確認方法は以下のコマンドで行います。近年の金融取引システムにでは、100万分の1秒単位でのパフォーマンスを競う「LowLatency」システムが要求されます。下のカーネルパラメータ設定は、ハイ・パフォーマンスのPHP環境構築のため、「Low Latency System」の設定を一部参考にしました。

Tunedでのチューニング

以下のツールをインストールしてコマンドを実行すると自動でチューニングしてくれるそうです。内容が分からない場合は、次のコマンドは実行しないでそのままスキップしてください。

インストール

yum install -y tuned

オプション確認

tuned-adm list
Available profiles:
- default
- enterprise-storage
- desktop-powersave
- laptop-ac-powersave
- laptop-battery-powersave
- sap
- spindown-disk
- virtual-guest
- server-powersave
- throughput-performance
- virtual-host
- latency-performance

チューニング実行（latency-performance）

tuned-adm profile latency-performance

GRUB構文追加設定によるチューニング

以下の内容については、カーネルとOSの知識がある方に限ります。OSが起動しなくなる危険もありますので、参考程度にしていただければ幸いです。100万分の１秒単位を競う金融機関の高速取引システム（Low latency Trading System）で効果を発揮する設定を参考にしたものです。今はリアルタイムカーネル等の応用もありますので、Unix/Linuxで新しい技術について興味のある方は、Ubuntuのlowlatencyカーネルを参考にしていただければと思います。GRUB構文の最後に以下の行を追加して設定します。以下の作業は、ご自身の責任と判断で行ってください。不安があるようでしたら、この設定はスキップしてください。

nosoftlockup nohz=off highres=off intel_idle.max_cstate=0 processor.max_cstate=0 cgroup_disable=memory nmi_watchdog=0 divider=4 nosoftlockup mce=ignore_ce

GRUB構文の例

注意：以下の「kernel」の部分をそのままコピーして入れ替えるとOSが起動しなくなります。必ず、上の行を最後に追加するようにしてください。

view /etc/
title CentOS (2.6.32-431.17.1.el6.x86_64)
        root (hd0,0)
        kernel /vmlinuz-2.6.32-431.17.1.el6.x86_64 ro root=UUID=035d9a21-778d-40cf-9ecb-d244d7b95781 rd_NO_LUKS rd_NO_MD SYSFONT=latarcyrheb-sun16  KEYBOARDTYPE=pc KEYTABLE=jp106 LANG=ja_JP.UTF-8 rd_NO_LVM rd_NO_DM quiet nomodeset clocksource=kvm-clock console=tty0 console=ttyS0,115200n8r crashkernel=auto nosoftlockup nohz=off highres=off intel_idle.max_cstate=0 processor.max_cstate=0 cgroup_disable=memory nmi_watchdog=0 divider=4 nosoftlockup mce=ignore_ce
        initrd /initramfs-2.6.32-431.17.1.el6.x86_64.img

各GRUB設定項目の説明については紙面上省略します。項目別に検索してご確認いただければと思います。

ulimit設定変更

サーバーの負荷テストを行う際にulimit設定関連のエラーで検証できないことが多いため、ulimitのデフォルト値を変更します。変更しておいた方が問題が少ないです。「/etc/security/limits.conf」やコマンドで設定出来ますが、再起動するとデフォルト値に戻ります。再起動時に自動で反映されるようにするには、以下のように追加します。

制限確認

ulimit -n -u -s

推奨設定反映

ulimit -n 65536 -u 16384 -s 32768

起動時の推奨設定反映

echo "ulimit -n 65536 -u 16384 -s 32768" >> /etc/sysconfig/init

カーネルパラメータチューニング

以下の内容については、ご自身の責任と判断で行ってください。設定は、「Low latency Trading System」の設定を参考にしています。必ず設定内容を確認し、ご自分のシステムに合わせ、各項目の内容を理解した上で変更を行ってください。以下の設定反映によるシステムの停止及びトラブル等に対しての責任は負いかねます。以下の設定は、IPV6をを無効にし、IPV4のみを利用している環境の設定になります。

セフォマ計算とメモリのLatency問題関連設定適用

以下のcatコマンドで作成されたシェルを実行し、出力される内容をカーネルパラメータのセフォマとして設定します。 ファイアウォール設定でリバーシプロキシーサーバーでの利用または大規模サイトの場合、メモリに合わせて「netfilter」のCONNTRACK_MAXのチューニングを行う必要があります。

CONNTRACK_MAXチューニング

参照 http://wiki.khnet.info/index.php/Conntrack_tuning

OS_BIT=64
RAMSIZE=`grep MemTotal /proc/meminfo | sed -e 's/^[^0-9]*//' | cut -d' ' -f1`
HASHSIZE=`echo "scale=0; ($RAMSIZE * 1024) / 131072 / ($OS_BIT / 32)" | bc -l`
CONNTRACK_MAX = `echo "scale=0; $HASHSIZE * 8" | bc -l`

チューニング値計算と一部設定反映

計算された値をカーネルパラメータ設定の内容を確認して修正します。

cd /opt
cat > "kernel_optimize.sh" <<'EOF'
#!/bin/sh
SHARED_BUFFER_RATIO=0.25
OPTIMAL_SHMMNI=8192
OS_BIT=64
echo "kernel.shmmni=$OPTIMAL_SHMMNI"
MAX_MEM=`grep MemTotal /proc/meminfo | sed -e 's/^[^0-9]*//' | cut -d' ' -f1`
OS_PAGE_SIZE=`getconf PAGE_SIZE`
OPTIMAL_SHMMAX=`echo "scale=0; (8192 + 208) * (($MAX_MEM * 1024) / $OS_PAGE_SIZE) * $SHARED_BUFFER_RATIO" | bc -l | cut -d'.' -f1`0
echo kernel.shmmax=$OPTIMAL_SHMMAX
OPTIMAL_SHMALL=`echo "scale=0; ($OPTIMAL_SHMMAX / $OS_PAGE_SIZE) * ($OPTIMAL_SHMMNI / 16)" | bc -l | cut -d'.' -f1`
echo kernel.shmall=$OPTIMAL_SHMALL
if [ $MAX_MEM -gt 8192 ]; then #latency issues configuration
    echo 2 > /proc/sys/vm/dirty_ratio
    echo 1 > /proc/sys/vm/dirty_background_ratio
else
    echo 10 > /proc/sys/vm/dirty_ratio
    echo 5 > /proc/sys/vm/dirty_background_ratio
fi
#netfilter設定
HASHSIZE=`echo "scale=0; ($MAX_MEM * 1024) / 131072 / ($OS_BIT / 32)" | bc -l`
CONNTRACK_MAX=`echo "scale=0; $HASHSIZE * 8" | bc -l`
echo "net.netfilter.nf_conntrack_max=$CONNTRACK_MAX"
echo "options nf_conntrack hashsize=$HASHSIZE" >/etc/modprobe.d/nf_conntrack.conf
EOF


#既存カーネルパラメータファイルのバックアップ
cp /etc/sysctl.conf /etc/sysctl.conf_backup

#上記設定を反映
sh kernel_optimize.sh

#カーネルパラメータの設定
#下の内容は、各項目の内容を確認し、上で実行して計算された数値に変更してからcatコマンドを実行してください。修正は★マークが付いている箇所になるます。

cat > "/etc/sysctl.conf" <<'EOF'
### カーネルパラメータ設定
# SysRq設定
kernel.sysrq=0

# スケジューラの設定
kernel.sched_nr_migrate=12

# コアダンプファイル名の設定
kernel.core_uses_pid=1

###### チューニング設定 ######
# カーネル・メッセージキュー最大サイズ
kernel.msgmnb=65536

# カーネル・メッセージ最大サイズ
kernel.msgmax=65536

# セマフォチューニング計算
#SHARED_BUFFER_RATIO=0.25
#OPTIMAL_SHMMNI=8192
#echo "kernel.shmmni = $OPTIMAL_SHMMNI"
#MAX_MEM=`grep MemTotal /proc/meminfo | sed -e 's/^[^0-9]*//' | cut -d' ' -f1`
#OS_PAGE_SIZE=`getconf PAGE_SIZE`
#OPTIMAL_SHMMAX=`echo "scale=0; (8192 + 208) * (($MAX_MEM * 1024) / $OS_PAGE_SIZE) * $SHARED_BUFFER_RATIO" | bc -l | cut -d'.' -f1`0
#echo kernel.shmmax=$OPTIMAL_SHMMAX
#OPTIMAL_SHMALL=`echo "scale=0; ($OPTIMAL_SHMMAX / $OS_PAGE_SIZE)*(OPTIMAL_SHMMNI / 16)" | bc -l | cut -d'.' -f1`
#echo kernel.shmall=$OPTIMAL_SHMALL

# デフォルトの設定内容について
#kernel.shmmni = 4092
#kernel.shmmax = 68719476736
#kernel.shmall = 4294967296

# カーネルヘッダーソースの内容
#define SHMMAX 0x2000000          /* max shared seg size (bytes) */
#define SHMMIN 1               /* min shared seg size (bytes) */
#define SHMMNI 4096               /* max num of segs system wide */
#define SHMALL (SHMMAX/getpagesize()*(SHMMNI/16))
#define SHMSEG SHMMNI               /* max shared segs per process */

##              SHMMAX        SHMMNI        68719476736     4096
##  SHMALL =  ----------- * ----------  =  ------------- * ------ = 4294967296
##             PAGE_SIZE        16             4096          16

#以下4Gメモリ設定の例
#セマフォチューニング計算の内容を下で設定します。

#１プロセスごとの共有メモリの最小サイズ (byte)
kernel.shmmni=8192

#システム全体の共有メモリ・ページ最大数
#★下はセマフォチューニング計算の内容に合わせて修正します。
kernel.shmmax=20593713000

#共有メモリ・セグメントのバイト数上限
#★下はセマフォチューニング計算の内容に合わせて修正します。
kernel.shmall=2574213632

#パラメータ順の内容
#semmsl semmns semopm semmni
#セマフォIDごとのセマフォの数、システム全体のセマフォの数、一度に実施できるセマフォ操作の数、セマフォIDの最大値
#OracleDB(semopm)は100以上設定必須
#以下の設定はメモリデータベースのALTIBASEチューニング参考。
kernel.sem=2000 32000 512 5029

# ファイルオープン・IO関連
#Oracle/MySQLチューニング参照
fs.aio-max-nr=1048576
fs.file-max=6815744

# メモリチューニング
vm.swappiness=20
vm.overcommit_ratio=99
vm.overcommit_memory=2

#IPV6無効化
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1

# パケット転送無効
net.ipv4.conf.all.forwarding=0
net.ipv4.conf.default.forwarding=0

# listenキュー制限設定
net.core.somaxconn=262144

# ICMPエラーメッセージを無視
net.ipv4.icmp_ignore_bogus_error_responses=1

# 偽装・不正パケット：リダイレクトログ記録
net.ipv4.conf.all.log_martians=1
net.ipv4.conf.default.log_martians=1

# スプーフィング対策 送信元IP偽装防止
net.ipv4.conf.all.rp_filter=1

# L3 環境のジャンボフレームで通信する場合
#net.ipv4.tcp_mtu_probing=1 

# ネットワークリソース関連設定
net.ipv4.tcp_fin_timeout=15
net.ipv4.tcp_sack=1
net.ipv4.tcp_fack=1
net.ipv4.tcp_keepalive_time=60
net.ipv4.tcp_keepalive_intvl=3
net.ipv4.tcp_keepalive_probes=3

# RFC1337に準拠（Protect Against TCP Time-Wait）
net.ipv4.tcp_rfc1337=1

# ソケットの高速リサイクル（DOS攻撃防止）
net.ipv4.tcp_max_tw_buckets=1440000 
net.ipv4.tcp_tw_recycle=1 
net.ipv4.tcp_tw_reuse=1 

# TCP SYN Flood攻撃対策
net.ipv4.tcp_syncookies=1

# RFC1323
# TCPウィンドウスケーリング有効（64KByte以上のバッファー）
net.ipv4.tcp_timestamps=0 
net.ipv4.tcp_window_scaling=1

# ブロードキャストアドレス宛pingには無応答
# ※Smurf攻撃対策
net.ipv4.icmp_echo_ignore_broadcasts=1

# ICMP Redirectパケットを拒否
net.ipv4.conf.all.accept_redirects=0
net.ipv4.conf.default.accept_redirects=0

# Source Routedパケットは拒否
net.ipv4.conf.all.accept_source_route=0
net.ipv4.conf.default.accept_source_route=0

# Kdump使用設定
net.ipv4.conf.all.force_igmp_version=2
net.ipv4.conf.default.force_igmp_version=2
kernel.unknown_nmi_panic=1
kernel.panic_on_unrecovered_nmi=1
kernel.panic_on_io_nmi=1

# ARP応答なし設定
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.default.arp_ignore=1

# スプーフィング対策（送信元IP偽装防止）
net.ipv4.conf.all.rp_filter=1
net.ipv4.conf.default.rp_filter=1

#クライアントが増えた時のトラブル回避策
net.ipv4.neigh.default.gc_thresh1=1024
net.ipv4.neigh.default.gc_thresh2=2048
net.ipv4.neigh.default.gc_thresh3=4096

# NICチューニング設定
# ネットワークバッファーは16Mで十分
# 4MBまではカーネルで自動調整
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.core.rmem_default=16777216
net.core.wmem_default=16777216
net.core.optmem_max=16777216
net.core.netdev_max_backlog=250000
net.ipv4.tcp_mem=4096 87380 16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 87380 16777216
net.ipv4.tcp_max_orphans=16777216
net.ipv4.tcp_max_syn_backlog=65535
net.ipv4.tcp_low_latency=1
net.ipv4.tcp_no_metrics_save=1
net.ipv4.tcp_congestion_control=htcp
net.ipv4.neigh.default.unres_qlen=100
net.ipv4.neigh.lo.unres_qlen=100
net.ipv4.neigh.eth0.unres_qlen=100
net.ipv4.neigh.eth1.unres_qlen=100
net.ipv4.route.flush=1

# 高負荷のサーバ/NAT/プロキシーサーバー向けのエラー対策設定
# iptablesの再起動必要、iptablesが動作していない環境では設定する必要はありません。

#net.netfilter.nf_conntrack_max 計算
#OS_BIT=64
#RAMSIZE=`grep MemTotal /proc/meminfo | sed -e 's/^[^0-9]*//' | cut -d' ' -f1`
#HASHSIZE=`echo "scale=0; ($RAMSIZE * 1024) / 131072 / ($OS_BIT / 32)" | bc -l`
#CONNTRACK_MAX = `echo "scale=0; $HASHSIZE * 8" | bc -l`
#echo net.netfilter.nf_conntrack_max=$CONNTRACK_MAX

#4Gメモリ設定例
#★下はメモリに合わせて修正します。
#iptablesが起動していない場合は、反映時にエラーになります。
net.netfilter.nf_conntrack_max=122576
net.netfilter.nf_conntrack_generic_timeout=10
net.netfilter.nf_conntrack_tcp_timeout_established=2160
net.netfilter.nf_conntrack_tcp_timeout_close=8
net.netfilter.nf_conntrack_tcp_timeout_close_wait=10
net.netfilter.nf_conntrack_tcp_timeout_time_wait=10
net.netfilter.nf_conntrack_tcp_timeout_fin_wait=10
net.netfilter.nf_conntrack_tcp_timeout_syn_sent=10
net.netfilter.nf_conntrack_tcp_timeout_syn_recv=10
net.netfilter.nf_conntrack_tcp_timeout_max_retrans=30
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged=30
net.netfilter.nf_conntrack_tcp_loose=1
net.netfilter.nf_conntrack_tcp_be_liberal=0
net.netfilter.nf_conntrack_tcp_max_retrans=3
net.netfilter.nf_conntrack_acct=1
net.netfilter.nf_conntrack_checksum=1
net.netfilter.nf_conntrack_log_invalid=0
net.netfilter.nf_conntrack_expect_max=256
EOF

今回は以上になります。 次回は、PHP構築設定、MySQL設定、Redis設定などについてお話します。 長文を読んで頂き、ありがとうございました。