並行処理をマスターする：マルチプロセス・マルチスレッド・イベントループの違いと選び方

並行処理のマスタリング

あなたが開発したアプリには、同時に複数のユーザーがアクセスします。そして、誰もができるだけ速いレスポンスを求めています。そのためには、何らかの方法で並行性（コンカレンシー）に対応する必要があります。でも心配は無用です。多くのWebサーバーはデフォルトで並行処理に対応しています。ただし、アプリをスケールさせる段階になると、並行性を最も効率的な形で活用することが求められます。

並行処理の主な方式

並行処理を実現する方法は主に3つあります。マルチプロセス、マルチスレッド、イベント駆動です。それぞれに適した用途やメリット・デメリットがあります。この記事では、それぞれの違いと、どのような場面でどれを使うべきかを解説します。

マルチプロセス（Unicorn）

これは最もシンプルな並行処理の方式です。マスタープロセスが自身を複数のワーカープロセスへフォークし、実際のリクエスト処理は各ワーカーが担当し、マスターはワーカーの管理を行います。

各ワーカープロセスはコードベース全体をメモリ上に保持します。そのため、この方式はかなりメモリを消費し、大規模なインフラへのスケールが難しくなるという弱点があります。

マルチスレッド（Puma）

このスレッディングモデルでは、1つのプロセスが複数のリクエストを同時に処理できます。仕組みとしては、単一のプロセス内で複数のスレッドを実行します。

マルチプロセス方式とは異なり、すべてのスレッドは同じプロセス内で動作します。つまり、グローバル変数などのデータを共有します。そのため、スレッドごとの追加メモリ消費はわずかで済みます。

GIL（グローバルインタプリタロック）

ここでMRI（CRuby）におけるグローバルインタプリタロック（GIL）について触れておきましょう。GILとは、すべてのRubyコードの実行を囲むロックのことです。スレッドが並列に動いているように見えても、実際にアクティブになれるスレッドは常に1つだけです。

一方、I/O処理はGILの外側で実行されます。データベースクエリの結果を待っている間はロックされないため、その間に別のスレッドが処理を進めることができます。しかし、スレッド内で大量の計算処理やハッシュ・配列への操作を行う場合、MRIでは1コアしか活用できません。多くの場合、マシンの性能を最大限に引き出すには複数プロセスの併用が必要です。あるいは、GILを持たないRubiniusやJRubyを選択するという手もあります。

スレッドセーフティ

複数のスレッドを使う場合は、共有データを扱うすべてのコードをスレッドセーフな形で書くよう注意が必要です。たとえば、Mutexを使って共有データ構造を操作前にロックすることで実現できます。こうすることで、自分がデータを書き換えている間に、他のスレッドが古いデータをもとに処理を進めてしまう事態を防げます。

イベントループ（Thin）

イベントループは、大量の同時I/O処理が必要な場面で活躍します。このモデル自体は複数のリクエストを厳密に同時実行するものではありませんが、多数の同時接続ユーザーを効率的に捌く手法として優れています。

以下はRubyで書かれた非常にシンプルなイベントループの例です。ループはevent_queueからイベントを取り出して処理します。イベントが存在しなければスリープし、再びキューに新しいイベントがないか確認します。

loop do
  if event_queue.any?
    handle_event(event_queue.pop)
  else
    sleep 0.1
  end
end

図解バージョン

次の図解では、もう一歩踏み込んでみましょう。イベントループがOS、キュー、そしてメモリと美しいダンスを踊る様子をイメージしてください。

ステップごとの流れ

1. OSがネットワークとディスクの利用可能状態を監視します。
2. I/Oの準備が整うと、OSがキューへイベントを送信します。
3. キューはイベントのリストであり、イベントループは先頭のイベントを取り出します。
4. イベントループがそのイベントを処理します。
5. 接続に関するメタデータを保存するために、いくらかのメモリを使用します。
6. イベントの内容に応じて、新しいイベントを直接イベントキューへ投入することもあります。たとえば、イベントの内容に基づいてキューをシャットダウンする指示などを送れます。
7. I/O操作を行いたい場合は、OSに対して特定のI/O操作に関心があることを伝えます。OSはネットワークとディスクの監視（[1]を参照）を続け、I/Oの準備ができたら再度イベントを追加します。

どれを選ぶべきか？

この記事を通じて、さまざまな並行処理モデルへの理解が深まったなら幸いです。開発者にとって習得が難しいテーマのひとつですが、きちんと理解しておけば、自分のアプリに最適な構成を試験的に導入し、判断する力が身につきます。

まとめ

• ほとんどのアプリにとってはマルチスレッドが合理的な選択です。Ruby/Railsエコシステムも（緩やかにではありますが）この方向へ移行しつつあります。
• 長時間持続するストリームを含む高並行性アプリを運用しているなら、イベントループがスケールの鍵となります。
• トラフィックがそれほど多くないサイトや、ワーカーのクラッシュを許容したい場合は、安定のマルチプロセスが頼りになります。

さらに、イベントループをスレッドの中で動かし、そのスレッドをマルチプロセス構成の中で実行することも可能です。つまり、stroopwafel（シロップワッフル）を「持って」かつ「食べる」こともできるのです！

これらの並行処理モデルについてさらに詳しく知りたい方は、マルチプロセス、マルチスレッド、イベントループに関する詳細記事もぜひご覧ください。