社内勉強会 NGINX誕生の歴史
554 Views
May 31, 24
スライド概要
社内勉強会の資料です。
NGINXの歴史についてまとめています。
日本・中国・カナダを拠点に、AWS や GCP・Azure などのマルチクラウドに対応した、クラウド / サーバーの構築・移行、24時間365日の運用保守 / 監視、負荷テスト、Webシステム開発、サーバーサイド / API 開発 など、クラウド / サーバーに特化したサービスをご提供いたします。 ● コーポレートサイト https://beyondjapan.com ● YouTube https://www.youtube.com/c/beyomaruch ● X（Twitter） https://twitter.com/beyondjapaninfo ● Instagram https://www.instagram.com/beyondjapan_24365
関連スライド
各ページのテキスト
社内勉強会 NGINXの誕生の歴史
目次 ・NGINXとは ・ApacheとC10K問題☆ ・NGINXの誕生 ・まとめ
NGINXとは
プロフィール ・WEBサーバー ・2004年生まれ 得意な事 ・大量の同時アクセス耐える事 など 苦手な事 ・動的コンテンツの処理(スクリプト言語の処理) など
Apacheと C10K問題
圧倒的シェア！ プロフィール ・WEBサーバー ・1995年生まれ 得意な事 ・動的コンテンツの処理(スクリプト言語の処理) など 苦手な事 ・大量の同時アクセス
その後インターネットが普及し...
C10K問題 =クライアント 10000台 問題 原典引用：So hardware is no longer the bottleneck. →クライアントが増えた時に ハードウェアの 限界でない理由でのパフォーマンス劣化 FD,PIDの枯渇、同時起動可能なプロセス数の上限に達し 前の 処理が終るまでプロセスを起動出来なくなる
Apache (当時は)C10K問題に対抗できなかった...
なぜApacheはC10K問題に 対応できなかったのか
Apacheのリクエスト処理方法の特徴 MPM(Multi Processing Module ) プロセスを複数生成することで同時にリクエストを処理出来る。 これを実現するモジュール（追加機能）の事 →同時リクエストが来た際の処理の方法 3種類ある → prefork / worker / (event driven)
ポイント prefork プロセスを増やす worker
処理の流れ リクエスト受け取る ↓ プロセス / スレッド を増やす ↓ プロセス数の上限に達する ↓ 新たにプロセスを生成出来ず あるリクエストの処理が終わるまで新たな接続は待たなければならない
NGINXの誕生
NGINXのリクエスト処理方法の特徴 ・イベント駆動 →クライアントからのリクエストをイベントとして プロセス内で処理を実行する ・ノンブロッキングI/O →データ処理の完了を待たずに他の処理を行うこと
プロセスを増やさない イベント駆動
ノンブロッキングI/O 炊飯 米を洗う 肉.野菜を切る 煮込む 待 米盛付け ルー盛付け 完成
処理の流れ リクエスト受け取る ↓ クライアントの接続要求、リクエストの読み込み、応答等の処理を イベントとして並列実行する ↓ プロセス数を増やさない為、クライアントが増えても対応出来る
まとめ Apache１強 ↓ インターネットの普及 ↓ C10K問題 ↓ Apacheが対応出来ない ↓ NGINX開発 ☆だからNGINXは大量アクセスに強い
技術の生まれた歴史を学ぶと 理解が深まるし楽しい！
ご清聴ありがとうございました！