スケーラブルなnginx構成

イゴール・シソエフ（ isysoev ）

私の名前はIgor Sysoevです。nginxの著者であり、同じ名前の会社の共同設立者です。



オープンソースの開発を続けています。 会社の設立以来、多くの人々が製品に取り組んでいるため、開発のペースが大幅に向上しています。 オープンソースの一部として、 有料サポートを提供しています。



スケーラブルなnginx構成について説明しますが、nginxを構成する必要がないため、nginxを使用して数十万の同時接続を処理する方法については説明しません。 適切な数のワークフローを設定するか、「自動」モードに設定し、worker_connectionsを100,000接続に設定する必要があります。その後、nginxを設定するよりもはるかにグローバルにカーネルを調整します。 したがって、別のスケーラビリティについて説明します-nginx構成のスケーラビリティ、つまり 数百行から数千行への構成の拡大を保証すると同時に、この構成を維持するために最小限の（好ましくは一定の）時間を費やす方法について。







なぜ、実際にそのような話題が生じたのですか？ 約15年前、私はRamblerで働き始め、サーバー、特にApacheの管理を始めました。 また、Apacheにはこのような不快な機能があります。これは、次の2つの構成でよく示されています。







ここには2つの場所があり、順番は異なります。 使用されている構成に応じて、同じ要求が異なるファイル（phpファイルまたはhtmlファイル）によって処理されます。 つまり、Apache構成を使用する場合、順序が重要です。 そして、これは元に戻すことはできません-要求を処理するとき、Apacheはすべてのlocation'amを通過し、何らかの形でこの要求に一致するものを見つけようとし、これらすべてのlocation'ovから構成を収集します。 彼はそれをマージし、最終的に結果を使用します。



これは、構成が小さい場合に便利です。したがって、構成をさらに小さくすることができます。 しかし、成長するにつれて、次の問題が発生します。 たとえば、最後に新しい場所を追加する場合はすべて機能しますが、その後、構成を中央で変更するか、関係のない場所を中央から外す必要があります。 これらの場所の後に設定全体を見て、すべてが以前と同じように機能し続けることを確認する必要があります。 したがって、構成はカードの家に変わります。1枚のカードを引き出すと、構造全体が台無しになります。



apacheでは、設定に地獄を追加するために、同じように機能するいくつかのセクションがあり、それらは異なる順序で処理されますが、1つの結果設定がそれらすべてから収集されます。 これらはすべてランタイムで実行されます。 多くのモジュールがある場合、各モジュール構成でマージされます（一部のテストでは、nginxは実行時に構成をマージしないため、一部のテストではnginxがapacheより高速である理由が部分的に説明されます）。 これらのセクションの一部とほとんどのディレクティブは、サイト全体に散らばる.htaccessファイルに配置できます。あなたと同僚の生活をさらに面白くするために、これらのファイルの名前を変更して、この構成を検索できます...



また、「ケーキの上のチェリー」はRewriteRulesであり、構成をsendmailのように見せることができます。 幸いなことに、ほとんどの人はもはやそれが何であるかを知らないので、ユーモアを評価する人はほとんどいませんでした。



RewriteRulesは一般に悪夢です。 多くの管理者は、共有ホスティングのapache管理のバックグラウンドほどapacheのバックグラウンドではありません。 唯一の管理ツールが.htaccessだったとき。 そして、その中で非常に複雑なRewriteRulesを作成します。これは、構文の長所と論理の長所の両方によって理解するのが非常に困難です。



これはapacheの欠点の1つであり、非常に悩みました。十分な大きさの構成を作成できませんでした。 nginxの開発中に、これを変更したかったため、Apacheの多くの迷惑な機能を修正し、独自の機能を追加しました。 これは、nginxの前の例のようなものです。







Apacheとは異なり、場所の順序に関係なく、リクエストは同じ方法で処理されます。 nginxは、正規表現で指定されていないプレフィックスの場所との可能な最大一致を探してから、この場所を選択します。 選択した場所の構成が使用され、他のすべての場所は無視されます。 このアプローチにより、数百の場所で構成を記述でき、これが他のすべてにどのように影響するかを考える必要がなくなります。 ある種のコンテナを取得します。 1つの小さな場所で処理を分離します。



nginxがリクエストを処理するときに使用する設定をどのように選択するかを検討してください。 最初のステップは、適切なサーバーのサブクエリを探すことです。 選択は、最初にアドレスとポートに基づいて行われ、次に指定されたアドレスとポートに関連付けられているすべてのサーバー名に基づいて行われます。



たとえば、サーバーを複数のアドレスに配置し、そこに多数のサーバー名を書き込み、これらすべてのサーバー名をすべてのアドレスで機能させる場合は、すべての名前でアドレスを複製する必要があります。 サーバーが選択された後、適切な場所がサーバー内で検索されます。 最初に、すべてのプレフィックスロケーションがチェックされ、最大一致が検索され、次に正規表現で指定されたロケーションが存在するかどうかがチェックされます。 正規表現の最大一致を判別できないため、最初に正規表現が一致する場所を選択します。 その後、この場所の構成名が使用されます。 一致する正規表現がない場合、前に見つかった、最も一致するプレフィックスを持つ構成が使用されます。



正規表現は順序依存性を追加するため、サポートが不十分な構成が作成されます。これは、人生が理論よりも複雑であり、多くの場合、サイト構造が多数の静的ファイル、スクリプトなどからのダンプであり、この場合すべてを解決する唯一の方法であるためですクエリは正規表現です。







このスライドは、それをしない方法を示しています。 そのようなサイトがすでにある場合は、それらをやり直す必要があります。



構成処理の順序について話したとき、それは元の設計でした。 その後、ロケーション内のロケーションを記述することが可能になりました。 包括的な場所、および順序は少し適応しています。 つまり 最初に、最大一致プレフィックスロケーションが検索され、次にその内部で最大一致プレフィックスロケーションが検索されます。 このような再帰的な検索は、これ以上何もない場所に到達するまで続きます。



その後、逆順の正規表現で場所のチェックを開始します。 最もネストされた場所を入力しました。そこに正規表現があるかどうかを確認します。 そうでない場合は、下位レベルなどに進みます。 繰り返しますが、正規表現で最初に一致した場所が「勝ちます」。 このアプローチにより、次の処理を行うことができます。







ここには正規表現を使用した2つの場所がありますが、リクエスト/admin/index.phpの場合、ネストされた最初の場所が選択され、2番目の場所は選択されません。



また、正規表現検索の2番目の部分は、^〜で場所をマークすることで無効にできます。







このような禁止は、この場所が最大一致を示した場合、その後に正規表現が検索されないことを意味します。



多くの場合、人々は構成を小さくしようとします。 構成の一般的な部分を取り出し、そこにリクエストをリダイレクトするだけです。 たとえば、ここではすべてをPHP処理に投入する非常に悪い方法です。







Nginxには、構成の一般的な部分を強調表示する他の方法があります。 まず、前のレベルから構成を継承します。 たとえば、ここでは、すべてのサーバーとすべての場所に対して、httpレベルでsendfileを有効にできます。







この構成は、ネストされたすべてのサーバーと場所に継承されます。 たとえば、ファイルシステムがサポートしていないなどの理由で、sendfileをキャンセルする必要がある場合は、特定の場所または特定のサーバーでsendfileをオフにすることができます。



または、たとえば、サーバーの場合、再定義する必要がある共通ルートを作成できます。



このアプローチは、場所に影響を与える可能性のある共通の部分を探す必要がある特定の場所を知っているという点で、Apacheとは異なります。



共有できない唯一のことは、たとえば、httpレベルでその場所を記述できないことです。 これは意図的に行われました。 Apacheではこれを実行できますが、使用すると多くの問題が発生します。



個人的には、構成で場所を明示的に説明することを好みます。 これを行いたくない場合は、外部ファイルを介して含めることができます。







今、私は人々が書くことを少なくしたい理由、つまり なぜ彼らは共有構成を急いでいます。 彼らはより少ない努力を費やすと信じています。 実際、人々はより少ない時間を費やすよりも書くことを望んでいます。 しかし、彼らは未来については考えていませんが、彼らが今書くことを少なくすれば、それは同じままであると信じています...



適切なアプローチは、コピーと貼り付けを使用することです。 つまり、ロケーション内には、その処理に必要なすべてのディレクティブが必要です。



DRY（Do n’t Repeat Yourself）愛好家の通常の主張は、何かを修正する必要がある場合、1か所で修正すればすべてがうまくいくということです。



実際、最新のエディターには検索置換機能があります。 たとえば、バックエンドの名前/ポートを修正したり、ルート、バックエンドに渡されるヘッダーなどを変更したりする必要がある場合は、findを使用してこれを安全に行うことができます。



特定の場所でパラメータを変更する必要があるかどうかを理解するには、数秒で十分です。 たとえば、100の場所がある場合、各場所に2秒を費やし、合計で200秒かかります。 〜3分 これは少しです。 しかし、将来的に共通部分からいくつかの場所を解く必要がある場合、それははるかに複雑になります。 変更するもの、他の場所にどのように影響するかなどを理解する必要があります。 したがって、nginxの構成に関しては、コピーと貼り付けを使用する必要があります。



一般的に、管理者は構成に多くの時間を費やすことを好みません。 私自身もそうです。 管理者は2〜3個のお気に入りの製品を使用できますが、時間をかけたくない製品は他にもたくさんあります。 たとえば、個人用サイトにメールがあります。これはExim、Dovecotです。 私はそれらを管理するのは好きではありません。 それらを機能させたいだけで、何か追加する必要がある場合は数分で完了します。 私は設定を学ぶのが面倒だし、ほとんどのnginx管理者は同じだと思う、彼らはできるだけngnixを管理したくない、彼らが動作することが重要です。 あなたがそのような管理者である場合は、コピーと貼り付けを使用してください。



短い非スケーラブル構成を必要なものに変換する方法の例：







ここで、人は正規表現を書いたと思います。ほんの数個しかなく、すべてが順調です。 実際、 正規表現がありますが、それは悪いです-それは他のすべてに影響を与える可能性があります。 したがって、個人的には、私はこれが好きです：







このルートがすべての場所に共通している場合、または少なくともほとんどの場所で使用されている場合は、これを行うこともできます。







これは、一般に、正当な構成です。 完全に空のロケーション設定。



コピーアンドペーストを回避する2番目の方法は、次の例です。







Apacheを使用していた管理者は、admin / index.phpが認証を要求する必要があると考えています。 nginxでは、これは機能しません。 index.phpは1つの場所で処理され、場所/管理者は完全に異なります。 ただし、ネストされた構成を作成すると、index.phpは自然に認証を要求します。



多くの場合、URLの一部を「バイト」して処理で使用するには、正規表現を使用する必要があります。 これは悪い方法です。







そうです-ネストされた場所を使用して、サイトの残りの構成から正規表現を分離します。 画面に配置されたこの場所/ img /を超えて、コントロールは消えません。







nginxで正規表現を使用しても安全な別の場所はマップです。 正規表現などを使用して、他のいくつかの変数に基づいて変数を生成します。







Rewriteを使用する必要はまったくないため、Rewriteの使用については何も言いませんでした 。 使用できない場合は、バックエンド側で使用してください。



また、悪はnginxの推奨設計ではありません。世界中の10人が悪が内部でどのように機能するかを知っているからです。



if（true）が2つある場合の構成を次に示します。







gzipとetagがオフにされると予想されます。 実際、最後のifのみが機能します。



ifの安全な使用方法の1つは、クライアントに応答を返すために使用する場合です。 あなたはこの場所で書き換えを使用できますが、私はそれが好きではありません、私はリターンを使用します（コードを追加することができますなど）：







要約すると：

• プレフィックスの場所のみを使用することをお勧めします。
• 構成に正規表現がまだ必要な場合は、正規表現を避けてください。正規表現を分離することをお勧めします。
• マップを使用します。
• DRYは普遍的なパラダイムであると言う人々の言うことを聞かないでください。 これは、製品が好きなとき、または製品をプログラムするときに便利です。 管理作業を簡単にするだけの場合は、コピーペーストが最適です。 あなたの友人は、優れた検索置換機能を持つ編集者です。
• 書き換えを使用しないでください。
• 何らかの種類の応答をクライアントに返す場合にのみifを使用します。

聴衆からの質問： httpsでrewrites httpを使用する場合、nginxまたはバックエンドでそれを使用する方が良いでしょうか？



回答： nginxで使用してください。 理想的には、2つのサーバーを実行します。 プレーンテキストサーバーが1つあり、書き換えのみを行います。 この場所には、文字通りいくつかのディレクティブがあります。サーバーは、必要に応じてポート、サーバー名でリッスンし、リクエストURIを複製してhttpsで301または302に戻ります。 そこでは、書き換えさえ必要ないので、returnを使用します。



もっと複雑なことをしたい場合は、どこかにifを挿入できます。 場所の一部をプレーンテキストで作成し、たとえば、マップ内の正規表現を使用してそれらを記述し、他のすべてをhttpsにリダイレクトできるとします。 または、逆に、各ロケーション内に1つを挿入すると、httpsにリダイレクトされます。



聴衆からの質問： nginxに感謝します。 少し遊び心のある質問があります。 include 'ディレクティブの使用を妨げるスタートアップキーまたはコンパイルキーを追加する予定はありませんが、location'ahでの正規表現の使用は許可されませんか？



回答：いいえ、ほとんどありません。 通常、いくつかのディレクティブを追加し、それらを改善してから廃止します。 完全に消えるまでしばらくログに警告を表示しますが、いくつかのモードで動作します。 あなたが言ったことをするつもりはありません。おそらくこのプレゼンテーションの資料に基づいて、良いユーザーガイドを書くほうが良いでしょう。



聴衆からの質問： ifを使用するときに生じる通常の欲求は、サーバーと場所で使用でき、マップを使用できないためです。 なぜこれが起こったのですか？



回答： nginxのすべての変数はオンデマンドで計算されます。 マップがhttpレベルで記述されている場合、これはリクエストを処理するときにこの変数が必ず計算されるという意味ではありません。 何かを1つにマッピングし、次に何かを1つから別のマッピングするために、Mapが必要です。また、結果の変数をif式またはif式で使用したり、どこかでプロキシしたりできます。 マップは宣言のようなものです...たぶん、同じ変数を持っている場合、サーバーに対してローカルにするためにそれらをサーバーに移動するのが理にかなっています。 そこでプログラムするのは難しいので、グローバルサーバーに移動しました。 nginxには、サーバー内でローカルになる変数はありません。



パフォーマンスの観点からは問題はありません。それは単に不便です。 たとえば、3つのサーバーと3つのマップを作成する必要があります。変数には接頭辞「server such and such」が付いています...原則として、サーバーの前でそれらを記述できます。 これらのマップ— 1つは最初のサーバーの前にあり、2つ目のサーバーの前にあります...構成によって、上下にジャンプする必要はなく、サーバーにより近くなります。



聴衆からの質問：私は復帰作業の論理に慣れていない。 書き換えの代わりにリターンを使用する価値がある場所を教えてください、いくつかのユースケース固有ですか？



回答：一般に、書き換えは次のような構造に置き換えられます。キャプチャ、選択、およびreturnディレクティブなど、いくつかのキャプチャを作成できる正規表現の場所。 つまり 1つの書き換えはその場所の左側の部分であり、右側の部分は応答コードの後に​​戻る部分です。 Returnは、異なる応答コードを返す機能を提供し、リライトではクライアントに戻るのは301、302のみです。Returnは、何らかのボディ（おそらく200、500）で404を返すことができ、リダイレクトを返すことができます。 そして彼の体では、変数を使用して何かを書くことができます。 301、302の場合、これは本文ではなく、すでにリダイレクトが必要なURLです。 一般的に、リターンにはより豊富な機能があります。



聴衆からの質問：適用された質問があります。 Nginxはメールプロキシとして使用できます。 メールクライアントへのSMTPアクセスを許可し、このメールクライアントを介してレターを送信し、nginxでメールWebサーバーをバイパスしてデータをインターセプトしてスクリプトに送信することは可能ですか？ 現在、postfixを使用してこのタスクを実現しています。メッセージをインターセプトしてから、処理が行われるスクリプトにスローします。



回答：これはnginxを使用して実行できるとは思いません。 SMTPプロキシがnginxに持っている機能を簡単に説明できます。 彼は次の方法を知っています-SMTPクライアントがそれに接続し、認証を表示し、nginxが外部スクリプトに移動し、ユーザー名とパスワードを確認してから、クライアントをサーバーに移動させます（そしてサーバーを転送します）。させないでください。 彼ができることはそれだけです。 どこかで起動することにした場合、nginxはSMTP経由でこのサーバーに接続し、サーバーに渡します。 これがあなたのシナリオに当てはまるかどうかは言えません。 ほとんどない。



Ramblerには、これらのクライアントがメールを送信するためのメールクライアント用の特別なサーバーがあるため、許可付きのSMTPプロキシが登場しました。 そして、接続の約90％がRamblerのクライアントではなく、スパムとウイルスであることが判明しました。 ポストフィックスをオーバーロードしないように、不要なプロセスを発生させないように、nginxをその前に置き、このクライアントが認証データを提供するかどうかをチェックします。 実際、これはこれのために行われました-「ごみ」の顧客を打ち負かすためだけです。



聴衆からの質問：今日、コンテナについて言及しましたが、これはもちろん有望なアプローチですが、トポロジーと動的構成の変化を意味します。 これは、トポロジーの変更イベントに定期的に応答し、テンプレートを介して実際のnginx構成を生成し、手のひらでそれをキックして構成を再集計する外部「クランチ」を構築しているという事実につながります。 興味深い-同社は、コンテナ化に向けた開発計画を立てています。 この傾向により便利で自然な手段を提供することに向けて？



回答：この場合のコンテナの意味に依存します。 , , , , location' .



: docker', - , , , , …



: NGINX+ Advanced Load Balancing, , , . , reload nginx', — API.



. open source nginx , , nginx , .. , . 50 , 5-10 ., , . NGINX+ , .. , .



: , , , , JSON- , ?



: , , , , JSON, html'.

連絡先

» isysoev

» Nginx

— HighLoad++ . 2016 — HighLoad++ , 7 8 .



DevOps , Express42 . , Nginx.



- HighLoad.Guide — , , , . 30 . !