nginxをHTTPロードバランサのように使う

ロードバランスの方法
デフォルトのロードバランシングの設定
least connectedロードバランシング
セッションのpersistence
重み付けされたロードバランシング
ヘルスチェック
更なる読み込み

はじめに

複数のアプリケーションインスタンスを横断してロードバランスすることは、リソースの利用の最適化、スループットの最大化、待ち時間の削減、障害耐性の構成のために一般的に用いられる方法です。

nginxをとても効果的なHTTPロードバランサとしてトラフィックを幾つかのアプリケーションサーバに分配するために使うことが可能です。nginxを使ってwebアプリケーションのパフォーマンス、スケーラビリティ、信頼性を改善することができます。

ロードバランスの方法

nginxでは以下のロードバランシングメカニズム(あるいはメソッド)がサポートされています:

デフォルトのロードバランシングの設定

nginxのもっとも単純なロードバランシングの設定は次のようになるでしょう: 

http {
    upstream myapp1 {
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://myapp1;
        }
    }
}

上の例では、srv1-srv3で動作している同じアプリケーションの3つのインスタンスがあります。ロードバランシングメソッドが具体的に設定されていない場合は、デフォルトがラウンドロビンになります。全てのリクエストはサーバグループmyapp1に proxiedされ、nginxはリクエストを分配するためにHTTPロードバランシングを適用します。

nginxのリバースプロキシ実装はHTTP, HTTPS, FastCGI, uwsgi, SCGI, memcached および gRPC のロードバランシングを含んでいます。

HTTPではなくHTTPSのためのロードバランシングを設定するためには、単にプロトコルとして"https"を使います。

FastCGI, uwsgi, SCGI, memcached または gRPCのロードバランシングを設定する場合、fastcgi_pass, uwsgi_pass, scgi_pass, memcached_passおよびgrpc_pass ディレクティブをそれぞれ利用します。

least connectedロードバランシング

別のロードバランシング規律はleast-connectedです。Least-connectedはリクエストのいくつかが完了に時間が掛かるような場合に、アプリケーションインスタンスの負荷をもっと公平に制御できます。

least-connected ロードバランシングを使って、nginxは過度のリクエストが忙しいアプリケーションサーバの過負荷にならないようにしようとします。新しいリクエストは代わりにより忙しくないサーバに分配されます。

nginxのLeast-connected ロードバランシングは least_conn ディレクティブがサーバグループの設定の一部として使われた場合に活躍します。 

    upstream myapp1 {
        least_conn;
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

セッションのpersistence

ラウンドロビンまたはleast-connectedロードバランシングを使うと、連続するクライアントのリクエストのそれぞれが潜在的に異なるサーバに分配されるかも知れないということに注意してください。同じクライアントが常に同じサーバに向かうという保証はありません。

もしクライアントと特定のアプリケーションサーバを結びつける必要がある場合は、- 言い換えると常に特定のサーバを選択しようとするという天でクライアントのセッションを"sticky"または"persistent"にする、- ip-hash ロードバランシングメカニズムを使うことができます。

ip-hashによって、クライアントのIPアドレスはサーバグループのどのサーバがクライアントのシーケンスとして選択されるべきかを決定するハッシュキーとして使われます。このメソッドは同じクライアントからのリクエストはサーバが利用不可の場合を除いて常に同じサーバに向かうことを保証します。

ip-hashロードバランシングを設定するには、単にip_hashディレクティブをサーバ(upstream)グループ設定に追加します: 

upstream myapp1 {
    ip_hash;
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}

重み付けされたロードバランシング

サーバの重み付けを使ってnginxのロードバランシングアルゴリズムにもっと影響を与えることもできます。

上の例では、サーバの重み付けは設定されていません。つまり全ての指定されたサーバは特定のロードバランシングメソッドについて同じ条件で扱われることを意味します。

十分なリクエストがあり、リクエストが一様な方法で処理され十分早く完了するという条件では、特にラウンドロビンを使うと、サーバ間でリクエストの配分がだいたい同じであることも意味します。

weightパラメータがサーバに指定されている場合、重み付けはロードバランシングの決定の一部分として考慮されます。 

    upstream myapp1 {
        server srv1.example.com weight=3;
        server srv2.example.com;
        server srv3.example.com;
    }

この設定の場合、アプリケーション間で5つの新しいリクエストが次のように分配されるでしょう: 3つのリクエストはsrv1に向かい、一つのリクエストはsrv2に向かい、その他の一つはsrv3に向かうでしょう。

最近のバージョンのnginxではleast-connected と ip-hash ロードバランシングの重み付けに同じように使うことができます。

ヘルスチェック

nginxのリバースプロキシの実装は、in-band(あるいは受動的な)サーバヘルスチェックを含んでいます。特定のサーバからの応答がエラーで失敗した場合は、nginxはこのサーバを失敗だと印をつけ、しばらくの間連続して入ってくるリクエストにこのサーバを選択することを避けようとするでしょう。

max_fails ディレクティブは、fail_timeoutの間にサーバとの通信に連続して失敗する数を設定します。デフォルトでは、max_fails は1に設定されます。0に設定されると、このサーバのヘルスチェックは無効にされます。fail_timeout パラメータはサーバが失敗したものとしてどれくらい長く印を付けられるかも定義します。サーバの失敗の後にfail_timeoutの間隔を置いて、nginxは実際のクライアントのリクエストを使って淑やかにサーバの調査を開始するでしょう。調査が成功した場合には、サーバは生きているものとして印をつけられます。

更なる読み込み

更に、nginxのサーバロードバランシングの制御をするもっと多くのディレクティブとパラメータがあります。例えば、proxy_next_upstream, backup, down と keepaliveです。更に詳しい情報はreference documentationを確認してください。

大事なことを言い忘れましたが、有償のNGINX Plus サブスクリプションの一部として、アプリケーションのロードバランシング , アプリケーションのヘルスチェック, 能動的な監視 そして サーバグループの その場での再設定が利用可能です。

次の文章ではNGINX Plusを使ったロードバランシングをもっと詳しく説明します:

TOP
inserted by FC2 system