Tech Learning Daily

1 接続 1 スレッドという素朴なモデル

ソケットの read() は、デフォルトではブロッキング I/O（データが届くまで呼び出したスレッドを眠らせて待たせる I/O）だ。この前提で素直にサーバーを書くと、接続を 1 本受け付けるたびにスレッドを 1 本作り、そのスレッドに読み書きを任せる形になる。コードは上から下へ読めて書きやすい。

問題は、HTTP の keep-alive やスマホの遅い回線のせいで、接続の大半は「つながっているが何も送ってこない」時間が長いことだ。待っている間もスレッドはスタックなどのメモリを握ったまま消えない。nginx のエンジニアリングブログは、この方式を「アクティブな HTTP 接続 1 本ごとに専用のプロセスかスレッドが必要」で重いと書き、I/O が多い状況ではコンテキストスイッチ（CPU が実行するスレッドを切り替える処理）が増えて性能が大きく落ちると説明している。1 台で 1 万接続を捌く難しさは、「C10K 問題」と呼ばれてきた。

解決の方向ははっきりしている。「待つ」ことをスレッドに任せるのをやめ、待っている接続の一覧をどこか 1 か所で監視して、準備ができた接続にだけスレッドを向けることだ。

ノンブロッキングにするだけでは足りない

ソケットをノンブロッキングモードにすると、データが無いときの read() は眠らずに即座に EAGAIN（今は無い、あとで試せ）というエラーで返る。これで 1 スレッドが複数の接続を扱えそうに見える。しかし全接続に順番に read() を試すループを回すと、何も届いていない間も CPU を空回しし続けることになる。

欲しいのは「この fd の中で、読み書きできる状態になったものを教えて、それまでは眠らせて」とカーネルに頼む仕組みで、これを I/O 多重化と呼ぶ。fd（ファイルディスクリプタ）はプロセスが開いたファイルやソケットを指す整数の番号だ。最古の API である select() は、監視したい fd をビットの並び（fd_set）にして渡し、カーネルがその中から準備完了のものを探して返す。

select() には 2 つの癖がある。1 つは、man ページが明言するとおり FD_SETSIZE（1024）未満の番号の fd しか監視できないこと。もう 1 つは、渡した fd_set が「準備完了の fd だけ」に上書きされて返るので、ループのたびに監視対象を全部詰め直して渡し直す必要があることだ。監視する接続が増えるほど、毎回の受け渡しと走査が重くなる。man ページ自身が「現代のアプリケーションは代わりに poll(2) か epoll(7) を使うべき」と書いている。poll() は 1024 の制限を取り除いたが、毎回全リストを渡す構造は変わらない。

epoll: 登録は一度、返すのは準備できた分だけ

Linux の epoll は、監視の一覧をカーネル側に持たせることでこの往復をやめた。epoll_create1() で epoll インスタンスを作り、epoll_ctl() で監視したい fd を一度だけインタレストリスト（監視対象の登録簿）に加える。以後、パケットが届くなどの I/O が起きるたびに、カーネル自身がその fd をレディリスト（準備完了の fd の一覧）に載せていく。

1 接続 1 スレッド
 conn1 ── thread1 (read で寝ている)
 conn2 ── thread2 (read で寝ている)
 connN ── threadN (read で寝ている)

epoll（1 スレッド）
┌─ kernel ─────────────────────┐
│ interest list (epoll_ctl)    │
│  conn1  conn2  ...  connN    │
│          │ data arrives      │
│          ▼                   │
│ ready list: conn2            │
└──────────┬───────────────────┘
           │ epoll_wait() が返す
           ▼
 イベントループ: conn2 だけ read

アプリ側のスレッドは epoll_wait() を呼んで眠り、レディリストに何か載ると起こされて、載っていた fd だけを受け取る。1 万接続を監視していても、届いたのが 3 本なら返ってくるのは 3 本だ。監視対象を毎回渡し直す必要がないので、待っているだけの接続はほとんど費用をかけずに置いておける。この「眠って、起こされて、準備できた fd を順に処理して、また眠る」繰り返しがイベントループの正体だ。BSD 系と macOS では kqueue が同じ役割を担う。

レベルトリガとエッジトリガ

epoll の通知には 2 つのモードがある。デフォルトのレベルトリガは「読めるデータが残っている間は毎回通知する」方式で、man ページは「単に速い poll」と説明している。データを半分だけ読んで次の epoll_wait() を呼んでも、残りがあればまた通知されるので取りこぼしは起きにくい。

EPOLLET フラグを付けるとエッジトリガになり、通知は「状態が変わったとき」だけになる。届いたデータの一部しか読まずに次の epoll_wait() を呼ぶと、新しいデータが来ない限り二度と起こされず、残ったデータが宙に浮く。そのため man ページは、fd をノンブロッキングにし、read() が EAGAIN を返すまで読み切ってから次を待つ使い方を推奨している。

struct epoll_event ev;
ev.events = EPOLLIN | EPOLLET; /* EPOLLET を外せばレベルトリガ */
ev.data.fd = conn_fd;
epoll_ctl(epfd, EPOLL_CTL_ADD, conn_fd, &ev);

ここで lead の疑問に戻る。Go の conn.Read() はブロックしているように見えるが、ランタイム内部では fd はノンブロッキングで、エッジトリガで epoll（macOS では kqueue）に登録されている。read() が EAGAIN を返すと、ランタイムはスレッドではなく goroutine だけを止めて脇に置き、その OS スレッドで別の goroutine を走らせる。netpoller と呼ばれるこの部品が準備完了の通知を受けると、止めていた goroutine を再開させる。「ブロックする」のは goroutine であって OS スレッドではない、というのが Go の書きやすさと接続数を両立させている仕掛けだ。Node.js の libuv も同じ API を使っている。

nginx の設定で効くところ

nginx はこの設計を設定にそのまま映している。worker_processes はイベントループを回すワーカープロセスの数で、デフォルトは 1。auto にすると CPU コア数を検出してその数だけ起動する。ワーカーが CPU コアに対応して並ぶので、コンテキストスイッチは仕事が無いときくらいしか起きない。

worker_processes auto;
worker_rlimit_nofile 16384;

events {
    worker_connections 4096;
}

worker_connections は 1 ワーカーが同時に開ける接続数の上限で、デフォルトは 512 だ。公式ドキュメントは 2 つ注意している。この数にはクライアントだけでなくプロキシ先（upstream）との接続も含まれるので、リバースプロキシでは 1 リクエストあたり 2 本消費しうる。また実際の同時接続数はオープンファイル数の上限（RLIMIT_NOFILE）を超えられない。worker_connections だけを上げても fd の上限で頭打ちになるので、worker_rlimit_nofile で上限も一緒に上げる。上の数値は組み合わせ方の例であって推奨値ではない。