Nginx のリロード プロセスの背後にある真実を探る

本日の記事では、主にNginxのリロードプロセスについて紹介します。実は前回の記事では、nginx の設定ファイルを変更した際に、nginx -s reload コマンドを実行していました。このコマンドを実行する理由は、nginx の設定ファイルを古い nginx.conf 設定から新しい nginx.conf 設定にスムーズに更新しながら、nginx がサービスを停止せず、常に新しいリクエストを処理することを期待するためです。

このような機能は nginx にとって非常に必要ですが、 nginx -s reloadコマンドを実行した後にワーカー サブプロセスの数が増えることがあります。これは、古い構成で実行されているワーカー プロセスが長時間終了していないためです。ストリームを 4 層リバース プロキシとして使用する場合、このシナリオがより一般的になる可能性があります。

それでは、nginx のリロード プロセスを分析して、nginx が何を行うのかを調べてみましょう。優雅な退出と即時退出の違いは何ですか?

リロードプロセス

最初のステップは、nginx 構成ファイル nginx.conf を変更した後、マスター プロセスに HUP シグナルを送信することです。これは実際には、コマンド ラインでnginx -s reloadコマンドを実行するのと同じです。

HUP シグナルを受信した後、マスター プロセスは 2 番目のステップで設定ファイルの構文が正しいかどうかを確認します。つまり、nginx のマスター プロセスは 2 番目のステップでこのステップを必ず実行するので、nginx -s reload の前に nginx -t を実行して構文が正しいかどうかを確認する必要はありません。

nginx の設定構文が正しい場合、マスター プロセスは新しいリスニング ポートを開きます。マスター プロセスで新しいリスニング ポートを開く必要があるのはなぜですか? nginx.conf で 443 などの新しいリスニング ポートや、これまで開かれていなかったリスニング ポートが導入される可能性があり、すべてのワーカー プロセスはマスター プロセスの子プロセスであり、子プロセスは親プロセスの開かれたポートをすべて継承するためです。これは Linux オペレーティング システムによって定義されているため、3 番目のステップでは、マスター プロセスが、導入される可能性のある新しいリスニング ポートを開きます。

次に、マスター プロセスは新しい nginx.conf 構成ファイルを使用して新しいワーカー サブプロセスを開始しますが、古いワーカー サブプロセスはどうなるでしょうか?

5 番目のステップでは、新しいワーカー子プロセスを開始した後、マスタープロセスは古いワーカー子プロセスに QUIT 信号を送信します。QUIT 信号は、TERM 信号や INT 信号とは異なります。QUIT 信号は、子プロセスを正常に閉じるためのものです。このとき、順序に注意する必要があります。nginx はスムーズさを保証する必要があるため、最初に新しいワーカー子プロセスを開始し、次に古いワーカー子プロセスに QUIT 信号を送信する必要があります。

その後、古いマスター子プロセスは QUIT シグナルを受信した後、まずリスニング ハンドルを閉じます。つまり、この時点では、新しい接続は新しいワーカー子プロセスにのみ送信されます。そのため、それらの間には時間差がありますが、時間は非常に高速です。その後、リスニング ハンドルを閉じた後、プロセスは現在の接続を処理して終了します。

以下は、マシンを停止せずにリロードによって新しい構成がロードされる様子を示す図です。

reload は停止せずに新しい設定をロードします

元々、マスター プロセスには 4 つの緑色のワーカー サブプロセスがあり、古い構成を使用していました。nginx.conf 構成ファイルを変更すると、マスターに SIGHUP シグナルを送信するか、リロード コマンドを実行しました。すると、マスターは新しい構成ファイルを使用して 4 つの新しい黄色のワーカー サブプロセスを開始しました。この時点で、4 つの古い緑色のワーカー サブプロセスと 4 つの新しい黄色のワーカー サブプロセスが共存していました。その後、古いワーカー子プロセスは、接続が keeplive 要求であっても、確立された接続で要求を処理した後、通常は接続を閉じます。

ただし、異常な状況では、一部のリクエストに問題があり、クライアントが長時間処理できない場合、リクエストはワーカー サブプロセスに長時間残ります。この場合、ワーカー サブプロセスは長時間存在します。新しい接続はすでに黄色のワーカー サブプロセスで実行されているため、影響は大きくありません。影響を受けるのは、緑色のワーカー サブプロセスが長時間存在することですが、これは既存の接続にのみ影響し、新しい接続には影響しません。

私たちはそれに対して何ができるでしょうか?新しいバージョンでは、最大待機時間を意味する新しい構成 worker_shutdown_timeout が提供されます。これにより、マスター プロセスが新しい黄色のワーカー プロセスを開始した後、古いワーカー プロセスが終了していない場合は、時間切れ後に古いワーカー プロセスが強制的に終了します。

要約する

この記事では主に、Nginx が新しい構成ファイルをスムーズにアップグレードするプロセスについて説明します。ワーカー サブプロセスを適切にシャットダウンすることと、新しく構成されたワーカー サブプロセスを開始することの関係を理解すると、まれに発生する異常なシナリオをより適切に処理できるようになります。

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