Azure Cache for Redis インスタンスのデータ永続化の構成

  • [アーティクル]

Redis の永続化を使用すると、キャッシュインスタンスに格納データを保持できます。 ハードウェア障害が発生した場合、キャッシュ インスタンスは、オンラインに戻ったときに永続化ファイルのデータでリハイドレートされます。 データを保持する機能は、すべてのキャッシュ データがメモリに保存されるため、キャッシュ インスタンスの持続性を向上させる重要な方法です。 キャッシュ ノードがダウンしているときに障害が発生した場合、データ損失が発生する可能性があります。 永続化は、Azure Cache for Redis を使用した高可用性とディザスター リカバリー戦略の重要な部分である必要があります。

警告

Premium レベルで永続化を使用している場合は、データ永続化機能を使用する前に、ストレージ アカウントで論理的な削除が有効になっているかどうかを確認します。 論理的な削除でデータ永続化を使用すると、ストレージ コストが非常に高くなります。 詳細については、論理的な削除を有効にする必要性に関するページを参照してください。

警告

Enterprise レベルと Enterprise Flash レベルでの AOF 永続化の "常に書き込む" オプションは、2025 年 4 月 1 日に廃止される予定です。 このオプションにはパフォーマンスに大きな制限があり、現在は推奨されていません。 代わりに、"1 秒ごとに書き込む" オプションを使用するか、RDB 永続化を使用することをお勧めします。

可用性のスコープ

レベル Basic、Standard Premium Enterprise、Enterprise Flash
使用可能 いいえ はい はい (プレビュー)

Redis でのデータ永続化の型

Azure Cache for Redis での永続化には、Redis データベース (RDB) 形式と Append only File (AOF) 形式の 2 つのオプションがあります。

  • RDB 永続化 - RDB 永続化を使用する場合、Azure Cache for Redis によってキャッシュのスナップショットがバイナリ形式で保持されます。 スナップショットは Azure Storage アカウントに保存されます。 構成可能なバックアップ頻度によって、スナップショットを永続化する頻度が決まります。 プライマリとレプリカの両方のキャッシュが無効になるような致命的なイベントが発生した場合、最新のスナップショットを使用してキャッシュが自動的に再構築されます。 RDB 永続化の長所と短所について、詳細をご確認ください。
  • AOF の永続化 - AOF の永続化を使用する場合、Azure Cache for Redis がすべての書き込み操作をログに保存します。 ログは、少なくとも 1 秒に 1 回 Azure Storage アカウントに保存されます。 プライマリとレプリカの両方のキャッシュが無効になるような致命的なイベントが発生した場合、保存されている書き込み操作を使用してキャッシュが自動的に再構築されます。 AOF 永続化の長所と短所について、詳細をご確認ください。

Azure Cache for Redis の永続化機能は、データを損失した後に同じキャッシュにデータを自動的に復元するために使うことが想定されています。 RDB/AOF 永続化データ ファイルを新しいキャッシュまたは既存のキャッシュにインポートすることはできません。 キャッシュ間でデータを移動するには、インポートとエクスポートの機能を使用してください。 詳細については、「Azure Cache for Redis でデータをインポートまたはエクスポートする」を参照してください。

新しいキャッシュに追加できるデータのバックアップを生成するには、PowerShell または CLI を使って、定期的にデータをエクスポートする自動化スクリプトを作成できます。

前提条件と制限事項

永続化機能は、データを損失した後に同じキャッシュにデータを復元するために使うことが想定されています。

  • RDB/AOF 永続化データ ファイルを新しいキャッシュまたは既存のキャッシュにインポートすることはできません。 代わりに、インポート/エクスポート機能を使用します。
  • パッシブ geo レプリケーションまたはアクティブ geo レプリケーションを使用するキャッシュでは、永続化はサポートされていません。
  • Premium レベルでは、AOF 永続化は複数のレプリカではサポートされていません。
  • Premium レベルでは、キャッシュ インスタンスと同じリージョン内のストレージ アカウントにデータを永続化する必要があります。
  • Premium レベルでは、マネージド ID を使用してストレージ アカウントに接続する場合、異なるサブスクリプションのストレージ アカウントを使用してデータを保持できます。

Premium レベルと Enterprise レベルの永続化の違い

Premium レベルでは、データは自分が所有および管理する Azure Storage アカウントに直接永続化されます。 Azure Storage では、データが永続化されると自動的に暗号化されますが、暗号化には独自のキーを使用することもできます。 詳細については、「Azure Storage 暗号化のカスタマー マネージド キー」を参照してください。

警告

Premium レベルで永続化を使用している場合は、データ永続化機能を使用する前に、ストレージ アカウントで論理的な削除が有効になっているかどうかを確認します。 論理的な削除でデータ永続化を使用すると、ストレージ コストが非常に高くなります。 詳細については、論理的な削除を有効にする必要性に関するページを参照してください。

Enterprise および Enterprise Flash レベルでは、データはキャッシュ インスタンスに直接接続されたマネージド ディスクに保持されます。 場所は構成できず、ユーザーがアクセスすることもできません。 マネージド ディスクを使用すると、永続化のパフォーマンスが向上します。 既定では、ディスクは Microsoft マネージド キー (MMK) を使用して暗号化されますが、カスタマー マネージド キー (CMK) も使用できます。 詳細については、「データの暗号化」を参照してください。

Azure portal を使用してデータ永続化を設定する方法

  1. Premium キャッシュを作成するには、Azure portal にサインインし、[リソースの作成] を選択します。 キャッシュは Azure portal で作成できます。 Resource Manager テンプレート、PowerShell、または Azure CLI を使用してそれを作成することもできます。 Azure Cache for Redis の作成について詳しくは、キャッシュの作成に関するページを参照してください。

    Azure Cache for Redis リソースを作成するフォームを示すスクリーンショット。

  2. [リソースを作成] ページで、[データベース] を選択し、[Azure Cache for Redis] を選択します。

    新しいデータベースの種類として選ばれた Azure Cache for Redis を示すスクリーンショット。

  3. [新規 Redis Cache] ページで、新しい Premium キャッシュの設定を構成します。

    設定 提案された値 説明
    DNS 名 グローバルに一意の名前を入力します。 キャッシュ名は 1 から 63 文字の文字列で、数字、英字、ハイフンのみを使用する必要があります。 名前の先頭と末尾には数字または文字を使用する必要があり、連続するハイフンを含めることはできません。 キャッシュ インスタンスのホスト名は \<DNS name>.redis.cache.windows.net です。
    サブスクリプション ドロップダウンでご自身のサブスクリプションを選択します。 この新しい Azure Cache for Redis インスタンスが作成されるサブスクリプション。
    リソース グループ ドロップダウンでリソース グループを選択するか、 [新規作成] を選択して新しいリソース グループ名を入力します。 その中にキャッシュやその他のリソースを作成するリソース グループの名前。 すべてのアプリ リソースを 1 つのリソース グループに配置することで、それらをまとめて簡単に管理または削除できます。
    場所 ドロップダウンで場所を選択します。 キャッシュを使用する他のサービスの近くのリージョンを選択します。
    キャッシュの種類 ドロップダウンで Premium キャッシュを選択し、Premium 機能を構成します。 詳細については、「Azure Cache for Redis の価格」を参照してください。 価格レベルによって、キャッシュに使用できるのサイズ、パフォーマンス、および機能が決まります。 詳細については、Azure Cache for Redis の概要に関するページを参照してください。

  4. [ネットワーク] タブを選択するか、ページの下部にある [ネットワーク] ボタンを選択します。

  5. [ネットワーク] タブで、接続方法を選択します。 Premium キャッシュ インスタンスの場合、パブリック IP アドレスまたはサービス エンドポイント経由で公的に接続することができます。 プライベートに接続するには、プライベート エンドポイントを使用します。

  6. [次へ: 詳細] タブを選択するか、ページの下部にある [次へ: 詳細] ボタンを選択します。

  7. Premium キャッシュ インスタンスの [詳細] タブで、非 TLS ポート、クラスタリング、データ永続化の設定を構成します。 データの永続化の場合、RDB または AOF 永続化を選択できます。

  8. RDB 永続化を有効にするには、 [RDB] を選択し、設定を構成します。

    設定 提案された値 説明
    認証方法 ドロップダウンで認証方法を選択します。 選択肢は [マネージド ID] または [ストレージ キー] です。 好みの認証方法を選択します。 マネージド ID を使用すると、キャッシュが配置されているものとは異なるサブスクリプションのストレージ アカウントを使用できます。
    サブスクリプション ドロップダウンでサブスクリプションを選択します。 認証方法としてマネージド ID を使用している場合は、異なるサブスクリプションのストレージ アカウントを選択できます。
    バックアップ頻度 ドロップダウンからバックアップ間隔を選択します。 選択肢は、15 分、30 分、60 分、6 時間、12 時間、24 時間です。 前のバックアップ操作が正常に完了すると、この間隔のカウントダウンが開始されます。 この期間が経過すると、新しいバックアップが開始されます。
    ストレージ アカウント ドロップダウンで、お使いのストレージ アカウントを選択します。 キャッシュと同じリージョンおよびサブスクリプション内にあるストレージ アカウントを選択してください。 スループットが高い Premium Storage アカウントの使用をお勧めします。 また、ストレージ コストの増加につながるため、ストレージ アカウントでの論理的な削除機能を無効化することを強くお薦めします。 詳細については、「価格と課金」を参照してください。
    ストレージ キー ドロップダウンで、使用する [主キー] または [セカンダリ キー] を選択します。 永続化アカウントのストレージ キーを再生成した場合、 [ストレージ キー] ドロップダウンからキーを再構成する必要があります。

    バックアップ間隔が経過すると、最初のバックアップが開始されます。

    Note

    RDB ファイルがストレージにバックアップされると、ページ BLOB の形式で格納されます。 HNS が有効になっているストレージ アカウントを使用している場合、HNS が有効になっているストレージ アカウント (ADLS Gen2) ではページ BLOB はサポートされていないため、永続化は失敗する傾向があります。

  9. AOF の永続化を有効にするには、 [AOF] を選択し、設定を構成します。

    設定 提案された値 説明
    認証方法 ドロップダウンで認証方法を選択します。 選択肢は [マネージド ID] または [ストレージ キー] です。 好みの認証方法を選択します。 マネージド ID を使用すると、キャッシュが配置されているものとは異なるサブスクリプションのストレージ アカウントを使用できます。
    サブスクリプション ドロップダウンでサブスクリプションを選択します。 認証方法としてマネージド ID を使用している場合は、異なるサブスクリプションのストレージ アカウントを選択できます。
    最初のストレージ アカウント ドロップダウンで、お使いのストレージ アカウントを選択します。 キャッシュと同じリージョンおよびサブスクリプション内にあるストレージ アカウントを選択してください。 スループットが高い Premium Storage アカウントの使用をお勧めします。 また、ストレージ コストの増加につながるため、ストレージ アカウントでの論理的な削除機能を無効化することを強くお薦めします。 詳細については、「価格と課金」を参照してください。
    最初のストレージ キー ドロップダウンで、使用する [主キー] または [セカンダリ キー] を選択します。 永続化アカウントのストレージ キーを再生成した場合、 [ストレージ キー] ドロップダウンからキーを再構成する必要があります。
    2 つ目のストレージ アカウント (省略可能) ドロップダウンで、お使いの 2 つ目のストレージ アカウントを選択します。 必要に応じて、別のストレージ アカウントを構成できます。 2 つ目のストレージ アカウントが構成されていると、レプリカ キャッシュへの書き込みはこの 2 つ目のストレージ アカウントに書き込まれます。
    2 つ目のストレージ キー (省略可能) ドロップダウンで、使用する [主キー] または [セカンダリ キー] を選択します。 永続化アカウントのストレージ キーを再生成した場合、 [ストレージ キー] ドロップダウンからキーを再構成する必要があります。

    AOF 永続化が有効になっていると、キャッシュへの書き込み操作は指定したストレージ アカウント (2 つ目のストレージ アカウントを構成している場合は 2 つのストレージ アカウント) に保存されます。 プライマリとレプリカの両方のキャッシュが削除されるような致命的なエラーが発生した場合は、保存されている AOF ログを使用してキャッシュが再構築されます。

  10. ページの下部にある [次へ: タグ] タブを選択するか、ページの下部にある [次へ: タグ] ボタンを選択します。

  11. 必要に応じて、 [タグ] タブで、リソースを分類する場合は名前と値を入力します。

  12. [Review + create](レビュー + 作成) を選択します。 [確認および作成] タブが表示され、Azure によって構成が検証されます。

  13. 緑色の検証に成功のメッセージが表示された後、 [作成] を選択します。

キャッシュが作成されるまで、しばらく時間がかかります。 Azure Cache for Redis の [概要] ページで進行状況を監視できます。 [状態] に "実行中" と表示されている場合は、キャッシュを使用する準備ができています。

PowerShell と Azure CLI を使用してデータ永続化を設定する方法

New-AzRedisCache コマンドを使用すると、データ永続化を使用して新しい Premium レベル キャッシュを作成できます。 RDB 永続化と AOF 永続化の例を参照してください

既存のキャッシュは、Set-AzRedisCache コマンドを使用して更新できます。 既存のキャッシュに永続化を追加するの例を参照してください。

az redis create コマンドを使用すると、データ永続化を使用して新しい Premium レベル キャッシュを作成できます。 次に例を示します。

az redis create --location westus2 --name MyRedisCache --resource-group MyResourceGroup --sku Premium --vm-size p1 --redis-configuration @"config_rdb.json"

既存のキャッシュは、 az redis update コマンドを使用して更新できます。 次に例を示します。

az redis update --name MyRedisCache --resource-group MyResourceGroup --set "redisConfiguration.rdb-storage-connection-string"="BlobEndpoint=https//..." "redisConfiguration.rdb-backup-enabled"="true" "redisConfiguration.rdb-backup-frequency"="15" "redisConfiguration.rdb-backup-max-snapshot-count"="1"

データ暗号化の管理

Redis 永続化では保存データが作成されるため、このデータの暗号化は多くのユーザーにとって重要な問題です。 暗号化オプションは、使用されている Azure Cache for Redis のレベルによって異なります。

Premium レベルでは、永続化が開始されると、データがキャッシュ インスタンスから Azure Storage に直接ストリーミングされます。 Azure Storage では、Microsoft マネージド キー、カスタマー マネージド キー、カスタマー指定キーなど、さまざまな暗号化方法を使用できます。 暗号化方法の詳細については、保存データの Azure Storage 暗号化 をご覧ください。

Enterprise および Enterprise Flash レベルでは、データはキャッシュ インスタンスにマウントされたマネージド ディスクに保存されます。 既定では、永続化データを保持しているディスクと OS ディスクは、Microsoft マネージド キーを使用して暗号化されます。 カスタマー マネージド キー (CMK) を使用して、データ暗号化を制御することもできます。 手順については、「Enterprise レベルのキャッシュでの暗号化」を参照してください。

永続化の FAQ

次の一覧は、Azure Cache for Redis の永続化に関するよく寄せられる質問への回答です。

RDB 永続化

AOF 永続化

以前に作成したキャッシュで永続化を有効にできますか

はい、永続化はキャッシュの作成時と、既存の Premium、 Enterprise、または Enterprise Flash キャッシュの両方に構成できます。

AOF 永続化と RDB 永続化を同時に有効にすることはできますか

いいえ、RDB または AOF を有効にすることはできますが、両方を同時に有効にすることはできません。

geo レプリケーションではどのように永続化が行われるのですか。

データの永続化を有効にした場合、キャッシュでは geo レプリケーションを有効にできません。

どちらの永続化モデルを選択すべきですか

AOF 永続化では、すべての書き込みがログに保存されます。これはスループットに大きな影響を与えます。 AOF と比較して RDB の永続化では、構成されたバックアップ間隔に基づいてバックアップを保存し、パフォーマンスへの影響を最小限に抑えます。 主な目的がデータ損失の最小化で、キャッシュでのスループットの低下に対処できるという場合は、AOF 永続化を選択してください。 キャッシュでのスループットを最適に維持したいものの、データ復旧メカニズムも必要という場合は、RDB 永続化を選択してください。

  • RDB 永続化の長所と短所について、詳細をご確認ください。
  • AOF 永続化の長所と短所について、詳細をご確認ください。

AOF 永続化を使用しているときのパフォーマンスの詳細については、「AOF 永続化はキャッシュのスループット、待ち時間、またはパフォーマンスに影響しますか」を参照してください。

AOF 永続化はキャッシュのスループット、待ち時間、またはパフォーマンスに影響しますか?

AOF 永続化はスループットに影響します。 AOF はプライマリ プロセスとレプリカ プロセスの両方で実行されるため、AOF 永続化のない同一のキャッシュよりも、AOF 永続化を持つキャッシュの CPU とサーバーの負荷が高くなります。 AOF は、各書き込みと削除が数秒の遅延のみで保持されるため、メモリ内のデータとの最適な整合性を提供します。 トレードオフは、AOF の方がコンピューティング集中型であるということです。

CPU とサーバーの負荷の両方が 90% 未満である限り、スループットは低下しますが、それ以外の場合は、キャッシュは正常に動作します。 CPU とサーバーの負荷が 90% を超えると、スループットが大幅に低下し、キャッシュによって処理されるすべてのコマンドの待機時間が長くなる可能性があります。 待ち時間の増大は、AOF 永続化がプライマリ プロセスとレプリカ プロセスの両方で実行され、使用中のノードの負荷が増加し、永続化がデータのクリティカル パスに配置されるためです。

別のサイズにスケーリングしていて、スケーリング操作の前に作成したバックアップを復元したらどうなりますか

RDB 永続化の場合も AOF 永続化の場合も、以下のように処理されます。

  • より大きなサイズにスケーリングした場合、影響はありません。
  • 小さいサイズにスケーリングした場合、新しいサイズのデータベースの制限より大きなカスタムのデータベース設定が存在すると、そのデータベースのデータは復元されません。 詳細については、「スケーリング中に影響を受けるカスタム データベース」を参照してください
  • 小さいサイズにスケーリングしていて、最新のバックアップからのデータをすべて保持するにはサイズが小さいためスペースが足りない場合、キーは復元プロセス中に削除されます。 通常は allkeys-lru 削除ポリシーを使用して、キーが削除されます。

2 つの異なるキャッシュ間で永続化するために同じストレージ アカウントを使用することはできますか。

いいえ、異なるキャッシュには異なるストレージ アカウントを使用する必要があります。 永続化を設定するには、各キャッシュに独自のストレージ アカウントが必要です。

重要

永続化とキャッシュに対する定期的なエクスポート操作の実行には、個別のストレージ アカウントを使用してください。

データ永続化で使用されているストレージに対して課金されますか。

  • Premium キャッシュの場合、使用されているストレージ アカウントの価格モデルに従って、使用されているストレージに対して課金されています。
  • Enterprise および Enterprise Flash キャッシュの場合、マネージド ディスク ストレージには課金されません。 価格に含まれています。

RDB および AOF 永続化の BLOB への書き込みはどのくらいの頻度で行われますか。また、論理的な削除を有効にする必要はありますか。

Premium レベルで Azure Cache for Redis のデータ永続化を使用する場合は、ストレージ アカウントで論理的な削除を有効にしないことをお勧めします。 RDB および AOF 永続化では、1 時間ごと、数分ごと、または 1 秒ごとに BLOB に書き込むことができます。 また、ストレージ アカウントで論理的な削除を有効にすると、Azure Cache for Redis では、古いバックアップ データを削除することでストレージ コストを最小限に抑えることができなくなります。

論理的な削除を実行すると、毎秒の書き込み操作を行うキャッシュの通常のデータ サイズでは、すぐにコストが高くなります。 論理的な削除のコストの詳細については、「価格と課金」を参照してください。

キャッシュの作成後に RDB バックアップ頻度を変更できますか

はい。Azure portal、CLI、または PowerShell を使用して、RDB 永続化のバックアップ頻度を変更できます。

RDB バックアップ頻度を 60 分に設定しているときに、バックアップの間隔が 60 分より長くなるのはなぜですか

RDB 永続化のバックアップ頻度の間隔は、その前のバックアップ プロセスが正常に完了するまでは開始しません。 バックアップ間隔を 60 分に設定し、バックアップ プロセスが完了するのに 15 分かかる場合、次のバックアップは、前回のバックアップの開始時刻から 75 分経過するまで開始しません。

新しいバックアップが作成されると、古い RDB バックアップはどうなりますか

最新のものを除くすべての RDB 永続化のバックアップは自動的に削除されます。 この削除はすぐに行われないことがありますが、古いバックアップは無期限には保持されません。 永続化のために Premium レベルを使用していて、ストレージ アカウントで論理的な削除が有効になっている場合、論理的な削除の設定が適用され、既存のバックアップは引き続き論理的な削除状態になります。

どのような場合に 2 つ目のストレージ アカウントを使用すべきですか

AOF 永続化用の 2 つ目のストレージ アカウントは、キャッシュに対するセット操作の数が予想より多いと思われる場合に使用してください。 2 つ目のストレージ アカウントを設定することにより、キャッシュがストレージの帯域幅制限に達することを防止できます。 このオプションは、Premium レベルのキャッシュにのみ使用できます。

2 つ目のストレージ アカウントを削除するには、どうすればよいですか

AOF 永続化の 2 つ目のストレージ アカウントは、その 2 つ目のストレージ アカウントを最初のストレージ アカウントと同じように設定にすることで削除できます。 既存のキャッシュでは、[データ永続化] には、ご利用のキャッシュの [リソース メニュー] からアクセスします。 AOF の永続化を無効にするには、 [無効] を選択します。

再書き込みとは何ですか。キャッシュにどのように影響しますか

AOF ファイルが十分な大きさになると、キャッシュに対する再書き込みが自動的にキューに登録されます。 再書き込みにより、現在のデータ セットを作成するために必要な最小の操作セットで AOF ファイルのサイズ変更が行われます。 再書き込み中はパフォーマンス制限に早く達するということを想定しておいてください (特に大型のデータセットを処理する場合)。 再書き込みの発生頻度は、AOF ファイルが大きくなるにつれて低下しますが、発生時にはかなりの時間を要します。

AOF が有効になっているキャッシュをスケーリングする場合に、どのようなことを想定すべきですか

スケーリング時の AOF ファイルが大きい場合は、スケーリングの完了後にファイルが再度読み込まれるため、スケール操作に予想よりも長い時間がかかることを想定しておいてください。

スケーリングの詳細については、「別のサイズにスケーリングしていて、スケーリング操作の前に作成したバックアップを復元したらどうなりますか」を参照してください。

AOF データはストレージ内でどのように整理されますか

Premium レベルを使用する場合、AOF ファイルに保存されたデータは、シャードごとに複数のページ BLOB に分割されます。 既定では、BLOB の半分はプライマリ ストレージ アカウントに保存され、もう半分はセカンダリ ストレージ アカウントに保存されます。 複数のページ BLOB と 2 つの異なるストレージ アカウントにデータを分割することで、パフォーマンスが向上します。

キャッシュへの書き込みのピーク レートがそれほど高くない場合は、この追加のパフォーマンスは必要ない可能性があります。 その場合は、セカンダリ ストレージ アカウントの構成を削除できます。 すべての AOF ファイルは、代わりに単一のプライマリ ストレージ アカウントに保存されます。 次の表は、各価格レベルで使用されるページ BLOB の合計数を示しています。

Premium レベル BLOB
P1 シャードあたり 8
P2 シャードあたり 16
P3 シャードあたり 32
P4 シャードあたり 40

クラスタリングが有効になっている場合は、前の表に示されているように、キャッシュ内の各シャードにそれぞれのページ BLOB のセットが含まれます。 たとえば、3 つのシャードがある P2 キャッシュでは、AOF ファイルが 48 個のページ BLOB (シャードあたり 16 BLOB で 3 シャード) に振り分けられています。

再書き込み後、ストレージ内には 2 セットの AOF ファイルが存在します。 再書き込みはバックグラウンドで実行され、最初のファイルのセットに追加されます。 再書き込み時にキャッシュに送信されるセット操作は、2番目のセットに追加されます。 障害が発生した場合、バックアップは再書き込み中に一時的に保存されます。 再書き込みが完了すると、バックアップは即座に削除されます。 ストレージ アカウントで論理的な削除が有効になっている場合、論理的な削除設定が適用され、既存のバックアップは引き続き論理的な削除状態になります。

ストレージ アカウントにファイアウォール例外が発生すると永続化に影響しますか?

マネージド ID を使用すると、 信頼できるサービスのリストにキャッシュ インスタンスが追加され、ファイアウォールの例外の実行が容易になります。マネージド ID を使用せず、代わりにキーを使用してストレージ アカウントに対する承認を行っている場合、ストレージ アカウントにファイアウォール例外が発生すると、永続化プロセスが中断する傾向があります。 これは、Premium レベルの永続化にのみ適用されます。

複数のレプリカがある場合に AOF 永続化を有効化できますか?

Premium レベルでは、Append-only File (AOF) の永続化は複数のレプリカでは利用できません。 Enterprise および Enterprise Flash レベルでは、レプリカ アーキテクチャはより複雑になりますが、ゾーン冗長デプロイで Enterprise キャッシュを使用する場合は AOF 永続化がサポートされます。

ストレージ アカウントで論理的な削除が有効になっているかどうかを確認するにはどうしたらよいですか?

キャッシュで永続化のために使用しているストレージ アカウントを選択します。 [リソース] メニューから [データ保護] を選択します。 作業ペインで、"BLOB の論理的な削除を有効にする" の状態を確認します。 Azure ストレージ アカウントでの論理的な削除の詳細については、「BLOB の 論理的な削除を有効にする」を参照してください。

次のステップ

Azure Cache for Redis の機能について