セキュリティにも?nginxとWEBサーバーの基本をまとめてみた。

こんにちは。subaruです!
最近、徐々にキャラが迷走してきていますw

思っているよりも、方向性が難しくて、試行錯誤していますが徐々に文章書くのにも慣れてきたので、徐々に技術的な話にシフトしていけたらなぁと思っています。

ということで、今日はみんな知ってるWEBサーバーの話題をさせていただきます。

 

「nginx」ってなんて読むの?

 

nginxが何かということよりも、まず読み方ですよねw 「エンジンエックス」と読みます。

ンギクスとかギンクスではないですよ。(かくいう私もしばらくジンクスって読んでました)
なぜこんなにも難しい読み方なのかというと、ロシアで開発されていたソフトウェアだからっぽいです。(正確な命名由来は不明)
ただ、こいつが最近というかここ数年やけに注目されているので、それがなぜなのか!調べてみました。

 

nginxとApache

 

WEBサーバーといえばApache!という風潮はまだまだあると思います。が、
アクティブサイトのシェアでは14%に迫っており、Apacheに続く第2位という順位になっています。

参考:ApacheとIISのシェア逆転!? nginxは? Webサーバの世界で今何が起きているのか

 

ついでにGoogleトレンドの両者の比較を見てみましょう。
\"スクリーンショット

2010年くらいからどっと検索量が増えているのがわかりますね。
ここ5年くらいで注目を浴びているWEBサーバーということですね。

 

それでは、Apacheとnginx、その違いってなんなんでしょうか。

 

nginxの役割

ざっくり言うと

  • WEBサーバー
  • リバースプロキシサーバー
  • メールプロキシサーバー

という、3つの側面を持っています。

WEBサーバーとしては、C10K問題を解決できるサーバーとして注目されています。

 

C10K問題とは、

ハードウェアの性能上は問題がなくても、クライアント数があまりにも多くなるとサーバがパンクする問題のこと。C は「Client(クライアント)」の頭文字、10K は「1 万台」を意味する。「クライアント 1 万台問題」ともいわれる。
C10K 問題しーてんけーもんだい

と、引用させていただきました。

 

つまり、Apacheの従来のWEBサーバークライアント数が多くなると、ハードの性能をどんなに良くしたとしてもクライアントの数が多くなると処理が止まってしまうという問題を抱えているものでした。それを解決するために開発されたのが、このnginxなわけです!

 

WEBサーバーの仕組み

 

なぜnginxを使えばC10K問題が解決するのか!?それを知るためには、WEBサーバーの接続処理について知らなければいけません。

接続処理のアーキテクチャ
* マルチプロセスモデル
* マルチスレッドモデル
* イベント駆動モデル

という3つのモデルがよく使われています。

 

マルチプロセスモデル

 

このマルチプロセスモデルは、クライアントからの接続毎にプロセスをフォーク(分岐)して処理するモデルとなっています。
つまり、あらかじめ複数のプロセスを生成してクライアントの接続に備えているということですね。
その分だけメモリを消費しているということなので、接続がなくても負担が高いということになります。
Apacheではprefolkという名前でデフォルトで設定されているのがこの、マルチプロセスモデルということですね。

 

マルチスレッドモデル

 

マルチスレッドモデルは、クライアントからの接続毎にスレッドを生成して処理するモデルです。
マルチスレッドモデルよりも、メモリの消費量は少ないのですが、同時接続数が増えるとその分だけスレッド数も増えるという欠点があります。
Apacheではworkerという名前でマルチプロセスモデルとマルチスレッドモデルのハイブリッドが採用されています。

 

C10K問題の正体

 

ここでお気づきになった方もいるかと思いますが、どちらのモデルも同時接続数が増えれば増えるほど、そのプロセス数やスレッド数は多くなるということがわかるかと思います。つまり、負担がかかり本来の処理ができなくなる…。

これがC10K問題の正体ということですね!

 

イベント駆動モデル

 

そしてnginxで採用されているのが、このイベント駆動モデルです。

クライアントからの接続毎にイベント処理を行うというシンプルな構成になっていますね。この場合、1プロセスに1CPUしか使えないので、CPUの数だけプロセスを用意するワーカーモデルが採用されています。
そしてこのイベント駆動モデルによって、接続数が増えてもプロセス数やスレッド数は増えず、高速に処理を行うことができるということですね。

 

リバースプロキシサーバーとしても!

 

リバースプロキシサーバーとしてリクエストを受け付けて、バックエンドのWEBサーバーやAPサーバに処理を割り振ったりすることで、
ロードバランサーやSSLアクセラレーションやWAFとしても使えるという機能も持ち合わせているので、
その機能を説明したかったのですが…!!

 

 

ちょっと記事も長くなってきたので、来週実践したものを紹介させていただきます!

それでは!(中途半端な感じですみません><)

  • このエントリーをはてなブックマークに追加
  • Pocket