3

私の Django アプリは Amazon EC2 でホストされています。Gunicorn は同じマシンで実行され、私が持っているすべての動的コンテンツを提供します。静的コンテンツはありません。これらのマシンが 2 台あり (両方のマシンがマイクロ インスタンスで Ubuntu 11.04 を実行しています。これらは水平方向に簡単にスケーリングできます)、これらの両方のサーバーの前に ELB (エラスティック ロード バランサー) があります。

例として、これら両方の gunicorn/django ubuntu マシンの外部 IP は次のとおりです。

12.34.567.12:8000 & 21:43:765:21:8000 (gunicorn runs on port 8000).

これらのアドレスのいずれかをブラウザに入力すると、サーバーと対話してデータを送受信できます。

これら 2 台のマシンの前に ELB を配置すると、両方の DJANGO/GUNICORN サーバーと対話するために使用できる新しいアドレスは次のようになります。

dualstack.myloadbalancer-123456789.us-east-1.elb.amazonaws.com:8000

私がインターネット上で多くのリソースを読んでいるときに、多くの人が、遅いクライアントのリクエストをバッファリングするために、ELB の背後にある Django アプリ サーバーの前に NGINX ボックスを配置することを提案しました。リクエストを失いたくないので、これは良い機能だと思います。以下の図は、より明確に説明します。

ここに画像の説明を入力

上の図のように、django app/gunicorn サーバーの前にある nginx ボックスをリバース プロキシとして機能するように構成して、遅いクライアントの要求をバッファリングできるようにするにはどうすればよいでしょうか? (この方法では、タイムアウトする代わりに、リクエストを失うことなく保持します)

4

3 に答える 3

4

あなたは私が信じているnginx HttpProxyModuleを探しています。nginx でアップストリームを定義します

upstream webservers {
    server 12.34.567.12:8000;
    server 21.43.765.21:8000;
}

そして、proxy_pass 経由でリクエストをアップストリームに転送します。

server {
    listen 443; //Port you want nginx to listen on
    location / {
        proxy_set_header Host $http_host;
        proxy_read_timeout 330;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://webservers ;
     }
}

そして、私が間違っていない限り、HttpProxyModule はリクエスト全体をバッファリングしてから渡します。これにより、このプロセス中にストリーミングまたは対話を必要とする一部のアイテムが壊れる可能性がありますが、それはあなたが直面している制限です.

私のnginxは少し錆びているのでうまくいかないかもしれませんが、これらの線に沿ったものでなければなりません

于 2013-06-03T14:53:18.800 に答える