アプリケーション パフォーマンスを 10 倍にする 10 のヒント

Web アプリケーションのパフォーマンスを向上させることは、これまで以上に重要になっています。 オンラインで行われる経済活動の割合は増加しており、先進国の経済の 5% 以上が現在インターネット上にあります (下記のインターネット統計のリソースを参照)。 常時接続され、ハイパーコネクテッド化された現代の世界では、ユーザーの期待はかつてないほど高まっています。 サイトが即座に応答しなかったり、アプリが遅延なく動作しなかったりすると、ユーザーはすぐに競合他社のサイトに移行してしまいます。

たとえば、ほぼ 10 年前に Amazon が行った調査では、当時でもページの読み込み時間が 100 ミリ秒短縮されると収益が 1% 増加することが証明されました。 最近の別の調査では、調査対象となったサイト所有者の半数以上が、アプリケーションのパフォーマンスが低いために収益や顧客を失ったと述べているという事実が明らかになりました。

ウェブサイトはどれくらいの速さが必要ですか? ページの読み込みにかかる 1 秒ごとに、約 4% のユーザーがページを放棄します。 トップの電子商取引サイトでは、最初のインタラクションまでの時間が 1 ～ 3 秒に設定されており、最高のコンバージョン率を実現しています。 Web アプリケーションのパフォーマンスに対するリスクは高く、さらに高まる可能性が高いことは明らかです。

パフォーマンスを向上させたいと思うのは簡単ですが、実際に結果を確認するのは難しいです。 あなたの旅をサポートするために、このブログ投稿では、ウェブサイトのパフォーマンスを最大 10 倍向上させるのに役立つ 10 のヒントを紹介します。 これは、十分にテストされた最適化手法と NGINX のサポートを活用して、アプリケーションのパフォーマンスを向上させる方法を詳しく説明するシリーズの最初の記事です。このシリーズでは、その過程で得られるセキュリティの潜在的な改善についても概説します。

ヒント 1 – リバース プロキシ サーバーを使用してアプリケーションを高速化し、セキュリティを確保する

Web アプリケーションが 1 台のマシンで実行される場合、パフォーマンスの問題に対する解決策は明白に思えるかもしれません。つまり、プロセッサや RAM を増やし、ディスク アレイを高速化した、より高速なマシンを入手するだけです。 すると、新しいマシンで WordPress サーバー、Node.js アプリケーション、Java アプリケーションなどを以前よりも高速に実行できるようになります。 (アプリケーションがデータベース サーバーにアクセスする場合、解決策は依然として単純に思えるかもしれません。つまり、より高速な 2 台のマシンを用意し、それらの間の接続を高速化するのです。)

問題は、マシンの速度が問題ではないかもしれないということです。 Web アプリケーションの実行速度が遅くなることが多いのは、コンピューターが、何千もの接続でユーザーとやり取りしたり、ディスクからファイルにアクセスしたり、アプリケーション コードを実行したりするなど、さまざまな種類のタスクを切り替えているためです。 アプリケーション サーバーがスラッシング状態になっている可能性があります。つまり、メモリが不足し、メモリのチャンクがディスクにスワップされ、ディスク I/O などの単一のタスクで多くの要求が待機状態になっている可能性があります。

ハードウェアをアップグレードする代わりに、リバース プロキシ サーバーを追加してこれらのタスクの一部をオフロードするというまったく異なるアプローチを取ることもできます。 リバース プロキシ サーバーは、アプリケーションを実行しているマシンの前に配置され、インターネット トラフィックを処理します。 リバース プロキシ サーバーのみがインターネットに直接接続され、アプリケーション サーバーとの通信は高速な内部ネットワークを介して行われます。

リバース プロキシ サーバーを使用すると、アプリケーション サーバーはユーザーが Web アプリを操作するのを待つ必要がなくなり、リバース プロキシ サーバーがインターネット経由で送信するページの構築に集中できるようになります。 アプリケーション サーバーは、クライアントの応答を待つ必要がなくなり、最適化されたベンチマークで達成される速度に近い速度で実行できます。

リバース プロキシ サーバーを追加すると、Web サーバーのセットアップの柔軟性も向上します。 たとえば、特定のタイプのサーバーが過負荷になった場合、同じタイプの別のサーバーを簡単に追加できます。また、サーバーがダウンした場合は、簡単に交換できます。

リバース プロキシ サーバーは柔軟性が高いため、次のような他の多くのパフォーマンス向上機能の前提条件にもなります。

• 負荷分散(ヒント 2を参照) - ロード バランサーはリバース プロキシ サーバー上で実行され、複数のアプリケーション サーバー間でトラフィックを均等に共有します。 ロード バランサーを導入すると、アプリケーションをまったく変更せずにアプリケーション サーバーを追加できます。
• 静的ファイルのキャッシュ(ヒント 3を参照) - 画像ファイルやコード ファイルなど、直接要求されるファイルは、リバース プロキシ サーバーに保存してクライアントに直接送信できます。これにより、アセットの提供が高速化され、アプリケーション サーバーの負荷が軽減され、アプリケーションの実行速度が向上します。
• サイトのセキュリティ保護– リバース プロキシ サーバーは、高度なセキュリティを実現するように構成し、攻撃を迅速に認識して対応できるように監視できるため、アプリケーション サーバーが保護された状態を維持できます。

NGINX ソフトウェアは、上記の追加機能を備えたリバース プロキシ サーバーとして使用するために特別に設計されています。 NGINX は、従来のサーバーよりも効率的なイベント駆動型処理アプローチを使用します。 NGINX Plus には、アプリケーションのヘルス チェック、特殊なリクエスト ルーティング、高度なキャッシュ、サポートなど、より高度なリバース プロキシ機能が追加されています。

ヒント 2 – ロードバランサーを追加する

ロードバランサーの追加は比較的簡単な変更ですが、サイトのパフォーマンスとセキュリティを大幅に向上させることができます。 コア Web サーバーをより大きく強力にする代わりに、ロード バランサーを使用してトラフィックを複数のサーバーに分散します。 アプリケーションが適切に記述されていなかったり、スケーリングに問題があったりする場合でも、ロード バランサを使用すると、他の変更を加えなくてもユーザー エクスペリエンスを向上させることができます。

ロード バランサは、まずリバース プロキシ サーバーです (ヒント 1を参照)。インターネット トラフィックを受信し、リクエストを別のサーバーに転送します。 ポイントは、ロード バランサが 2 つ以上のアプリケーション サーバーをサポートし、選択したアルゴリズムを使用してサーバー間で要求を分割することです。 最も単純な負荷分散アプローチはラウンドロビンであり、新しいリクエストはリスト上の次のサーバーに送信されます。 他の方法としては、アクティブな接続が最も少ないサーバーにリクエストを送信する方法があります。 NGINX Plus には、特定のユーザー セッションを同じサーバー上で継続する機能があり、これをセッション永続性と呼びます。

ロード バランサは、他のサーバーがトラフィックを待機している間に 1 つのサーバーが過負荷になるのを防ぐため、パフォーマンスを大幅に向上させることができます。 また、比較的低コストのサーバーを追加して、確実に最大限に活用できるため、Web サーバーの容量を簡単に拡張できます。

負荷分散できるプロトコルには、HTTP、HTTPS、SPDY、HTTP/2、WebSocket、 FastCGI 、SCGI、uwsgi、memcached、および TCP ベースのアプリケーションやその他のレイヤー 4 プロトコルを含むその他のいくつかのアプリケーション タイプが含まれます。 Web アプリケーションを分析して、どのアプリケーションを使用しているか、パフォーマンスが低下している箇所を特定します。

負荷分散に使用される同じサーバーは、SSL 終了、クライアントによる HTTP/ 1.xおよび HTTP/2 の使用のサポート、静的ファイルのキャッシュなど、他のいくつかのタスクも処理できます。

NGINX は負荷分散によく使用されます。 詳細については、電子書籍「ソフトウェア ロード バランサーを選択する 5 つの理由」をダウンロードしてください。 基本的な構成手順については、「NGINX および NGINX Plus を使用した負荷分散、パート 1」を、詳細なドキュメントについては「 NGINX Plus 管理ガイド」を参照してください。 NGINX Plusは当社の商用製品であり、サーバーの応答時間に基づく負荷ルーティングや Microsoft の NTLM プロトコルでの負荷分散機能など、より特殊な負荷分散機能をサポートしています。

ヒント3 – 静的コンテンツと動的コンテンツをキャッシュする

キャッシュにより、クライアントにコンテンツがより速く配信され、Web アプリケーションのパフォーマンスが向上します。 キャッシュには、必要なときに高速配信できるようにコンテンツを前処理する、より高速なデバイスにコンテンツを保存する、クライアントの近くにコンテンツを保存する、またはこれらの組み合わせなど、いくつかの戦略が含まれます。

考慮すべきキャッシュには 2 つの種類があります。

• 静的コンテンツのキャッシュ- 画像ファイル (JPEG、PNG) やコード ファイル (CSS、JavaScript) などの頻繁に変更されないファイルは、エッジ サーバーに保存して、メモリまたはディスクからすばやく取得できます。
• 動的コンテンツのキャッシュ- 多くの Web アプリケーションは、ページ要求ごとに新しい HTML を生成します。 生成された HTML のコピーを 1 つ短時間キャッシュすることで、要件を満たす最新のコンテンツを配信しながら、生成する必要があるページの総数を大幅に削減できます。

たとえば、ページが 1 秒あたり 10 回表示され、そのページを 1 秒間キャッシュすると、そのページに対するリクエストの 90% がキャッシュから送信されます。 静的コンテンツを個別にキャッシュすると、ページの新しく生成されたバージョンであっても、大部分がキャッシュされたコンテンツで構成される可能性があります。

Web アプリケーションによって生成されたコンテンツをキャッシュするための主な手法は 3 つあります。

• コンテンツをユーザーの近くに移動する- コンテンツのコピーをユーザーの近くに保持すると、送信時間が短縮されます。
• コンテンツをより高速なマシンに移動する- コンテンツをより高速なマシンに保存して、より高速に取得できます。
• 過度に使用されているマシンからコンテンツを移動する– マシンは他のタスクで忙しいため、特定のタスクのベンチマーク パフォーマンスよりもはるかに遅く動作することがあります。 別のマシンにキャッシュすると、ホスト マシンの負荷が軽減されるため、キャッシュされたリソースだけでなく、キャッシュされていないリソースのパフォーマンスも向上します。

Web アプリケーションのキャッシュは、Web アプリケーション サーバーの内部から外部に実装できます。 まず、動的コンテンツにキャッシュを使用して、アプリケーション サーバーの負荷を軽減します。 次に、静的コンテンツ（動的コンテンツの一時コピーを含む）にキャッシュが使用され、アプリケーション サーバーの負荷がさらに軽減されます。 そして、キャッシュはアプリケーション サーバーから、より高速でユーザーに近いマシンに移動され、アプリケーション サーバーの負荷が軽減され、取得および送信時間が短縮されます。

キャッシュの改善により、アプリケーションの速度が大幅に向上します。 多くの Web ページでは、大きな画像ファイルなどの静的データがコンテンツの半分以上を占めています。 キャッシュなしでこのようなデータを取得して送信するには数秒かかる場合がありますが、データがローカルにキャッシュされている場合はほんの数秒しかかかりません。

キャッシュが実際にどのように使用されるかの例として、NGINX と NGINX Plus は、キャッシュを設定するためにproxy_cache_pathとproxy_cache という2 つのディレクティブを使用します。 キャッシュの場所とサイズ、ファイルがキャッシュに保持される最大時間、およびその他のパラメータを指定します。 3 番目の (そして非常に人気のある) ディレクティブproxy_cache_use_staleを使用すると、新しいコンテンツを提供するサーバーがビジー状態またはダウンしているときに、キャッシュに古いコンテンツを提供するように指示して、クライアントに何も提供しないのではなく、何かを提供することもできます。 ユーザーの観点から見ると、これによりサイトまたはアプリケーションの稼働時間が大幅に向上する可能性があります。

NGINX Plus には、キャッシュの消去のサポートや、ライブ アクティビティの監視のためのダッシュボードでのキャッシュ ステータスの視覚化など、高度なキャッシュ機能があります。

NGINX によるキャッシュの詳細については、リファレンス ドキュメントとNGINX Plus 管理者ガイドを参照してください。

注記： キャッシュは、アプリケーションを開発する人々、資本投資の決定を行う人々、およびネットワークをリアルタイムで実行する人々の間で組織の境界を越えます。 ここで言及したような洗練されたキャッシュ戦略は、アプリケーション開発者、アーキテクチャ、運用の観点が統合され、サイトの機能性、応答時間、セキュリティ、および完了したトランザクションや売上などのビジネス成果の目標を達成するのに役立つ DevOps の観点の価値を示す良い例です。

ヒント4 – データを圧縮する

圧縮はパフォーマンスを大幅に向上させる可能性があります。 写真 (JPEG および PNG)、ビデオ (MPEG-4)、音楽 (MP3) などには、慎重に設計された非常に効果的な圧縮規格があります。 これらの各標準により、ファイル サイズが 1 桁以上削減されます。

テキスト データ (HTML (プレーン テキストと HTML タグを含む)、CSS、JavaScript などのコードを含む) は、多くの場合、圧縮されずに送信されます。 このデータを圧縮すると、特にモバイル接続が低速または制限されているクライアントの場合、Web アプリケーションのパフォーマンスに不釣り合いな影響を与える可能性があります。

これは、テキスト データだけでユーザーがページと対話するのに十分な場合が多く、マルチメディア データはより補助的または装飾的になる可能性があるためです。 スマートなコンテンツ圧縮により、HTML、Javascript、CSS、その他のテキストベースのコンテンツの帯域幅要件が通常 30% 以上削減され、読み込み時間もそれに応じて短縮されます。

SSL を使用する場合、圧縮によって SSL エンコードする必要があるデータの量が削減され、データの圧縮にかかる CPU 時間の一部が相殺されます。

テキストデータを圧縮する方法はさまざまです。 たとえば、ヘッダー データに特化して適応された SPDY および HTTP/2 の新しいテキスト圧縮方式については、ヒント 6 を参照してください。 テキスト圧縮の別の例として、NGINX でGZIP 圧縮を有効にすることができます。サービスでテキスト データを事前に圧縮した後、 gzip_staticディレクティブを使用して圧縮された.gzファイルを直接提供できます。

ヒント 5 – SSL/TLS を最適化する

Secure Sockets Layer ( SSL ) プロトコルとその後継である Transport Layer Security ( TLS ) プロトコルは、ますます多くの Web サイトで使用されるようになっています。 SSL/TLS は、オリジン サーバーからユーザーに転送されるデータを暗号化し、サイトのセキュリティを向上させます。 この傾向に影響を与えている要因の 1 つは、Google が SSL/TLS の存在を検索エンジンのランキングにプラスの影響を与えるものとして利用していることです。

人気が高まっているにもかかわらず、SSL/TLS に伴うパフォーマンスの低下は多くのサイトにとって問題点となっています。 SSL/TLS によって Web サイトのパフォーマンスが低下する理由は 2 つあります。

1. 新しい接続が開かれるたびに暗号化キーを確立するために必要な初期ハンドシェイク。 HTTP/ 1.xを使用するブラウザがサーバーごとに複数の接続を確立する方法により、そのヒットは倍増します。
2. サーバー上でデータを暗号化し、クライアント上でそれを復号化することによる継続的なオーバーヘッド。

SSL/TLS の使用を促進するために、HTTP/2 および SPDY (次のヒントで説明) の作成者は、ブラウザー セッションごとに 1 つの接続のみが必要になるようにこれらのプロトコルを設計しました。 これにより、SSL オーバーヘッドの 2 つの主な原因の 1 つが大幅に削減されます。 ただし、SSL/TLS 経由で配信されるアプリケーションのパフォーマンスを向上させるために、今日ではさらに多くのことを行うことができます。

SSL/TLS を最適化するメカニズムは Web サーバーによって異なります。 たとえば、NGINX は標準の汎用ハードウェア上で実行されるOpenSSL を使用して、専用ハードウェア ソリューションと同様のパフォーマンスを提供します。 NGINX SSL のパフォーマンスは十分に文書化されており、SSL/TLS 暗号化と復号化の実行にかかる時間と CPU のペナルティを最小限に抑えます。

さらに、SSL/TLS パフォーマンスを向上させる方法の詳細については、このブログ投稿を参照してください。 簡単にまとめると、テクニックは次のとおりです。

• セッション キャッシュ– ssl_session_cacheディレクティブを使用して、SSL/TLS で新しい接続を保護するときに使用されるパラメータをキャッシュします。
• セッション チケットまたは ID – 特定の SSL/TLS セッションに関する情報をチケットまたは ID に保存し、新しいハンドシェイクなしで接続をスムーズに再利用できるようにします。
• OCSP ステープル- SSL/TLS 証明書情報をキャッシュすることでハンドシェイク時間を短縮します。

NGINX と NGINX Plus は、SSL/TLS ターミネーションに使用できます。つまり、クライアント トラフィックの暗号化と復号化を処理しながら、他のサーバーとクリア テキストで通信します。 SSL/TLS 終了を処理するように NGINX または NGINX Plus を設定するには、 HTTPS 接続と暗号化された TCP 接続の手順を参照してください。

ヒント 6 – HTTP/2 または SPDY を実装する

すでに SSL/TLS を使用しているサイトでは、単一の接続で 1 回のハンドシェイクのみが必要となるため、HTTP/2 と SPDY によってパフォーマンスが向上する可能性が高くなります。 SSL/TLS をまだ使用していないサイトの場合、HTTP/2 と SPDY により、応答性の観点からは SSL/TLS (通常はパフォーマンスが低下します) への移行は意味がありません。

Google は、HTTP/ 1.x上でより高速なパフォーマンスを実現する方法として、2012 年に SPDY を導入しました。 HTTP/2 は、SPDY をベースにした最近承認された IETF 標準です。 SPDY は広くサポートされていますが、間もなく廃止され、HTTP/2 に置き換えられます。

SPDY と HTTP/2 の主な特徴は、複数の接続ではなく単一の接続を使用することです。 単一の接続が多重化されるため、複数の要求と応答の一部を同時に伝送できます。

これらのプロトコルは、1 つの接続を最大限に活用することで、ブラウザーが HTTP/ 1.xを実装する方法で必要とされる複数の接続の設定と管理のオーバーヘッドを回避します。 単一の接続を使用すると、SSL/TLS が安全な接続を確立するために必要な時間のかかるハンドシェイクが最小限に抑えられるため、SSL では特に役立ちます。

SPDY プロトコルでは SSL/TLS の使用が必須でした。HTTP/2 では公式には必須ではありませんが、これまでのところ HTTP/2 をサポートするすべてのブラウザは SSL/TLS が有効になっている場合にのみ SSL/TLS を使用します。 つまり、HTTP/2 をサポートするブラウザは、Web サイトが SSL を使用しており、そのサーバーが HTTP/2 トラフィックを受け入れる場合にのみ HTTP/2 を使用します。 それ以外の場合、ブラウザは HTTP/ 1.x経由で通信します。

SPDY または HTTP/2 を実装すると、ドメイン シャーディング、リソースのマージ、イメージの分割などの一般的な HTTP パフォーマンスの最適化は不要になります。 これらの変更により、コードとデプロイメントがよりシンプルになり、管理しやすくなります。 HTTP/2 がもたらす変化について詳しくは、ホワイト ペーパー「Web アプリケーション開発者向け HTTP/2」をお読みください。

これらのプロトコルのサポート例として、NGINX は早くから SPDY をサポートしており、現在 SPDY を使用しているほとんどのサイトはNGINX 上で実行されています。NGINX は HTTP/2 のサポートも先駆的に行っており、2015 年 9 月現在、NGINX オープンソースと NGINX Plus で HTTP/2 をサポートしています。

NGINX では、時間の経過とともに、ほとんどのサイトで SSL が完全に有効化され、HTTP/2 に移行すると予想しています。 これにより、セキュリティが強化され、新しい最適化が発見され実装されるにつれて、パフォーマンスが向上するよりシンプルなコードが実現します。

ヒント7 – ソフトウェアのバージョンを更新する

アプリケーションのパフォーマンスを向上させる簡単な方法の 1 つは、安定性とパフォーマンスの評判に基づいてソフトウェア スタックのコンポーネントを選択することです。 さらに、高品質なコンポーネントの開発者は、時間の経過とともにパフォーマンスの向上やバグの修正を追求していく可能性が高いため、最新の安定したバージョンのソフトウェアを使用することは有益です。 新しいリリースは、開発者やユーザー コミュニティからより多くの注目を集めます。 新しいビルドでは、新しいハードウェアのチューニングなど、新しいコンパイラの最適化も活用されます。

安定した新しいリリースは通常、古いリリースよりも互換性が高く、パフォーマンスも優れています。 また、ソフトウェアの更新を常に把握しておけば、チューニングの最適化、バグ修正、セキュリティ警告を常に把握しやすくなります。

古いソフトウェアを使い続けると、新しい機能を活用できなくなる可能性もあります。 たとえば、上記の HTTP/2 には現在 OpenSSL 1.0.1 が必要です。 2016 年半ばより、HTTP/2 には 2015 年 1 月にリリースされた OpenSSL 1.0.2 が必要になります。

NGINX ユーザーは、まず最新バージョンのNGINXまたはNGINX Plusに移行することから始めることができます。これらには、ソケット シャーディングやスレッド プール (ヒント 9を参照) などの新しい機能が含まれており、どちらもパフォーマンスが継続的に調整されています。 次に、スタック内のより深いところにあるソフトウェアを確認し、可能な限り最新バージョンに移行します。

ヒント 8 – パフォーマンスのために Linux を調整する

Linux は、今日のほとんどの Web サーバー実装の基盤となるオペレーティング システムであり、インフラストラクチャの基盤として、パフォーマンスを大幅に向上させる機会を提供します。 デフォルトでは、多くの Linux システムは、リソースをほとんど使用せず、一般的なデスクトップのワークロードに一致するように保守的に調整されています。 つまり、Web アプリケーションのユースケースでは、パフォーマンスを最大限に高めるために、少なくともある程度の調整が必要になります。

Linux の最適化は Web サーバーに固有です。 NGINX を例に、Linux を高速化するために検討できる変更点のいくつかを次に示します。

• バックログ キュー– 停止しているように見える接続がある場合は、 NGINX からの対応を待機するためにキューに入れることができる接続の最大数であるnet.core.somaxconn を増やすことを検討してください。既存の接続制限が小さすぎる場合はエラー メッセージが表示されるので、エラー メッセージがなくなるまでこのパラメータを徐々に増やすことができます。
• ファイル記述子– NGINX は接続ごとに最大 2 つのファイル記述子を使用します。 システムが多数の接続を処理している場合、増加した負荷に対応するために、システム全体のファイル記述子の制限であるsys.fs.file_maxと、ユーザーのファイル記述子の制限であるnofile を増やす必要がある場合があります。
• エフェメラル ポート– プロキシとして使用する場合、NGINX は各アップストリーム サーバーに一時的な (「エフェメラル」) ポートを作成します。 net.ipv4.ip_local_port_rangeで設定されたポート値の範囲を広げることで、使用可能なポートの数を増やすことができます。 また、 net.ipv4.tcp_fin_timeout設定を使用して、非アクティブなポートが再利用される前のタイムアウトを短縮し、ターンオーバーを高速化することもできます。

NGINX については、 NGINX パフォーマンス チューニング ガイドを参照して、Linux システムを最適化する方法を学習し、大量のネットワーク トラフィックに簡単に対処できるようにしてください。

ヒント 9 – パフォーマンスのために Web サーバーを調整する

どのような Web サーバーを使用する場合でも、Web アプリケーションのパフォーマンスに合わせて調整する必要があります。 以下の推奨事項は一般的にどの Web サーバーにも適用されますが、NGINX には特定の設定が示されています。主な最適化は次のとおりです。

• アクセス ログ– すべてのリクエストのログ エントリをすぐにディスクに書き込む代わりに、エントリをメモリにバッファリングし、グループとしてディスクに書き込むことができます。 NGINX の場合、メモリ バッファーがいっぱいになったときにログ エントリをディスクに書き込むには、 access_logディレクティブにbuffer= sizeパラメーターを追加します。 flush= timeパラメータを追加すると、指定された時間後にバッファの内容もディスクに書き込まれます。
• バッファリング- バッファリングでは、バッファがいっぱいになるまで応答の一部をメモリ内に保持し、クライアントとの通信をより効率的にすることができます。 メモリに収まらない応答はディスクに書き込まれるため、パフォーマンスが低下する可能性があります。 NGINX バッファリングがオンの場合、 proxy_buffer_sizeおよびproxy_buffersディレクティブを使用してそれを管理します。
• クライアント キープアライブ- キープアライブ接続は、特に SSL/TLS が使用されている場合にオーバーヘッドを削減します。 NGINX の場合、特定の接続でクライアントが実行できるkeepalive_requestsの最大数をデフォルトの 100 から増やすことができます。また、 keepalive_timeout を増やすと、keepalive 接続をより長く開いたままにすることができ、後続のリクエストが高速化されます。
• アップストリーム キープアライブ- アップストリーム接続 (アプリケーション サーバー、データベース サーバーなどへの接続) も、キープアライブ接続の恩恵を受けます。 アップストリーム接続の場合、各ワーカー プロセスに対して開いたままになっているアイドル キープアライブ接続の数であるkeepalive を増やすことができます。 これにより、接続の再利用が増加し、まったく新しい接続を開く必要性が減ります。 詳細については、ブログ記事「HTTP キープアライブ接続と Web パフォーマンス」を参照してください。
• 制限– クライアントが使用するリソースを制限すると、パフォーマンスとセキュリティが向上します。 NGINX の場合、 limit_connおよびlimit_conn_zoneディレクティブは特定のソースからの接続数を制限し、 limit_rate は帯域幅を制限します。 これらの設定により、正当なユーザーによるリソースの「独占」を阻止し、攻撃を防ぐこともできます。 limit_reqおよびlimit_req_zoneディレクティブは、クライアント要求を制限します。 アップストリーム サーバーに接続するには、アップストリーム構成ブロックのserverディレクティブにmax_connsパラメーターを使用します。 これにより、アップストリーム サーバーへの接続が制限され、過負荷が防止されます。 関連するキューディレクティブは、 max_conns制限に達した後、指定された数のリクエストを指定された時間保持するキューを作成します。
• ワーカー プロセス– ワーカー プロセスはリクエストの処理を担当します。 NGINX は、イベントベースのモデルと OS に依存するメカニズムを採用して、ワーカー プロセス間でリクエストを効率的に分散します。 推奨されるのは、CPU ごとにworker_processesの値を 1 に設定することです。 必要に応じて、ほとんどのシステムでworker_connectionsの最大数 (デフォルトでは 512) を安全に増やすことができます。システムに最適な値を見つけるために実験してください。
• ソケット シャーディング- 通常、単一のソケット リスナーが新しい接続をすべてのワーカー プロセスに分散します。 ソケット シャーディングでは、各ワーカー プロセスに対してソケット リスナーが作成され、カーネルはソケット リスナーが使用可能になると接続を割り当てます。 これにより、ロックの競合が軽減され、マルチコア システムのパフォーマンスが向上します。 ソケット シャーディングを有効にするには、 listenディレクティブにreuseportパラメータを含めます。
• スレッド プール– あらゆるコンピューター プロセスは、単一の低速な操作によって停止する可能性があります。 Web サーバー ソフトウェアの場合、ディスク アクセスによって、メモリ内の情報の計算やコピーなど、多くの高速操作が遅延される可能性があります。 スレッド プールを使用すると、低速な操作は別のタスク セットに割り当てられ、メイン処理ループは高速な操作を実行し続けます。 ディスク操作が完了すると、結果はメイン処理ループに戻ります。 NGINX では、 read()システム コールとsendfile()の 2 つの操作がスレッド プールにオフロードされます。

ヒント。 オペレーティング システムまたはサポート サービスの設定を変更する場合は、一度に 1 つの設定を変更し、パフォーマンスをテストします。 変更によって問題が発生した場合、またはサイトの実行速度が向上しない場合は、変更を元に戻してください。

NGINX Web サーバーのチューニングの詳細については、ブログ記事「パフォーマンス向上のための NGINX のチューニング」を参照してください。

ヒント 10 – ライブアクティビティを監視して問題とボトルネックを解決する

アプリケーションの開発と配信に対する高パフォーマンスなアプローチの鍵は、アプリケーションの実際のパフォーマンスを綿密にリアルタイムで監視することです。 特定のデバイス内および Web インフラストラクチャ全体のアクティビティを監視できる必要があります。

サイトアクティビティの監視は主に受動的です。つまり、何が起こっているかを伝え、問題を見つけて修正するのはユーザーの責任になります。

監視により、さまざまな種類の問題を検出できます。 これらには以下が含まれます:

• サーバーがダウンしています。
• サーバーが不安定になり、接続が切断されます。
• サーバーはキャッシュミスの割合が高くなっています。
• サーバーが正しいコンテンツを送信していません。

New Relic や Dynatrace などのグローバル アプリケーション パフォーマンス監視ツールは、リモートの場所からページの読み込み時間を監視するのに役立ちます。一方、NGINX は、アプリケーション配信側を監視するのに役立ちます。 アプリケーション パフォーマンス データは、最適化がユーザーにとって実際にどのような変化をもたらすか、またトラフィックを維持するためにインフラストラクチャに容量を追加することを検討する必要がある時期を示します。

問題を迅速に特定して解決できるように、NGINX Plus はアプリケーション対応のヘルスチェック(定期的に繰り返され、問題を警告するために使用される合成トランザクション) を追加します。 NGINX Plus には、既存のタスクが完了するまで新しい接続を停止するセッション ドレイン機能と、回復したサーバーが負荷分散されたグループ内で速度を上げることができるスロー スタート機能もあります。 ヘルスチェックを効果的に使用すると、問題がユーザー エクスペリエンスに大きな影響を与える前に問題を特定できます。また、セッション ドレインとスロー スタートを使用すると、サーバーを交換して、プロセスが認識されるパフォーマンスや稼働時間に悪影響を与えないようにすることができます。 この図は、サーバー、TCP 接続、キャッシュを備えた Web インフラストラクチャ用の組み込みの NGINX Plusライブ アクティビティ監視ダッシュボードを示しています。

結論 – パフォーマンスが10倍向上

1 つの Web アプリケーションで実現できるパフォーマンスの向上は大きく異なり、実際の向上は予算、投資できる時間、既存の実装のギャップによって異なります。 では、独自のアプリケーションのパフォーマンスを 10 倍向上させるにはどうすればよいでしょうか?

各最適化の潜在的な影響について理解を深めるために、上記の各ヒントで実現できる可能性のある改善点についてのヒントを以下に示します。ただし、効果はほぼ確実に異なります。

• リバース プロキシ サーバーと負荷分散– 負荷分散が行われていないか、負荷分散が不十分な場合、パフォーマンスが著しく低下する可能性があります。 NGINX などのリバース プロキシ サーバーを追加すると、Web アプリケーションがメモリとディスク間でスラッシングするのを防ぐことができます。 負荷分散により、負荷が高すぎるサーバーから利用可能なサーバーに処理を移動し、スケーリングを容易にすることができます。 これらの変更により、パフォーマンスが劇的に向上し、現在の実装の最悪の瞬間と比較して 10 倍の改善が簡単に達成され、全体的なパフォーマンスについては、それほど大きくはありませんが、大きな成果が得られます。
• 動的コンテンツと静的コンテンツのキャッシュ– アプリケーション サーバーとしても機能している過負荷の Web サーバーがある場合、動的コンテンツのみをキャッシュすることで、ピーク時のパフォーマンスを 10 倍向上できます。 静的ファイルのキャッシュによっても、パフォーマンスが 1 桁の倍数向上する可能性があります。
• データの圧縮- 写真の場合は JPEG、グラフィックの場合は PNG、ムービーの場合は MPEG-4、音楽ファイルの場合は MP3 などのメディア ファイル圧縮を使用すると、パフォーマンスが大幅に向上します。 これらをすべて使用したら、テキスト データ (コードと HTML) を圧縮すると、初期ページの読み込み時間が 2 倍短縮されます。
• SSL/TLS の最適化– セキュア ハンドシェイクはパフォーマンスに大きな影響を与える可能性があるため、最適化すると、特にテキストを多用するサイトでは、初期応答性が 2 倍向上する可能性があります。 SSL/TLS でのメディア ファイル転送を最適化しても、パフォーマンスの向上はわずかしか得られない可能性があります。
• HTTP/2 と SPDY の実装– SSL/TLS と併用すると、これらのプロトコルによってサイト全体のパフォーマンスが徐々に向上する可能性があります。
• Linux および Web サーバー ソフトウェア (NGINX など) のチューニング- バッファリングの最適化、キープアライブ接続の使用、時間のかかるタスクを別のスレッド プールにオフロードするなどの修正により、パフォーマンスが大幅に向上します。たとえば、スレッド プールを使用すると、ディスクを大量に使用するタスクをほぼ 1 桁高速化できます。

ぜひこれらのテクニックを実際に試してみてください。 どのようなアプリケーション パフォーマンスの改善を実現できたかをお聞かせください。 結果を下のコメント欄で共有するか、ハッシュタグ #NGINX および #webperf を付けてツイートしてください。

インターネット統計のリソース

Statista.com – 2016 年の G-20 諸国における国内総生産に占めるインターネット経済の割合

Kissmetrics – 読み込み時間が収益に与える影響（インフォグラフィック）

Econsultancy – サイトの速度: コンバージョン率を向上させるためのケーススタディ、ヒント、ツール