Reactor パターン

2025年11月16日

Reactor パターン

英語表記: Reactor Pattern

概要

Reactor パターンは、並行・並列処理において、単一または少数のスレッドで多数のI/Oイベントを効率的に処理するために設計された並行デザインパターンの一つです。これは、I/O処理の完了を待たずに他のタスクを実行し続ける「ノンブロッキングI/O」を実現する中核的な仕組みであり、高いスケーラビリティが求められるネットワークアプリケーション、特にサーバーサイドの設計で非常に重要視されています。本パターンは、イベントの発生を監視する中央ディスパッチャ（リアクター）と、そのイベントに対応する処理ロジック（イベントハンドラ）を明確に分離することで、システム全体の応答性を高める役割を果たしています。

詳細解説

Reactor パターンが属する「並行デザインパターン」のカテゴリは、マルチスレッド環境における複雑な処理を整理し、安定したシステムを構築するために欠かせない知識です。このパターンは、特に「メッセージ駆動とアクターモデル」の文脈において、メッセージ（イベント）がシステムに入力された際の初期処理を担う重要な役割を持っています。

目的と背景

従来のマルチスレッド設計では、クライアントからの接続ごとに新しいスレッドを割り当てる「スレッド・パー・コネクション」モデルが一般的でした。しかし、接続数が増大すると、スレッドの生成や切り替え（コンテキストスイッチ）にかかるオーバーヘッドが無視できなくなり、システムのパフォーマンスが急激に悪化するという問題が発生します。

Reactor パターンは、この問題を解決するために考案されました。その最大の目的は、限られたリソース（スレッド）を最大限に活用し、多数のI/Oイベントを同時に、かつ効率的に処理することにあります。これはまさに、現代の「並行・並列処理」の分野における究極の課題の一つと言えるでしょう。

主要コンポーネント

Reactor パターンは、以下の主要なコンポーネントで構成されています。

リアクター (Reactor):
パターンの中心となる要素です。I/Oデマルチプレクサとイベントハンドラの登録を管理し、イベントが発生した際に適切なハンドラに処理をディスパッチ（振り分け）します。リアクター自身は具体的なビジネスロジックを実行せず、交通整理役として機能します。
I/O デマルチプレクサ (I/O Demultiplexer):
OSが提供するI/O多重化機能（例：Linuxのepoll、BSD/macOSのkqueue、標準のselect/pollなど）を利用します。これは、多数のI/Oソース（ソケットやファイルディスクリプタなど）を監視し、どのソースからデータが読み取り可能になったか、または書き込み可能になったかを検知する役割を果たします。
イベントハンドラ (Event Handler):
特定のイベント（例：接続確立、データ受信完了、書き込み可能など）が発生した際に実行される具体的な処理ロジックをカプセル化したモジュールです。リアクターからイベントを受け取り、実際のメッセージ処理やビジネスロジックを実行します。
ハンドル (Handle):
I/Oリソース（ソケットなど）を一意に識別するための抽象的な参照（識別子）です。デマルチプレクサはこのハンドルを通じてリソースの状態を監視します。

動作の流れ（ノンブロッキング I/O の実現）

Reactor パターンが「ノンブロッキング」である点が非常に重要です。処理の流れは以下のようになります。

登録: 各I/Oリソース（ハンドル）と、それに対応するイベントハンドラがリアクターに登録されます。
監視: リアクターはI/Oデマルチプレクサを利用して、登録されたすべてのハンドルを監視します。この監視処理は、いずれかのハンドルでイベントが発生するまでブロックされますが、単一のスレッドが多数のハンドルを効率的に監視できるため、全体の効率が向上します。
イベント発生: クライアントからデータが到着するなど、イベントが発生します（これはメッセージ駆動のシステムにおける「メッセージ到着」に相当します）。
ディスパッチ: I/Oデマルチプレクサがイベントを検知し、リアクターに通知します。リアクターは、対応するイベントハンドラを見つけ出し、そのハンドラを呼び出して処理を委譲します。
処理実行: イベントハンドラは、イベントからメッセージを読み取り、必要な処理を実行します。この際、ハンドラは長時間ブロックするような処理（例：データベースへの問い合わせなど）は避け、すぐに完了するロジックのみを実行することが理想です。長時間かかる処理は、別のスレッドやキューに渡すことで、リアクターのメインスレッドがブロックされるのを防ぎます。

このように、リアクターはイベントの受付と振り分けに特化し、実際の処理はイベントハンドラに任せることで、単一スレッドでも高い並行性を実現しているのです。これは本当に素晴らしい設計思想だと思います。

具体例・活用シーン

Reactor パターンは、特に高負荷なネットワークサービスや、イベント駆動型のフレームワークの基盤として広く採用されています。

Node.jsのイベントループ:
JavaScriptの実行環境であるNode.jsは、シングルスレッド環境でありながら高いパフォーマンスを発揮します。その心臓部にある「イベントループ」は、まさにReactor パターンの実装例です。I/O操作の完了を待たずに次の処理に移り、完了通知（イベント）が来たらコールバック関数（イベントハンドラ）を実行します。
高性能Webサーバー:
Nginxや一部のApacheモジュールなど、多数の同時接続を扱うWebサーバーの多くは、このパターンやその派生形を利用して効率的な接続管理を実現しています。
ゲームサーバー:
多数のプレイヤーからのリアルタイムな入力（メッセージ）を処理する必要があるオンラインゲームのサーバーサイドでも、応答性を確保するために利用されます。

アナロジー：救急病院のトリアージナース

Reactor パターンの動作を理解するための最も分かりやすい比喩は、「救急病院のトリアージナース」です。

一般的な病院（スレッド・パー・コネクションモデル）では、患者（接続）が来るとすぐに医師（スレッド）が一人専属で付き、レントゲン待ちや検査待ちの間もその医師は他の患者を診ることができません。これは非常に非効率です。

一方、Reactor パターンを採用した救急病院では、トリアージナース（リアクター）が中央にいます。

受付と監視（I/Oデマルチプレクサ）: ナースは待合室（多数のハンドル）全体を監視し、どの患者が治療準備完了か、あるいは緊急の容態変化（イベント）があったかを常にチェックしています。
医師団（イベントハンドラ）: 専門分野ごとの医師団が待機しています。
振り分け（ディスパッチ）: 患者Aの検査結果（イベント）が出たら、ナースはすぐにそれを外科医（イベントハンドラ）に渡し、「この患者の次の処理をお願いします」と指示を出します。

ナース（リアクター）は患者の治療（ビジネスロジック）自体は行いません。ひたすら「イベントの発生」を待ち、「適切な担当者」に振り分けることに集中します。これにより、少人数のスタッフ（スレッド）で、多数の患者（接続）の状態を同時に、かつ迅速に管理できるのです。ナースがブロックされることなく動き続けることが、システムの応答性を保証する鍵となります。

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

Reactor パターンは、特に応用情報技術者試験（AP）や基本情報技術者試験（FE）の午後問題における、アーキテクチャ設計やデザインパターンの知識として問われることが多いです。

[FE/AP] ノンブロッキング I/Oの実現:
Reactor パターンの最大の目的は、I/O処理中にスレッドをブロックさせないことです。この「ノンブロッキング」というキーワードと、スケーラビリティ向上の関係性を必ず覚えておきましょう。
[FE/AP] Proactor パターンとの対比:
Reactor パターンは、イベントが発生したことを通知する「受動的」なパターンです（イベントハンドラがI/O処理を開始する）。これに対し、Proactor パターンは、I/O処理の完了を通知する「能動的」なパターンです（OSや別スレッドがI/O処理を完了させてから通知が来る）。この違いは頻出です。Reactorは「イベント発生通知」、Proactorは「処理完了通知」と区別すると覚えやすいですね。
[AP] 主要コンポーネントの役割:
リアクター、イベントハンドラ、デマルチプレクサのそれぞれの役割を正確に説明できることが求められます。特に、デマルチプレクサがOSの提供するI/O多重化機能を利用している点も重要です。
[IP/FE] 並行処理のオーバーヘッド削減:
多数のスレッドを使うことによるコンテキストスイッチのオーバーヘッドを削減し、システムリソースを効率的に利用できる点が、このパターンのメリットとして問われます。これは、並行・並列処理の文脈で必ず押さえるべきポイントです。