nginx がどのようにして高いパフォーマンスとスケーラビリティを実現するのかを深く理解する

NGINX の全体的なアーキテクチャは、連携して動作する一連のプロセスによって特徴付けられます。

メイン プロセス: 構成ファイルの読み取り、ソケットのバインド、子プロセスの作成/シグナル送信などの特権操作を実行します。

ワーカー プロセス: 接続要求の受信と処理、ディスクの読み取りと書き込み、上流サーバーとの通信を担当します。 NGINX がアクティブな場合、ワーカー プロセスのみがビジー状態になります。

キャッシュ ローダー プロセス: ディスク キャッシュをメモリにロードする役割を担います。このプロセスは起動時に実行され、その後終了します。

キャッシュ マネージャー プロセス: ディスク キャッシュ データが境界を越えないように整理する役割を担います。このプロセスは断続的に実行されます。

NGINX の高パフォーマンスとスケーラビリティの鍵は、次の 2 つの基本的な設計選択にあります。

コンテキスト切り替えによって発生するオーバーヘッドを削減するために、ワーカー プロセスの数を可能な限り制限します。ハードウェア リソースを効率的に利用するために、CPU コアごとに 1 つのワーカー プロセスを持つのがデフォルトであり、推奨される構成です。

ワーカー プロセスはシングル スレッドであり、複数の同時接続を非ブロッキング方式で処理します。

各 NGINX ワーカー プロセスは、非ブロッキング方式で実装されたステート マシンを通じて複数の接続要求を処理します。

各ワーカー プロセスは、リスニング ソケットや接続ソケットなど、複数のソケットを処理する必要があります。

リスニング ソケットが新しい要求を受信すると、クライアントとの通信を処理するために新しい接続ソケットが開かれます。

接続されたソケットにイベントが到着すると、ワーカー プロセスはすぐに応答を完了し、他のソケットで新しく受信したイベントの処理に進みます。

ギャレット氏は、NGINX の設計上の選択が他の Web サーバーとは根本的に異なると述べた。一般的な Web サーバーは、各接続を個別のスレッドに割り当てることを選択します。これにより、各接続を複数のステップの線形シーケンスと見なすことができるため、複数の接続の処理が非常に簡単になりますが、コンテキスト切り替えのオーバーヘッドが発生します。実際、ワーカー スレッドは、クライアントまたは他の上流サーバーを待機して、ほとんどの時間をブロックされた状態で過ごします。 I/O 操作を実行しようとする同時接続/スレッドの数が特定のしきい値を超えた場合、またはメモリが使い果たされた場合、コンテキスト切り替えのコストが明らかになります。

一方、NGINX は、実行する作業がない限り、ワーカー プロセスがネットワーク トラフィックをブロックしないように設計されています。さらに、それぞれの新しい接続は、ファイル記述子と少量のワーカー プロセス メモリのみを含む、非常に少ないリソースを消費します。

一般的に、システムを調整すると、NGINX の各作業プロセスは、数百または数千の同時 HTTP 接続を処理できるようになります。

NGINX の内部: パフォーマンスとスケーラビリティを考慮した設計

NGINX のパフォーマンスが優れている理由は、その設計にあります。多くの Web サーバーやアプリケーション サーバーは単純なスレッドベースまたはプロセスベースのアーキテクチャを使用していますが、NGINX は最新のハードウェア上で数万の同時接続をサポートできる洗練されたイベント駆動型アーキテクチャを採用しています。

Inside NGINX インフォグラフィックでは、プロセス アーキテクチャの高レベルの調査から、単一の NGINX プロセスが複数の接続を処理する方法の図まで、あらゆる内容を網羅しています。この記事では、これらの操作の詳細について説明します。

背景設定 - NGINX プロセス モデル

舞台設定？NGINXプロセスモデル

設計をより深く理解するには、NGINX の仕組みを理解する必要があります。 NGINX には、マスター プロセス (構成の読み取りやポートへのバインドなどの特権操作を実行する) と、一連のワーカー プロセスおよびヘルパー プロセスがあります。

このクアッドコア サーバーでは、NGINX マスター プロセスが 4 つのワーカー プロセスと 2 つのキャッシュ ヘルパー プロセスを作成し、ディスク上のコンテンツ キャッシュを管理します。

建築はなぜ重要なのでしょうか?

アーキテクチャはなぜ重要なのか?

あらゆる Unix アプリケーションの基本的な基盤はスレッドまたはプロセスです。 (Linux オペレーティング システムの観点から見ると、スレッドとプロセスは本質的に同じです。主な違いは、メモリを共有する程度です。) プロセス、つまりスレッドは、オペレーティング システムが CPU コアで実行するようにスケジュールできる独立した命令のセットです。ほとんどの複雑なアプリケーションでは、次の 2 つの理由により、複数のスレッドまたはプロセスを並行して実行します。

● より多くのコンピュータコアを同時に使用できます。

●スレッドとプロセスにより、並列操作の実装が容易になります（たとえば、複数の接続を同時に処理するなど）。

プロセスとスレッドの両方がリソースを消費します。これらはすべてメモリやその他の OS リソースを使用するため、コアの切り替え (コンテキスト スイッチと呼ばれる操作) が頻繁に発生します。最新のサーバーのほとんどは、数百の小さなアクティブなスレッドまたはプロセスを同時に処理できますが、メモリが使い果たされたり、I/O 負荷が高くなってコンテキストスイッチが大量に発生したりすると、サーバーのパフォーマンスが大幅に低下する可能性があります。

ネットワーク アプリケーションの場合、通常、各接続にスレッドまたはプロセスが割り当てられます。このアーキテクチャは実装が簡単ですが、アプリケーションが数万の同時接続を処理する必要がある場合、このアーキテクチャのスケーラビリティが問題になります。

NGINX はどのように機能しますか?

NGINX はどのように機能しますか?

NGINX は予測可能なプロセス モデルを使用して、利用可能なハードウェア リソースをスケジュールします。

1. メインプロセスは、構成の読み取りやポートのバインドなどの特権操作を実行し、子プロセス (以下の 3 種類) の作成も担当します。

2. キャッシュ ローダー プロセスは起動時に実行され、ディスクベースのキャッシュをメモリにロードしてから終了します。リソース要件が低くなるように慎重にスケジュールされます。

3. キャッシュ マネージャー プロセスは定期的に実行され、ディスク キャッシュからエントリを削除して、設定された範囲内に維持します。

4. ワーカー プロセスは、ネットワーク接続の処理、ディスクのコンテンツの読み取りと書き込み、上流サーバーとの通信など、実際のすべてのタスクを実行するプロセスです。

ほとんどの場合、NGINX では、ハードウェア リソースを最も効率的に使用するために、CPU コアごとに 1 つのワーカー プロセスを実行することを推奨しています。構成では次のディレクティブを設定できます。

ワーカープロセス自動

NGINX サーバーが実行中の場合、ワーカー プロセスのみがビジー状態になります。各ワーカー プロセスは、コンテキスト切り替えのオーバーヘッドを削減するために、複数の接続を非ブロッキング方式で処理します。

各ワーカー プロセスはシングル スレッドであり、独立して実行され、新しい接続を取得して処理します。プロセスは、共有メモリを通じてキャッシュ データ、セッション永続データ、およびその他の共有リソースを共有します。

NGINX 内のワーカープロセス

NGINXワーカープロセスの内部

各 NGINX ワーカー プロセスは NGINX 構成で初期化され、マスター プロセスによって一連のリッスン ソケットが割り当てられます。

NGINX ワーカー プロセスは、ソケット (accept_mutex およびカーネル ソケット シャーディング) のイベントをリッスンして、いつ作業を開始するかを決定します。イベントは新しい接続によって開始されます。これらの接続はステート マシンに割り当てられます。最も一般的に使用されるのは HTTP ステート マシンですが、NGINX はストリーミング (ネイティブ TCP) およびいくつかのメール プロトコル (SMTP、IMAP、POP3) 用のステート マシンも実装しています。

ステート マシンは、基本的に、NGINX にリクエストの処理方法を指示する一連の命令です。 NGINX と同じ機能を実行するほとんどの Web サーバーは、同様のステート マシンを使用します。実装が異なるだけです。

スケジューリングステートマシン

ステートマシンのスケジュール

状態マシンをチェスのルールのようなものだと考えてください。すべての HTTP トランザクションはチェス ゲームです。チェス盤の片側には、素早い決断ができるチェスのグランドマスターである Web サーバーが座っています。もう一方の側はリモート クライアントです。これは、比較的低速なネットワーク経由でサイトまたはアプリケーションにアクセスする Web ブラウザーです。

ただし、競技のルールは複雑になる場合があります。たとえば、Web サーバーは他のパーティと通信したり (アップストリーム アプリケーションのプロキシ)、認証サーバーと通信したりする必要がある場合があります。 Web サーバーのサードパーティ モジュールによってゲームのルールを拡張することもできます。

ブロッキングステートマシン

ブロッキングステートマシン

プロセスとスレッドについての以前の説明を思い出してください。プロセスとスレッドは、オペレーティング システムによってスケジュールされ、CPU コア上で実行できる独立した命令セットのセットです。ほとんどの Web サーバーと Web アプリケーションは、このチェス ゲームをプレイするために 1 つの接続/1 つのプロセスまたは 1 つの接続/1 つのスレッド モデルを使用します。各プロセスまたはスレッドには、ゲームを最後までプレイするための命令が含まれています。このプロセス中、プロセスはサーバーによって実行され、その時間のほとんどは「ブロック」されて、クライアントが次のアクションを完了するのを待機することになります。

1. Web サーバー プロセスは、リスニング ソケットで新しい接続 (クライアントによって開始された新しい一致) をリッスンします。

2. 新しいゲームが開始されると、プロセスが動作を開始します。各移動の後に、プロセスはブロック状態に入り、クライアントが次の移動を行うのを待機します。

3. ゲームが終了すると、Web サーバー プロセスはクライアントが新しいゲームを開始するかどうかを確認します (これはキープアライブ接続に相当します)。接続が閉じられた場合 (クライアントが離脱するかタイムアウトした場合)、Web サーバー プロセスはリスニング状態に戻り、新しい一致を待機します。

覚えておくべき重要な点は、アクティブな HTTP 接続 (各チェス ゲーム) ごとに専用のプロセスまたはスレッド (グランドマスター プレーヤー) が必要であるということです。このアーキテクチャは、サードパーティのモジュール (「新しいルール」) を使用して簡単に拡張できます。しかし、ここには大きな不均衡があります。ファイル記述子と少量のメモリによって表される軽量の HTTP 接続が、非常に重いオペレーティング システム オブジェクトである単一のプロセスまたはスレッドにマップされます。これはプログラミング的には便利ですが、膨大な無駄を生み出します。

NGINXこそ真のマスター

NGINXは真のグランドマスターです

チェスのグランドマスターが同時に数十人の対戦相手と対戦するトーナメントについて聞いたことがあるかもしれません。

キリル・ゲオルギエフはブルガリアの首都ソフィアで360人のプレイヤーと同時に対戦し、最終的に284勝、70引き分け、6敗という成績を収めました。

これは、NGINX ワーカーが「チェス」をプレイする方法です。各ワーカー プロセスはグランドマスターであり (通常、各ワーカー プロセスは 1 つの CPU コアを占有することに注意してください)、同時に数百人 (実際には数千人) のプレイヤーと対戦できます。

1. ワーカー プロセスは、リスニング ソケットと接続ソケットでイベントを待機します。

2. ソケット上でイベントが発生し、ワーカー プロセスがこれらのイベントを処理します。

●リスニングソケット上のイベントは、クライアントが新しいゲームを開始したことを意味します。ワーカー プロセスは新しい接続ソケットを作成します。

●接続ソケット上のイベントは、クライアントがチェスの駒を動かしたことを意味します。ワーカープロセスは迅速に応答します。

ワーカー プロセスはネットワーク上で停止することはなく、常に「相手」(クライアント) の応答を待機します。このゲームの駒を動かしたら、すぐに次のゲームに取り掛かるか、新しい対戦相手と対戦します。

ブロッキングマルチプロセスアーキテクチャよりも高速なのはなぜですか?

なぜこれがブロッキング型マルチプロセス アーキテクチャよりも高速なのでしょうか?

NGINX は、ワーカー プロセスごとに数万の接続をサポートできるほど拡張性に優れています。新しい接続ごとに別のファイル記述子が作成され、ワー​​カー プロセスで少量の追加メモリが消費されます。各接続の追加コストは非常に小さいです。 NGINX プロセスは一定の CPU 使用率を維持できます。作業がないときのコンテキストスイッチも少なくなります。

ブロッキング型の 1 接続 / 1 プロセス モデルでは、各接続に大量の追加リソースとオーバーヘッドが必要になり、コンテキスト スイッチ (1 つのプロセスから別のプロセスへ) が非常に頻繁に発生します。

さらに詳しく知りたい場合は、NGINX のコーポレート開発担当副社長兼共同創設者の Andrew Alexeev が書いた NGINX アーキテクチャに関するこの記事をご覧ください。

適切なシステムチューニングを行うことで、NGINX はトラフィックの急増時に情報 (新しい競合) を失うことなく、ワーカー プロセスごとに数十万の同時 HTTP 接続を処理できるように拡張できます。

設定の更新とNGINXのアップグレード

設定の更新とNGINXのアップグレード

少数のワーカープロセスのみで構成される NGINX プロセス アーキテクチャにより、構成の更新やバイナリ自体の更新も非常に効率的になります。

NGINX 設定の更新は非常にシンプルで軽量、かつ信頼性の高い操作です。 nginx の reload コマンドを実行するだけで、ディスク上の構成がチェックされ、メイン プロセスに SIGHUP シグナルが送信されます。

メイン プロセスは SIGHUP シグナルを受信すると、次の 2 つの処理を実行します。

1. 構成を再ロードし、新しい作業プロセス セットをフォークします。これらの新しいワーカー プロセスは、すぐに接続の受け入れとトラフィックの処理を開始します (新しい構成を使用)。

2. 古いワーカープロセスに静かに終了するように通知するシグナルを送信します。これらの古いプロセスは、新しい接続を受け入れなくなります。処理中の HTTP リクエストが終了するとすぐに、接続が正常に閉じられます。すべての接続が閉じられると、ワーカー プロセスは終了します。

このプロセスにより、CPU 使用率とメモリ使用量がわずかに増加しますが、このわずかな増加は、アクティブな接続からリソースを読み込む場合に比べれば無視できる程度です。 1 秒間に複数回構成を再読み込みできます。まれに、世代のワーカーが接続の終了を待機している間に問題が発生することがあります。ただし、問題が発生した場合でも、すぐに解決されます。

NGINX のバイナリ アップグレード プロセスはさらに驚くべきもので、接続が切断されたり、ダウンタイムが発生したり、サーバーへのサービスが中断したりすることなく、NGINX 自体をオンザフライでアップグレードできます。

バイナリ アップグレード プロセスは構成の更新と似ています。新しい NGINX マスター プロセスは元のマスター プロセスと並行して実行され、リスニング ソケットを共有します。両方のプロセスがアクティブであり、それぞれのワーカー プロセスが独自のトラフィックを処理します。その後、古いマスター プロセスとそのワーカーに正常に終了するように通知できます。

プロセス全体については、「NGINX の制御」で詳しく説明されています。

結論は

結論

この NGINX の内部図は、NGINX の仕組みを大まかに説明していますが、このシンプルな説明の背後には 10 年以上にわたる革新と最適化があります。これらの革新と最適化により、NGINX はさまざまなハードウェアで優れたパフォーマンスを発揮すると同時に、最新の Web アプリケーションに必要なセキュリティと信頼性も提供します。

以上がこの記事の全内容です。皆様の勉強のお役に立てれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。