はじめに（この記事の役割）
この記事は、
- 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 を使わなかった理由は、
技術的な優劣ではありません。
「このツールは、何のために存在するのか」
それに正直に向き合った結果です。