現代の分散システムや高負荷なWebアプリケーションにおいて、「並行性（Concurrency）」と「並列性（Parallelism）」の混同は、致命的なパフォーマンスボトルネックを招く原因となります。これらは似て非なる概念であり、解決しようとするエンジニアリング上の課題が根本的に異なります。リソース効率を最大化するのか、それとも計算速度を最大化するのか。本稿では、OSレベルのスケジューリング、ハードウェアの活用、そして言語ごとの実装モデル（Go, Python, Rust）を比較し、アーキテクチャ設計における適切なトレードオフの判断基準を提示します。
1. 並行性 (Concurrency)：構造と構成の管理
並行性とは、システムが複数のタスクを「重複した時間区間」で進行させるための論理的な構造です。これは必ずしも物理的な同時実行を意味しません。シングルコアCPU環境下であっても、OSのタスクスケジューラが高速にコンテキストスイッチ（Context Switch）を行うことで並行性は成立します。
I/Oバウンドな処理（DBクエリ待ち、ネットワークリクエスト待ち）において、CPUサイクルを無駄にしないために並行性は不可欠です。プロセスがI/O待ち状態（Blocked）に入った際、即座に計算リソースを他の実行可能なスレッドへ譲渡することで、システム全体のスループット（Throughput）を維持します。
2. 並列性 (Parallelism)：物理的な同時実行
並列性は、物理的に複数の計算ユニット（マルチコアCPU、GPU、分散クラスタ）が存在し、タスクが「全く同じ瞬間」に実行される状態を指します。並行性が「構成（Structure）」の問題であるのに対し、並列性は「実行（Execution）」の問題です。
計算集約型（CPU-bound）のタスク、例えば行列演算、画像処理、暗号化処理などは、並行化によるコンテキストスイッチよりも、並列化による純粋な演算能力の向上が効果的です。しかし、並列化の効果は無限ではなく、アムダールの法則（Amdahl's Law）によって制限されます。
| 特性 | 並行性 (Concurrency) | 並列性 (Parallelism) |
|---|---|---|
| 焦点 | 構造、非同期、割り込み処理 | ハードウェア、スループット、物理実行 |
| コア数 | シングルコアでも可能 | マルチコア必須 |
| 目的 | レイテンシ隠蔽、I/O待機時間の活用 | 計算時間の短縮 |
| 制御主体 | スケジューラ、イベントループ | ハードウェアアーキテクチャ |
並行的なコード設計は、並列実行を可能にするための前提条件です。しかし、並行設計されたコードが必ずしも並列に動くとは限りません（例：PythonのGIL）。
3. 言語別実装モデルとトレードオフ
各プログラミング言語が採用している並行/並列モデルを理解することは、技術選定において極めて重要です。
Go: CSPモデル (Goroutines & Channels)
Goは「メモリ共有による通信」ではなく「通信によるメモリ共有」を推奨します。GoroutineはOSスレッドよりも軽量（数KBのスタック）で、GoランタイムがM:Nスケジューリング（M個のGoroutineをN個のOSスレッドにマッピング）を行います。これにより、数万単位の並行処理を低いオーバーヘッドで実現可能です。
// Worker Pool パターンの簡易実装例
// チャネルを利用してタスクを並行処理し、結果を集約する
func worker(id int, jobs <-chan int, results chan<- int) {
for j := range jobs {
// CPUバウンドな処理をシミュレート
results <- j * 2
}
}
func main() {
const numJobs = 100
jobs := make(chan int, numJobs)
results := make(chan int, numJobs)
// 3つのワーカー（並列実行の可能性あり）を起動
for w := 1; w <= 3; w++ {
go worker(w, jobs, results)
}
// タスク投入
for j := 1; j <= numJobs; j++ {
jobs <- j
}
close(jobs)
// 同期処理などは省略
}
Python: GIL (Global Interpreter Lock) の制約
CPython実装では、GILの存在により、同一プロセス内でPythonバイトコードを実行できるスレッドは常に1つに制限されます。したがって、threadingライブラリを使用しても、CPUバウンドな処理においては並列性の恩恵を受けられず、むしろコンテキストスイッチの分だけ性能が低下します。CPU並列化が必要な場合は、multiprocessingライブラリを使用してプロセスをフォークする必要があります。
asyncioやthreadingが有効ですが、数値計算にはnumpy（C拡張でGILを解放する）やマルチプロセス処理を選択してください。
Rust: 所有権システムによるデータ競合の防止
Rustは、コンパイル時に「所有権（Ownership）」と「借用（Borrowing）」の規則を厳格に適用します。これにより、データ競合（Data Race）を含む多くの並行性バグをコンパイルエラーとして検出します。「Fearless Concurrency（恐れることなき並行性）」を実現し、C++と同等のパフォーマンスを安全に提供します。
Rust Concurrency Guide4. 同期プリミティブとアンチパターン
並行処理における最大の課題は、共有リソースへのアクセス制御です。
- Race Condition (競合状態): 実行タイミングによって結果が変わるバグ。再現性が低くデバッグが困難です。
- Deadlock (デッドロック): 複数のプロセスが互いのリソース解放を待ち続け、停止する状態。リソースの取得順序を統一するなどの対策が必要です。
- Starvation (飢餓): 特定のプロセスの優先度が低く、永遠に実行されない状態。
結論：アーキテクチャとしての選択
並行性と並列性は、単に「速くする」ための魔法の杖ではありません。並行性はシステムの構造を整理し、I/Oレイテンシを隠蔽するための手段であり、並列性はハードウェアリソースを投入して計算能力をスケールさせるための手段です。開発者は、扱う問題が「CPUバウンド」なのか「I/Oバウンド」なのかを正確にプロファイリングし、言語特性（GILの有無、GCの影響、メモリ安全性）を考慮した上で、適切なアーキテクチャを選択する必要があります。
Post a Comment