nginxサーバーの概要とインストール

機械学習技術人工知能技術自然言語処理技術セマンティックウェブ技術オントロジー技術検索技術データベース技術アルゴリズムデジタルトランスフォーメーション技術 Visualization & UX ワークフロー&サービス ITインフラ技術本ブログのナビ

サマリー

“webサーバー概要“で述べたようにWebサーバーは常時ネットワークに接続して、クライアントから要求に対してHTTPレスポンスデータを返すweb技術のベースとなるモジュールとなる。今回はそのwebサーバーの中で多く使われているサーバー技術の一つであるnginxについて「nginx実践ガイド」より抜粋して述べる。

nginxの概要

nginx(engine x:エンジンエックス)は、webサーバーやロードバランサ、リバースプロキシとしてニカ機を集めているソフトウェアとなる。Webサーバー、ロードバランサ、リバースプロキシは、いずれも普段ブラウザからあくせすさけるWebシステムに必須の構成要素となる。

webの世界には、CERN httpdやNCSA HTTPdといったWebサーバーが使われてきたが、いずれもApache HTTP SEver(以下Apache)に取って代わられた。その後Microsoft Internet Information Server(IIS)、LightSpeed、lighthttpdなど様々なWebサーバーが新たに開発され、使われてきた。nginxもその中の一つとなる。

nginxは、2004年にIgor Sysonev氏によって最初のバージョンがリリースされてから活発に開発を続け、シェアを伸ばしてきた。2011年には、開発とサポートを行うNGINX. Incが設立され、機能を追加した商用版のNGINX Plusとオープンソース版のnginxの両方の開発を継続している。現在では、国内のOSSサポート会社もnginxのサポートを始めている。

長年webサーバーの統計情報を取得して公表しているNetcraft社の調査では、2016年時点では、ApacheとIISとnginxが3強といえる位置を占めており、アクセスの多いトップ100万サイトのうち、3割近くがnginxを使っている状況となる。この数字は2010年時点では5%だったが、年をおうごとにサイト数は増えており、徐々に人気が高まっている。

Apacheは20年以上も前から使われており、現在も活発に開発が続いている。Linux/UNIXの多くのディストリビューションで標準的なWebサーバーとして、特に理由がない限り、Apacheを使うケースが多くなる。IISはWindowsでの標準的なWebサーバーなので、OSにWindowsを選べばIISを使うことが多くなる。nginxに関しては、標準で用意されているwebサーバーとしてではなくあえて選ばれているものとなる。

nginxの機能と特徴

nginxには、主に3つの使い方がある。

静的なコンテンツのwebサーバー

静的なコンテンツとは、変更が滅多にない固定データのこととなる。静的なコンテンツのwebサーバーは、webページのデータや、webページが使う画像やスタイルシートなどのリソースファイル、ダウンロードファイルの提供などに使われる。nginxは静的なコンテンツのwebサーバーとして高い性能を発揮する。

動的なコンテンツのwebサーバー

動的なコンテンツとは、悪声してきたユーザーや入力の状況などによって内容が変わるデータのこととなる。動的なコンテンツのwebサーバーでは、webアプリケーションと呼ばれる種類のソフトウェアが動作し、アクセスを処理してデータを生成する。webアプリケーションとの正続はFastCGIやWSGI、TCPソケットなどさまざまな方法がある。

ロードバランサ、リバースプロキシ

リバースプロキシは、クライアントからのwebアクセスを別のwebサーバーに転送するサーバーとなる。複数の転送先に負荷を分散するリバースプロキシを、特にロードバランサと呼ぶ。nginxは、ロードバランサやリバースプロキシの設定が容易で、性能も高いため、これらの機能のみを利用する場合もある。nginxにHTTPSの処理を担当させて、暗号化を解いた状態で別のWEBサーバーにアクセスを転送するような使い方もある。

次にnginxの特徴をいくつか挙げる。

設定ファイルの構造がシンプル

他のサーバーと同様、nginxでも様々な設定をファイルに記述していくが、Apacheなどと比較するとシンプルな構造になっており、内容も直感的に理解しやすい希有校がある。設定ファイルから他の設定ファイルを読み込むこともできるし、バーチャルホストごとに別の設定ファイルを用意するなど、管理もしやすい。

基本構造がしっかり作ってあり、安定して動作する。

nginxは、動作に必要なメモリやCPUのリソースが少なく、効率よく動作する。サービスを止めない再起動やバージョンアップなど、サーバーに求められている機能が充実しており、安定してドキュメントの記述通りに動作する。

性能が高い

近年のwebアクセスは、接続を比較的長時間維持する傾向があるが、nginxはアクセス性能が高く、特に同時接続数が増えて交付化になっても性能が落ちにくい特徴があり、小さなコンテンツから大きなこんてんつまで、さまざまな場面で高い性能を発揮できる。キャッシュの機能もあり、ファイルIOやネットワークIOを節約することでさらに性能を高められる。

新機能への対応が早い

HTTP/2やWebSocketのリバースプロキシなど、新機能への対応が早期に実現されている。

Webシステムのアーキテクチャ

一般的なWebシステムの構成は下図のようになる。

ユーザーのwebアクセスは、まずロードバランサーが受け付ける。ロードバランサは、アクセスをwebサーバーに振り分け、webサーバーはwebアプリケーションがアクセスを処理する、webアプリケーションが使用するデータは、データベースやファイルに保存される。これらロードバランサやwebサーバー、データベースサーバーはそれぞれ別のインスタンスで動作する。インスタンスとは、ハードウェアや仮想マシン(VM)、コンテナ、プロセスなどの動作単位を示す総称となる。

実際のwebシステムでは、インスタンスの構成はシステムの目的や規模によって様々となる。システムが小規模な場合は、ロードバランサを使っていなかったり、データベースも含めてすべて一台ののサーバーに構築したりする場合もある。逆に大規模なシステムでは、ロードバランサ自体も複数のノードで構成して負荷分散したいたり、画像と本文、あるいはアップロード用とダウンロード用など、コンテンツの種類や役割によってwebサーバーを分けていたり、さらにはCDN(コンテンツデリバリネットワーク)と呼ばれる外部のコンテンツ配信サービスを使って、大量のアクセスに対応したりする場合もある。

nginxが活躍するのは、ロードバランサとwebサーバーの部分となる。クライアントとロードバランサ、ロードバランサとwebサーバー間の通信プロトコルは、どちらもHTTPやHTTPSが使われている。そのため、ロードバランサをnginxで構築したら、Webサーバーもnginxでなければならないということもない。ロードバランサにnginx、webサーバーにApacheやIISという構成でも良い。逆にロードバランサにApache、wbサーバーにnginxというケース、両方hginxというケースもある。

nginxの内部構造

nginxを起動すると、2種類のプロセスが起動していることがわかる。psコマンドで確認すると、それぞれプロセス名が「nginx: master process」「nginx: worker process」となっていて、masterはrootユーザーで起動し、workerは「nginx」や「www」といった名前の一般ユーザーで起動している。masterとworkerは、それぞれ異なる役割をになっている。

masterは、設定ファイルを読み込み、ネットワークの通信に使えソケットの待ち受けを設定して、workerを起動し、監視する。workerは、ネットワーク処理のイベントループを処理し、masterが待ち受けを設定したソケットを使って接続を受付、ネットワークやファイルIOを実施する。HTTPやSSL/TLSのプロトコルを処理するのも、workerの仕事となる。(下図)

nginxは、一つのmasterが複数のworkerを動作させることができるが、単一のworkerの中でもIOを多重化している。多重化というのは処理を待たずに、できるところから次々に処理を進めていく処理方法となる。一般にIOはメモリやCPUと比べて遅いものなので、IOを多重化できるようなソフトウェア構造にしないと、サーバーの性能を高めることは難しいが、多重化のためには「クライアントから接続された」「受信が可能になった」「送信が可能になった」といったイベントに応じて処理を進める必要があり、イベントループの処理が重要になる。

その点nginxは、ネットワークIOに関してはLinuxのepolやFreeBSDのkquequeなど、動作するOSでも効率のよいイベントループ処理が自動的に選択され、多重化されることで高い性能を発揮できるように作られている。効率の良いイベントループ処理は、多くの接続を同時に処理するときに特に大きな効果がある。

一方で、ファイルIOに関してはのデフォルト状態では多重化されないが、LinuxやFreeBSDであれば、非同期IOやダイレクトIOを組み合わせて指定することで多重化する設定にもできる。ファイルIOはキャッシュの効果により多重化しない方が性能が良いことも多く、どちらが高速化は状況によって異なる。

nginxのモジュール構成

nginxは、内部で機能ごとのモジュールに分かれており、コンパイル時のフラグによってモジュールを組み込むかどうかを指定できるようになっている。そのため、公式サイトのドキュメントでは、モジュールごとの設定項目という形でページが分けられて記述されている。しかし、nginxの開発元が配布しているバイナリパッケージは、ほとんどのモジュールが組込み済みであり、バイナリが別のファイルに納められた動的モジュール以外では、モジュールの違いを意識することはない。

静的に組み込まれたモジュールに関しては、設定ファイルにおいても様々なモジュールの設定項目が混在しており、それぞれの設定項目がどのモジュールのものであるか知らなくても、設定を進められるようになっている。ただし、組み込まれていないモジュール用の設定項目が設定ファイルに書かれていると、nginxはエラーと見做して動作しなくなる。

動的モジュールの場合は、モジュールのバイナリファイルも辺のパッケージや別のファイルになっているし、設定の最初の部分でモジュールを読み込む設定を記述する必要があるため、組込みモジュールを意識する必要がある。

nginxのパッケージ

nginxにはとかちこりいとminlineの2つのバージョン系統がある。stablef

その名の通り、APIの変更を伴わないバグ修正が取り込まれるバージョンで、mainlineは活発に開発が続き新機能が盛り込まれているバージョンとなる。

開発元のブログによるとnginxへの変更はまずmainlineに取り込まれ、そのうち、重大なばぐ修正のみがstableに取り込まれるという流れとなる。メジャーバージョンアップは毎年4月、1年おきに行われる。

開発元では、特別な理由がない限りはmainlineを利用することを奨励している。

その他のパッケージ

nginxを使う上で、本体のパッケージ以外にも必要なソフトウェアがある。例えばHTTPSに対応させるための暗号関連の処理をするopenssl、ファイアウォールを設定するためのfirewalls、またnginxを含むサーバーの起動の管理にはsystemdを使うし、ログファイルを入れ替えて古いログから消していく処理には、logrotateを使う。webアプリケーションを動作させるには、利用するスクリプト言語の処理系なども必要となる。

このようなwebサーバーを動作させるには様々な周辺ソフトウェアが必要となるが、今回はnginx以外のパッケージは特別に理由のない場合CentOS7の標準パッケージを利用することにし、CentOS7の最小インストールに入っていないパッケージを利用するときには、必要に応じて適時yumコマンドでインストールすることとした。

nginxのインストール

nginxは、多様なOSで動作するが、ここではCentOS7のx86_64版でのインストールについて述べる。まずSELinuxが有効な状態では、待ち受けポートを変更したり、アプリケーションサーバーと接続したりする場合に、起動しなくなるなど問題が発生しやすいため無効に設定する。

$ sudo vi /etc/sellunux/config
……
#. disabled - No SELinux policy is loaded
SELINUX=disabled. 

$ reboot

リポジトリの追加

CentoOSのデフォルトのリポジトリにはnginxが入っていないため、CentOS7にnginxをインストールする前に、リポジトリを追加する。

[user@host] Sudo vi /etc/yum.repos.d/nginx.repo

[nginx]
name=nginx repo
baseurl=htttp://nginx.org/packages/mainline/centos/7/$basearch/
gpgcheck=1
enable=1
gpgkey=http://nginx.org/keys/nginx_signing.key

[nginx-source]
name=nginx source
baseurl=htttp://nginx.org/packages/mainline/centos/7/SRPMS/
gpgcheck=1
enable=1
gpgkey=http://nginx.org/keys/nginx_signing.key

yumコマンドによるインストール

次に以下のようにyum installコマンドでnginxをインストールする。yumコマンドは自動的に最新のバージョンを選択し、パッケージをインストールする。リポジトリ追加後の初回実行時は、バージョンに署名した公開鍵をインストールするかどうかの確認が必要になる。

[user@host]$ sudo yum install nginx
(input password)
………………
Loading mirror speeds from cached hostfile
………………
Is this ok [y/d/N] : y
Downloading Packages:
………………
thank you for using nginx!
………………
install:
 nginx.x86.64 1:1.11:8-1.e17.ngx

done!
[user@host]$

自動アップデートの設定

nginxの自動アップデートを設定すると、毎日深夜に更新を確認し、常に新しいバージョンが使われるようになる。nginxのパッケージをアップデートすると、設定ファイルの文法チェックがパスすることを確認した上で、無停止で新しいバイナリへの変更が行われるように設定されている。万一バイナリで動作しない場合は、古いバイナリのままで動作するようになる。

インストールパッケージの確認

インストールしたパッケージの内容はrpmコマンドで確認することができる。

[user@host]$ rpm -qi nginx
Name    :nginx
Epoch.  :1
Version :1.11.8
……………………
nginx [engine x] is an HPPT and reverse proxy server, as well as a mail proxy server

パッケージ内のファイルの確認は”rpm -ql nginx”で行うことができる。

ファイアーウォールの設定

現在のところ、たいていのディストリビューションには初期設定でファイアウォールが設定されており、Webサーバーを起動しただけではクライアントからのリクエストを受け付けることができないようになっている。そこで、ファイアウォールでHTTPポートを開ける設定をしてWebサーバーとして動作できるようにする。

CentoOS7では、firewall-cmdというコマンドを使ってファイアウォールを設定する。その際に現在の設定を変更するコマンドと、設定を保存するコマンドの2つを実行する必要がある。

#サービスの指定
[user@host]$ sudo firewall-cmd --add-service http
success
[user@host]$ sudo firewall-cmd --add-service http -permanent
success

ぁポートの指定
[user@host]$ sudo firewall-cmd --add-port 8080/tcp
success
[user@host]$ sudo firewall-cmd --add-port 8080/tcp -permanent
success

起動/終了/再起動/設定ファイル読み込み

CentOSに限らず、最近のLinuxディストリビューションのほとんどは、systemdを使ってサービスを起動したり終了したりしている。nginxのパッケージもsystemdに対応してしており、通常の動作もsystemdコマンドによって実行される。systemdのコマンドのオプションには以下に示すものがある。

開始 systemctl start nginx
終了 systemctl stop nginx
再起動 systemctl restart nginx
設定の再読み込み systemctl reload nginx
状態確認 systemctl status nginx

Webサーバーの構築

nginxでは設定ファイルが入れ子のブロックで構成されており、ブロックで囲まれた構造をコンテキストと呼ぶ。そして、それぞれのコンテキストにディレクティブと呼ばれる設定項目を書いていく。ただし、設定ファイル内のコンテキストによって、書けるディレクティブが異なっていたり、書式が複雑な部分もある。また、評価の優先順位が複雑なディレクティブもあるため、nginxの使い初めは設定章の問題で悩むことも少なくない。

nginxの設定ファイルは、/etc/nginx/nginx.confにある。nginxの設定ファイルでは、ディレクティブと呼ばれる設定項目を書いていく。ディレクティブには「;」で終わるものと「{}」を使って囲ったブロックでコンテキストを作成できるものもある。どのブロックにも含まれない、最も外側のコンテキストをmainコンテキスト、ディレクティブによって即成されたコンテキストは、コンテキストを作成したディレクティブの名前をつけて<ディレクティブ名>コンテキストと呼ぶ。たとえばhttpというディレクティブは、webサーバーの設定を記述するためのコンテキストを作成し、httpディレクティブで作成されたコンテキストを「httpコンテキスト」と呼ぶ。

コンテキストは以下のように書ける。

# '#'から行末までコメント

nginxの本体の設定(mainコンテキスト)

events {
  イベント待ち関連のパラメータ
　}

htttp {
 webサーバー全体の設定
　　server {
     バーチャルホストの設定
　　　　　location … {
          URLのパス名ごとの設定
　　　　　}
    }
   server {
     バーチャルホストの設定
　　　　　location … {
          URLのパス名ごとの設定
　　　　　}
    }
}

ディレクティブにはそれぞれ、記述できるコンテキストが決まっている。httpディレクティブはmianコンテキスト、serverディレクティブはhttpコンテキストの中にしか書けない。また、locationディレクティブはserverコンテキストかlocationコンテキストの中にしかかれない

静的なwebサイトのserverコンテキストの例を以下に示す。

server {
  listen 80;
  serve_name stastic.example.com;
  access_log /var/log/nginx/stastic-access.log;
  error_log /var/log/nginx/stastic-error.log;

  location / {
     root /www/dir;
     index index.html index.htm;
  }
}