同時実行と並列処理

Scrapeless Scraping Browser は、JavaScript でレンダリングされた公開ページの管理されたブラウザセッションを提供しますが、アプリケーションは、スケジュールするジョブの数と同時に実行できるジョブの数を制御します。

TL;DR

同時実行は重複する作業を整理します。 タスクは、1 つのプロセッサがそれらをインターリーブしても、同じ期間内に進行できます。
並列処理は、作業を同時に実行します。 複数のコア、プロセッサ、またはワーカーが同時に計算を実行します。
I/O 待機は通常、同時実行の恩恵を受けます。 スケジューラは、ネットワークまたはストレージ操作が保留中の間に別のタスクを進めることができます。
CPU 集中型の作業には、実際のコンピューティングの並列処理が必要です。 より多くのスケジュールされたタスクは、それ自体でより多くの算術能力を生み出すことはありません。
両方のモデルには制限と所有権が必要です。 キュー、キャンセル、共有状態、サービス制限は、スループットが安定しているかどうかを決定します。

同時実行と並列処理の定義

同時実行は、生存期間が重なり合う複数のタスクを構成する方法であり、並列処理は、2 つ以上の計算が同時に実行されていることを意味します。同時実行プログラムは、タスクをインターリーブすることで 1 つのコアで実行できます。並列プログラムは、同時に動作できる実行リソースを必要とします。

その区別は、構造と実行に関するものです。同時実行は、独立して進行するアクティビティにワークロードを分解し、それらがどのように調整されるかを定義します。並列処理は、複数の実行ユニットに作業をマッピングして、経過したコンピューティング時間を短縮したり、スループットを増加させたりします。ここで使用される主要な用語は、同時実行と並列処理の Go の説明に従い、概念に技術的な境界を与え、マーケティングラベルとして扱わないようにします。

便利な比較は、各モデルが整理する作業、同時に実行できるリソース、待機、調整、またはスキーマの決定が発生する場所を尋ねます。同時実行はスレッドの同義語ではなく、並列処理はプログラムが複数のワーカーを作成するたびに保証されるわけではありません。イベントループ、プロセス、アクセラレーター、ベクトル命令、および分散ノードはすべて、異なる組み合わせで参加できます。その境界を見えるように保つことで、アーキテクチャ図が他のレイヤーに属するコンポーネントに保証を割り当てるのを防ぎます。

重複が同時作業になる方法

ワークロードは、スケジューリング、待機、実行、調整を通じてリクエストから結果に移行します。同じプログラムは、タスクレベルで同時実行され、選択された段階でのみ並列になります。

アプリケーションは、明示的な入力、出力、およびキャンセルルールを持つタスクにワークロードを分割します。
スケジューラは、準備ができているタスクのうち、どれがスレッド、プロセス、イベントループ、またはリモートワーカーの時間を受け取るかを決定します。
1 つのタスクが I/O を待っているとき、同時実行設計により、別の準備ができたタスクが進むことができ、実行リソースをアイドルのままにすることはありません。
複数の実行リソースが同時に準備ができたタスクを実行する場合、そのワークロードの部分は並列です。
システムは結果を結合し、失敗を伝播し、最終出力を公開する前に、順序付けや一貫性のルールを適用します。

イベントループは、CPU 命令を同時に実行することなく、数千の待機操作を調整できます。プロセスプールは、コア全体で独立した CPU 作業を実行できますが、シリアル化と調整には依然としてコストがかかります。ハイブリッドサービスは、計算負荷の高い変換のために、境界のあるプールの周りで非同期 I/O を使用することがよくあります。この動作は、 Python の asyncio タスクのドキュメントにもっと詳しく記載されています。ソースは、緩い類推に依存せず、実際の実行またはデータモデルを説明するため、有用です。

同時実行と並列処理の概要

次元	同時実行	並列処理
主な目的	重複活動を調整する	同時に作業を行う
単一コアの可能性	はい、インターリーブを通じて	同時の CPU 実行にはいいえ
典型的な強み	I/O 待機と応答サービス	独立した CPU 集中型計算
一般的なコスト	調整、キャンセル、共有状態のバグ	パーティショニング、転送、同期
測定の証拠	重複するタスクの寿命	同時リソース使用

表は目標をメカニズムから分けます。スレッドはどちらの列もサポートする場合があり、プロセスは両方をサポートすることが多いです。非同期関数は通常、同時実行性を重視します。正しいラベルは、作業を開始するために使用されるAPI名ではなく、観察された実行に従います。

各モデルに有利なワークロード

多くのネットワークリクエスト

クライアントがホストごとの制限とメモリ制約を尊重する限り、同時実行性は進行を維持しつつソケットが待機します。

インタラクティブサーバー

同時にタスクを処理することで、一つの遅いリクエストが無関係なクライアントをブロックするのを防ぎ、キャンセルが呼び出し元にスコープされるようにします。

画像または数値変換

並列処理ワーカーは、転送と設定コストが節約された計算時間よりも小さい場合、独立したCPU集中的なユニットを分割できます。

ウェブデータパイプライン

コレクションはしばしばI/Oが重いですが、解析、圧縮、結合、モデル準備は別の並列ステージに値するかもしれません。

これらのユースケースは選択ルールを共有しています：名前がより先進的に聞こえるからではなく、実行と所有モデルがワークロードに一致するため、同時実行性と並列処理を選択します。小さなワークロードは、オーケストレーションにコストがかかるため、単純な逐次ループで最も速くなる場合があります。ワーカーを追加する前に、キュー時間、サービス時間、エンドツーエンド遅延を測定してください。

同時実行性と並列処理モデルの選択

選択は支配的な待機から始まります。ネットワークバウンドの作業、ストレージバウンドの作業、メモリのプレッシャー、CPUの飽和は、ユーザー側の症状が同じ遅い完了時間であっても異なる反応を必要とします。

ボトルネックを分類します。 タスクが待っている、実行している、データを転送している、調整している間にどれだけの時間を費やしているかを記録します。
制限された受け入れ。 トラフィックバーストが一時的な圧力をプロセス全体のメモリ枯渇に変えることができないように、キューを有限に保ちます。
共有ミューテーションを最小限にします。 不変の入力と隔離された出力は、レースを減らし、失敗したタスクを新しいジョブとして再生しやすくします。
キャンセルを保持します。 もはや結果が必要ない呼び出し元は、キューにある作業を停止し、下流の能力を解放できるべきです。
全パスをベンチマークします。 1つの関数だけの時間を測るのではなく、シリアル化、開始、コレクション、解析、結果の組み立てを含めます。

CPUバウンドのPythonプログラムの場合、プロセスまたは隔離されたインタープリタは、通常のスレッドではできない真のマルチコア実行を提供できます。ネットワークが重いプログラムの場合、非同期タスクまたはスレッドは、各ステップを並列計算に変えずに利用率を改善できます。関連する主要なリファレンスは Pythonマルチプロセッシングドキュメント, それにより、その選択の背後にあるストレージ、実行、または相互運用性の仮定が明確になります。

比較を歪める間違い

最も高価なエラーは、ワーカー数を普遍的なパフォーマンス制御として扱うことから生じます。各追加タスクは、障害処理中にデスクリプタ、メモリ、キューのスペース、リモートの能力、注意を消費します。

すべての重複並列性の呼び出し。 1つの実行リソースでのインターリーブ作業は同時ではありませんが、同時です。
測定前にワーカーを追加する。 より多くのワーカーは、完了時間を改善することなく競合や下流の制限を増幅できます。
イベントループ内でのブロッキング。 長い同期操作は、同じループを共有する無関係なコルーチンをフリーズさせることがあります。
可変状態をカジュアルに共有する。 ロックは、すべてのアクセスが同じ所有権プロトコルに従う場合にのみ、不変条件を保護します。
結果の順序を無視する。 完了順序、入力順序、ビジネス順序は、定義されなければならない別々の契約です。

失敗は、最も責任のあるレイヤーに遡るべきです。CPUがアイドル状態のままリクエストが待機している場合はI/Oの同時実行性を調査し、CPUが飽和している場合は計算と分割を調査し、下流の遅延が上昇する間にキューが増加する場合は受け入れを削減するかバックプレッシャーを追加します。この実践により、より多くの容量を追加するという漠然とした指示の代わりに、有用な是正措置が生まれます。

公共ウェブデータパイプラインの同時実行性

公共ウェブパイプラインは、しばしば両方のモデルを組み合わせます。URLの発見とページの収集は、その生涯の多くがネットワーク待機であるため、重複します。レコードが独立している場合、解析と正規化は並行して実行されることがあります。ストレージのコミットは、順序やトランザクションの保証を保護するために再びシリアル化されることがあります。

公共ウェブ入力の場合、取得レイヤーは、要求されたURL、最終URL、収集時間、応答モード、および下流処理が開始される前にコンテンツチェックを記録する必要があります。各収集したレコードは、完了順序が静かにデータ順序に変わらないように、安定した識別子を持つべきです。その引き渡しにより、アナリストは再現可能なソースレコードを持ち、収集の動作を解釈から分離します。

Scrapelessは、冒頭の文で説明された管理されたウェブコレクションステップを処理します。アプリケーションは、ソースの承認、フィールド定義、ワークロードの境界、保持、アクセス制御、および検証を引き続き所有します。収集サービスはレンダリングされたページコンテンツを提供できますが、オーケストレーションレイヤーは受け入れ率、アクティブセッションの最大数、ホストごとの公平性、時間予算、およびキャンセルを決定します。これらのレイヤー間の明確な契約は、後の変更をテストしやすくします。

パイプラインは、ユースケースが監査可能性を必要とする際に、生の証拠とキュレーションされた出力の両方を保持するべきです。生素材は、パーサーやスキーマが変更された後の再処理をサポートします。キュレーションされたテーブルは安定した分析をサポートします。コレクションと変換の間の制限されたキューは、短い変動を吸収し、メモリ成長が制御メカニズムになる前に持続的な過負荷を警告します。2つの表現は異なる運用上の質問に応え、重複と間違われるべきではありません。

アーキテクチャレビューチェックリスト

デザインレビュー中に以下の質問を使用してください。書面での回答は、想定されたデフォルトよりも価値があります。これは、チームが同時実行性と並列性について異なる意見を持っている場所を明らかにするからです。

どのタスクが順序や一貫性のルールを違反することなく重複できますか？
どのステージがI/Oを待っていて、どのステージがCPUを消費していますか？
各境界でキューに入ったジョブとアクティブジョブの最大数は何ですか？
キャンセルはどのように呼び出し元からキューに入った作業や下流の操作に移動しますか？
どのデータが共有され、どのコンポーネントがすべての可変値を所有していますか？
ワークロードは入力順序、完了順序、または順序を必要としますか？
どのメトリックが有用な重複や同時実行を証明しますか？
下流のサービスがプロデューサーよりも遅くなった場合、何が起こりますか？

デザインは同時実行が制限され、並列ステージが調整コストを回収するための十分な独立作業を持ち、過負荷が意図的な応答を生成する場合に準備が整います。ワークロードの形状、データ量、サービス制限、または消費者の期待が変わった後に回答を再確認してください。探索的バッチに対して合理的であったアーキテクチャは、継続的な生産経路に対しては不適切な場合があります。

結論

同時実行性と並列性は関連していますが、異なる問題を解決します。同時実行性は重複する活動を構造化し、待機中にシステムを応答可能に保ちます。並列性は同時実行を使用して適切な作業を加速します。多くの生産パイプラインには、制限されたキューと明示的な所有権で結ばれた両方が必要です。実用的な決定は、時間がどこで費やされているかを測定し、それぞれのステージに実際のボトルネックに一致する実行モデルを割り当てることから来ます。

制御されたコレクションパイプラインの構築を準備していますか？

レンダリングされた公共ウェブ入力を、明示的なタスク制限、証拠チェック、下流のハンドオフを持つオーケストレーションレイヤーに接続します。

今日サインアップして、 $5の無料クレジットを取得 — クレジットカードは不要です.

$5クレジットを取得 →

FAQ

同時実行なしで並列性は存在できますか？

はい。単一プロセッサは、インタリーブによって複数のタスクを重ね合わせることができ、そのライフタイムを重複させることができますが、特定の瞬間に実行されるのは1つのタスクだけです。イベントループは、I/O集約型作業にこのモデルを一般的に使用します。アプリケーションは応答性を向上させ、待機時間を効果的に使用できますが、同時にCPU実行を得ることはありません。

並列設計なしで並列性は存在できますか？

はい、限られた意味で。ランタイムまたはプロセッサは、アプリケーションが単純な逐次インターフェースを提供している場合でも、内部的に単一の計算を並列化することができます。ベクトル命令や並列データベースオペレータが例です。アプリケーションレベルの同時実行性は、いくつかの独立したアクティビティを時間をかけて調整する必要があるときにも有用です。

スレッドは同時か並列か？

スレッドは同時実行、並列性、またはその両方をサポートできます。答えは、ランタイム、プロセッサ、ワークロード、スケジューラによって異なります。いくつかのスレッドが1つのコアでインタリーブされるか、別のコアで同時に実行される別々のスレッドが存在する場合があります。スレッドを作成するだけでは、有用な並列作業が発生したことを証明することはできません。

ウェブリクエストにはどのモデルがより良いですか？

同時実行は通常、ウェブリクエストの最初のツールです。ネットワーク操作は待機に substantialな時間を費やすためです。デザインは、ホストポリシー、メモリ、ファイル記述子、および下流の処理能力によって制限されるべきです。並列CPUワーカーは、後で解析、圧縮、または分析変換を手伝うかもしれません。

チームは同時実行の変更をどのようにテストすべきですか？

代表的なワークロードでテストし、スループット、キュー時間、サービス時間、エラーカテゴリ、メモリ、CPU使用、下流のレイテンシを記録します。同じ入力でパイプライン全体を比較します。変更は、対象メトリックを改善し、順序、公平性、またはリソース制限を違反しない場合にのみ有用です。