web-dev-qa-db-ja.com

私が5歳のようにNginxとの負荷分散について説明する

アップストリームサーバーを使用してNginxをロードバランサーとして構成する方法に関するDIYの投稿とチュートリアルをたくさん見つけました。

upstream backend  {
  ip_hash;
  server 1.2.3.4;
  server 1.2.3.5;
  server 1.2.3.6;
}

server {
  location / {
    proxy_pass  http://backend;
  }
}

しかし、それは、このアーキテクチャを構成する限り、私が見つけることができる範囲です。現在、Railsアプリケーションを3つのバックエンドVPSサーバーにデプロイしており、HTTPサーバーにUnicornを使用しています。Rubyを一緒にインストールする必要がありますか？ RailsアプリケーションとUnicornも負荷分散サーバーにありますか？各アップストリームサーバーにNginxをインストールする必要がありますか？そうであれば、どのように構成しますか？次のようなものを導入した場合アーキテクチャにニスをかけます、それはどこに行きますか？ロードバランサーの前または各バックエンド？

これが私がすべてをどのように整理しているかのビジュアルです：

                                       +---> backend1 <---+
                                       |                  |
[requests] <---> [Nginx load-balancer]-+---> backend2 <---+-[Database server]
                                       |                  |
                                       +---> backend3 <---+
ruby-on-railsnginxunicorn
3
Cyle

短い答え：

Nginxには実際には1つのジョブしかありません。そのジョブは、着信要求を受け入れてバックエンドサーバーに渡すことです。

その場合、フロントエンドサーバーはnginxを実行するだけでよく、バックエンドサーバーはRailsを実行するだけで済みます。意味がありますか？

さて、バックエンドとフロントエンドの両方が同じサーバーで実行されている場合は、もちろん、そこにもインストールする必要がありますが、図からはそうではないと思います。

VarnishなどのHTTPキャッシングソフトウェアを導入すると、NginxとRailsの間に配置され、バックエンドサーバーでも実行される可能性があります。したがって、リクエストは次のパスに従います。

Nqinx -> Varnish -> Rails
4
Donovan

Railsを使用する場合、nginxを使用していくつかの役割を果たします。ほとんどの場合、HTTPロードバランサーまたはアプリサーバーのフロントエンドとして機能します。セットアップは機能する一般的なものですが、トラフィックのレベルが高くなるにつれてスケーリングの課題が発生する可能性があります。

説明したように少数のVPSサーバーで作業している場合、1つのnginxインスタンスは、着信トラフィックのプライマリHTTPロードバランサーと、Railsアプリサーバー（静的ファイルの提供、URLの書き換え/リダイレクトなど）。

nginxは多くのリソースなしで数千の同時接続を処理できますが、Unicorn Railsアプリサーバーは通常、少数の同時接続しか処理できません。規模を拡大すると、より多くのロードバランサー/フロントエンドが必要になります。 nginxインスタンス（およびDNSラウンドロビンやその他のメカニズムなど、インスタンス間の負荷分散の方法）。

Amazon AWSまたはその他のより成熟したホスティングプラットフォームを使用する場合、プライマリWebロードバランサーとしてElastic Load Balancing（ELB）などのサービスを使用することがよく使用されます。各アプリサーバーはnginx/Unicornを実行し、nginxをフロントエンドとして利用して各Unicornから処理をオフロードします。各サーバーの前に大量のELBがあるため、これはスケーリングがはるかに簡単です。

3
Winfield