はじめに（この記事の役割）

この記事は、

Python の並行処理入門
asyncio の使い方解説

ではありません。

edrsim を設計・実装する中で、

「なぜこの並行処理モデルを選んだのか」
「なぜ他を選ばなかったのか」

という 設計判断そのものを残すための記事です。

この連載の全体像・目次はこちら

先に結論を書きます

edrsim では、

multiprocessing
threading

を使い、

asyncio は使っていません

理由は単純です。

edrsim の目的は
処理を効率化することではなく、
“狙った重さの負荷”を安定して出すことだからです。

並行処理の選択肢を整理する

まずは、選択肢を並べます。

それぞれの特徴を 教科書的に ではなく
今回の目的目線で見ます。

edrsim の処理は何が重いのか？

ここを誤ると、設計が全部ズレます。

edrsim の中身は？

ファイルイベントを受け取る
疑似検査処理を行う
ログ・状態を記録する

重要なのはここです。

疑似検査処理は
意図的に CPU を使うように作っています

つまり edrsim は、

CPU-bound な処理を“わざと” 持っているツール

です。

CPU-bound と I/O-bound の違い（超重要）

ここが分かれていないと、asyncio を選びがちになります。

CPU-boundとI/O-boundのことはこちらの投稿も参照してみてください。

I/O-bound
- ネットワーク待ち
- ファイル待ち
CPU-bound
- 計算
- ハッシュ
- スキャンっぽい処理

edrsim は後者です。

なぜ asyncio を使わなかったのか

ここはよく聞かれます。

「asyncio の方が今風では？」

asyncio を使うとどうなるか

asyncio は 1スレッド
CPU-bound 処理をすると
- イベントループが止まる
- 他タスクが進まない
「負荷を分散」ではなく
「負荷を隠す」方向に寄ってしまう

並行処理の判断を図にするとこうなる

edrsim では、「どの技術が流行っているか」ではなく
主な処理が何かを起点に判断しています。

edrsim で重要だったのは「見える負荷」

edrsim の目的を思い出します。

EDR導入後のサーバ負荷を評価する

ここで欲しいのは、

CPU 使用率が どう上がるか
コア数によって どう変わるか
他プロセスに どう影響するか

asyncio は、

OSレベルの負荷分散を見にくくする

という点で 目的に合いません。

multiprocessing を選んだ理由

GIL の影響を受けない
CPU コアをちゃんと使う
本番環境の負荷に近い

「重くなるなら、ちゃんと重くなれ」

これが設計思想です。

threading を併用した理由

すべてを multiprocessing にしなかった理由もあります。

設定読み込み
ログ出力
軽い制御処理

これらは、

CPU を食わない
同期しやすい
threading で十分

edrsim の並行処理構成（全体像）

役割で分ける
技術で分けない

「速さ」より「制御できる重さ」

ここが一番大事なポイントです。

高速に処理したい → asyncio
最大効率を出したい → 並列最適化

edrsim は違います。

「どのくらい重くするか」を
再現・調整できることが最優先

この判断が後で効いてきた

この並行処理設計のおかげで、

CPUコア数違いの比較ができる
仮想環境 / 物理環境差が見える
「思ったより重い」が事前に分かる
設計判断は、後工程で回収される

まとめ

asyncio を使わなかったのは「遅れている」からではない
目的に合わなかった
edrsim は CPU-bound を前提に設計されている
並行処理は「技術選定」ではなく「負荷設計」

次回予告

edrsim は Python 初級・中級・上級のどこか？

次は、

PCEP / PCAP / PCPP
コード量ではなく「設計レベル」

という視点で、edrsim を分解します。

「Python が書ける」と「作れる」の境界線の話です。

ツール公開先

Github にコードを公開しています。

最後に

asyncio を使わなかった理由は、
技術的な優劣ではありません。

「このツールは、何のために存在するのか」

それに正直に向き合った結果です。