API Gatewayの遅いリクエストは他のリクエストに影響を与えるか？

APIゲートウェイの領域で頻繁に議論される懸念の一つは、大量の同時リクエストを効率的に処理する能力です。具体的には、遅いリクエストがAPIゲートウェイ内の他の通常のリクエストの応答時間を大幅に増加させるかどうかという疑問が生じます。

その答えは、APISIXがこの点で優れており、遅いリクエストが他の通常のリクエストに悪影響を及ぼさないことを示しています。しかし、異なる言語やソフトウェアアーキテクチャに基づくAPIゲートウェイ製品では、性能がそれほど良くない場合があります。

さまざまなプログラミング言語は、並行ソフトウェアアーキテクチャに対する親和性が異なります。CやFortranなどの初期のプログラミング言語は、主に単一プロセッサシステム向けに設計されており、並行性に対するサポートが限られています。しかし、マルチプロセッサやマルチスレッド環境の登場により、JavaやPythonなどの新しい言語は、より強力な並行性と並列処理能力を備えています。Goのような言語は、並行性を念頭に設計されており、その並行モデルを言語機能と緊密に統合しています。プログラミング言語の並行性に対するサポートは、その言語が誕生した技術環境を反映するだけでなく、その意図されたアプリケーションシナリオも予測しています。

コルーチンとスレッド

数千の同時リクエストを想定すると、マルチスレッドやマルチプロセッシングアーキテクチャ（JavaやPythonで見られるような）を使用する場合、リクエストコンテキストを管理するために数千のスレッドやプロセスを割り当てる必要があります。コンピュータプログラミングに詳しい人なら、たとえ大多数のスレッドがアイドル状態であっても、オペレーティングシステムが数千のスレッドやプロセスを維持するためにハードウェアリソースを消費することを理解しています。しかし、コルーチン（APISIXやGolangで使用されるような）を使用すると、同時リクエストが増加しても追加のスレッドやプロセスは必要ありません。

コルーチン、スレッド、プロセスはすべてマルチタスクのアプローチを表しますが、以下のような重要な違いがあります：

スケジューリングメカニズム: スレッド/プロセスのスケジューリングはプリエンプティブであり、オペレーティングシステム（OS）によって管理されます。つまり、OSがいつ中断して別のスレッドやプロセスに切り替えるかを決定します。一方、コルーチンのスケジューリングは協調的であり、プログラマーや言語ライブラリによって明示的に駆動されます。コルーチンは、他のコルーチンに切り替えるために明示的に制御を放棄する必要があります。
オーバーヘッド: スレッド/プロセスはオペレーティングシステムレベルであるため、作成、切り替え、終了に高いリソースが必要です。一方、コルーチンはユーザースペースで動作するため、作成、切り替え、終了のオーバーヘッドが比較的低くなります。
データ共有と同期: スレッド間/プロセス間のデータ共有には、データ競合を防ぐためにミューテックスロック、リードライトロック、セマフォなどの複雑な同期操作が必要です。コルーチンは同じスレッド内にあるため、複雑な同期を必要とせずに直接グローバル変数を共有できます。

コルーチン、スレッド、プロセスの関係

APISIXの世界では、遅いリクエストは単に上流の応答を待つことであり、ネットワークイベントをリスニングするプロセスに限定され、追加のシステムリソースオーバーヘッドを発生させません。結論として、APISIXは、一部のリクエストの応答時間が長くなることで、他の通常のリクエストの応答時間を犠牲にすることはありません。