Clever Geek Handbook

内郚からのNGINXパフォヌマンスずスケヌラビリティのために生たれた

NGINXは圓然、最高のパフォヌマンスのサヌバヌの1぀であり、これはすべお内郚構造のおかげです。 倚くのWebおよびアプリケヌションサヌバヌはシンプルなマルチスレッドモデルを䜿甚したすが、NGINXはその重芁なむベントアヌキテクチャによっお矀を抜いおいたす。



NGINX内郚のむンフォグラフィックは、プロセス蚭蚈の基本を通しお、NGINXが1぀のプロセスで耇数の接続を凊理する方法を説明したす。 この蚘事では、これらすべおをもう少し詳しく調べたす。





シヌンの準備NGINXプロセスモデル









デバむスをよりよく理解するには、たずNGINXの起動方法を理解する必芁がありたす。 NGINXには、1぀のマスタヌプロセススヌパヌナヌザヌに代わっお、構成の読み取りやポヌトのオヌプンなどの操䜜を実行するず、倚数の䜜業および補助プロセスがありたす。 



# service nginx restart * Restarting nginx # ps -ef --forest | grep nginx root 32475 1 0 13:36 ? 00:00:00 nginx: master process /usr/sbin/nginx \ -c /etc/nginx/nginx.conf nginx 32476 32475 0 13:36 ? 00:00:00 \_ nginx: worker process nginx 32477 32475 0 13:36 ? 00:00:00 \_ nginx: worker process nginx 32479 32475 0 13:36 ? 00:00:00 \_ nginx: worker process nginx 32480 32475 0 13:36 ? 00:00:00 \_ nginx: worker process nginx 32481 32475 0 13:36 ? 00:00:00 \_ nginx: cache manager process nginx 32482 32475 0 13:36 ? 00:00:00 \_ nginx: cache loader process


4コアサヌバヌでは、NGINXマスタヌプロセスが4぀のワヌクフロヌず、ハヌドドラむブ䞊のキャッシュのコンテンツを管理するいく぀かの補助キャッシュプロセスを䜜成したす。



なぜアヌキテクチャがただ重芁なのですか



Unixアプリケヌションの基本的な基盀の1぀は、プロセスたたはスレッドですLinuxカヌネルの芳点から芋るず、プロセスずスレッドはほが同じです。党䜓の違いはアドレス空間の分離にありたす。 プロセスたたはスレッドは、オペレヌティングシステムがプロセッサコアで実行するようにスケゞュヌルできる自己完結型の呜什セットです。 ほずんどの耇雑なアプリケヌションは、次の2぀の理由で耇数のプロセスたたはスレッドを䞊行しお実行したす。





プロセスずスレッドのみが远加のリ゜ヌスを消費したす。 そのような各プロセスたたはスレッドは、䞀定量のメモリを消費し、さらに、プロセッサ䞊で垞に盞互に亀換したすいわゆるコンテキストスむッチング。 最新のサヌバヌは数癟のアクティブなプロセスずスレッドを凊理できたすが、メモリが䞍足したり、倧量のI / O操䜜が頻繁にコンテキストを倉曎したりするずすぐにパフォヌマンスが倧幅に䜎䞋したす。



ネットワヌクアプリケヌションを構築する最も䞀般的なアプロヌチは、接続ごずに個別のプロセスたたはスレッドを割り圓おるこずです。 このアヌキテクチャは理解しやすく、実装も簡単ですが、アプリケヌションが同時に数千の接続を凊理する必芁がある堎合、うたく拡匵できたせん。



NGINXはどのように機胜したすか



NGINXは、利甚可胜なシステムリ゜ヌスを最も効率的に利甚するプロセス数が固定されたモデルを䜿甚したす。





NGINXのドキュメントでは、ほずんどの堎合、ワヌクプロセスの数をプロセッサコアの数に蚭定するこずを掚奚しおいたす。これにより、システムリ゜ヌスを可胜な限り効率的に䜿甚できたす。 蚭定ファむルのworker_processes autoディレクティブを䜿甚しお、このモヌドを蚭定できたす。 



 worker_processes auto;


NGINXに負荷がかかっおいる堎合、ワヌクプロセスはほずんどビゞヌ状態です。 それぞれがノンブロッキングモヌドで倚くの接続を凊理し、コンテキストスむッチの数を最小限に抑えたす。



各ワヌクフロヌはシングルスレッドであり、独立しお実行され、新しい接続を受け入れお凊理したす。 プロセスは、キャッシュデヌタ、セッション、およびその他の共有リ゜ヌス甚の共有メモリを䜿甚しお盞互にやり取りしたす。



内郚ワヌクフロヌ









各NGINXワヌクフロヌは、指定された構成ず、マスタヌプロセスから継承されたリスニング゜ケットのセットで初期化されたす。



ワヌクフロヌは、リッスン゜ケットでむベントを埅機するこずから始たりたす accept_mutexおよび共有゜ケットも参照。 むベントは新しい接続を発衚したす。 これらの接続は最終的にステヌトマシンで行われたす -最も䞀般的に䜿甚されるのはHTTP凊理甚ですが、NGINXにはTCPトラフィックフロヌ ストリヌムモゞュヌルおよび倚数の電子メヌルプロトコル SMTP 、 IMAP 、 POP3 を凊理するステヌトマシンも含たれたす。









NGINXのステヌトマシンは、本質的にリク゚ストを凊理するための䞀連の呜什です。 ほずんどのWebサヌバヌは同じ機胜を実行したすが、違いは実装にありたす。



有限状態マシン



ステヌトマシンは、チェスをするためのルヌルの圢で想像できたす。 各HTTPトランザクションはチェスゲヌムです。 チェス盀の片偎では、Webサヌバヌは非垞に迅速に意思決定を行うグランドマスタヌです。 反察偎には、比范的䜎速のネットワヌクを介しおサむトたたはアプリケヌションを芁求するブラりザヌであるリモヌトクラむアントがありたす。



なるほど、ゲヌムのルヌルは非垞に耇雑になる可胜性がありたす。 たずえば、Webサヌバヌは他のリ゜ヌスプロキシバック゚ンド芁求ず察話したり、認蚌サヌバヌにアクセスしたりする必芁がある堎合がありたす。 サヌドパヌティのモゞュヌルは、凊理をさらに耇雑にする可胜性がありたす。



ロック可胜なステヌトマシン



プロセスたたはスレッドの定矩を、オペレヌティングシステムが特定のプロセッサコアに割り圓おるこずができる自己完結型の呜什セットずしお思い出しおください。 ほずんどのWebサヌバヌずWebアプリケヌションは、「チェスのゲヌム」で接続ごずに1぀のプロセスたたはスレッドが存圚するモデルを䜿甚したす。 各プロセスたたはスレッドには、1぀のゲヌムを最埌たでプレむするための指瀺が含たれおいたす。 この間ずっず、サヌバヌで実行されおいるプロセスは、ブロックされた時間のほずんどを費やし、クラむアントからの次の移動を埅ちたす。









  1. Webサヌバヌプロセスは、リスニング゜ケットでの新しい接続クラむアントによっお開始された新しいバッチを埅機しおいたす。
  2. 新しい接続を受信するず、圌はゲヌムをプレむし、クラむアントからの応答を期埅しお各移動埌にブロックしたす。
  3. バッチが再生されるずき、Webサヌバヌプロセスは、クラむアントが次のバッチを開始するのを埅機しおいる堎合がありたすこれは、長時間のキヌプアラむブ接続に察応したす。 接続が閉じられた堎合クラむアントが終了したか、タむムアりトが発生した堎合、プロセスはリッスン゜ケット䞊の新しいクラむアントの䌚議に戻りたす。


泚目に倀する重芁な点は、アクティブなHTTP接続各バッチごずに個別のプロセスたたはスレッドグランドマスタヌが必芁なこずです。 このアヌキテクチャはシンプルであり、サヌドパヌティのモゞュヌルを䜿甚しお簡単に拡匵できたす新しい「ルヌル」。 ただし、倧きな䞍均衡がありたす。ファむル蚘述子ず少量のメモリの圢匏で衚されるかなり軜量なHTTP接続は、オペレヌティングシステムのかなり重いオブゞェクトである別のプロセスたたはスレッドず盞関したす。 プログラミングには䟿利ですが、非垞に無駄です。



NGINX、本圓のグランドマスタヌのような



1人のグランドマスタヌが倚数の察戊盞手ず䞀床に倚くのチェスフィヌルドでプレヌする同時ゲヌムのセッションに぀いお聞いたこずがあるでしょうか









ブルガリアのトヌナメントでのキリルゲオルギ゚フは、360の䞊行ゲヌムでプレヌしたした。 最終結果は284勝、70匕き、6敗です。



同様に、NGINXワヌクフロヌは「チェスをしたす」。 各ワヌクフロヌ通垞、コンピュヌティングコアごずに1぀のみは、数癟および実際には数十䞇のゲヌムを同時にプレむできるグランドマスタヌです。









  1. ワヌクフロヌは、リスニング゜ケットず接続゜ケットでむベントを予期したす。
  2. むベントは゜ケットで発生し、プロセスがそれらを凊理したす。
    • リスニング゜ケット䞊のむベントは、新しいクラむアントがゲヌムを開始するために到着したこずを意味したす。 ワヌクフロヌは、新しい接続゜ケットを䜜成したす。
    • 接続゜ケットのむベントは、クラむアントが移動したこずを通知したす。 ワヌクフロヌは即座に圌に答えたす。


ネットワヌクトラフィックを凊理するワヌクフロヌはブロックされず、盞手クラむアントからの次の移動を埅ちたす。 プロセスが移動した埌、すぐにプレむダヌが移動を埅っおいる他のボヌドに移動するか、ドアで新しいボヌドに䌚いたす。



マルチスレッドアヌキテクチャをロックするよりも高速なのはなぜですか



新しい接続ごずにファむル蚘述子が䜜成され、ワヌ​​クフロヌで少量のメモリが消費されたす。 これは、非垞に小さな接続オヌバヌヘッドです。 NGINXプロセスは、特定のプロセッサコアに関連付けられたたたにするこずができたす。 コンテキストの切り替えはたれであり、ほずんどの堎合、䜜業が残っおいないずきに行われたす。



接続ごずに個別のプロセスを䜿甚するブロッキングアプロヌチでは、比范的倧量の远加リ゜ヌスが必芁であり、あるプロセスから別のプロセスぞのコンテキストの切り替えがはるかに頻繁に発生したす。



このトピックに関する远加情報は、 NGINX、Inc.の開発担圓副瀟長兌共同蚭立者であるAndrey AlekseevによるNGINXアヌキテクチャに関する蚘事にも蚘茉されおいたす 。



適切なシステム構成により、NGINXはワヌクフロヌごずに数十䞇の䞊列HTTP接続に完党に拡匵し、トラフィックのバヌスト新しいプレヌダヌのクラりドを確実に吞収したす。



構成および実行可胜コヌドの曎新



少数のワヌクフロヌを備えたNGINXアヌキテクチャにより、蚭定やその実行可胜コヌドさえも非垞に効率的に曎新できたす。









NGINX構成の曎新は、非垞にシンプルで軜量で信頌性の高い手順です。 これは、マスタヌプロセスにSIGHUPシグナルを送信するだけです。



ワヌクフロヌは、SIGHUPを受け取るず、いく぀かの操䜜を実行したす。

  1. 構成を再ロヌドし、ワヌクフロヌの新しいセットを生成したす。 これらの新しいワヌクフロヌはすぐに接続を受け入れ、トラフィックを凊理し始めたす新しい蚭定を䜿甚。
  2. スムヌズな完了のために叀いワヌクフロヌを通知したす。 新しい化合物の受け入れを停止したす。 珟圚のHTTP芁求の凊理が完了するずすぐに、接続が閉じられたすキヌプアラむブ接続が長匕くこずはありたせん。 すべおの接続が閉じられるず、ワヌクフロヌは終了したす。


この手順は、プロセッサずメモリにわずかな負荷のバヌストを匕き起こす可胜性がありたすが、䞀般的には、アクティブな接続の凊理コストの背景に察しおほずんど感知できたせん。 蚭定を毎秒数回リロヌドできたすこれを行う倚くのNGINXナヌザヌがいたす。 たれに、NGINXワヌクフロヌの䞖代が倚すぎお接続が閉じるのを埅っおいるずきに問題が発生するこずがありたすが、それらはすぐに解決されたす。



NGINX実行可胜コヌドの曎新は、高可甚性サヌビスの聖杯です。 接続の損倱、リ゜ヌスのダりンタむム、顧客サヌビスの䞭断なしに、サヌバヌをその堎で曎新できたす。









実行可胜コヌドを曎新するプロセスは、構成を再ロヌドするために同様のアプロヌチを䜿甚したす。 新しいNGINXマスタヌプロセスは叀いものず䞊行しお実行され、そこからリスナヌ゜ケット蚘述子を受け取りたす。 䞡方のプロセスがロヌドされ、それらのワヌクプロセスがトラフィックを凊理したす。 その埌、コマンドを叀いマスタヌプロセスに枡しお、スムヌズに完了させるこずができたす。



手順党䜓に぀いおは 、ドキュメントで詳しく説明しおいたす。



たずめるず



NGINXの機胜の衚面的な抂芁を説明したした。 これらの簡単な説明は、10幎以䞊の開発ず最適化の経隓をカバヌしおおり、NGINXは、最新のWebアプリケヌションが必芁ずする信頌性ず安党性を維持しながら、幅広い機噚ず実際のタスクで卓越したパフォヌマンスを発揮できたす。



このトピックの詳现を知りたい堎合は、次のこずを理解するこずをお勧めしたす。





More articles:


All Articles