クイックスタート：高負荷サーバー向けの実践的な設定
トラフィックが急増した際に、サーバーのレスポンスが低下したり接続が切断されたりしていませんか？以下は、私がこの問題を根本的に解決するために使用している sysctl.conf の設定セットです。この設定により、フラッシュセール時にCCU（同時接続ユーザー数）が1,000から15,000に急増した際も、APIシステムの安定性を維持することができました。
まず、システム設定ファイルを開きます：
sudo nano /etc/sysctl.conf以下の最適化設定をファイルの最後に追加します：
# エフェメラルポートの範囲を拡張し、ポート枯渇を防止
net.ipv4.ip_local_port_range = 10000 65535
# TIME_WAIT状態のソケットをより早く再利用
net.ipv4.tcp_tw_reuse = 1
# SYNハンドシェイク中の接続待ち行列を増やす
net.ipv4.tcp_max_syn_backlog = 8192
# 確立済み接続の待ち行列制限を増やす
net.core.somaxconn = 8192
# 高速回線向けにバッファサイズを16MBに拡張
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# 輻輳制御アルゴリズムBBRを有効化し、スループットを向上
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbrサーバーを再起動せずに変更を即座に反映させるには、次のコマンドを実行します：
sudo sysctl -pなぜデフォルト設定は「高トラフィックの敵」なのか？
UbuntuやCentOSなどのディストリビューションは、多くのハードウェアで動作するように設計されています。しかし、デフォルトのパラメータは保守的すぎることが多いです。Nginx、Redis、Node.jsなどを高負荷で運用する場合、これらの制限がボトルネックとなります。
実際、TIME_WAIT 状態はサーバーがハングアップする最も一般的な原因です。接続が閉じられると、Linuxは迷子になったパケットを処理するために、そのソケットを60秒間保持します。秒間1,000リクエストが発生する場合、すぐに利用可能なポートを使い果たしてしまい、CPUに余裕があってもサーバーが新しい接続を拒否するようになります。
バックログ待ち行列とパケットドロップ現象
クライアントがSYNパケットを送信するたびに、tcp_max_syn_backlog のキューに並びます。このキューがデフォルトの128しかない場合、攻撃やトラフィックの急増時に数ミリ秒で満杯になります。その結果、ユーザーには「Connection Refused（接続拒否）」エラーが表示されたり、ページがいつまでも読み込まれなくなったりします。
主要なパラメータの分析
1. エフェメラルポート：接続スペースの拡張
デフォルトのLinuxでは、外部への接続用に約28,000個のポートしか割り当てられていません。サーバーが多くのバックエンドサービスに接続するリバースプロキシとして動作している場合、この数値は少なすぎます。ポート範囲を10,000から65,535に広げることで、システムはより多くの並行データストリームを処理できるようになります。
2. tcp_tw_reuseの活用
ソケットを60秒間「冬眠」させる代わりに、tcp_tw_reuse を使用すると、カーネルが TIME_WAIT 状態のソケットを新しい接続に再利用できるようになります。これは、tcp_tw_recycle（NAT環境で問題を引き起こすため、新しいカーネルでは削除されました）よりもはるかに安全な解決策です。
3. 1Gbps以上を活かすためのバッファ最適化
デフォルトの rmem および wmem の値は小さすぎることが多く、現代のネットワークカードの帯域幅を十分に活用できません。バッファを16MBに増やすことで、TCP Window Scalingが自動調整するための十分なスペースを確保でき、大容量データの転送速度が目に見えて向上します。
BBR：Googleが開発した「強力な武器」
BBR (Bottleneck Bandwidth and Round-trip propagation time) は、輻輳管理の方法を根本から変えます。パケットロスが発生してから減速するのではなく、BBRは能動的に帯域幅を推定し、可能な限り最高の速度を維持します。
遅延の大きい国際回線での実地テストでは、BBRによってスループットが最大40%向上し、ラグが大幅に減少しました。現在使用しているアルゴリズムは、次のコマンドで確認できます：
sysctl net.ipv4.tcp_congestion_controlbbr と表示されれば、システムは大規模なトラフィックへの準備が整っています。
運用上の重要な注意点
- RAMのバランス： 各ソケットは一定量のバッファメモリを消費します。サーバーのRAMが1GBしかない場合、バッファを64MBに設定しないでください。すぐにOut of Memory (OOM) エラーが発生します。
- 待ち行列の監視： 定期的に
ss -plntコマンドを使用してください。Send-Q列がsomaxconnの値を超えている場合は、設定のアップグレードやサーバークラスターの拡張が必要です。 - TIME_WAITの確認： 以下のコマンドで、待機状態の接続数を監視します：
ss -ant | awk '{print $1}' | sort | uniq -c - ファイアウォール： 追跡テーブルが満杯になって正当な接続がドロップされないよう、
net.netfilter.nf_conntrack_maxを十分に大きく（例：262144）設定してください。
TCPスタックの最適化は、継続的な微調整のプロセスです。すべてのアプリケーションに対して完璧な設定セットというものは存在しません。まずは私が提案した値から始め、モニタリングダッシュボードを観察しながら、システムにとって最適なバランスを見つけてください。
