NGINX で Python パフォーマンスを最大化する、パート 1: Web サービスとキャッシュ

はじめに – Python で NGINX を使用する方法

Python は、使いやすく楽しいこと、ソフトウェア開発が容易になること、他のスクリプト言語を上回ると言われる実行時パフォーマンスがあることで有名です。 (ただし、PHP の最新バージョンである PHP 7 は、Python に匹敵する可能性があります。)

誰もが自分のウェブサイトやアプリケーションをより速く実行したいと考えています。 また、トラフィックが増加したり、急激にトラフィックが急増したりするすべての Web サイトは、パフォーマンスの問題やダウンタイムの影響を受けやすく、最悪の時間帯、つまり最も忙しい時間帯に発生することがよくあります。 また、トラフィック量が着実に増加している場合でも、使用量が急増している場合でも、ほぼすべての Web サイトはパフォーマンスの問題やダウンタイムに悩まされています。

ここで、NGINX と NGINX Plus が登場します。 ウェブサイトのパフォーマンスは、次の 3 つの方法で向上します。

1. Web サーバーとしてのNGINX は、もともとC10K 問題を解決するために、つまり 10,000 以上の同時接続を簡単にサポートするために開発されました。 Python アプリの Web サーバーとして NGINX を使用すると、トラフィック量が少ない場合でも Web サイトの速度が向上します。 何千人ものユーザーがいる場合、パフォーマンスが大幅に向上し、クラッシュやダウンタイムが減少することはほぼ確実です。 NGINX Web サーバー上で静的ファイル キャッシュまたはマイクロキャッシュを実行することもできますが、どちらも別の NGINX リバース プロキシ サーバー上で実行するとより効果的に機能します (次の段落を参照)。
2. リバース プロキシ サーバーとして– 現在のアプリケーション サーバー セットアップの前に、リバース プロキシ サーバーとして NGINX を「ドロップイン」できます。 NGINX は Web に接続し、リクエストをアプリケーション サーバーに渡します。 この「奇妙なトリック」により、Web サイトの実行速度が上がり、ダウンタイムが短縮され、サーバー リソースの消費が減り、セキュリティが向上します。 また、リバース プロキシ サーバーに静的ファイルをキャッシュしたり (非常に効率的)、動的コンテンツのマイクロキャッシュを追加してアプリケーション自体の負荷を軽減したりすることもできます。
3. 複数のアプリケーション サーバーのロード バランサーとして– リバース プロキシ サーバーを展開することから始めます。 次に、複数のアプリケーション サーバーを並行して実行し、NGINX または NGINX Plus を使用してそれらの間でトラフィックの負荷を分散することでスケールアウトします。 このような展開により、トラフィック要件に応じて Web サイトのパフォーマンスを簡単に拡張でき、信頼性と稼働時間が向上します。 特定のユーザー セッションを同じサーバー上に維持する必要がある場合は、セッションの永続性をサポートするようにロード バランサーを構成します。

NGINX と NGINX Plus は、Python アプリの Web サーバー、リバース プロキシ サーバー、ロード バランサー、または 3 つの目的すべてで使用する場合でも利点があります。

2 部構成のシリーズの最初の記事では、NGINX と NGINX Plus を Web サーバーとして使用する方法、静的ファイルのキャッシュを実装する方法、アプリケーション生成ファイルのマイクロキャッシュなど、Python アプリのパフォーマンスを向上させるための 5 つのヒントについて説明します。 パート 2では、NGINX と NGINX Plus をリバース プロキシ サーバーとして、また複数のアプリケーション サーバーのロード バランサーとして使用する方法について説明します。

ヒント 1 – Python のパフォーマンスのボトルネックを見つける

Python アプリケーションのパフォーマンスが重要になる条件は 2 つあり、1 つは日常的に「妥当な」数のユーザーがいる場合、もう 1 つは負荷が高い場合です。 多くのサイト所有者は、負荷が軽い場合のパフォーマンスについてあまり心配していませんが、私たちの意見では、応答時間の 10 分の 1 秒ごとに心配するべきです。 応答時間を数ミリ秒短縮することは困難で報われない作業ですが、ユーザーの満足度が高まり、ビジネス成果も向上します。

ただし、このブログ投稿とそれに付随するパート 2 では、誰もが心配するシナリオ、つまり、サイトが混雑したときに発生するパフォーマンスの大幅な低下やクラッシュなどのパフォーマンスの問題に焦点を当てています。 また、多くのハッカー攻撃はユーザー数の急増の影響を模倣しており、サイトのパフォーマンスを向上させることは攻撃に対処する上でも重要なステップとなることがよくあります。

Apache HTTP Server のように、ユーザーごとに一定量のメモリを割り当てるシステムでは、ユーザーを追加すると、ユーザー数が増えるにつれて物理メモリが過負荷になります。 サーバーがディスクへのスワップを開始し、パフォーマンスが急落し、パフォーマンスの低下やクラッシュが発生します。 このブログ投稿で説明されているように、NGINX に移行すると、この問題の解決に役立ちます。

Python は、一般的に他のスクリプト言語よりも多くのメモリを使用してタスクを実行するため (その結果、タスクの実行速度が速くなるため)、メモリ関連のパフォーマンスの問題が発生しやすい傾向があります。 したがって、他の条件が同じであれば、Python ベースのアプリは、他の言語で書かれたアプリよりもユーザー負荷が少ない場合に「ダウン」する可能性があります。

アプリを最適化すると多少は役立ちますが、通常、トラフィック関連のサイト パフォーマンスの問題を解決する最良または最速の方法ではありません。 このブログ投稿とそれに付随するパート 2 の手順は、トラフィック関連のパフォーマンスの問題に対処するための最良かつ最速の方法です。 次に、ここに示した手順を実行した後、必ず戻ってアプリを改善するか、マイクロサービス アーキテクチャを使用するように書き直してください。

ヒント 2 – 単一サーバーまたは複数サーバーの展開を選択する

小規模な Web サイトは、単一のサーバーに展開すると正常に動作します。 大規模な Web サイトには複数のサーバーが必要です。 しかし、中間のグレーゾーンにいる場合、またはサイトが小規模サイトから大規模サイトに成長している場合は、興味深い選択肢がいくつかあります。

単一サーバーの展開の場合、トラフィックの急増や全体的なトラフィックの急激な増加が発生すると、大きなリスクにさらされます。 スケーラビリティは限られていますが、アプリの改善、Web サーバーの NGINX への切り替え、より大規模で高速なサーバーの取得、ストレージのコンテンツ配信ネットワーク (CDN) へのオフロードなどの修正が可能です。 これらのオプションはそれぞれ実装に時間がかかり、コストがかかり、実装時にバグや問題が発生するリスクがあります。

また、単一サーバー展開では、定義上、サイトには単一障害点があり、サイトをオフラインにする可能性のある問題の多くには、迅速かつ簡単な解決策がありません。

単一サーバー展開でサーバーを NGINX に切り替える場合は、NGINX Open Source と NGINX Plus を自由に選択できます。 NGINX Plus には、エンタープライズ グレードのサポートと追加機能が含まれています。 ライブ アクティビティ モニタリングなどの追加機能の一部は、単一サーバーの展開に関連し、ロード バランシングやセッション パーシステンスなどのその他の機能は、マルチサーバーの展開で NGINX Plus をリバース プロキシ サーバーとして使用する場合に有効になります。

すべてを考慮すると、サイトが今後も長期間小規模のままであり、ダウンタイムが大きな心配ではないことが確実でない限り、単一サーバーの展開にはリスクが伴います。 マルチサーバーの展開はほぼ任意に拡張可能です。単一障害点を排除でき、パフォーマンスは自由に選択でき、容量をすばやく追加できます。

ヒント3 – WebサーバーをNGINXに変更する

Web の初期の頃、「Apache」という名前は「Web サーバー」と同義でした。 しかし、NGINX は 2000 年代初頭に開発され、着実に人気が高まっています。すでに、世界の 1,000、10,000、100,000、[ngx_snippet name='proportion-top-sites'] で第 1 位の Web サーバーとなっています。

NGINX は、C10K 問題、つまり、与えられたメモリ バジェット内で 10,000 を超える同時接続を処理する問題を解決するために開発されました。 他の Web サーバーは接続ごとに大量のメモリを必要とするため、何千人ものユーザーが同時にサイトにアクセスすると物理メモリが不足し、速度が低下したりクラッシュしたりします。 NGINX は各リクエストを個別に処理し、より多くのユーザーにスムーズに拡張します。 (以下で説明するように、追加の目的にも最適です。)

NGINX のアーキテクチャの概要を以下に示します。

この図では、Python アプリケーション サーバーがバックエンドのアプリケーション サーバーブロックに収まり、FastCGI によってアクセスされていることが示されています。NGINX は Python の実行方法を「知らない」ため、Python を実行する環境へのゲートウェイが必要です。 FastCGI は、PHP、Python、その他の言語で広く使用されているインターフェースです。

ただし、Python と NGINX 間の通信では、Web Server Gateway Interface (WSGI) がより一般的な選択肢となります。 WSGI はマルチスレッドおよびマルチプロセス環境で動作するため、このブログ記事で説明したすべてのデプロイメント オプションにわたって適切に拡張できます。

Web サーバーとして NGINX に移行する場合、必要な手順については多くのサポートが提供されています。

• gunicorn の設定– NGINX で使用するための、人気の WSGI サーバー「Green Unicorn」。
• uWSGI の設定– NGINX で使用するための、もう 1 つの一般的な WSGI サーバー。uWSGI には、NGINX の直接サポートが含まれています。
• uWSGI、NGINX、Django (人気の Python Web フレームワーク) を使用します。

このスニペットは、 NGINX を uWSGI で使用するために設定する方法を示しています。この場合は、Python フレームワーク Django を使用するプロジェクトです。

http { # ...
アップストリーム django {
サーバー 127.0.0.1:29000;
}

サーバー {
listen 80;
server_name myapp.example.com;

root /var/www/myapp/html;

location / {
index index.html;
}

location /static/ {
alias /var/django/projects/myapp/static/;
}

location /main {
include /etc/nginx/uwsgi_params;
uwsgi_pass django;

uwsgi_param Host $host;
uwsgi_param X-Real-IP $remote_addr;
uwsgi_param X-Forwarded-For $proxy_add_x_forwarded_for;
uwsgi_param X-Forwarded-Proto $http_x_forwarded_proto;
}
}
}

ヒント4 – 静的ファイルキャッシュを実装する

静的コンテンツのキャッシュには、それほど頻繁に変更されない（数時間ごと、またはまったく変更されない）ファイルのコピーをアプリケーション サーバー以外の場所に保存することが含まれます。 静的コンテンツの典型的な例は、Web ページの一部として表示される JPEG 画像です。

静的ファイルのキャッシュは、アプリケーションのパフォーマンスを向上させる一般的な方法であり、実際にはいくつかのレベルで実行されます。

• ユーザーのブラウザで
• 企業の内部ネットワークからインターネット サービス プロバイダー (ISP) まで、さまざまなレベルのインターネット プロバイダー
• ここで説明するように、ウェブサーバー上で

Web サーバーに静的ファイル キャッシュを実装すると、次の 2 つの利点があります。

• ユーザーへの配信が高速化– NGINX は静的ファイルのキャッシュに最適化されており、静的コンテンツのリクエストをアプリケーション サーバーよりもはるかに高速に実行します。
• アプリケーション サーバーの負荷が軽減されます- Web サーバーがキャッシュされた静的ファイルの要求を満たすため、アプリケーション サーバーはキャッシュされた静的ファイルの要求を認識しません。

静的ファイル キャッシュは単一サーバー実装では正常に機能しますが、基盤となるハードウェアは Web サーバーとアプリケーション サーバーによって共有されます。 Web サーバーのハードウェアがキャッシュされたファイルの取得でビジー状態になっている場合 (非常に効率的であっても)、そのハードウェア リソースはアプリケーションで使用できず、ある程度速度が低下する可能性があります。

ブラウザのキャッシュをサポートするには、静的ファイルの HTTP ヘッダーを正しく設定します。 HTTP Cache-Controlヘッダー (特にそのmax-age設定)、 Expiresヘッダー、およびEntityタグを考慮してください。 このトピックの優れた入門書としては、NGINX Plus 管理者ガイドの「uWSGI と Django を使用したアプリケーション ゲートウェイとしての NGINX と NGINX Plus の使用」を参照してください。

次のコードは、JPEG ファイル、GIF、PNG ファイル、MP4 ビデオ ファイル、Powerpoint ファイルなど、静的ファイルをキャッシュするように NGINX を構成します。 www.example.com をWeb サーバーの URL に置き換えます。

server { # 「www.example.com」を Web サーバーの URL に置き換えます
server_name www.example.com;
root /var/www/example.com/htdocs;
index index.php;
access_log /var/log/nginx/example.com.access.log;
error_log /var/log/nginx/example.com.error.log;

location / {
try_files $uri $uri/ /index.php?$args;
}

location ~ .php$ {
try_files $uri =404;
include fastcgi_params;
# Python サーバーのソケット、またはアドレスとポートに置き換えます
fastcgi_pass unix:/var/run/php5-fpm.sock;
#fastcgi_pass 127.0.0.1:9000;
} 

location ~* .(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg
|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid
|midi|wav|bmp|rtf)$ {
expires max;
log_not_found off;
access_log off;
}
}

ヒント5 – マイクロキャッシングを実装する

マイクロキャッシングは、Python、PHP、その他の言語を実行するアプリケーション サーバーのパフォーマンスを大幅に向上させる機会を活用します。 キャッシュの目的上、Web ページには次の 3 つの種類があります。

• 静的ファイル–ヒント 4で説明されているように、これらはキャッシュできます。
• アプリケーションによって生成された、パーソナライズされていないページ– これらは最新の状態にしておく必要があるため、通常はキャッシュしても意味がありません。 一例として、ログインしていない e コマース ユーザーに配信されるページが挙げられます (次のポイントを参照)。入手可能な製品、推奨される類似製品などは常に変化する可能性があるため、最新のページを提供することが重要です。 ただし、たとえば 10 分の 1 秒後に別のユーザーが来た場合は、前のユーザーと同じページを表示しても問題ない場合があります。
• アプリケーションによって生成されたパーソナライズされたページ– これらはユーザー固有であり、同じユーザーが同じパーソナライズされたページを 2 回表示する可能性は低いため、キャッシュすることは有効ではありません。 例としては、ログインしているユーザー向けの電子商取引ページが挙げられます。同じページを他のユーザーに表示することはできません。

マイクロキャッシュは、上で説明した 2 番目のページ タイプ (アプリケーションによって生成された、パーソナライズされていないページ) に役立ちます。 「マイクロ」とは短い時間枠を意味します。 サイトが 1 秒間に同じページを複数回生成する場合、そのページを 1 秒間キャッシュしてもページの鮮度に大きな影響はない可能性があります。 しかし、この短いキャッシュ期間により、特にトラフィックの急増時にアプリケーション サーバーの負荷が大幅に軽減される可能性があります。 キャッシュタイムアウト期間中に 10 ページ、20 ページ、または 100 ページ (同じコンテンツ) を生成する代わりに、特定のページを 1 回だけ生成し、そのページをキャッシュして、キャッシュから多くのユーザーに提供します。

その効果は奇跡のようです。 1 秒あたり数十件のリクエストを処理するときには遅いサーバーでも、1 件のリクエストだけを処理するときには、かなり高速になります。 (もちろん、パーソナライズされたページも含まれます。) 弊社の Owen Garrett が、マイクロキャッシングの利点について設定コードとともに詳しく説明したブログ記事を書いています。 コアの変更は、1 秒のタイムアウトでプロキシ キャッシュを設定することですが、必要な構成コードはわずか数行です。

proxy_cache_path /tmp/cache keys_zone=cache:10m levels=1:2 inactive=600s max_size=100m;server {
proxy_cache cache;
proxy_cache_valid 200 1s;
# ...
}

詳細なサンプル構成については、Tyler Hicks‑Wright のブログ「Python と uWSGI と NGINX」を参照してください。

結論

パート I では、単一サーバーの Python 実装のパフォーマンスを向上させるソリューションと、単一サーバーの実装に展開することも、リバース プロキシ サーバーまたは別のキャッシュ サーバーで実行することもできるキャッシュについて説明しました。 (キャッシュは別のサーバー上でより効果的に機能します。) 次のパート 2では、2 台以上のサーバーを必要とするパフォーマンス ソリューションについて説明します。

サポート、ライブ アクティビティの監視、オンザフライ再構成など、アプリケーション向けのNGINX Plusの高度な機能を試してみたい場合は、今すぐ30 日間の無料トライアルを開始するか、お問い合わせの上、ユースケースについてご相談ください。