epoll/kqueue（イーポールケーキュー）

2025年11月16日

epoll/kqueue（イーポールケーキュー）

英語表記: epoll/kqueue

概要

epoll（Linux）およびkqueue（BSD系OS、macOS）は、オペレーティングシステム（OS）のカーネルレベルで提供される、非常に効率的かつスケーラブルなI/Oイベント通知メカニズムです。これは、並行・並列処理の中でも特に非同期/イベント駆動型のシステムにおいて、多数の入出力（I/O）処理を単一のスレッドで高速に扱うことを可能にする、Event Loopの心臓部と言える技術です。従来のI/O監視手法であるselectやpollが抱えていたスケーラビリティの課題を克服し、Webサーバーや高負荷なネットワークアプリケーションの性能を飛躍的に向上させました。

詳細解説

epoll/kqueueは、私たちが普段利用している高効率なサーバー処理や、Node.jsなどのモダンな非同期フレームワークが、なぜ少数のスレッドで大量の接続を処理できるのか、という問いに対する決定的な答えを提供しています。

1. Event Loopにおける役割と目的

この技術が属する「並行・並列処理」→「非同期/イベント駆動」→「Event Loop」という文脈において、その目的は「ブロッキングを最小限に抑え、I/O待機時間を有効活用すること」にあります。

従来の同期的なI/O処理では、データが到着するまで処理が停止（ブロック）してしまいます。これを避けるため、多くの接続を扱うサーバーは、接続ごとに新しいスレッドやプロセスを立ち上げる「スレッド・パー・コネクション」モデルを採用していましたが、これはリソース消費が激しく、数千の接続を超えるとOSのオーバーヘッドで性能が劣化するという問題がありました。

epoll/kqueueは、アプリケーションが「どのI/Oが準備完了したか」をカーネルに効率的に尋ねるための仕組みを提供します。これにより、Event Loopは、準備完了したイベントだけをカーネルから通知（ディスパッチ）され、その処理に集中できます。これにより、単一のスレッドでも数万、数十万の接続を効率的に管理できるのです。

2. 動作原理：ポーリングからの脱却

epoll/kqueueの最大の革新は、従来の「ポーリング（Polling）」モデルから「イベント通知（Event Notification）」モデルへの移行です。

従来の課題（select/poll）

selectやpollといった古いAPIは、監視対象のファイルディスクリプタ（FD、接続やファイルを表す識別子）のリスト全体を、アプリケーションからカーネルに渡す必要がありました。カーネルはリスト全体をチェックし、準備完了したものを見つけますが、アプリケーション側は次のチェック時にもリスト全体を渡し直さなければなりません。接続数Nが増えるほど、このチェック処理の計算量はO(N)となり、スケーラビリティが失われてしまいます。これは、非常に非効率的だと感じませんか？

epoll/kqueueの解決策

epoll/kqueueでは、カーネル内部に「監視対象リスト」を保持します。

登録（epoll_ctl/kqueue）： アプリケーションは、監視したいFDを一度だけカーネルの監視リストに登録します。
待機（epoll_wait/kevent）： アプリケーションは、Event Loopのコアとなる関数で待機します。
通知（Ready List）： データが到着するなど、イベントが発生すると、カーネル自身がそのFDを「準備完了リスト（Ready List）」に移動させます。
取得： アプリケーションが待機から解放されると、カーネルは準備完了リストにあるFDだけを返します。

アプリケーションは監視リスト全体を毎回チェックする必要がなくなり、準備完了したイベントの取得は接続数Nに関わらずほぼO(1)（定数時間）で完了します。これが、高負荷下でも性能を維持できる秘密なのです。

3. エッジトリガーとレベルトリガー

epollには「エッジトリガー（ET）」と「レベルトリガー（LT）」というモードがあり、これも非常に重要です。

レベルトリガー（LT）： FDが読み取り可能である限り、epoll_waitを呼び出すたびに通知されます。扱いやすいですが、読み取り残しがあると何度も通知が来ます。
エッジトリガー（ET）： イベントが発生した瞬間（状態が変化した瞬間）にのみ一度だけ通知されます。非常に高速ですが、アプリケーション側で「データがなくなるまで」徹底的に読み取る必要があり、実装が少し複雑になります。高効率なサーバーでは、このエッジトリガーモードがよく利用されます。

具体例・活用シーン

epoll/kqueueは、私たちが日常的に利用するインターネットサービスを支える、目立たないながらも極めて重要なインフラ技術です。

活用シーン

高性能Webサーバー: NginxやApache HTTP Server（Event MPM使用時）は、epoll/kqueueを利用して数万の同時接続を少ないリソースで捌いています。
非同期ランタイム: Node.jsやPythonのasyncio、RustのTokioなど、現代的な非同期プログラミングフレームワークのI/O基盤として組み込まれています。
データベースプロキシ: 大量のDB接続を効率的に管理する必要があるミドルウェア。
オンラインゲームサーバー: リアルタイム性の高い通信を多数のプレイヤーと維持するために不可欠です。

具体的な比喩：デパートの呼び出しベルシステム

epoll/kqueueの動作を理解するために、デパートのフードコートを想像してみましょう。

select/poll方式（非効率な店員）

これは、店員（Event Loop）が、料理を待っているすべてのお客様（接続N）のテーブルを、5秒おきに巡回して「まだですか？」「まだですか？」と聞き回る状態です。お客様が10人ならまだしも、1000人いたらどうなるでしょうか？店員は巡回だけで疲れ果ててしまい、新しい注文を受け付けたり、料理を作ったりする時間がなくなってしまいます。これが接続数が増えるほど遅くなるO(N)のポーリング処理です。

epoll/kqueue方式（スマートな呼び出しベル）

最新のフードコートでは、お客様に「呼び出しベル（ファイルディスクリプタ）」を渡します。店員はカウンター（epoll_waitの待機場所）で待機しており、料理（I/Oデータ）が完成したときだけ、カーネル（フードコートの調理担当者）がベルを鳴らします。店員は、鳴ったベル（準備完了リスト）を持ったお客様のところへ、まっすぐ向かえば良いのです。

このシステムのおかげで、店員は無駄な巡回をする必要がなくなり、1000人の客がいても、同時に料理ができた5組だけを効率的に対応できます。これにより、単一の店員でも非常に高い処理能力を発揮できるのです。epoll/kqueueは、まさにこの「スマートな呼び出しベルシステム」をOSレベルで実現していると考えると、その革新性がよく理解できるかと思います。

資格試験向けチェックポイント

epoll/kqueue自体がITパスポートや基本情報技術者試験で直接問われることは稀ですが、「非同期処理」や「サーバーのスケーラビリティ」の文脈で重要となります。応用情報技術者試験以上では、その概念や従来のAPIとの違いが問われる可能性があります。

並行・非同期処理の効率化: epoll/kqueueは、単一スレッドで多数のI/Oを扱う「ノンブロッキングI/O」を実現するための、OSカーネル側の仕組みであると理解しておきましょう。
従来のAPIとの比較: selectやpollといった旧来の手法が、接続数増加に伴い性能が劣化する（O(N)）のに対し、epoll/kqueueは接続数に依存せず高速（O(1)）であることを押さえてください。このスケーラビリティが、現代のサーバーアーキテクチャの根幹です。
Event Loopのコア: Node.jsなどの非同期実行環境において、I/Oイベントを監視し、コールバック関数を実行キューに投入する「Event Loop」のエンジン部分として機能していることを理解することが重要です。
OS依存性: epollはLinux固有、kqueueはBSD系（macOS含む）固有の機能であり、APIが異なる点にも注意が必要です。