Nginx が大量の同時接続を少ないリソースで処理できる理由となるアーキテクチャの特徴はどれですか。

解説

正解は「少数のワーカープロセスがイベント駆動・非同期のループで多数の接続を多重処理する」です。Nginx は接続数に比例してプロセスやスレッドを増やさない設計になっており、CPU コア数程度のワーカープロセスが、それぞれ数千〜数万の接続をイベントループで回します。イベント駆動とは何かイベント駆動とは、「データが届いた」「書き込み可能になった」といった出来事（イベント）が発生したものだけを OS から受け取り、順に処理していく方式です。Linux では epoll、BSD 系では kqueue といった仕組みを使い、多数のソケットを1回のシステムコールで監視します。ソケットはノンブロッキングモードにしてあるため、1つの接続がデータ待ちで止まっても、ワーカーは他の接続の処理へ進めます。worker_processes auto; # CPU コア数に合わせてワーカー数を決めます events { worker_connections 1024; # ワーカー1つあたりの最大同時接続数です use epoll; # Linux で使う多重化の仕組みです }他の方式がスケールしにくい理由「接続ごとに専用のスレッドを生成し」や「リクエストを受けるたびに子プロセスを fork して」は、Apache の prefork/worker MPM に近い古典的な方式です。分かりやすい反面、接続ごとにスタックメモリとコンテキストスイッチのコストがかかり、数万接続では破綻します。いわゆる C10K 問題です。「すべてのリクエストを単一プロセスの同期処理で」では、1つの遅いクライアントが全体を止めてしまうため、そもそも並行処理になりません。ワーカーを止める処理が混ざると台無しになりますイベント駆動は「各処理がすぐ返ること」を前提にしています。そのためディスク I/O のようにブロックしうる処理が混ざると、そのワーカーが担当する他の数千接続がまとめて待たされます。大きなファイル配信では aio threads; や sendfile on; を使い、ブロッキングを別スレッドに逃がすか、カーネル内でコピーを完結させる設定が定石です。worker_connections を上げる際は、OS のファイルディスクリプタ上限（worker_rlimit_nofile）も併せて見直す必要があります。参考Connection processing methods - nginxCore functionality - nginx