ASP.NET Core でのキャッシュの概要

作成者: Rick Anderson および Kirk Larkin

メモリ内キャッシュ

メモリ内キャッシュの場合、キャッシュされるデータはサーバー メモリを使用して格納されます。 この種類のキャッシュは、1 台またはセッション アフィニティを使用する複数のサーバーに適しています。 セッション アフィニティは、スティッキー セッションとも呼ばれます。 スティッキー セッションは、クライアントからの要求が処理のために常に同じサーバーにルーティングされることを意味します。

詳細については、「ASP.NET Core でメモリ内にキャッシュする」と「Azure Application Gateway セッション アフィニティの問題のトラブルシューティング」を参照してください。

分散キャッシュ

アプリがクラウドまたはサーバー ファームでホストされている場合にデータをメモリに格納するには、分散キャッシュを使用します。 このキャッシュは、要求を処理するサーバー間で共有されます。 クライアントのためのキャッシュされたデータが使用可能な場合、クライアントから送信された要求は、グループ内の任意のサーバーで処理できます。 ASP.NET Core は、SQL Server、Redis、NCache の分散キャッシュと連携して動作します。

詳細については、「ASP.NET Core の分散キャッシュ」を参照してください。

キャッシュ タグ ヘルパー

キャッシュ タグ ヘルパーを使用して、MVC ビューまたは Razor ページからのコンテンツをキャッシュします。 キャッシュ タグ ヘルパーは、メモリ内キャッシュを使用してデータを格納します。

詳細については、「ASP.NET Core MVC のキャッシュ タグ ヘルパー」を参照してください。

分散キャッシュ タグ ヘルパー

分散キャッシュ タグ ヘルパーを使用して、分散クラウドまたは Web ファームのシナリオで MVC ビューまたは Razor ページからのコンテンツをキャッシュします。 分散キャッシュ タグ ヘルパーは、SQL Server、Redis、または NCache を使用してデータを格納します。

詳細については、「ASP.NET Core の分散型キャッシュ タグ ヘルパー」を参照してください。

応答キャッシュ

応答キャッシュ ミドルウェア:

• HTTP キャッシュ ヘッダーに基づくサーバー応答のキャッシュを有効にします。 標準の HTTP キャッシュ セマンティクスを実装します。 プロキシなどの HTTP キャッシュ ヘッダーに基づいてキャッシュします。
• 通常、ブラウザーによってキャッシュを防ぐ要求ヘッダーが設定されるため、Razor Pages などの UI アプリには有益ではありません。 出力キャッシュは、ASP.NET Core 7.0 以降で使用でき、UI アプリにベネフィットがあります。 出力キャッシュでは、HTTP ヘッダーとは別にキャッシュする必要がある内容が構成によって決定されます。
• キャッシュの条件が満たされているクライアントからのパブリック GET または HEAD API 要求に役立つ場合があります。

応答キャッシュをテストするには、Fiddler または要求ヘッダーを明示的に設定できる別のツールを使用します。 キャッシュをテストするには、ヘッダーを明示的に設定することをおすすめします。 詳細については、「 トラブルシューティング」を参照してください。

出力キャッシュ

出力キャッシュ ミドルウェアを使用すると、HTTP 応答のキャッシュが可能になります。 出力キャッシュは、次の点で応答キャッシュとは異なります。

• キャッシュの動作は、サーバー上で構成できます。

  応答キャッシュの動作は、HTTP ヘッダーによって定義されます。 たとえば、Chrome または Edge を使用して Web サイトにアクセスすると、ブラウザーから Cache-control: max-age=0 ヘッダーが自動的に送信されます。 このヘッダーは、サーバーがクライアントによって提供される指示に従っているため、応答キャッシュを効果的に無効にします。 サーバーに新しいキャッシュされた応答がある場合でも、要求ごとに新しい応答が返されます。 出力キャッシュでは、サーバーで構成したキャッシュ動作はクライアントによってオーバーライドされません。

• キャッシュ ストレージ メディアは拡張可能です。

  既定でメモリーが使用されます。 応答キャッシュはメモリに制限されます。

• 選択したキャッシュ エントリをプログラムで無効にすることができます。

  応答キャッシュの HTTP ヘッダーへの依存により、キャッシュ エントリを無効にするオプションはほとんどありません。

• リソース ロックにより、キャッシュ スタンピードや thundering herd のリスクが軽減されます。

  キャッシュ スタンピードは、頻繁に使用されるキャッシュ エントリが取り消され、同じキャッシュ エントリを同時に再入力しようとする要求が多すぎる場合に発生します。 Thunderbolt herd も似ています。キャッシュ エントリにまだ存在しない同一の応答に対する要求のバーストです。 リソース ロックにより、特定の応答のすべての要求が、最初の要求がキャッシュに設定されるまで待機します。 応答キャッシュには、リソース ロック機能がありません。

• キャッシュの再検証により、帯域幅の使用が最小限に抑えられます。

  キャッシュの再検証とは、サーバーがキャッシュされた応答本文の代わりに 304 Not Modified HTTP 状態コードを返すことができることを意味します。 この状態コードは、要求に対する応答が以前に受信されたものと変更されていないことをクライアントに通知します。 応答キャッシュでは、キャッシュの再検証は行われません。