Nginx HTTPプロキシ、ロードバランシング、バッファリング、およびキャッシュ：概要

はじめに

Nginxは、リバースプロキシ、メールプロキシ、ロードバランサー、HTTPキャッシュとしても使用される高性能なWebサーバーです。Nginxは無料でオープンソースであり、誰でもダウンロードして自身のサーバー環境で使用することができます。

すでにウェブサイトを配信するためにNginxを使用したことがあるかもしれません。このチュートリアルでは、Nginxのその他の機能について説明します。NginxのHTTPプロキシ機能により、リクエストをバックエンドのHTTPサーバーに渡して処理させることができます。この機能を使用すると、複数のバックエンドサーバーをセットアップできます。これにより、クライアントからのリクエストの急増に対応するために、必要に応じてインフラストラクチャを拡張できます。

チュートリアルを進めるにつれて、Nginxのロードバランシング機能、バッファリング、およびキャッシュレスポンスを使用してインフラストラクチャを拡張し、サーバーのパフォーマンスを向上させるとともに、クライアントにより良いエクスペリエンスを提供する方法について学びます。始めましょう！

まず最初に、Nginxを始めるには、こちらのUbuntuサーバーにNginxをインストールする方法に関するチュートリアルをご覧ください。.

プロキシに関する一般情報

Webサーバーに関する知識が、Webサイトのリクエストの処理やWebページの配信だけである場合、なぜリクエストをプロキシする必要があるのか疑問に思うかもしれません。以下にその理由を説明します。

Nginxから他のサーバーにリクエストをプロキシする理由の1つは、インフラストラクチャのスケーラビリティをサポートすることです。Nginxはデフォルトで多くの接続を同時に処理します。これにより、クライアントにとっての最初の接点として最適になります。その後、リクエストをさまざまなバックエンドサーバーに渡して、クライアントリクエストの実際の処理を行わせることができます。これが負荷を分散させる仕組みです。したがって、インフラストラクチャを可能な限り拡張できるようになります。また、他のサーバーがリクエストの処理を継続している間に、一部のサーバーをメンテナンスのために停止することも可能になります。

他のサーバーにリクエストをプロキシする2つ目の理由は、本番環境でクライアントからのリクエストを直接処理するのに適していないアプリケーションサーバーを使用している場合です。Webサーバーを含むいくつかのフレームワークは、Nginxのような高いパフォーマンスには適していません。Nginxをエントリポイントにし、これらの低パフォーマンスなサーバーにリクエストをプロキシすることで、ユーザーにより良いエクスペリエンスを提供できます。さらに、アプリケーションのセキュリティ向上も保証できます。

Nginxにおけるリクエストのプロキシプロセスは、Nginxサーバーからのリクエストを操作し、実際の処理のために他のバックエンドサーバーに渡すことを含みます。他のバックエンドサーバーがリクエストを処理すると、その結果がNginxに返されます。その後、Nginxは結果をクライアントへのレスポンスとして送信します。この場合のクライアントは、WebブラウザやモバイルWebアプリなどです。他のバックエンドサーバーは、インターネット上で公開されていないローカルサーバー、リモートサーバー、あるいはNginxのサーバーブロック設定内の他の仮想サーバーである場合もあります。Nginxがリクエストをプロキシしているこれらの他のサーバーは、アップストリームサーバーと呼ばれます。.

Nginxは、HTTP(S)、Memcached, SCGI, FastCGI、およびuWSGIを含む複数のプロトコルを使用して通信するサーバーにリクエストをプロキシできます。プロトコルの種類ごとに、ディレクティブのセットが存在します。このチュートリアルでは、HTTPプロトコルに焦点を当てます。Nginxはリクエストとメッセージコンポーネントを、アップストリームサーバーが解釈して処理できる形式に解析します。

基本的なHTTPプロキシパスの分析

最も単純なタイプのプロキシは、HTTP経由で通信する単一のサーバーにリクエストを渡すことです。このタイプのプロキシは一般に「プロキシパス」と呼ばれ、Nginx設定ファイル内の適切に命名された proxy_pass ディレクティブによって処理されます。

proxy_pass ディレクティブは location ブロック内に記述されます。また、location コンテキストのブロック内や limit_except コンテキスト内にも記述されます。リクエストが proxy_pass ディレクティブを含む location に一致すると、リクエストはディレクティブが指定するURLに送信されます。以下は設定スニペットの例です。

上記の例では、ポート80へのリクエストはlocalhost:3000に送られます：

上のスクリーンショットは、localhostにアクセスしようとしたときのデフォルトのNginxページを示しています。proxy passディレクティブを有効にしてNginxサーバーを再起動すると、すべてのリクエストがポート3000に送られます。下の画像からわかるように、デモアプリケーションがポート3000で実行されており、ポートを指定せずにlocalhostから直接アクセスできます：

次の例では、proxy_pass定義のサーバーの末尾にURIが指定されていません。このパターンに適合する定義の場合、クライアントがリクエストしたURIはそのままアップストリームサーバーに渡されます。

たとえば、このブロックが/match/url/hereへのリクエストを処理する場合、リクエストURIはhttp://example.com/match/url/hereとしてexample.comサーバーに送られます。

以下は、代替設定スニペットの例です：

上のスニペットでわかるように、プロキシサーバーの末尾にURIセグメントをnew/url/prefixとして定義しています。proxy_pass定義でURIを定義すると、処理のためにアップストリームサーバーに送られる際、location定義に一致するリクエストの部分がこのURIに置き換えられます。

たとえば、Nginxサーバー上の/match/url/hereへのリクエストは、http://example.com/new/url/hereとしてアップストリームサーバーに渡されます。/match/urlが/new/urlに置き換えられます。この点を覚えておいてください。

場合によっては、上記のようなURIの受け渡しが不可能なことがあります。そのような場合、Nginxはproxy_pass定義の末尾にあるURIを無視します。最終的には、クライアントからの元のURI、または他のディレクティブが変更したURIのいずれかがアップストリームサーバーに渡されます。

一例として、正規表現がlocationに一致する場合が挙げられます。Nginxは、URIのどの部分が式に一致したかを判断できない場合があります。そのため、元のクライアントリクエストURIを送信します。これにより、同じブロック内でクライアントURIの書き換えと処理が行われます。このような場合、書き換えられたURIが渡されます。

Nginxはヘッダーをどのように処理しますか？

ヘッダーは、サーバーがリクエストを処理する方法において極めて重要です。一部のヘッダーには認証情報が含まれている場合があります。したがって、Nginxのプロキシ処理がヘッダーをどのように処理するかを理解する必要があります。Nginxからアップストリームサーバーへのプロキシリクエストは、クライアントから直接送られてきたものとは異なって見えます。違いの一部は、プロキシリクエストに伴うヘッダーによるものです。

リクエストのプロキシ処理中、Nginxはクライアントから受信したリクエストヘッダーを調整します。これらの調整には以下が含まれます：

• すべての空のヘッダーを削除すること。空のヘッダーはリクエストを肥大化させるだけなので、アップストリームサーバーに渡す意味はありません。

• アンダースコアを含むヘッダーはデフォルトで無効とみなされ、リクエストから削除されます。この動作を変更し、Nginxがアンダースコアを含むヘッダーを有効として解釈できるようにしたい場合は、underscores_in_headersディレクティブを「on」に指定できます。指定しない場合、クライアントからのそのようなヘッダーがアップストリームサーバーに到達することはありません。

• 「Host」ヘッダーは、$proxy_host変数で指定された値に書き換えられます。これは、proxy_passディレクティブで指定されたアップストリームサーバーのIPアドレスまたは名前とポート番号です。

• 「Connection」ヘッダーの値は「close」に変更されます。connectionヘッダーは、2者間で確立された特定の接続に関する情報を保持します。Nginxがその値をcloseに設定すると、元のリクエストへの応答が完了した時点で接続が閉じられることをアップストリームサーバーに示します。したがって、持続的な接続であることを期待すべきではありません。

上記で概説したプロキシリクエストヘッダーの調整から、以下の点に注意できます：

• アップストリームサーバーにヘッダーを渡したくない場合は、空の文字列に設定することで、リクエストから完全に削除されます。

• アップストリームサーバーのアプリケーションが非標準のヘッダーを処理する場合は、ヘッダーにアンダースコアが含まれていないことを確認してください。オプションとして、設定で underscores_in_headers ディレクティブを “on” に設定することもできます（IPアドレスとポートの組み合わせに対するデフォルトのサーバー宣言のコンテキスト、またはHTTPコンテキストのいずれかで有効です）。これにより、ヘッダーが無効としてフラグを立てられることがなくなり、実際にアップストリームサーバーに渡されるようになります。

• ほとんどのプロキシ処理において、“Host” ヘッダーは非常に重要です。デフォルトでは、proxy_pass の指定から取得されたドメイン名またはIPアドレスとポートを含む変数である $proxy_host の値に設定されます。このアドレスはデフォルトで選択され、接続情報から直接取得されます。これは、Nginxがアップストリームサーバーからの応答を保証できる唯一のアドレスです。

以下は、“Host” ヘッダーの最も一般的な値です。

• $host – リクエストライン自体のホスト名、クライアントリクエストからの “Host” ヘッダー、またはリクエストに一致するサーバー名の優先順位で設定される変数です。

• $http_host – “Host” ヘッダーをクライアントリクエストからの “Host” ヘッダーに設定する変数です。クライアントのリクエスト内のヘッダーは、常に変数としてNginxで利用可能です。これらの変数は $http_ プレフィックスで始まり、その後に小文字のヘッダー名が続きます。$http_host 変数はほとんどの場合問題なく動作しますが、クライアントリクエストに有効な “Host” ヘッダーがない場合、転送が失敗する原因となることがあります。

• $proxy_host – “Host” ヘッダーを、proxy_pass の指定から取得されたドメイン名またはIPアドレスとポートの組み合わせに設定する変数です。これはNginxの観点からはデフォルトの動作であり、安全であると見なされます。ただし、サーバーがリクエストを正しく処理するために必要なものではない場合があります。

ほとんどの設定では、“Host” ヘッダーを $host 変数に設定することになります。これは非常に柔軟であり、アップストリームサーバーに正確に入力されたヘッダーを提供します。

ヘッダーの設定と変更

proxy_set_header ディレクティブを使用すると、プロキシ接続のヘッダーを設定または変更できます。前述の “Host” ヘッダーにおいて、プロキシされたリクエストで一般的な追加のヘッダーを変更および追加するには、以下のように行います。

上記の設定スニペットでは、“Host” ヘッダーを、リクエストされている元のホストに関する情報を含む $host 変数に設定しています。また、クライアントからの元のリクエストのスキーム（HTTPまたはHTTPSリクエストのいずれか）に関する情報を含む X-Forwarded-Proto ヘッダーを設定しています。

クライアントの実際のIPアドレスを X-Real-IP に渡します。これにより、アップストリームサーバーはクライアントの送信元IPに基づいて、適切に判断を下したりログを保存したりできます。X-Forwarded-For ヘッダーには、クライアントがこのポイントに到達するまでにプロキシ経由で通過したサーバーに属するすべてのIPアドレスのリストが含まれています。上記のコードスニペットでは、これを $proxy_add_x_forwarded_for 変数に設定しています。この変数は、クライアントから取得した元の X-Forwarded-For ヘッダーの値を受け取り、その末尾に Nginx プロキシサーバーのIPアドレスを追加します。

proxy_set_header ディレクティブを複数のロケーションで参照したい場合は、それを server または http コンテキストに移動できます。以下の設定スニペットを参考にしてください。

プロキシ接続をロードバランスするためのアップストリームコンテキストの定義

ここまでに、単一のバックエンドアップストリームサーバーに対するシンプルなHTTPプロキシの実行方法を理解できたと思います。幸いなことに、Nginxを使用すると、リクエストを処理するために渡すバックエンドサーバーのプールを定義することで、このような構成をスケールさせることができます。

Nginxは、サーバーのプールを定義するために使用されるupstreamと呼ばれるディレクティブを提供します。ディレクティブの設定内では、クライアントのリクエストを処理できるサーバーのみを指定する必要があります。プロキシサーバーとしてのNginxは、最小限の労力でインフラストラクチャのスケーリングを可能にします。upstreamディレクティブは、Nginx設定のhttpコンテキスト内で指定する必要があります。

以下は、upstreamディレクティブを示す例です。

上記の設定コードスニペットでは、several_backend_hostsという名前のアップストリームコンテキストを定義しました。定義されたコンテキスト名は、プロキシパス内で利用可能になります。この例に示すように、通常のドメインであるかのように使用できます。serverブロック内では、example.com/proxy-me/…へのすべてのリクエストを、upstreamディレクティブを使用して定義したプール（この場合はseveral_backend_hosts）に渡します。プール内のホストは、設定可能なアルゴリズムを適用して、着信リクエストを処理するために選択されます。デフォルトでは、選択はラウンドロビン（循環）プロセス – 各リクエストは順番に異なるホストにルーティングされます。

アップストリームのバランシングアルゴリズムを変更する方法

上記で強調したように、選択プロセスはラウンドロビンプロセスに従います。このセクションでは、アップストリームプールで使用されるバランシングアルゴリズムを変更する方法を説明します。アルゴリズムを変更するには、以下で定義されているように、upstreamコンテキスト内に他のディレクティブまたはフラグを含めます。

• （ラウンドロビン）– 他のアップストリームバランシングディレクティブが指定されていない場合、デフォルトで、アップストリームコンテキストで定義された各サーバーにリクエストが順番に順次渡されます。

• least_conn – このディレクティブは、アクティブな接続数が最も少ないバックエンドサーバーを選択するようアップストリームに指示します。これは、1つのバックエンドサーバーへの接続がしばらく持続する可能性がある状況に適用できます。

• hash – このディレクティブは、memcachedプロキシで一般的です。接続は、ランダムに提供されるハッシュキーの値に基づいてバックエンドサーバーに渡されます。ハッシュキーの値は、変数、テキスト、またはその両方の組み合わせにすることができます。hashは、ハッシュに使用されるキーとして機能するためにユーザーからの入力を必要とする唯一のバランシング方法です。

• ip_hash – このディレクティブは、クライアントのIPアドレスに基づいてリクエストを異なるサーバーに分散するようアップストリームに指示します。IPアドレスの最初の3つのオクテットが、どのサーバーがリクエストを処理すべきかを決定するキーになります。このディレクティブの利点は、クライアントが毎回同じサーバーに接続される傾向があるため、セッションの一貫性が確保されることです。

以下は、アップストリームコンテキストにバランシングアルゴリズムディレクティブを追加する方法の例です。

上記のスニペットでは、Nginxは接続数が最も少ないサーバーを選択して、受信したリクエストを処理します。ip_hashディレクティブも同じ構文に従います。hashディレクティブの場合、ハッシュの基準となる任意のキーを指定する必要があります。以下に例を示します。

ここで使用されるハッシュは、クライアント’のIPアドレスとポートの結果になります。オプションのパラメータであるconsistentは、ketama consistent hashing algorithmを実装します。これにより、アップストリームサーバーを変更した場合でも、キャッシュへの影響を最小限に抑えることができます。

バランシングのためのサーバーの重み（Weight）の指定方法

デフォルトでは、バックエンドサーバーを宣言すると、各サーバーの重みは均等になります。これは、各サーバーが同じ量の負荷を処理するためのリソースと能力を備えていることを前提としています。もちろん、これはupstreamコンテキストで指定するバランシングアルゴリズムを考慮した上でのことです。このデフォルトの動作を変更するには、宣言時に各サーバーに別の重みを設定できます。例を見てみましょう。

この例では、host1.example.comは他の2つのサーバーの2倍のトラフィックを受信します。各サーバーの重みはデフォルトで1です。

バッファによるバックエンドサーバーの解放

サーバー設定でプロキシを設定する際、プロセスにサーバーを追加することによるパフォーマンスへの影響が懸念される場合があります。幸いなことに、Nginxにはこれらのパフォーマンス問題を軽減するのに役立つバッファリングおよびキャッシュ機能が備わっています。

別のサーバーにプロキシする場合、2つの異なる接続の速度がクライアントの体験に確実に影響します。

• 最初の接続は、クライアントからNginxプロキシへの接続です。

• 2番目の接続は、Nginxプロキシからバックエンドのアップストリームサーバーへの接続です。

Nginxは、必要に応じてどちらの接続も最適化できるように動作を調整できます。

バッファを無効にすると、アップストリームのバックエンドからのデータは、Nginxプロキシを介してすぐにクライアントへの送信を開始します。クライアントの接続速度が速いことがわかっている場合は、バッファリングを完全にオフにして、データがクライアントに十分に速く届くようにすることができます。バッファをオンにしている場合、Nginxプロキシはバックエンドのアップストリームサーバーから受信したレスポンスデータを一時的に保存します。その後、クライアントの速度に応じてデータを送信します。Nginxがバッファにレスポンスを保持すると、バックエンドサーバーへの接続を閉じることができます。その後、クライアントがサポートする速度でクライアントにデータを配信します。同時に、バックエンドサーバーが他の受信リクエストの処理を続行できるようにします。

デフォルトでは、Nginxのバッファリングはオンになっています。これは、クライアントの接続速度を把握できないためです。クライアントの接続環境は様々であり、遅い場合もあります。以下では、Nginxのバッファリング動作を調整するために指定できるさまざまなディレクティブを定義します。これらのディレクティブはhttp、server、またはlocationコンテキストで定義できますが、サイズ指定のディレクティブはリクエストごとに設定されることに注意してください。そのため、必要以上に大きくすると、受信するクライアントリクエストが多すぎる場合にサーバーのパフォーマンスに影響を与える可能性があります。ディレクティブは以下の通りです。

• proxy_buffering – 特定のコンテキストおよび子コンテキストでバッファリングを有効にするかどうかを制御するディレクティブ。proxy_bufferingのデフォルト設定は「on」です。

• proxy_buffer_size – バックエンドサーバーからのレスポンスに含まれるヘッダーを格納するためのバッファのサイズを指定するディレクティブ。ヘッダーはバックエンドサーバーからのレスポンスの最初の部分を構成します。これらのヘッダーのバッファリングは、レスポンスの残りの部分とは別に行われます。デフォルトでは、このバッファの設定サイズはproxy_buffersと同じです。ただし、ヘッダー情報が小さい場合は、サイズをより小さい値に設定できます。

• proxy_buffers – プロキシされたレスポンス用のバッファの数（第1引数）とサイズ（第2引数）を制御するディレクティブ。デフォルト設定では、1つのメモリページ（4kまたは8k）に等しいサイズのバッファが8個指定されています。バッファの数を増やすことで、より多くの情報のバッファリングを許可できます。

• proxy_max_temp_file_size – リクエストごとに、ディスク上のテンポラリファイルの最大サイズを指定するディレクティブ。アップストリームのレスポンスが大きすぎてバッファに収まらない場合に、テンポラリファイルが作成されます。

• proxy_busy_buffers_size – 「クライアントへの送信準備完了」としてビジー状態にできるバッファの最大サイズを指定するディレクティブ。クライアントは一度に1つのバッファからしかデータを読み取ることができません。ただし、バッファはバッチでクライアントに送信するためにキューに入れられます。このディレクティブを変更することで、この状態になることが許可されるバッファスペースのサイズを指定できます。

• proxy_temp_file_write_size – バックエンドのアップストリームサーバーからのレスポンスが大きすぎて設定されたバッファに収まらない場合に、Nginxが一度にテンポラリファイルに書き込むデータ量を指定するディレクティブ。

• proxy_temp_path – バックエンドのアップストリームサーバーからのレスポンスが大きすぎて設定されたバッファに収まらない場合に、Nginxがテンポラリファイルを保存するディスク上の場所へのパスを指定するディレクティブ。

Nginxは高度にカスタマイズ可能であり、バッファリングの動作を微調整するためのいくつかのディレクティブを提供しています。ほとんどの場合、デフォルト値で問題なく動作します。同時に、カスタム実装のためにこれらの値の一部を調整できることを知っておくと便利です。主にproxy_buffersおよびproxy_buffer_sizeディレクティブを調整することになるでしょう。

以下は、各アップストリームリクエストに対して利用可能なプロキシバッファの数を増やす例です。ヘッダーを格納するバッファのサイズを縮小しながら、これを行います。

バッファリングを完全にオフにすることで、高速なクライアントに対してより迅速にデータを配信する方法を見てみましょう。クライアントの速度が十分に速くない場合、Nginxは自動的にバッファを使用します。ただし、バッファプールを待つのではなく、最初にデータをクライアントにフラッシュします。この設定にはデメリットがあります。この設定では、クライアントがすべてのレスポンスデータを受信するまで、低速なクライアントに対してアップストリームサーバーの接続が開いたままになります。バッファリングが「off」に設定されている場合、proxy_buffer_sizeディレクティブで定義されたバッファのみが使用されます。以下は、バッファリングをオフに指定する方法を示すスニペットです。

• 高可用性（HA）インフラストラクチャの構成（オプションのセットアップ）

Nginxプロキシ設定に冗長なロードバランサーのセットを追加することで、堅牢性を高め、高可用性を確保できます。高可用性（HA）構成とは、単一障害点のないインフラストラクチャのことです。ロードバランサーはこの構成の一部です。複数のロードバランサーを用意することで、1つのロードバランサーが故障したり、メンテナンスのためにオフラインになったりした場合の潜在的なダウンタイムを防ぐことができます。

レスポンス時間を短縮するためのNginxプロキシキャッシュの実装方法

前のセクションでは、バッファリングを使用してバックエンドサーバーを解放し、より多くのリクエストを処理できるようにする方法について説明しました。Nginxには、バックエンドからのレスポンスデータをキャッシュできる別の機能もあります。これにより、すべての受信リクエストに対してアップストリームに接続する必要が完全になくなります。

プロキシキャッシュの実装

proxy_cache_pathディレクティブを使用すると、プロキシされたコンテンツの保存に使用するディスク上の領域を指定してキャッシュを設定できます。proxy_cache_pathディレクティブは、httpコンテキスト内で定義されます。

以下の設定コードスニペットは、キャッシュシステムを実装する方法の例です。

このコードスニペットでは、proxy_cache_pathディレクティブを使用して、キャッシュを保持するファイルシステム上のディレクトリを定義しています。この例で設定したディレクトリは/var/lib/nginx/cacheです。ディレクトリパスは自由に定義できます。適切な権限と所有権を設定して、選択したディレクトリを作成するには、次のコマンドを使用します。

このコードスニペットでは、levels=パラメータでキャッシュの階層構造を指定しています。Nginxは、キー（proxy_cache_keyディレクティブを使用して指定）の値をハッシュ化してキャッシュキーを作成します。指定したレベル（1:2）は、1文字のディレクトリ（ハッシュ値の最後の文字）と、その中に2文字のサブディレクトリ（ハッシュ値の末尾から2番目と3番目の文字）が作成されることを示しています。ほとんどの場合、これを意識する必要はありません。しかし、それがNginxが関連する値を素早く見つけるのにどのように役立つかを知っておくことは良いことです。

keys_zone=パラメータはキャッシュゾーンの名前を定義します。この例ではbackendcacheと名付けています。ここでは、保存するメタデータの量も定義します。この例では、8 MBのキーを保存しています。Nginxは1メガバイトあたり約8000個のエントリを保存できます。max_sizeパラメータは、実際のキャッシュデータの最大サイズを指定します。この例では50MBです。

使用されているproxy_cache_keyディレクティブにも注目してください。このディレクティブは、キャッシュされた値を保存するために使用するキーを指定します。リクエストがキャッシュ内に存在するかどうかを確認するためにも、同じキーを使用します。この例では、そのキーをスキーム（httpまたはhttps）、HTTPリクエストメソッド、およびリクエストされたホストとURIの組み合わせとして指定しています。

さらに、proxy_cache_validディレクティブを使用しています。このディレクティブは、さまざまなステータスコードに対して複数回指定できます。ステータスコードに応じて値を保存する期間を指定できます。このコードスニペットでは、成功コードに対しては10分、404レスポンスに対しては1分を指定しました。

キャッシュゾーンを設定したので、次のステップは、Nginxにキャッシュを使用するタイミングを指示して設定を有効にすることです。以下は、このキャッシュの使用を実装する方法を示す設定スニペットです。

proxy_cacheディレクティブでは、このコンテキストに使用するキャッシュゾーンとしてbackendcacheを指定しています。キャッシュ設定で別の名前を選択した場合は、ここでその名前を置き換えます。有効なエントリごとに、Nginxはリクエストをバックエンドのアップストリームサーバーに渡す前にキャッシュを確認します。

$http_cache_control変数を使用するためにproxy_cache_bypassディレクティブを定義します。この変数は、キャッシュされたレスポンスで応答するか、リソースのキャッシュされていない最新のバージョンで応答するかをサーバーに伝えます。このディレクティブを適切に設定することで、Nginxはクライアントからのさまざまなタイプの発信リクエストを正しく処理できるようになります。

X-Proxy-Cacheという追加のヘッダーも指定されています。このヘッダーには$upstream_cache_status変数の値が設定されます。これにより、リクエストがキャッシュヒット、キャッシュミス、またはキャッシュが明示的にバイパスされたかどうかの情報が得られます。このような情報は、クライアントにとって有用であり、アプリケーションのデバッグ中に極めて重要になります。

キャッシュ結果に関する重要なポイント

キャッシュはプロキシサーバーのパフォーマンスを大幅に向上させますが、キャッシュを実装する際には以下の点に注意する必要があります。

あるユーザーのデータが別のユーザーに表示されてしまう事態を避けるため、ユーザーの個人情報に関連するデータはキャッシュすべきではありません。

バックエンドサーバーは、ウェブサイトのすべての動的要素を考慮する必要があります。さまざまな目的に対応するために、レスポンスで指定できるいくつかのCache-Controlヘッダーがあります。それらについて説明しましょう。

• no-cache – レスポンスを返す前に、バックエンドでデータが変更されたかどうかをプロキシが確認する必要があることを指定します。これは、動的で重要なデータに適用されます。リクエストごとにETagハッシュメタデータヘッダーがチェックされ、バックエンドが同じハッシュ値を返した場合は、以前の値が提供されます。

• no-store – 受信したデータに対してキャッシュを行わないことを指定します。したがって、すべてのリクエストは最新のデータを取得するためにサーバーに送信されます。これは機密データに対して最も安全です。

• private – 共有キャッシュスペースがデータをキャッシュしてはならないことを指定します。このヘッダーを使用してユーザーのブラウザでのキャッシュを指定できますが、同時にプロキシサーバーに対して、それ以降のリクエストではそのデータを無効とみなすよう通知することもできます。

• public – パブリックレスポンスを指定し、接続の任意のポイントでのキャッシュを許可します。

max-ageヘッダーを使用して、キャッシュを保持する期間を秒単位で指定できます。上記で定義したさまざまなヘッダーは、機密データを安全に保ち、動的データを最新に保ち、そして最も重要なこととして、サーバーのパフォーマンスを向上させながらキャッシュを実装するのに役立ちます。

バックエンドサーバーがNginxサーバーを実行している場合は、サーバーブロック内でキャッシュの有効期間を指定できます。これを行うには、以下に示すように設定にexpiresディレクティブを追加します。

最初のブロックはコンテンツのキャッシュを59分間許可し、2番目のブロックはキャッシュしないことを示します。これらの設定はCache-Controlヘッダーのオプションに適用され、たとえば2番目のブロックでは「no-cache」になります。

add-headerディレクティブを使用して、追加の値を設定できます。

結論

このチュートリアルでは、Nginxの強力な機能について学びました。Nginxはウェブサーバーであると同時に、最も重要なこととしてリバースプロキシでもあります。Nginxの設計により、数千の同時接続を処理できます。これにより、ロードバランシングに最適です。この設計のおかげで、処理のために他のバックエンドサーバーにリクエストをプロキシすることは非常に簡単です。

Nginxの柔軟性のおかげで、このチュートリアルの知識があれば、複雑なプロキシやロードバランサーを実装できるはずです。

以下は、当社のブログでご覧いただける、Nginxについてさらに理解を深めるためのリソースです：

• Ubuntu 20.04でLet’s Encryptを使用してNginxを保護する方法

• Ubuntu 20.04にLEMPスタック（Linux、Nginx、MySQL、PHP）をインストールする方法

• Webサーバーの世界：Apache vs. Nginx

• Docker Composeを使用してLaravel、Nginx、MySQLをデプロイする方法

ハッピーコンピューティング！