用語辞典・サーバー・Web運営

Nginx

Nginxとは

Nginxは、静的配信、リバースプロキシ、負荷分散などに広く使われるWebサーバーです。公式サイトは名称をnginx(engine x/エンジン・エックス)と表記し、HTTPサーバーのほか、コンテンツキャッシュ、TCP・UDPプロキシ、メールプロキシとしての機能も提供します。

多数の接続を、少数のワーカー処理がイベント駆動方式で扱う設計です。要求を静的ファイルへ対応させたり、FastCGIや背後のアプリへ転送したり、複数サーバーへ分配したりできます。

Nginxは「Webサイトを作る言語」ではありません。HTTP要求の受付・振り分け・転送・応答を担当し、動的な業務処理はPHP-FPMや別のアプリが行う構成が一般的です。

マスターが設定とワーカーを管理し、ワーカーが多数の接続イベントを静的棚・プロキシ・バックエンド群へ流す接続ごとに専用処理を増やすのではなく、イベントの準備ができた順に処理する
多数の端末から届く要求の粒を中央制御が四つのワーカーへ渡し、ワーカーが静的ファイル棚、プロキシ橋、複数バックエンドへ流すNginxのイベント駆動構造を示すピクトグラム図解
図1イベント駆動は待ち時間の多い接続を効率よく扱う設計です。アプリのCPU計算やデータベース処理が自動で速くなる意味ではありません。

要求は文脈と選択規則を通る

接続受付からサーバー・位置選択、コンテンツ処理、フィルター、ログまでの流れを分ける設定ファイルの上から単純に一行ずつ適用されるとは考えない
  1. 01
    待受けで受ける

    IP・ポートとプロトコル選択肢に合う接続をワーカーが受け、HTTPSならTLSを処理する。

  2. 02
    サーバーを選ぶ

    接続先とホスト名をサーバー_名前へ照合し、該当しなければ既定サーバーを使う。

  3. 03
    位置を選ぶ

    URIを完全一致、プレフィックス、正規表現などの規則で比較し、処理範囲を決める。

  4. 04
    コンテンツを得る

    静的ファイル、プロキシ_通過、fastcgi_通過、戻り値など、選ばれたコンテンツ処理ハンドラーを実行する。

  5. 05
    応答を整える

    圧縮、キャッシュ、ヘッダー、バッファー、範囲などのフィルターを適用し、クライアントへ送る。

  6. 06
    結果を記録する

    状態、バイト、処理時間、上流結果をアクセス・エラーログへ記録する。

図2内部リダイレクトや書き換えで位置選択がやり直される場合があります。複雑な規則は最小の構成で検証します。

マスター処理とワーカー処理を分ける

マスター処理は設定を読み、ポートを準備し、ワーカーの起動・終了・再読み込みを管理します。実際のクライアント要求はワーカー処理が処理します。通常はOS機能を使い、読み取り・書き込みの準備ができたイベントを効率よく進めます。

ワーカー数を増やせば無条件に速くなるわけではありません。CPU数、ワーカー接続、ファイル記述子、上流、ディスクI/O、TLS、アプリ処理を合わせます。上限へ達したときのエラーログとOS制限を確認します。

ディレクティブは文脈の中へ置く

Nginxの設定はsimpleディレクティブとブロックディレクティブから成り、主要の中にイベントとHTTP、HTTPの中にサーバー、サーバーの中に位置などの文脈を作ります。同じディレクティブでも置ける文脈が公式文書で決まっています。

含むで分割したファイルも、読み込んだ位置の文脈として解釈されます。Apacheの.htaccessのようにコンテンツディレクトリーから要求ごとに分散設定を読む方式ではなく、通常は管理者が中央設定を編集して再読み込みします。

ルートと別名はURIの結び方が違う

ルートは選ばれた位置のURIを基準パスへ追加してファイルを探します。別名は位置に対応するファイルシステムパスを置き換えます。末尾スラッシュやキャプチャーの扱いを誤ると、別のファイルを返したり404になったりします。

ディレクトリー横断を防ぐため、利用者入力をそのままパスや別名へ連結しません。symbolicリンク、索引、autoindex、内部ファイルの拡張子、ファイル権限を確認します。

逆プロキシはクライアントとバックエンドを分離する

プロキシ_通過で要求をバックエンドへ送り、返った応答をクライアントへ返します。TLS終端、認証、キャッシュ、圧縮、統一ログ、複数アプリのパス分割を前段へまとめられます。

元のHost、スキーム、クライアントIPをバックエンドへ伝えるヘッダーを明示します。バックエンドは、Nginxなど信頼するプロキシから来た転送ヘッダーだけを信頼します。要求・応答buffering、本文大きさ、タイムアウトを用途に合わせ、長いアップロードやストリーミングを一律設定にしません。

上流で複数バックエンドへ分配する

上流グループへ複数サーバーを登録し、既定のラウンドロビン、最小権限のconnections、ハッシュなどで要求を分けられます。weight、障害判定、バックアップ、接続再利用なども構成できます。

同じ利用者を同じバックエンドへ固定する必要があるならセッション永続化を検討しますが、可能ならセッションを外部保存へ置き、どのバックエンドでも処理できる設計にします。ヘルスチェックがポート接続だけなら、アプリや依存先の故障を見逃すことがあります。

PHPはFastCGIへ渡す

PHPを使う構成では、対象URIをPHP-FPMなどのFastCGI処理へ渡します。実行するスクリプトパス、要求パラメーター、タイムアウト、応答bufferingを設定します。

存在しないPHPパスを不適切に分割すると、意図しないスクリプトを実行する危険があります。実ファイルの存在確認、正しいSCRIPT_FILENAME、アップロードディレクトリーでのスクリプト実行禁止を組み合わせます。

キャッシュは鮮度とプライベート情報を制御する

プロキシ応答をキャッシュすればバックエンド負荷と遅延を減らせますが、Cookie・認可・利用者別応答を共有キャッシュへ入れると情報が混ざります。キャッシュ鍵、迂回、no-cache、期限、削除手順を決めます。

Cache-Controlなどオリジンの指示とNginx側の上書きを対応させます。設定変更後に古いキャッシュが残る場合を想定し、削除またはバージョン付きURLを使います。

構文検査後に再読み込みする

設定変更は設定試験で構文と参照ファイルを確認してから再読み込みします。マスターは新しいワーカーを起動し、古いワーカーは既存処理を終えて退出するため、設定だけなら停止を抑えて反映できます。

証明書、秘密鍵、含む、DNS名前解決、権限、バックエンド疎通などは構文が正しくても失敗します。反映直後にエラーログ、試験要求、監視を確認し、前の設定へ戻せるようにします。

Nginxの調査では、どのサーバーが選ばれ、どの位置が選ばれ、静的・プロキシ・FastCGIのどれがコンテンツを作り、上流が何を返したかを順に追います。

Nginxの確認資料:nginx Official SiteBeginner’s GuideHow nginx processes a requestHTTP Load Balancing

関連用語