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

作成者: Rick Anderson および Tom Dykstra

メモリ内キャッシュ

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

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

分散キャッシュ

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

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

HybridCache

HybridCache API は、IDistributedCache および IMemoryCache API のいくつかのギャップを埋めます。 HybridCache は、キャッシュへの保存とキャッシュからの取得のほとんどの側面を処理する既定の実装を持つ抽象クラスです。

機能

HybridCache には、以下に示すように他の API にはない機能があります。

• インプロセス キャッシュとアウトプロセス キャッシュの両方に対応する統合 API。

  HybridCache は、既存の IDistributedCache と IMemoryCache の使用に完全に取って代わるように設計されており、新しいキャッシュ コードを追加するための簡単な API を提供します。 アプリに IDistributedCache の実装がある場合、HybridCache サービスはそれをセカンダリ キャッシュ用に使用します。 この 2 段階のキャッシュ戦略により、HybridCache はインメモリ キャッシュの速度と、分散キャッシュや永続キャッシュの持続性を実現できます。

• スタンピード保護。

  キャッシュ スタンピードは、頻繁に使用されるキャッシュ エントリが取り消され、同じキャッシュ エントリを同時に再入力しようとする要求が多すぎる場合に発生します。 HybridCache は同時操作を組み合わせて、特定の応答へのすべての要求が、最初の要求がキャッシュを設定するのを待機するように保証します。

• 構成可能なシリアル化。

  シリアル化は、サービスの登録の一環として構成され、AddHybridCache 呼び出しからチェーンされる WithSerializer および WithSerializerFactory メソッドを介して型固有シリアライザーと汎用シリアライザーをサポートします。 既定では、このサービスは string と byte[] を内部的に処理し、その他すべてに関しては System.Text.Json を使用します。 protobuf や XML など、他の種類のシリアライザー用に構成することも可能です。

HybridCache API が相対的に見てどれほど簡単かを確認するには、これを使用するコードを IDistributedCache を使用するコードと比較してください。 IDistributedCache を使用するとどのようになるかの例を以下に示します。

public class SomeService(IDistributedCache cache)
{
    public async Task<SomeInformation> GetSomeInformationAsync
        (string name, int id, CancellationToken token = default)
    {
        var key = $"someinfo:{name}:{id}"; // Unique key for this combination.
        var bytes = await cache.GetAsync(key, token); // Try to get from cache.
        SomeInformation info;
        if (bytes is null)
        {
            // Cache miss; get the data from the real source.
            info = await SomeExpensiveOperationAsync(name, id, token);

            // Serialize and cache it.
            bytes = SomeSerializer.Serialize(info);
            await cache.SetAsync(key, bytes, token);
        }
        else
        {
            // Cache hit; deserialize it.
            info = SomeSerializer.Deserialize<SomeInformation>(bytes);
        }
        return info;
    }

    // This is the work we're trying to cache.
    private async Task<SomeInformation> SomeExpensiveOperationAsync(string name, int id,
        CancellationToken token = default)
    { /* ... */ }
}

シリアル化などを含め、毎回やるべき作業が多数存在します。 また、"キャッシュ ミス" のシナリオでは、キャッシュ ミスが発生するスレッド、基になるデータをフェッチするスレッド、それをシリアル化するスレッド、そのデータをキャッシュに送信するスレッドなど、複数の同時実行スレッドを扱うことになる可能性があります。

HybridCache を使用した場合の同等なコードを以下に示します。

public class SomeService(HybridCache cache)
{
    public async Task<SomeInformation> GetSomeInformationAsync
        (string name, int id, CancellationToken token = default)
    {
        return await cache.GetOrCreateAsync(
            $"someinfo:{name}:{id}", // Unique key for this entry.
            async cancel => await SomeExpensiveOperationAsync(name, id, cancel),
            token: token
        );
    }
}

このコードはより簡単で、ライブラリはスタンピード保護やその他の IDistributedCache が提供しない機能を提供します。

互換性

HybridCache ライブラリでは、.NET Framework 4.7.2 および .NET Standard 2.0 までの古い .NET ランタイムがサポートされています。

その他のリソース

詳細については、次のリソースを参照してください。

• ASP.NET Core の HybridCache ライブラリ
• GitHub issue dotnet/aspnetcore #54647
• HybridCache ソース コード

応答キャッシュ

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

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

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

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

出力キャッシュ

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

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

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

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

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

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

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

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

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

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

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

詳細については、「ASP.NET Core の出力キャッシュ ミドルウェア」を参照してください。

キャッシュ タグ ヘルパー

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

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

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

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

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