リクエスト処理について知りたいが、尋ねるのが恥ずかしかったすべて

ネットワークサービスとは何ですか？ これは、ネットワークを介して着信要求を受け入れ、それらを処理し、おそらく応答を返すプログラムです。

ネットワークサービスが互いに異なる多くの側面があります。 この記事では、着信要求を処理する方法に焦点を当てます。

要求処理方法を選択すると、広範囲に及ぶ影響があります。 100,000の同時接続に耐えるチャットサービスを作成する方法 緩やかに構造化されたファイルのストリームからデータを抽出するためにどのアプローチを取るべきですか？ 間違った選択は時間とエネルギーの無駄につながります。

この記事では、プロセス/スレッドのプール、イベント指向処理、ハーフ同期/ハーフ非同期パターンなど、多くのアプローチについて説明しています。 多数の例が示され、アプローチの長所と短所、それらの機能とアプリケーションが考慮されています。

はじめに

クエリ処理メソッドのトピックは新しいものではありません。たとえば、 one 、 twoを参照してください。 ただし、ほとんどの記事では部分的にしか考慮されていません。 この記事は、ギャップを埋め、問題の一貫したプレゼンテーションを提供することを目的としています。

次のアプローチが検討されます。

• 順次処理
• 要求プロセス
• リクエストストリーム
• プロセス/スレッドプール
• イベント指向処理（リアクターパターン）
• 半同期/半非同期パターン
• コンベア処理

要求を処理するサービスは、必ずしもネットワークサービスではないことに注意してください。 これは、データベースまたはタスクキューから新しいタスクを受け取るサービスです。 この記事では、ネットワークサービスを示していますが、検討中のアプローチの範囲が広いことを理解する必要があります。

TL; DR

記事の最後には、各アプローチの簡単な説明が記載されたリストがあります。

順次処理

アプリケーションは、単一プロセスの単一スレッドで構成されます。 すべてのリクエストは順番にのみ処理されます。 並列性はありません。 複数の要求が同時にサービスに到達すると、そのうちの1つが処理され、残りはキューに入れられます。

このアプローチの利点は、実装が簡単なことです。 ロックやリソースの競合はありません。 明らかなマイナスは、多数の顧客に対応できないことです。

リクエストプロセス

アプリケーションは、着信リクエストとワークフローを受け入れるコアプロセスで構成されます。 メインプロセスは、新しいリクエストごとに、リクエストを処理するワークフローを作成します。 リクエスト数によるスケーリングは簡単です。各リクエストは独自のプロセスを取得します。

このアーキテクチャには複雑なものはありませんが、 問題 制限 ：

• プロセスは多くのリソースを消費します。
  
  PostgreSQL RDBMSへの10,000の同時接続を作成してみて、結果を確認してください。
• プロセスには共有メモリがありません（デフォルト）。 共有データまたは共有キャッシュにアクセスする必要がある場合は、共有メモリをマップする（Linux mmap、munmapを呼び出す）か、外部ストレージを使用する（memcahed、redis）必要があります

これらの問題は決して止まりません。 以下は、それらがPostgeSQL RDBMSで管理される方法を示します。

このアーキテクチャの長所 ：

• プロセスの1つが落ちても、他のプロセスには影響しません。 たとえば、まれに処理エラーが発生してもアプリケーション全体がドロップされることはなく、処理されたリクエストのみが影響を受けます。
• オペレーティングシステムレベルでのアクセス権の差別化。 プロセスはOSの本質であるため、OSリソースへのアクセス権を区切るための標準メカニズムを使用できます。
• 実行中のプロセスをその場で変更できます。 たとえば、リクエストの処理に別のスクリプトを使用し、処理アルゴリズムを置き換えるには、スクリプトを変更するだけで十分です。 以下に例を検討します。
• 効率的に使用されるマルチコアマシン

例：

• PostgreSQL RDBMSは、新しい接続ごとに新しいプロセスを作成します。 共有メモリは、一般的なデータを処理するために使用されます。 PostgreSQLのプロセスがリソースを大量に消費するという問題は、さまざまな方法で解決できます。 顧客が少ない場合（アナリスト専用のスタンド）、そのような問題はありません。 データベースにアクセスする単一のアプリケーションがある場合、アプリケーションレベルでデータベース接続プールを作成できます。 多くのアプリケーションがある場合は、pgbouncerを使用できます
• sshdは、ポート22で着信要求をリッスンし、接続ごとに分岐します。 各ssh接続は、ユーザーコマンドを順番に受信して実行するsshdデーモンの分岐です。 このアーキテクチャのおかげで、OS自体のリソースがアクセス権を区別するために使用されます
• 私たち自身の実践からの例。 メタデータを取得する必要がある非構造化ファイルのストリームがあります。 メインサービスプロセスは、ハンドラープロセス間でファイルを配布します。 各ハンドラープロセスは、パラメーターとしてファイルパスを取るスクリプトです。 ファイル処理は別のプロセスで行われるため、処理エラーが原因でサービス全体がクラッシュすることはありません。 処理アルゴリズムを更新するには、サービスを停止せずに処理スクリプトを変更するだけで十分です。

一般に、このアプローチにはその範囲を決定する利点があると言わなければなりませんが、スケーリングの可能性は非常に限られています。

リクエストストリーム

このアプローチは、前のアプローチとよく似ています。 違いは、プロセスの代わりにスレッドが使用されることです。 これにより、すぐに共有メモリを使用できます。 ただし、以前のアプローチの他の利点は使用できませんが、リソースの消費量も高くなります。

長所：

• すぐに使える共有メモリ
• 実装のしやすさ
• マルチコアCPUの効率的な使用

短所：

• ストリームは多くのリソースを消費します。 UNIXのようなオペレーティングシステムでは、スレッドはプロセスとほぼ同じ数のリソースを消費します

使用例はMySQLです。 ただし、MySQLは混合アプローチを使用しているため、この例については次のセクションで説明します。

プロセス/スレッドプール

ストリーム（プロセス）は、高価で長くなります。 リソースを無駄にしないために、同じスレッドを繰り返し使用できます。 さらにスレッドの最大数を制限して、スレッド（プロセス）のプールを取得します。 これで、メインスレッドは着信要求を受け入れ、それらをキューに入れます。 ワークフローは、キューからリクエストを取得して処理します。 このアプローチは、リクエストのシーケンシャル処理の自然なスケーリングとして採用できます。各ワーカースレッドはフローをシーケンシャルにしか処理できず、それらをプールすることでリクエストを並行して処理できます。 各ストリームが1000 rpsを処理できる場合、5ストリームが5000 rpsに近い負荷を処理します（共有リソースの競合は最小限に抑えられます）。

プールは、サービスの開始時に事前に作成することも、徐々に形成することもできます。 スレッドプールの使用は、より一般的です 共有メモリを適用できます。

スレッドプールのサイズを制限する必要はありません。 サービスはプールの空きスレッドを使用でき、存在しない場合は新しいスレッドを作成します。 要求を処理した後、スレッドはプールに参加し、次の要求を待ちます。 このオプションは、スレッドオンリクエストアプローチとスレッドプールの組み合わせです。 以下に例を示します。

長所：

• 多くのCPUコアの使用
• スレッド/プロセス作成のコスト削減

短所：

• 同時クライアント数の限られたスケーラビリティ。 プールを使用すると、追加のリソースコストなしで同じスレッドを複数回再利用できますが、スレッド/プロセスによって消費される大量のリソースの根本的な問題は解決しません。 このアプローチを使用して100,000の同時接続に耐えることができるチャットサービスの作成は失敗します。
• スケーラビリティは共有リソースによって制限されます。たとえば、スレッドがセマフォ/ミューテックスを使用してアクセスを調整することにより共有メモリを使用する場合です。 これは、共有リソースを使用するすべてのアプローチの制限です。

例：

1. uWSGIおよびnginxで実行されるPythonアプリケーション。 メインのuWSGIプロセスは、nginxから着信リクエストを受信し、リクエストを処理するインタープリターのPythonプロセスにそれらを配信します。 アプリケーションは、uWSGI互換フレームワーク（Django、Flaskなど）で作成できます。
2. MySQLはスレッドプールを使用します。新しい接続はそれぞれ、プールの空きスレッドの1つによって処理されます。 空きスレッドがない場合、MySQLは新しいスレッドを作成します。 空きスレッドのプールのサイズとスレッド（接続）の最大数は、設定によって制限されます。

おそらくこれは、最も一般的ではないにしても、ネットワークサービスを構築するための最も一般的なアプローチの1つです。 これにより、大きなrpに到達して、適切にスケーリングできます。 このアプローチの主な制限は、同時に処理されるネットワーク接続の数です。 実際、このアプローチは、リクエストが短いか、顧客が少ない場合にのみ有効です。

イベント指向の処理（リアクターパターン）

同期と非同期の2つのパラダイムは、互いに永遠の競争相手です。 これまで、同期アプローチのみが議論されてきましたが、非同期アプローチを無視するのは間違っています。 イベント指向またはリアクティブなリクエスト処理は、各IO操作が非同期で実行され、操作の最後にハンドラーが呼び出されるアプローチです。 原則として、各リクエストの処理は、多くの非同期呼び出しとそれに続くハンドラーの実行で構成されます。 いつでも、シングルスレッドアプリケーションは1つのハンドラーのコードのみを実行しますが、さまざまな要求のハンドラーの実行は交互に行われるため、多数の並列要求を同時に（疑似並列）処理できます。

このアプローチの詳細な説明は、この記事の範囲外です。 より詳しく見るには、 Reactor（Reactor）をお勧めしますNodeJS速度の秘密は何ですか？ 、 NGINXの内部 。 ここでは、このアプローチの長所と短所を考慮することに限定しています。

長所：

• rpsと同時接続数による効果的なスケーリング。 ほとんどの接続がI / Oの完了を待機している場合、リアクティブサービスは多数の接続（数万）を同時に処理できます。

短所：

• 開発の複雑さ。 非同期スタイルでのプログラミングは、同期プログラミングよりも困難です。 要求処理のロジックはより複雑であり、デバッグも同期コードよりも困難です。
• サービス全体のブロックにつながるエラー。 言語またはランタイムが元々非同期処理用に設計されていない場合、単一の同期操作がサービス全体をブロックする可能性があり、スケーリングの可能性がなくなります。
• CPUコア間でのスケーリングが困難。 このアプローチでは、単一プロセスの単一スレッドを想定しているため、複数のCPUコアを同時に使用することはできません。 この制限を回避する方法があることに注意してください。
• 前の段落の結果：このアプローチは、CPUを必要とする要求に対してうまくスケーリングしません。 このアプローチのrpの数は、各要求の処理に必要なCPU操作の数に反比例します。 CPU要求を要求すると、このアプローチの利点が無効になります。

例：

1. Node.jsは、すぐに使用できるリアクターパターンを使用します。 詳細については、「NodeJS速度の秘密とは」を参照してください。
2. nginx：nginxのワーカープロセスは、リアクタパターンを使用してリクエストを並列処理します。 詳細については、Inside NGINXを参照してください。
3. OSツール（Linuxではepoll、WindowsではIOCP、FreeBSDではkqueue）を直接使用するか、フレームワーク（libev、libevent、libuvなど）を使用するC / C ++プログラム。

半同期/半非同期

この名前は、書籍「 POSA：パターンと並行オブジェクトおよびネットワークオブジェクト」から取られています。 オリジナルでは、このパターンは非常に広く解釈されますが、この記事の目的のために、このパターンを多少狭く理解します。 ハーフ同期/ハーフ非同期は、各リクエストに軽量の制御フロー（グリーンフロー）を使用するリクエスト処理アプローチです。 プログラムはオペレーティングシステムレベルの1つまたは複数のスレッドで構成されますが、プログラム実行システムはグリーンスレッドをサポートします。これはOSが認識せず、制御できません。

検討をより具体的にするためのいくつかの例 ：

1. Go言語のサービス。 Go言語は、実行の多くの軽量スレッド-goroutineをサポートしています。 プログラムは1つ以上のOSスレッドを使用しますが、プログラマーはゴルーチンで動作します。ゴルーチンは、マルチコアCPUを使用するためにOSスレッド間で透過的に分散されます
2. geventライブラリを使用したPythonサービス。 geventライブラリにより、プログラマはライブラリレベルでグリーンスレッドを使用できます。 プログラム全体が単一のOSスレッドで実行されます。

本質的に、このアプローチは、非同期アプローチの高いパフォーマンスと同期コードのプログラミングのシンプルさを組み合わせるように設計されています。

このアプローチを使用すると、同期の錯覚にもかかわらず、プログラムは非同期に動作します。プログラム実行システムはイベントループを制御し、各「同期」操作は実際には非同期になります。 このような操作が呼び出されると、実行システムはOSツールを使用して非同期操作を呼び出し、操作の完了のハンドラーを登録します。 非同期操作が完了すると、実行システムは以前に登録されたハンドラーを呼び出し、「同期」操作の呼び出しポイントでプログラムを実行し続けます。

その結果、半同期/半非同期アプローチには、非同期アプローチのいくつかの利点と欠点の両方が含まれます。 この記事の量では、このアプローチを詳細に検討することはできません。 興味のある方は、本POSA：パターン同時およびネットワークオブジェクトの同じ名前の章を読むことをお勧めします。

ハーフシンク/ハーフ非同期のアプローチ自体は、新しい「グリーンストリーム」エンティティ、つまりプログラムまたはライブラリ実行システムのレベルでの軽量の制御フローを導入します。 緑色のスレッドをどうするかは、プログラマーの選択です。 グリーンスレッドのプールを使用でき、新しい要求ごとに新しいグリーンスレッドを作成できます。 OSスレッド/プロセスと比較した違いは、グリーンスレッドの方がはるかに安価であるということです。つまり、消費するRAMがはるかに少なく、作成がはるかに高速です。 これにより、Go言語で数十万など、膨大な数のグリーンスレッドを作成できます。 そのような膨大な量は、グリーンフローオンリクエストアプローチの使用を正当化します。

長所：

• rpsと同時接続数で適切にスケーリング
• 非同期アプローチに比べてコードの記述とデバッグが簡単です

短所：

• 操作の実行は実際には非同期であるため、単一の同期操作がプロセス全体をブロックすると、プログラミングエラーが発生する可能性があります。 これは、このアプローチがPythonなどのライブラリを使用して実装されている言語で特に顕著です。
• プログラムの不透明度。 スレッドまたはOSプロセスを使用する場合、プログラム実行アルゴリズムは明確です。各スレッド/プロセスは、コードに記述されている順序で操作を実行します。 ハーフシンク/ハーフ非同期のアプローチを使用すると、コード内で順番に記述された操作は、同時リクエストを処理する操作と予測不能に交替できます。
• リアルタイムシステムには適していません。 リクエストの非同期処理は、個々のリクエストの処理時間の保証の提供を非常に複雑にします。 これは前の段落の結果です。

実装に応じて、このアプローチはCPUコア全体で適切に拡張されます（Golang）またはまったく拡張されません（Python）。

このアプローチは、非同期と同様に、多数の同時接続を処理できます。 ただし、このアプローチを使用してサービスをプログラミングする方が簡単です。 コードは同期スタイルで記述されます。

コンベア処理

名前が示すように、このアプローチでは、リクエストはパイプラインによって処理されます。 処理プロセスは、チェーンに配置された複数のOSスレッドで構成されます。 各スレッドはチェーン内のリンクであり、リクエストの処理に必要な操作の特定のサブセットを実行します。 各リクエストはチェーン内のすべてのリンクを順番に通過し、各瞬間に異なるリンクが異なるリクエストを処理します。

長所：

• このアプローチは、rpsでうまくスケーリングします。 チェーン内のリンクが多いほど、1秒あたりに処理されるリクエストが多くなります。
• 複数のスレッドを使用すると、CPUコア全体で適切に拡張できます。

短所：

• すべてのクエリカテゴリがこのアプローチに適しているわけではありません。 たとえば、このアプローチを使用して長いポーリングを編成することは難しく、不便です。
• 実装とデバッグの複雑さ。 生産性が高くなるようにシーケンシャル処理を破ることは困難な場合があります。 各要求が複数の並列スレッドで順次処理されるプログラムのデバッグは、順次処理よりも困難です。

例：

1. コンベア処理の興味深い例は、レポートhighload 2018 The Moscow Evolution of the Trading and Clearing System of Moscow Exchangeに記載されています

パイプラインは広く使用されていますが、ほとんどの場合、リンクは、メッセージキューやデータベースなどを介してメッセージを交換する独立したプロセスの個々のコンポーネントです。

まとめ

検討されるアプローチの簡単な要約：

• 同期処理。
  
  シンプルなアプローチですが、スケーラビリティと同時接続数の両方のスケーラビリティが非常に制限されています。 複数のCPUコアを同時に使用することはできません。
• リクエストごとの新しいプロセス。
  
  プロセス作成の高コスト。 このアプローチでは、同時接続の数による効率的なスケーリングはできませんが、共有メモリを使用する場合は困難です。 同時接続数が少ない長期のクエリ実行に適しています。 一部のアプリケーションに役立つプロパティがあります（信頼性の向上、OSレベルでのアクセス制御）。
• 各リクエストの新しいストリーム。
  
  問題は前のアプローチと同じですが、共有メモリを簡単に使用できます。 以前のアプローチと同様のスコープを持ちますが、いくつかの有用なプロパティがありません。
• プロセス/スレッドプール。
  
  前の2つのアプローチと比較して、プロセス/スレッドを作成するオーバーヘッドを回避します。 ネットワークサービスを構築するために最も一般的に使用されるアプローチ。 rpと使用されるコアの数の点でうまくスケーリングします。 多数の短いリクエストを処理するのに適しています。 同時接続の数によるスケーリングが不十分です。
• イベント指向の処理（リアクターパターン）。
  
  rpsと同時接続の数で適切にスケーリングします。 非同期プログラミングスタイルのため、使用するのがより難しく、浮動エラーをキャッチするのが難しい場合があります。 使用するCPUコアの数によるスケーリングは困難です
• 半分の同期/半分の非同期。
  
  rpsと同時接続の数で適切にスケーリングします。 実装に応じて、CPUのコアで適切にスケーリングされます（Golang）またはまったくスケーリングされません（Python）。 要求に対するプロセス（ストリーム）アプローチよりも、要求あたりのリソース消費が大幅に少なくなります。 これは、リアクタパターンとは異なり、同期スタイルでプログラムされますが、リアクタパターンと同じ浮動エラーが発生する可能性があります。
• コンベア処理。
  
  高いパフォーマンスを実現できますが、実装が困難です。 すべてのタイプの要求には適していません（たとえば、長いポーリングを行うのは困難です）。

上記のリストは完全なものではありませんが、クエリ処理への基本的なアプローチが含まれています。

読者に目を向けます。どのようなアプローチを使用していますか？ 自分の経験から学んだ、賛否両論、特に彼らの仕事は何ですか？

参照資料

1. 関連記事：
   
   
   • もう一度ネットワークデーモンのアーキテクチャについて
   • 同時実行性対マルチスレッド化対非同期プログラミング：明確化
2. イベント駆動型アプローチ：
   
   
   • 原子炉
   • NodeJS速度の秘密は何ですか？
   • Nginxの内部
3. フローとイベントに基づくアプローチの比較：
   
   
   • Apache vs Nginx：実用的な外観
   • Node.jsとPHPを例として使用した非同期アーキテクチャとマルチスレッドアーキテクチャの違い
4. 半同期/半非同期：
   
   
   • 半同期/半非同期（Javaデザインパターン）
   • POSA：並行オブジェクトおよびネットワークオブジェクトのパターン
5. グリーンストリーム：
   
   
   • グリーンスレッド（Wikipedia）
   • グリーン対ネイティブスレッド
6. コンベア処理：
   
   
   • モスクワ取引所の取引および清算システムのアーキテクチャの進化