Linux システムでの nginx サーバーのインストールと負荷分散構成の詳細な説明

nginx (エンジン x) は、高性能な HTTP およびリバースプロキシサーバー、メールプロキシサーバー、および一般的な TCP/UDP プロキシサーバーです。その特徴は、軽量（システムリソースの占有が少ない）、優れた安定性、スケーラビリティ（モジュール構造）、強力な同時実行機能、シンプルな構成です。

この記事では主にテスト環境でnginxが実装した基本的な負荷分散機能を紹介します。

nginx は、静的ファイルの処理、SSL および TLS SNI、GZIP Web ページ圧縮、仮想ホスト、URL 書き換えなどの機能のサポートを含む HTTP サービスを提供でき、FastCGI、uwsgi などのプログラムと組み合わせて使用して動的リクエストを処理できます。

さらに、nginx は、プロキシ、リバースプロキシ、負荷分散、キャッシュなどのサーバー機能にも使用でき、クラスター環境でのネットワーク負荷と可用性が向上します。

1. テスト環境を構築する

ここでのテスト環境は、VirtualBox を通じてインストールされた 2 台の Lubuntu 19.04 仮想マシンです。Linux システムのインストール方法については詳しく説明しません。

2 台の Linux 仮想マシン間の相互アクセスを確保するために、仮想マシンのネットワーク構成では、デフォルトの NAT 方式に加えて、VirtualBox ソフトウェアによって提供される内部ネットワーク (Internal) ネットワーキング方式が使用されます。

さらに、2 つの仮想マシンの「内部ネットワーク」に関連付けられたネットワークカードを同じネットワークセグメントの静的 IP アドレスにバインドして、2 つのホストがローカルエリアネットワークを形成し、相互に直接アクセスできるようにする必要があります。

ネットワーク構成

VirtualBox ソフトウェアを開き、2 つの仮想マシンの設定インターフェイスにそれぞれ入り、接続方法として内部ネットワークを使用したネットワーク接続を追加します。スクリーンショットは次のとおりです (2 つの仮想マシンは同じ構成です)。

内部ネットワーク

仮想マシンシステムにログインし、ip addr コマンドを使用して現在のネットワーク接続情報を表示します。

$ IPアドレス
...
2: enp0s3: <BROADCAST、MULTICAST、UP、LOWER_UP> mtu 1500 qdisc fq_codel 状態 UP グループ デフォルト qlen 1000
 リンク/イーサ 08:00:27:38:65:a8 brd ff:ff:ff:ff:ff:ff
 inet 10.0.2.15/24 brd 10.0.2.255 スコープ グローバル ダイナミック noprefixroute enp0s3
  有効_lft 86390秒 推奨_lft 86390秒
 inet6 fe80::9a49:54d3:2ea6:1b50/64 スコープ リンク noprefixroute
  valid_lft 永久 preferred_lft 永久
3: enp0s8: <BROADCAST、MULTICAST、UP、LOWER_UP> mtu 1500 qdisc fq_codel 状態 UP グループ デフォルト qlen 1000
 リンク/イーサ 08:00:27:0d:0b:de brd ff:ff:ff:ff:ff:ff
 inet6 fe80::2329:85bd:937e:c484/64 スコープ リンク noprefixroute
  valid_lft 永久 preferred_lft 永久

enp0s8 ネットワークカードはまだ IPv4 アドレスにバインドされていないため、静的 IP を手動で割り当てる必要があることがわかります。

Ubuntu 17.10 以降では、netplan という新しいツールが導入され、元の/etc/network/interfaces有効ではなくなったことに注意してください。

したがって、ネットワークカードに静的 IP を設定する場合は、/etc/netplan/01-network-manager-all.yaml 構成ファイルを変更する必要があります。例は次のとおりです。

ネットワーク：
 バージョン: 2
 レンダラー: NetworkManager
  イーサネット:
  えんぷ0s8:
   dhcp4: いいえ
   dhcp6: いいえ
   アドレス: [192.168.1.101/24]
# ゲートウェイ4: 192.168.1.101
# ネームサーバー:
# アドレス: [192.168.1.101, 8.8.8.8]

2 つのホストは同じサブネット内にあるため、ゲートウェイと DNS サーバーが構成されていない場合でも相互にアクセスできます。今のところ、対応する構成項目をコメントアウトします (後で独自の DNS サーバーを構築することができます)。

編集後、 sudo netplan applyコマンドを実行すると、以前に設定した静的 IP が有効になります。

$ IPアドレス
...
3: enp0s8: <BROADCAST、MULTICAST、UP、LOWER_UP> mtu 1500 qdisc fq_codel 状態 UP グループ デフォルト qlen 1000
  リンク/イーサ 08:00:27:0d:0b:de brd ff:ff:ff:ff:ff:ff
  inet 192.168.1.101/24 brd 192.168.1.255 スコープ グローバル noprefixroute enp0s8
    valid_lft 永久 preferred_lft 永久
  inet6 fe80::a00:27ff:fe0d:bde/64 スコープ リンク
    valid_lft 永久 preferred_lft 永久

別の仮想マシンにログインし、同じ操作を実行します（構成ファイル内のアドレス項目が [192.168.1.102/24] に変更されていることに注意してください）。 2 つの仮想マシンのネットワーク構成が完了しました。

現時点では、IP アドレスが 192.168.1.101 の Linux 仮想マシン server1 と、IP アドレスが 192.168.1.102 の Linux 仮想マシン server2 が存在します。 2 つのホストは相互にアクセスできます。テストは次のとおりです。

starky@server1:~$ ping 192.168.1.102 -c 2
PING 192.168.1.102 (192.168.1.102) 56(84)バイトのデータ。
192.168.1.102 からの 64 バイト: icmp_seq=1 ttl=64 time=0.951 ms
192.168.1.102 からの 64 バイト: icmp_seq=2 ttl=64 time=0.330 ms
--- 192.168.1.102 ping 統計 ---
送信パケット 2 個、受信パケット 2 個、パケット損失 0%、時間 2 ミリ秒
rtt 最小/平均/最大/平均偏差 = 0.330/0.640/0.951/0.311 ミリ秒
skitar@server2:~$ ping 192.168.1.101 -c 2
PING 192.168.1.101 (192.168.1.101) 56(84)バイトのデータ。
192.168.1.101 からの 64 バイト: icmp_seq=1 ttl=64 time=0.223 ms
192.168.1.101 からの 64 バイト: icmp_seq=2 ttl=64 time=0.249 ms
--- 192.168.1.101 ping 統計 ---
送信パケット 2 個、受信パケット 2 個、パケット損失 0%、時間 29 ミリ秒
rtt 最小/平均/最大/平均偏差 = 0.223/0.236/0.249/0.013 ミリ秒

2. nginxサーバーをインストールする

nginx をインストールするには、主に 2 つの方法があります。

プリコンパイルされたバイナリ。これは最も簡単で最速のインストール方法です。すべての主要なオペレーティングシステムでは、パッケージマネージャー (Ubuntu の apt-get など) を通じてインストールできます。この方法では、ほぼすべての公式モジュールまたはプラグインがインストールされます。
ソースコードからコンパイルしてインストールします。この方法は前者よりも柔軟性が高く、インストールするモジュールやサードパーティのプラグインを選択できます。

この例では特別な要件はないので、最初のインストール方法を直接選択してください。コマンドは次のとおりです。

$ sudo apt-getアップデート
$ sudo apt-get nginxをインストール

インストールが成功したら、 systemctl status nginxコマンドを使用して、nginx サービスの実行ステータスを表示します。

$ systemctl ステータス nginx
● nginx.service - 高性能ウェブサーバーとリバースプロキシサーバー
  ロード済み: ロード済み (/lib/systemd/system/nginx.service; 有効; ベンダープリセット: en
  アクティブ: 2019-07-02 火曜日 01:22:07 CST からアクティブ (実行中)、26 秒前
   ドキュメント: man:nginx(8)
 メイン PID: 3748 (nginx)
  タスク: 2 (制限: 1092)
  メモリ: 4.9M
  Cグループ: /system.slice/nginx.service
      ├─3748 nginx: マスタープロセス /usr/sbin/nginx -g デーモンオン; master_pro
      └─3749 nginx: ワーカープロセス

curl -I 127.0.0.1コマンドを使用して、Web サーバーに正常にアクセスできるかどうかを確認します。

$ カール -I 127.0.0.1
HTTP/1.1 200 OK
サーバー: nginx/1.15.9 (Ubuntu)
...

3. 負荷分散構成

ロードバランシングとは、一定のルールに従って複数の業務ユニットに負荷を分散し、サービスの可用性や応答速度を向上させることです。

簡単な例の図は次のとおりです。

負荷分散

たとえば、Web サイトアプリケーションが複数のホストで構成されるサーバークラスターに展開されている場合、負荷分散サーバーは端末ユーザーとサーバークラスターの間に配置され、端末ユーザーのアクセストラフィックを受信し、一定のルールに従ってユーザーアクセスをバックエンドサーバーホストに分散する役割を担い、高い同時実行性での応答速度を向上させます。

負荷分散サーバー

Nginx は、アップストリームオプションを通じて負荷分散を構成できます。ここでは、仮想マシン server1 が負荷分散サーバーとして使用されます。

serve1 のデフォルトのサイト設定ファイル ( sudo vim /etc/nginx/sites-available/default ) を次の内容に変更します。

アップストリームバックエンド{
  サーバー 192.168.1.102:8000;
  サーバー 192.168.1.102;
}
サーバー{
  聞く 80;

  位置 / {
    proxy_pass http://backend;
  }
}

テスト目的のため、現在仮想マシンは 2 台のみです。 Server1 (192.168.1.101) はすでに負荷分散サーバーとして使用されているため、server2 (192.168.1.102) をアプリケーションサーバーとして使用します。

ここでは、nginx の仮想ホスト機能を利用して、192.168.1.102 と 192.168.1.102:8000 が 2 つの異なるアプリケーションサーバーとして「シミュレート」されます。

アプリケーションサーバー

server2 のデフォルトのサイト構成ファイル ( sudo vim /etc/nginx/sites-available/default ) を次の内容に変更します。

サーバー{
    聞く 80;

    ルート /var/www/html;

    インデックス index.html index.htm index.nginx-debian.html;

    サーバー名 192.168.1.102;

    位置 / {
        try_files $uri $uri/ =404;
    }
}

デフォルトサイトのインデックスページとして、/var/www/html ディレクトリに index.html ファイルを作成します。内容は次のとおりです。

<html>
  <ヘッド>
    <title>サーバー1からのインデックスページ</title>
  </head>
  <本文>
    <h1>これは Server1、アドレス 192.168.1.102 です。</h1>
  </本文>
</html>

sudo systemctl restart nginxコマンドを実行して、nginx サービスを再起動します。次に、http://192.168.1.102 にアクセスして、作成した index.html ページを取得します。

$ カール 192.168.1.102
<html>
  <ヘッド>
    <title>サーバー1からのインデックスページ</title>
  </head>
  <本文>
    <h1>これは Server1、アドレス 192.168.1.102 です。</h1>
  </本文>
</html>

「別のホスト」でサイトを設定し、server2 に次の内容の/etc/nginx/sites-available/server2設定ファイルを作成します。

サーバー{
    8000を聴く;

    ルート /var/www/html;

    インデックス index2.html index.htm index.nginx-debian.html;

    サーバー名 192.168.1.102;

    位置 / {
        try_files $uri $uri/ =404;
    }
}

リスニングポートとインデックスページの構成の変更に注意してください。 server2 サイトのインデックスページとして、/var/www/html ディレクトリに index2.html ファイルを作成します。内容は次のとおりです。

<html>
  <ヘッド>
    <title>サーバー2からのインデックスページ</title>
  </head>
  <本文>
    <h1>これは Server2、アドレス 192.168.1.102:8000 です。</h1>
  </本文>
</html>

PS: テスト目的で、デフォルトサイトと server2 サイトは同じホスト server2 上に構成されており、ページは若干異なります。実際の環境では、これら 2 つのサイトは通常、同じコンテンツを持つ異なるホスト上に構成されます。

sudo ln -s /etc/nginx/sites-available/server2 /etc/nginx/sites-enabled/コマンドを実行して、作成した server2 サイトを有効にします。

nginx サービスを再起動します。次に、http://192.168.1.102:8000 にアクセスして、作成した index2.html ページを取得します。

$ カール 192.168.1.102:8000
<html>
  <ヘッド>
    <title>サーバー2からのインデックスページ</title>
  </head>
  <本文>
    <h1>これは Server2、アドレス 192.168.1.102:8000 です。</h1>
  </本文>
</html>

負荷分散テスト

負荷分散サーバー (仮想マシン server1) に戻ると、その構成ファイルに設定されているリバースプロキシ URL は http://backend です。

ドメイン名解決サービスが構成されていないため、URL http://backend を正しい場所に見つけることができません。

server1 の /etc/hosts ファイルを変更し、次のレコードを追加できます。

127.0.0.1 バックエンド

ドメイン名をローカル IP に解決して、負荷分散サーバーへのアクセスを完了できます。

nginx サービスを再起動し、server1 の http://backend にアクセスします。結果は次のようになります。

$ curl http://バックエンド
<html>
  <ヘッド>
    <title>サーバー1からのインデックスページ</title>
  </head>
  <本文>
    <h1>これは Server1、アドレス 192.168.1.102 です。</h1>
  </本文>
</html>
$ curl http://バックエンド
<html>
  <ヘッド>
    <title>サーバー2からのインデックスページ</title>
  </head>
  <本文>
    <h1>これは Server2、アドレス 192.168.1.102:8000 です。</h1>
  </本文>
</html>
$ curl http://バックエンド
<html>
  <ヘッド>
    <title>サーバー1からのインデックスページ</title>
  </head>
  <本文>
    <h1>これは Server1、アドレス 192.168.1.102 です。</h1>
  </本文>
</html>
$ curl http://バックエンド
<html>
  <ヘッド>
    <title>サーバー2からのインデックスページ</title>
  </head>
  <本文>
    <h1>これは Server2、アドレス 192.168.1.102:8000 です。</h1>
  </本文>
</html>

出力から、server1 が負荷分散サーバー http://backend にアクセスすることで、アプリケーションサーバー server2 上の 2 つの Web サイトのポーリングが完了し、負荷分散の役割を果たしていることがわかります。

4. 負荷分散方法

nginx のオープンソースバージョンでは、4 つの負荷分散実装方法が提供されており、以下に簡単に紹介します。

1. ラウンドロビン

ユーザーリクエストはバックエンドサーバークラスターに均等に分散されます (ポーリングの重みは weight オプションで設定できます)。これは nginx が使用するデフォルトの負荷分散方法です。

アップストリームバックエンド{
  サーバー backend1.example.com 重み=5;
  サーバー backend2.example.com;
}

2. 最も少ない接続

ユーザー要求は、クラスター内でアクティブな接続数が最も少ないサーバーに転送されます。重量オプションもサポートされています。

アップストリームバックエンド{
  最小接続数;
  サーバー backend1.example.com;
  サーバー backend2.example.com;
}

3. IPハッシュ

ユーザー要求はクライアント IP アドレスに基づいて転送されます。つまり、この方法は、特定のクライアントが最終的に同じサーバーホストにアクセスするようにすることを目的としています。

アップストリームバックエンド{
  ip_ハッシュ;
  サーバー backend1.example.com;
  サーバー backend2.example.com;
}

4. 汎用ハッシュ

ユーザー要求により、カスタムキー値 (文字列、変数、または組み合わせ (送信元 IP とポート番号など)) に基づいて最終的な転送先が決定されます。

アップストリームバックエンド{
  ハッシュ $request_uri は一貫しています。
  サーバー backend1.example.com;
  サーバー backend2.example.com;
}

重さ

次の構成例を参照してください。

アップストリームバックエンド{
  サーバー backend1.example.com 重み=5;
  サーバー backend2.example.com;
  サーバー 192.0.0.1 バックアップ;
}

デフォルトの重みは 1 です。バックアップサーバーは、他のすべてのサーバーがダウンしている場合にのみ要求を受け入れます。

上記の例では、6 つのリクエストごとに 5 つがbackend1.example.comに転送され、1 つが backend2.example.com に転送されます。 backend1 と backend2 の両方がダウンしている場合にのみ、192.0.0.1 がリクエストを受信して処理します。

参考文献

HTTP 負荷分散

要約する

上記は、編集者が紹介したLinuxシステムのnginxサーバーのインストールと負荷分散構成の詳細な説明です。皆様のお役に立てれば幸いです。ご質問がある場合は、メッセージを残してください。編集者がすぐに返信します。また、123WORDPRESS.COM ウェブサイトをサポートしてくださっている皆様にも感謝申し上げます。
この記事が役に立ったと思われた方は、ぜひ転載していただき、出典を明記してください。ありがとうございます!

以下もご興味があるかもしれません: