分散型 - Nginx 負荷分散サーバー

この記事はWeChatの公開アカウントLing Haoyuから転載したものです。著者が許可しました。この記事を転載する場合は、Ling Haoyuの公式アカウントまでご連絡ください。

1. エヌギンス

1）。学習リソース

Nginx ドキュメント

Nginx の設定

2）。エンギンクス

Nginx は、メモリ使用量が少なく、強力な同時実行能力を特徴とする軽量の Web サーバー/リバースプロキシサーバーおよび電子メール (IMAP/POP3) プロキシサーバーです。 Nginx はロシア人によって書かれた非常に軽量な HTTP サーバーです。 Nginx (「エンジンエックス」と発音) は、高性能の HTTP およびリバースプロキシサーバーであり、IMAP/POP3/SMTP プロキシサーバーでもあります。 Nginx はロシア人の Igor Sysoev 氏によって、ロシアで 2 番目に訪問者数の多いサイトである Rambler.ru 向けに開発され、2 年半以上にわたって稼働しています。このプロジェクトは、BSD ライセンスに基づいて Igor Sysoev によって作成されました。

[[260565]]

3）。 Nginxの機能

HTTP サーバーとして、Nginx には次の基本機能があります。

静的ファイル、インデックスファイル、自動インデックス処理を処理します。ファイル記述子のバッファリングをオンにします。
非キャッシュリバースプロキシアクセラレーション、シンプルな負荷分散、フォールトトレランス。
FastCGI、シンプルな負荷分散、フォールトトレランス。
モジュール構造。 gzipping、バイト範囲、チャンク化された応答、SSI フィルターなどのフィルターが含まれます。 1 つのページ内の複数の SSI が FastCGI または別のプロキシサーバーによって処理される場合、処理は互いに待機することなく並行して実行できます。
SSL および TLSSNI をサポートします。

Nginx はパフォーマンスの最適化のために特別に開発されました。パフォーマンスは最も重要な考慮事項であり、その実装では効率性に重点が置かれています。カーネルポールモデルをサポートしており、高負荷のテストにも耐えることができます。最大 50,000 の同時接続をサポートできるという報告があります。

Nginx は安定性が高いです。他の HTTP サーバーでは、アクセスのピークが発生したり、誰かが悪意を持って低速接続を開始したりすると、サーバーの物理メモリが枯渇して頻繁にスワップが発生し、応答が失われてサーバーを再起動しなければならない場合があります。たとえば、Apache プロセスの数が 200 を超えると、Web の応答速度が大幅に低下します。 Nginx は段階的なリソース割り当てテクノロジーを採用しており、CPU とメモリの使用量が非常に低くなります。 Nginx は公式には 10,000 の非アクティブな接続を維持でき、メモリを 2.5 MB しか消費しないと述べているため、DOS のようなものは基本的に Nginx には役に立ちません。安定性の点では、Nginx は lighthttpd よりも優れています。

Nginx はホットデプロイメントをサポートしています。起動は非常に簡単で、数か月間再起動せずに実行した後でも、ほぼ 24 時間 365 日中断することなく実行できます。サービスを中断することなくソフトウェアのバージョンをアップグレードすることもできます。

Nginx はマスタースレーブモデルを採用しており、SMP の利点を最大限に活用し、ディスク I/O での作業プロセスのブロック遅延を削減できます。 select()/poll() 呼び出しを使用する場合、プロセスあたりの接続数を制限することもできます。

Nginx コードの品質は非常に高く、コードは非常に標準化されており、技術は成熟しており、モジュールの拡張も簡単です。特に言及する価値があるのは、強力なアップストリームとフィルターチェーンです。 Upstream は、リバースプロキシなどのモジュールの作成や他のサーバーとの通信に適した基盤を提供します。フィルターチェーンの最も優れた点は、各フィルターが前のフィルターの実行が完了するまで待つ必要がないことです。前のフィルターの出力を現在のフィルターの入力として使用することができ、これは Unix パイプラインに少し似ています。これは、モジュールがバックエンドサーバーから送信された要求の圧縮を開始し、バックエンドサーバーから要求全体を受信する前に、圧縮されたストリームをクライアントにリダイレクトできることを意味します。

Nginx は、sendfile (Linux2.2+)、accept-filter (FreeBSD4.1+)、TCP_DEFER_ACCEPT (Linux 2.4+) のサポートなど、オペレーティングシステムによって提供されるいくつかの新機能を使用しており、パフォーマンスが大幅に向上しています。

4）。リバースプロキシ

エージェントは代表者であり、チャネルです。このとき、プロキシロールとターゲットロールの 2 つのロールが設計されます。プロキシロールがエージェントを介してターゲットロールにアクセスし、いくつかのタスクを完了するプロセスをエージェント操作プロセスと呼びます。

I. フォワードプロキシの典型的な特徴は、クライアントがアクセスしたいサーバーのアドレスを明確に把握していることです。サーバーは、リクエストがどのプロキシサーバーから送信されたかは認識しますが、リクエストがどの特定のクライアントから送信されたかは認識しません。フォワードプロキシモードでは、実際のクライアント情報が保護または非表示になります。

II. nginx サーバーは、複数のクライアントからサーバーに送信されたリクエストを受信すると、それらをバックエンドのビジネス処理サーバーに配布し、特定のルールに従って処理します。この時点では、リクエストのソース、つまりクライアントは明らかですが、どのサーバーがリクエストを処理するかは明らかではありません。 Nginx はリバースプロキシの役割を果たします。リバースプロキシは主に、サーバークラスターの分散展開の場合に使用されます。リバースプロキシはサーバー情報を隠します!ウェブサイトの機能のほとんどは、リバースプロキシに nginx を使用して直接実装されています。 nginxと他のコンポーネントをカプセル化した後、それはTengineという高尚な名前を持っています。

III.通常、実際のプロジェクトを運用する場合、フォワードプロキシとリバースプロキシが同じアプリケーションシナリオ内に存在する可能性が高くなります。フォワードプロキシは、クライアントのターゲットサーバーへのアクセス要求をプロキシします。対象サーバーは、複数の実際の業務処理サーバーをリバースプロキシするリバースプロキシサーバーです。具体的なトポロジー図は次のとおりです。

5) 負荷分散

クライアントから送信され、nginx リバースプロキシサーバーが受信したリクエストの数 (負荷) を、一定のルール (バランシングルール) に従って異なるサーバーに分散して処理し、サーバーが受信したリクエストをルールに従って分散する処理を負荷分散と呼びます。

実際のプロジェクト運用プロセスでは、ハードウェア負荷分散とソフトウェア負荷分散の 2 種類の負荷分散が存在します。ハードウェアロードバランシングは、F5 ロードバランシングなど、ハードロードとも呼ばれます。比較的高価ですが、データの安定性とセキュリティは非常によく保証されています。中国移動や中国聯通などの企業は、運用にハードロードを選択します。コスト上の理由からソフトウェア負荷分散を選択する企業が増えるでしょう。ソフトウェアロードバランシングは、既存のテクノロジとホストハードウェアを組み合わせたメッセージキュー分散メカニズムです。

負荷分散スケジューリングアルゴリズムは次のとおりです。

重み付けポーリング (デフォルト): 受信したリクエストは順番に 1 つずつ異なるバックエンドサーバーに割り当てられます。使用中にバックエンドサーバーがダウンした場合でも、nginx は自動的にサーバーをキューから削除するため、リクエストの受け入れにはまったく影響がありません。このようにして、異なるバックエンドサーバーに重み値 (weight) を設定し、異なるサーバー上の要求の割り当て率を調整できます。重みデータが大きいほど、リクエストに割り当てられる可能性が高くなります。重み値は主に、実際の作業環境におけるさまざまなバックエンドサーバーのハードウェア構成に応じて調整されます。
ip_hash: 各リクエストは、開始クライアントの IP アドレスのハッシュ結果に従って照合されます。このアルゴリズムでは、固定 IP アドレスを持つクライアントは常に同じバックエンドサーバーにアクセスするため、クラスター展開環境でのセッション共有の問題もある程度解決されます。
fair: スケジューリングアルゴリズムをインテリジェントに調整し、バックエンドサーバーが処理して応答するまでの時間に基づいて、リクエストを動的に均等に分散します。応答時間が短く、処理効率が高いサーバーにはリクエストが割り当てられる可能性が高く、応答時間が長く、処理効率が低いサーバーにはリクエストが割り当てられる可能性が低くなります。これは、最初の 2 つの利点を組み合わせたスケジューリングアルゴリズムです。ただし、nginx はデフォルトでは公平なアルゴリズムをサポートしていないことに注意してください。このスケジューリングアルゴリズムを使用する場合は、upstream_fairモジュールをインストールしてください。
url_hash: アクセスした URL のハッシュ結果に従ってリクエストを割り当てます。要求された各 URL はバックエンドの固定サーバーを指すため、nginx を静的サーバーとして使用するとキャッシュ効率が向上します。また、nginx はデフォルトではこのスケジューリングアルゴリズムをサポートしていないことにも注意してください。使用したい場合は、nginxハッシュパッケージをインストールする必要があります

6）。 Windows のインストール

I. Nginxをダウンロードして解凍する

II. nginx.exe をダブルクリックし、ブラウザで http://localhost/ にアクセスします。

III.コマンドライン起動

nginx

IV.コマンドラインシャットダウン

# nginx サーバーを強制停止します。未処理のデータがある場合は破棄します。
 nginx -s 停止
# nginx サーバーを正常に停止します。未処理のデータがある場合は、処理が完了するまで待ってから停止してください。
 nginx -s 終了

7）。 nginx の設定

nginx サーバーの設定情報は、主に設定ファイル nginx.conf (\nginx-1.14.0\conf\nginx.conf) に集中しています。

 main # グローバル設定
 
 events { # nginx 動作モード設定
 
 } 
 
 http { # http設定
    .... 
 
    server { # サーバーホストの設定
        ....
        location { # ルーティング設定
            ....
        } 
 
        ロケーションパス {
            ....
        } 
 
        場所その他のパス{
            ....
        }
    } 
 
    サーバー{
        .... 
 
        位置 {
            ....
        }
    } 
 
    アップストリーム名{ # 負荷分散設定
        ....
    }
 }

main: nginxのグローバル情報を設定するために使用されます
イベント: nginx の動作モードの設定に使用されます
http: httpプロトコル情報を設定するために使用されます
サーバー: サーバーアクセス情報を構成するために使用します
場所: アクセスルートの設定に使用
アップストリーム: 負荷分散構成に使用

I. メインモジュール

#ユーザーnobody nobody;
ワーカープロセス 2;
 # error_log ログ/error.log
 # error_log ログ/error.log 通知
# error_log ログ/error.log 情報
# pid ログ/nginx.pid
ワーカー_rlimit_nofile 1024;

ユーザーは、nginx ワーカープロセスのユーザーとユーザーグループを指定するために使用されます。デフォルトのアカウントはnobodyです。
worker_processes は、nginx が開始する子プロセスの数を指定します。動作中は各プロセスのメモリ消費量（通常は数MBから数十MB）を監視し、実際の状況に応じて調整します。通常、その数は CPU コアの数の整数倍になります。
error_log はエラーログファイルの場所と出力レベルを定義します [debug / info / notice / warn / error / crit]
pidはプロセスIDの保存ファイルの場所を指定するために使用されます
worker_rlimit_nofileは、プロセスが開くことができるファイルの最大数を指定するために使用されます。

II.イベントモジュール

イベント {
    ワーカー接続 1024;
    multi_acceptオン;
    epoll を使用します。
 }

worker_connections は、同時に受信できる接続数の上限を指定します。上限はワーカープロセスとともに決定されることに注意することが重要です。

multi_accept 設定は、nginx が新しい接続通知を受け取った後、できるだけ多くの接続を受け入れるように指定します。

use epoll 構成は、スレッドのポーリング方法を指定します。 Linux 2.6 以上の場合は epoll を使用します。 MacなどのBSDの場合はKqueueを使用してください

III. http モジュール

Webサーバーとして、httpモジュールはnginxのコアモジュールであり、多くの設定項目があります。プロジェクトでは実際のビジネスシナリオが多数設定され、ハードウェア情報に応じて適切な構成を行う必要があります。通常の状況では、デフォルト設定を使用できます。

 http {
    ##
    # 基本設定
    ## 
 
    ファイル送信オン;
    tcp_nopushオン;
    tcp_nodelayオン;
    キープアライブタイムアウト65;
    タイプハッシュの最大サイズは2048です。
    # server_tokensオフ; 
 
    # server_names_hash_bucket_size 64;
    # server_name_in_redirectオフ; 
 
    /etc/nginx/mime.types を含めます。
    デフォルトタイプ アプリケーション/オクテットストリーム; 
 
    ##
    # SSL証明書の設定
    ## 
 
    ssl_プロトコル TLSv1 TLSv1.1 TLSv1.2; # SSLv3 の削除、参照: POODLE
    ssl_prefer_server_ciphersオン; 
 
    ##
    # ログ設定
    ## 
 
    アクセスログ /var/log/nginx/access.log;
    エラーログ /var/log/nginx/error.log; 
 
    ##
    # Gzip 圧縮設定
    ## 
 
    gzipオン;
    gzip_disable "msie6" ; 
 
    # gzip_varyオン;
    # gzip_proxied任意;
    # gzip_comp_level 6;
    # gzip_buffers 16 8k;
    # gzip_http_バージョン 1.1;
    # gzip_types テキスト/プレーン テキスト/css アプリケーション/json アプリケーション/javascript
    text/xml アプリケーション/xml アプリケーション/xml+rss text/javascript; 
 
    ##
    # 仮想ホストの設定
    ## 
 
    /etc/nginx/conf.d/*.conf をインクルードします。
    /etc/nginx/sites-enabled/* を含めます。
 }

=> 基本設定

sendfile オン: オンに設定すると、sendfile が機能し、ファイルの書き戻しプロセスがアプリケーションではなくデータバッファーによって完了するようになり、パフォーマンスが向上します。
tc_nopush on: nginx に、ヘッダーを 1 つずつ送信するのではなく、すべてのヘッダーを 1 つのパケットで送信するように指示します。
tcp_nodelay on: nginx にデータをキャッシュせず、少しずつ送信するように指示します。リアルタイムのデータ転送が必要な場合は設定できます。小さなデータを送信するとすぐに戻り値を取得できます。しかし、乱用しないでください。
keepalive_timeout 10: クライアントに接続タイムアウトを割り当てます。この時間が経過すると、サーバーは接続を閉じます。一般的に、セットアップ時間が短くなるため、nginx をより継続的に動作させることができます。
client_header_timeout 10: リクエストヘッダーのタイムアウトを設定する
client_body_timeout 10: リクエストボディのタイムアウトを設定する
send_timeout 10: クライアント応答タイムアウトを指定します。 2 つのクライアント操作間の間隔がこの時間を超えると、サーバーは接続を閉じます。
limit_conn_zone $binary_remote_addr zone=addr:5m: さまざまなキーを格納するために使用される共有メモリのパラメータを設定します。
limit_conn addr 100: 指定されたキーの接続数の上限を設定します
server_tokens: nginx の実行速度は上がりませんが、エラーページで nginx バージョンのプロンプトをオフにすることができます。これは、Web サイトのセキュリティの向上に役立ちます。
include /etc/nginx/mime.types: 現在のファイルに別のファイルを含めるための指示を指定します
default_type application/octet-stream: デフォルトのファイルタイプがバイナリであることを指定します
type_hash_max_size 2048: データが混乱し、3 列の競合率に影響します。値が大きいほど、メモリの消費量が多くなり、ハッシュキーの競合率が低くなり、取得速度が速くなります。値が小さいほど、占有されるメモリが少なくなり、競合率が高くなり、検索速度が遅くなります。

=> ログ構成

access_log logs/access.log: アクセス記録を保存するためのログを設定します
error_log logs/error.log: エラーを保存して記録するためのログを設定します

=> SSL証明書の暗号化

ssl_protocols: このディレクティブは、特定の暗号化プロトコルを開始するために使用されます。バージョン 1.1.13 および 1.0.12 以降の nginx のデフォルトの ssl_protocols は、SSLv3、TLSv1、TLSv1.1、TLSv1.2 です。 TLSv1.1 および TLSv1.2 の場合、OpenSSL >= 1.0.1 であることを確認してください。 SSLv3 は今でも多くの場所で使用されていますが、多くの脆弱性があります。
ssl はサーバー暗号を優先します: ネゴシエートされた暗号化アルゴリズムを設定するときに、クライアントブラウザーの暗号化スイートではなく、サーバーの暗号化スイートを優先します。

=> 圧縮設定

gzip は、nginx にデータを gzip 圧縮形式で送信するように指示します。これにより、送信されるデータの量が削減されます。
gzip_disable は指定されたクライアントの gzip 機能を無効にします。ソリューションの幅広い互換性を確保するため、IE6 以下に設定しました。
gzip_static は、圧縮する前に事前に gzip されたリソースを検索するように nginx に指示します。これには、ファイルを事前に圧縮する (この例ではコメントアウト) 必要があり、これにより、高い圧縮率を使用できるようになるため、nginx がファイルを再度圧縮する必要がなくなります。
gzip_proxied は、リクエストとレスポンスに基づいてレスポンスストリームの圧縮を有効または無効にします。これを any に設定すると、すべてのリクエストが圧縮されます。
gzip_min_length は、データの圧縮を有効にするための最小バイト数を設定します。リクエストが 1000 バイト未満の場合は、そのような小さなデータを圧縮すると、このリクエストを処理するすべてのプロセスの速度が低下するため、圧縮しないことをお勧めします。
gzip_comp_level はデータの圧縮レベルを設定します。このレベルは 1 ～ 9 の任意の値に設定できます。9 は速度は遅くなりますが、圧縮率は高くなります。私たちはそれを 4 に設定しました。これは良い妥協点です。
gzip_type は圧縮する必要があるデータ形式を設定します。

=> ファイルキャッシュの設定

open_file_cache はキャッシュを開くときに、キャッシュの上限とキャッシュ時間も指定します。比較的長いキャップ時間を設定すると、20 秒間操作がないとクリアされます。
open_file_cache_valid は、open_file_cache 内の情報が正しいかどうかを確認する間隔を指定します。
open_file_cache_min_uses は、open_file_cache ディレクティブパラメータの非アクティブ時間中に使用できるファイルの最小数を定義します。
open_file_cache_errors は、ファイルを検索するとき、またファイルを構成に再度追加するときにエラーメッセージをキャッシュするかどうかを指定します。別のファイルで定義されているサーバーモジュールも含めます。サーバーモジュールがこれらの場所にない場合は、この行を変更して正しい場所を指定する必要があります。

IV.サーバーモジュール

srever モジュール構成は http モジュールのサブモジュールであり、仮想アクセスホスト、つまり仮想サーバーの構成情報を定義するために使用されます。

サーバー{
    聞く 80;
    サーバー名 ローカルホスト 192.168.1.100;
    ルート /nginx/www;
索引        インデックス.phpインデックス.htmlインデックス.html;
    文字セット utf-8;
    access_log ログ/access.log;
    error_log ログ/error.log;
    ......
 }

サーバー: 仮想ホストの構成。 1 つの http で複数のサーバーを構成できます。
server_name: 指定された IP アドレスまたはドメイン名を使用します。複数の構成を区切るにはスペースを使用します。
ルート: サーバー仮想ホスト全体のルートディレクトリ、現在のホスト内のすべてのWebプロジェクトのルートディレクトリを表します。
インデックス: ユーザーがウェブサイトにアクセスしたときに表示されるグローバルホームページ
charset: www/ パスで設定された Web ページのデフォルトのエンコード形式を設定するために使用されます。
access_log: 仮想ホストサーバー内のアクセスログの保存パスを指定するために使用されます
error_log: 仮想ホストサーバー内のアクセスエラーログの保存パスを指定するために使用されます

V. ロケーションモジュール

location モジュールは、nginx 設定の中で最も一般的な設定であり、主にルーティングアクセス情報を設定するために使用されます。ルーティングアクセス情報の設定はリバースプロキシ、負荷分散などの機能に関係するため、ロケーションモジュールも非常に重要な設定モジュールです。

=> 基本設定

位置 / {
    ルート /nginx/www;
索引    インデックス.phpインデックス.htmlインデックス.htm;
 }

場所 /: ルートディレクトリへの一致するアクセスを示します
root: ルートディレクトリにアクセスするときに仮想ホストのWebディレクトリを指定するために使用されます
インデックス: アクセスに特定のリソースが指定されていない場合に表示されるリソースファイルのデフォルトのリスト

=> リバースプロキシの設定方法

リバースプロキシプロキシサーバーアクセスモードを通じて、クライアントアクセスはproxy_set構成を通じて透過的になります。

位置 / {
    proxy_pass http://localhost:8888;
    proxy_set_header X-実数-ip $remote_addr;
    proxy_set_header ホスト $http_host;
 }

=> uwsgi 設定

WSGI モードでのサーバー構成アクセス方法

位置 / {
    uwsgi_params を含めます。
    uwsgi_pass ローカルホスト:8888
 }

VI.上流モジュール

アップストリームモジュールは主に負荷分散の構成を担当し、デフォルトのポーリングスケジューリング方法を通じてバックエンドサーバーに要求を分散します。簡単な構成は次のとおりです。

アップストリーム名{
    ip_ハッシュ;
    サーバー 192.168.1.100:8000;
    サーバー 192.168.1.100:8001 がダウンしています。
    サーバー 192.168.1.100:8002 max_fails=3;
    サーバー 192.168.1.100:8003 fail_timeout=20s;
    サーバー 192.168.1.100:8004 max_fails=3 fail_timeout=20s;
 }

ip_hash: 要求のスケジューリングアルゴリズムを指定します。デフォルトは加重ラウンドロビンスケジューリングです。指定できます
サーバーホスト:ポート: 配信サーバーの構成を一覧表示します
ダウン: ホストが一時的にサービス停止中であることを示します
max_fails: 失敗の上限を示します。上限を超えた場合はサービスが停止されます。
fail_timeout: リクエストが受け入れられなかった場合、指定された時間後にリクエストが再開されます。

<<: エッジコンピューティングのキラーアプリ 9 選

>>: フォグコンピューティングとエッジコンピューティングをわかりやすく理解する方法