セールスエンジニアの加藤です。 ChatGPTとの高度な対話が話題ですね。私も色々問い合わせて楽しんでいますが、いつの日か「くだらん事聞くんじゃない」とシバかれる日が来ないかビクビクしています。
さて先日、コンテンツの高速な静的配信が期待出来るソフトウェア「NGINX」の勉強会#2に参加したので、その様子をレポートします。 私は#1に引き続き参加しました。
オープニング
- カジュアルに、毎月楽しく情報交換したい
- 登壇者募集中
前回は、主催の松本さんが1時間ノンストップで話続けましたが今回は声量が持つのか期待です。
- 今日は、NGINXの動作について解説してくれます
NGINX プロダクト詳細な構成・動作
- リソースパワーに従ってパフォーマンスは上がっていく為、柔軟に拡張が可能
参加者からコメント「松本さんの着ている、NGINXロゴ入りWork From HomeのTシャツいいですね」
松本さん「ありがとうございます！」
※このコメントをしたのは私です。
- Master Proces：いわば司令塔。重要なプロセス。
Worker Process：CPUのコア数に応じて動作し、並列処理を増やす事ができる。トランザクションを管理するプロセス。
Cache Manager：Webサーバの情報をキャッシュする。
- Config Fileを読み込んで動作する
- 上のフローは静的コンテンツの応答を示している。
- Master Processが検知して、WorkerProcessに処理を委ねる。内容に応じて、ディレクトリにあるファイルの返答を判断している。
- HTML Fileはリクエストに応じて読み込まれるの、HTML Fileの入れ替えで内容が反映される。
- 新旧のWorkerProcessは並列に処理する事が出来る。この並列処理が高速処理を実現している。
- 前項に加え、MasterProcess同士でコネクションを管理している為、アップグレードの影響は最小限になる。
参加者からコメント「MasterProcessが単一障害点になりますか？」
松本さん「そのとおりで、有事の際は起動が速いので再起動などを試してもらいたい。ハードウェアの構成でもカバー可能」
NGINXの動作Non Blocking I/Oによる違い
- 通信を受けた時の処理の違い
- 80番通信が発生すると、MasterProcessが処理行う専任のプロセスを割り当てる
- クライアントから80番での通信が来た場合、例えばアプリの処理が完了するまでプロセスはクライアントへの応答を待っている状態(リソースが確保されている)
- これがBlocking I/O
- 対して、Non Blocking I/Oは、コア数分のWorkerProcessを立ち上げる
- 専任担当の割当や、リソース確保を行わないので、効率的に処理ができる。
- これがNGINXの高速性能を実現している
- Apache(Prefork)のgetリクエストと比較
- Apacheの場合、プロセスの立ち上げでメモリを消費しており、枯渇に繋がる可能性がある
NGINX Plus・プロダクトのアップデート
最後に。その他ご紹介
前回好評だったようです！前回は直前にエントリーが増えたそうですが、今回はその傾向は見られなかったとの事。不思議ですね。
ブログ取り上げてもらいました！
次回は、NGINX Ingress Controller を取り上げるそうです！コンテナでアプリを実装している人は抑えておきたいですね。
zoomやslackでの解説やコミュニケーションをしながらのもくもく会も検討中との事。
感想
今回は前回以上に、テクニカルな内容でした。(Non)Blocking I/O については正直初めて理解しました。単純なスペックからは見えない動作の事を知ると、プロダクトへの信頼感が増しますね。また次回も更新します。
