【ITニュース解説】A Rant About Multiprocessing

システム開発における最もシンプルな構造は、単一のプログラムが全てを処理する「モノリシック（一枚岩的）なプロセス」だ。この設計の優れた点は、一つのプログラミング言語で完結し、異なるプログラム間での複雑なデータ交換、すなわちプロセス間通信が不要なことにある。開発者は一つの枠組みの中で、比較的安心してプログラミングに集中できるため、理想的な状態とも言える。

しかし、現代のウェブサイトやクラウドコンピューティングが普及した時代では、単一プロセスで全てをまかなうモノリシックなシステムは非常に稀になった。例えば、ウェブサーバーがデータベースサーバーに問い合わせを行うようなシステムでも、技術的にはウェブサーバーとデータベースサーバーという二つのプロセスが連携し、さらにクライアントからアクセスするためのライブラリが介在する。このように、機能の分離、物理的な分散、同時に多くの処理を行う必要性（並行性）といった要因が、システムの設計を必然的に複数のプロセスが連携する「マルチプロセスアーキテクチャ」へと推し進める。

マルチプロセスアーキテクチャが抱える根本的な課題は、プロセス間でのデータのやり取り、つまり通信の複雑さにある。プロセス自体の起動や管理は、Kubernetesのような専門ツールに任せることで解決できるため、これは主要な問題ではない。本当の難しさは、互いに通信し合うプロセス間で発生する。

例えば、ウェブサーバーとデータベースサーバーが連携するケースを考えてみよう。ウェブサーバーへの一回の問い合わせが、データベースサーバーへと伝わるまでに、内部では様々なデータの型が関わり、何度もデータの形式変換（エンコード/デコード）が行われることがある。これは非常に複雑な状況を生み出す。浮動小数点数のような一つのデータであっても、処理の過程で五種類の異なる形式をとり、JavaScript、Python、C++などのプログラミング言語が扱う実行時変数と、JSONやProtobufのような通信用の形式との間で、特定のコードを使って繰り返し変換される。このような構造は、しばしば「レイヤードアーキテクチャ」や「ソフトウェアスタック」と呼ばれる。

このスタックの最上部にJavaScriptアプリケーションがあり、最下部にデータベースの問い合わせ言語がある場合、スタックの各層で使われるデータの型（浮動小数点数、日付時刻、そして「人」のような開発者が独自に定義する型）は、データの整合性を保ったまま上下に伝達されなければならない。ブール値、整数、文字列といった基本的な型は比較的扱いやすいが、リストや配列、マップ（連想配列）といった「ジェネリック」な型では話が複雑になる。例えば、UUIDで識別される「人」オブジェクトのマップが、JavaScriptアプリケーションからデータベースクライアントライブラリへと完全にシームレスに渡される可能性は極めて低い。多くの場合、データの整合性を維持するためには、開発者が独自の変換処理コードを記述する必要がある。

このようなデータ変換に関する入念な作業は、詳細な調査、試作、そして単体テストを伴い、開発速度を低下させる要因となる。また、64ビットの識別子が32ビットしか扱えない型システムに渡されるような、想定外のケース（エッジケース）では深刻な問題が発生し、数ヶ月にわたって問題なく稼働した後にバグが表面化することもある。特に日付時刻の値は扱いが非常に難しく、多くのバグの原因となりやすい。

次に、クライアントがシステムと対話する方式についても課題がある。現代のソフトウェアスタックは、データベースモデルに基づいた「作成、読み出し、更新、削除（CRUD）」といったリクエストとレスポンスのやり取りに非常に効果的だ。これは、リクエストが完了するまで次の処理に進まない「ブロッキング」な対話モデルで、その有効性は証明されている。しかし、このモデルに合わないサービスを提供しようとすると、効果は薄れる。例えば、JavaScriptクライアントが、監視デバイスから送られてくるイベントのストリームをリアルタイムで表示するウィンドウを開きたい場合、どうすればよいだろうか。あるいは、運用上のエラーを適切な管理者に伝達するにはどうすればよいか。

HTTPとJavaScriptは、このような非同期な対話に対応するために、Push API、Server-side Events、HTTP/2 Server Push、WebSocketsといった様々な選択肢を提供している。特にWebSocketsは、双方向の非同期通信の最もクリーンな基盤となる可能性を秘めている。しかし、それでもなお多くの課題が残る。どのようなエンコーディング形式を使うべきか、利用可能な型システムは何をサポートしているのか（例えばJSONには日付時刻専用の型はない）、そして、一つのWebSocket接続上で複数の会話をどのように多重化（一つの回線で複数の通信を同時に行う）するか、といった問題だ。これらの会話に関わるのは誰で、どのような形でそれらを管理するのか、という点も考慮する必要がある。複数の会話を多重化する能力は、システムの内部アーキテクチャにも影響を与える。通信する各プロセスが、その複雑さに対応できるだけの高度な設計でなければ、多重化された通信路は結局、ボトルネックを生むだけになる。

メッセージング機能には、さらなる要求がある。ウェブサーバーのようなプロセスは、外部プロセスにとってのアクセスポイントとなる。複雑で多様な表示を持つクライアントに最適なサービスを提供するためには、関連するプロセスに直接アクセスできる複数の入り口が望ましい。しかし、セキュリティ上の懸念から、これらの複数の入り口を単一のアクセスポイントに統合せざるを得ない場合がある。その単一のアクセスポイントは、必要な内部接続を確立し、メッセージストリームを最終的な目的地へと継続的にルーティングする役割を担わなければならない。

最後に、複数のプログラミング言語を採用することは、それぞれの言語スキルが必要になるだけでなく、システム全体の均一性を損なう。各プロセスを泡、プロセス間の接続を矢印で表した図を想像してみよう。どこにでも矢印を追加できるという状況は、あらゆるプロセス、ひいてはあらゆる言語で同じメッセージングシステムが利用できることを前提としている。

マルチプロセスアーキテクチャと、それを支える多重化通信フレームワークの組み合わせは、開発者が無意識のうちに求めている理想的なシステム環境を提供できる可能性を秘めている。しかし、そのような理想的なフレームワークは現時点ではまだ存在せず、その姿も明確ではないのが現状だ。