Premium Azure Redis Cache のデータ永続化の構成方法How to configure data persistence for a Premium Azure Redis Cache

Azure Redis Cache には、クラスタリング、永続性、仮想ネットワークのサポートといった Premium レベルの機能など、キャッシュのサイズと機能を柔軟に選択できるさまざまなキャッシュ サービスがあります。Azure Redis Cache has different cache offerings which provide flexibility in the choice of cache size and features, including Premium tier features such as clustering, persistence, and virtual network support. この記事では、Premium Azure Redis Cache インスタンスで永続化を構成する方法について説明します。This article describes how to configure persistence in a premium Azure Redis Cache instance.

Premium キャッシュのその他の機能の詳細については、「 Azure Redis Cache Premium レベルの概要」を参照してください。For information on other premium cache features, see Introduction to the Azure Redis Cache Premium tier.

データの永続化とはWhat is data persistence?

Redis 永続化を使用すると、Redis に格納されたデータを保持できます。Redis persistence allows you to persist data stored in Redis. また、スナップショットを取得したりデータをバックアップしたりして、ハードウェア障害のときに読み込むことができます。You can also take snapshots and back up the data, which you can load in case of a hardware failure. これは、Basic レベルや Standard レベルにはない大きな利点です。Basic/Standard レベルでは、すべてのデータはメモリに格納され、Cache ノードがダウンするような障害時にはデータが失われる可能性があります。This is a huge advantage over Basic or Standard tier where all the data is stored in memory and there can be potential data loss in case of a failure where Cache nodes are down.

Azure Redis Cache では、以下のモデルを使用した Redis 永続化を提供しています。Azure Redis Cache offers Redis persistence using the following models:

  • RDB 永続化 - RDB (Redis データベース) 永続化が構成されている場合、Azure Redis Cache では、Redis キャッシュのスナップショットを構成可能なバックアップ頻度に基づき Redis バイナリ形式でディスクに保持します。RDB persistence - When RDB (Redis database) persistence is configured, Azure Redis Cache persists a snapshot of the Redis cache in a Redis binary format to disk based on a configurable backup frequency. プライマリとレプリカの両方のキャッシュが無効になるような致命的なイベントが発生した場合、最新のスナップショットを使用してキャッシュが再構築されます。If a catastrophic event occurs that disables both the primary and replica cache, the cache is reconstructed using the most recent snapshot. RDB 永続化の長所短所について、詳細をご確認ください。Learn more about the advantages and disadvantages of RDB persistence.
  • AOF 永続化 - AOF (追加専用ファイル) 永続化が構成されている場合、Azure Redis Cache では、すべての書き込み操作をログに保存します。このログは最低でも 1 秒に 1 回、Azure ストレージ アカウントに保存されます。AOF persistence - When AOF (Append only file) persistence is configured, Azure Redis Cache saves every write operation to a log that is saved at least once per second into an Azure Storage account. プライマリとレプリカの両方のキャッシュが無効になるような致命的なイベントが発生した場合、保存されている書き込み操作を使用してキャッシュが再構築されます。If a catastrophic event occurs that disables both the primary and replica cache, the cache is reconstructed using the stored write operations. AOF 永続化の長所短所について、詳細をご確認ください。Learn more about the advantages and disadvantages of AOF persistence.

永続化は、キャッシュの作成中に [新規 Redis Cache] ブレードから、また既存の Premium キャッシュ用の [リソース] メニューで構成します。Persistence is configured from the New Redis Cache blade during cache creation and on the Resource menu for existing premium caches.

Premium キャッシュを作成するには、Azure Portal にサインインし、[新規] > [データベース] > [Redis Cache] の順にクリックします。To create a premium cache, sign-in to the Azure portal and click New > Databases > Redis Cache.

キャッシュの作成

注意

キャッシュは、Azure ポータルだけでなく、Resource Manager テンプレート、PowerShell、または Azure CLI を使用して作成することもできます。In addition to creating caches in the Azure portal, you can also create them using Resource Manager templates, PowerShell, or Azure CLI. Azure Redis Cache の作成について詳しくは、キャッシュの作成に関するページをご覧ください。For more information about creating an Azure Redis Cache, see Create a cache.

Premium 機能を構成するには、まず [料金レベル] ドロップダウン リストで Premium 価格レベルのいずれかを選択します。To configure premium features, first select one of the premium pricing tiers in the Pricing tier drop-down list. 各価格レベルの詳細については、[価格の詳細を表示] をクリックし、[価格レベルの選択] ブレードから価格レベルを選択します。For more information about each pricing tier, click View full pricing details and select a pricing tier from the Choose your pricing tier blade.

[料金レベルの選択]

Premium 価格レベルを選択した後、 [Redis の永続化]をクリックします。Once a premium pricing tier is selected, click Redis persistence.

[Redis の永続化]

次のセクションの手順では、新しい Premium キャッシュで Redis 永続化を構成する方法を示します。The steps in the next section describe how to configure Redis persistence on your new premium cache. Redis の永続化が構成されたら、 [作成] をクリックして、Redis の永続化で新規 Premium キャッシュを作成します。Once Redis persistence is configured, click Create to create your new premium cache with Redis persistence.

Redis 永続化の有効化Enable Redis persistence

Redis 永続化は、[Redis データ永続化] ブレードで [RDB] または [AOF] 永続化のいずれかを選択して有効にします。Redis persistence is enabled on the Redis data persistence blade by choosing either RDB or AOF persistence. 新規キャッシュでは、前のセクションで説明したように、このブレードにはキャッシュの作成プロセス中にアクセスします。For new caches, this blade is accessed during the cache creation process, as described in the previous section. 既存のキャッシュでは、[Redis データ永続化] ブレードには、キャッシュの [リソース] メニューからアクセスします。For existing caches, the Redis data persistence blade is accessed from the Resource menu for your cache.

Redis の設定

RDB 永続化の構成Configure RDB persistence

RDB 永続化を有効にするには、[RDB] をクリックします。To enable RDB persistence, click RDB. 以前から有効になっている Premium キャッシュの RDB 永続化を無効にするには、[無効] をクリックします。To disable RDB persistence on a previously enabled premium cache, click Disabled.

Redis RDB 永続化

バックアップの間隔を構成するには、ドロップダウン リストから [バックアップの頻度] を選択します。To configure the backup interval, select a Backup Frequency from the drop-down list. 選択肢は、15 分30 分60 分6 時間12 時間24 時間です。Choices include 15 Minutes, 30 minutes, 60 minutes, 6 hours, 12 hours, and 24 hours. 前のバックアップ操作が正常に完了するとこの間隔のカウントダウンが開始し、期間が経過すると新しいバックアップが開始されます。This interval starts counting down after the previous backup operation successfully completes and when it elapses a new backup is initiated.

[ストレージ アカウント] をクリックして使用するストレージ アカウントを選択し、[ストレージ キー] ボックスの一覧から使用するプライマリ キーまたはセカンダリ キーを選択します。Click Storage Account to select the storage account to use, and choose either the Primary key or Secondary key to use from the Storage Key drop-down. Cache と同じリージョンのストレージ アカウントを選択する必要があり、また、スループットが高いため Premium Storage アカウントを使用することをお勧めします。You must choose a storage account in the same region as the cache, and a Premium Storage account is recommended because premium storage has higher throughput.

重要

永続化アカウントのストレージ キーを再生成した場合、[ストレージ キー] ドロップダウンから目的のキーを再構成する必要があります。If the storage key for your persistence account is regenerated, you must reconfigure the desired key from the Storage Key drop-down.

[OK] をクリックして永続化の構成を保存します。Click OK to save the persistence configuration.

バックアップ間隔が経過すると、次のバックアップ (または新しいキャッシュの最初のバックアップ) が開始されます。The next backup (or first backup for new caches) is initiated once the backup frequency interval elapses.

AOF 永続化の構成Configure AOF persistence

AOF 永続化を有効にするには、[AOF] をクリックします。To enable AOF persistence, click AOF. 以前から有効になっている Premium キャッシュの AOF 永続化を無効にするには、[無効] をクリックします。To disable AOF persistence on a previously enabled premium cache, click Disabled.

Redis AOF 永続化

AOF 永続化を構成するには、[最初のストレージ アカウント] を指定します。To configure AOF persistence, specify a First Storage Account. キャッシュと同じリージョンのストレージ アカウントを指定する必要があり、また、スループットが高いため Premium Storage アカウントを使用することをお勧めします。This storage account must be in the same region as the cache, and a Premium Storage account is recommended because premium storage has higher throughput. 必要に応じて [2 つ目のストレージ アカウント] という追加のストレージ アカウントを構成できます。You can optionally configure an additional storage account named Second Storage Account. 2 つ目のストレージ アカウントが構成されていると、レプリカ キャッシュへの書き込みはこの 2 つ目のストレージ アカウントに書き込まれます。If a second storage account is configured, the writes to the replica cache are written to this second storage account. 構成済みのストレージ アカウントごとに、[ストレージ キー] ボックスの一覧から、使用する [プライマリ キー] または [セカンダリ キー] を選択します。For each configured storage account, choose either the Primary key or Secondary key to use from the Storage Key drop-down.

重要

永続化アカウントのストレージ キーを再生成した場合、[ストレージ キー] ドロップダウンから目的のキーを再構成する必要があります。If the storage key for your persistence account is regenerated, you must reconfigure the desired key from the Storage Key drop-down.

AOF 永続化が有効になっていると、キャッシュへの書き込み操作は指定したストレージ アカウント (2 つ目のストレージ アカウントを構成している場合は 2 つのストレージ アカウント) に保存されます。When AOF persistence is enabled, write operations to the cache are saved to the designated storage account (or accounts if you have configured a second storage account). プライマリとレプリカの両方のキャッシュが削除されるような致命的なエラーが発生した場合は、保存されている AOF ログを使用してキャッシュが再構築されます。In the event of a catastrophic failure that takes down both the primary and replica cache, the stored AOF log is used to rebuild the cache.

永続化の FAQPersistence FAQ

次の一覧は、Azure Redis Cache の永続化に関するよく寄せられる質問への回答です。The following list contains answers to commonly asked questions about Azure Redis Cache persistence.

RDB 永続化RDB persistence

AOF 永続化AOF persistence

以前に作成したキャッシュで永続化を有効にできますかCan I enable persistence on a previously created cache?

はい、Redis の永続化はキャッシュの作成時と、既存の Premium キャッシュの両方に構成できます。Yes, Redis persistence can be configured both at cache creation and on existing premium caches.

AOF 永続化と RDB 永続化を同時に有効にすることはできますかCan I enable AOF and RDB persistence at the same time?

いいえ、有効にできるのは RDB と AOF のいずれか 1 つのみで、両方を同時に有効にすることはできません。No, you can enable only RDB or AOF, but not both at the same time.

どちらの永続化モデルを選択すべきですかWhich persistence model should I choose?

AOF 永続化ではすべての書き込みがログに保存され、スループットに多少の影響があるのに対し、RDB 永続化では構成済みのバックアップ間隔に基づきバックアップが保存され、パフォーマンスへの影響は最小限に抑えられます。AOF persistence saves every write to a log, which has some impact on throughput, compared with RDB persistence which saves backups based on the configured backup interval, with minimal impact on performance. 主な目的がデータ損失の最小化で、キャッシュでのスループットの低下に対処できるという場合は、AOF 永続化を選択してください。Choose AOF persistence if your primary goal is to minimize data loss, and you can handle a decrease in throughput for your cache. キャッシュでのスループットを最適に維持したいものの、データ復旧メカニズムも必要という場合は、RDB 永続化を選択してください。Choose RDB persistence if you wish to maintain optimal throughput on your cache, but still want a mechanism for data recovery.

AOF 永続化を使用しているときのパフォーマンスの詳細については、「AOF 永続化はキャッシュのスループット、待ち時間、またはパフォーマンスに影響しますか」を参照してください。For more information on performance when using AOF persistence, see Does AOF persistence affect throughout, latency, or performance of my cache?

別のサイズにスケーリングしていて、スケーリング操作の前に作成したバックアップを復元したらどうなりますかWhat happens if I have scaled to a different size and a backup is restored that was made before the scaling operation?

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

  • 大きいサイズにスケーリングした場合、影響はありません。If you have scaled to a larger size, there is no impact.
  • 小さいサイズにスケーリングした場合、新しいサイズのデータベースの制限より大きなカスタムのデータベース設定が存在すると、そのデータベースのデータは復元されません。If you have scaled to a smaller size, and you have a custom databases setting that is greater than the databases limit for your new size, data in those databases isn't restored. 詳細については、「スケーリング中に影響を受けるカスタム データベース」を参照してくださいFor more information, see Is my custom databases setting affected during scaling?
  • 小さいサイズにスケーリングしていて、最新のバックアップからのデータをすべて保持するにはサイズが小さいためスペースが足りない場合、キーは復元プロセス中に削除されます。通常は allkeys-lru 削除ポリシーを使用します。If you have scaled to a smaller size, and there isn't enough room in the smaller size to hold all of the data from the last backup, keys will be evicted during the restore process, typically using the allkeys-lru eviction policy.

キャッシュの作成後に RDB バックアップ頻度を変更できますかCan I change the RDB backup frequency after I create the cache?

はい、[Redis データ永続化] ブレードで RDB 永続化のバックアップ頻度を変更できます。Yes, you can change the backup frequency for RDB persistence on the Redis data persistence blade. 手順については、「 Redis の永続化を構成する」をご覧ください。For instructions, see Configure Redis persistence.

RDB バックアップ頻度を 60 分に設定しているのに、バックアップの間隔が 60 分より長くなるのはなぜですかWhy if I have an RDB backup frequency of 60 minutes there is more than 60 minutes between backups?

RDB 永続化のバックアップ頻度の間隔は、その前のバックアップ プロセスが正常に完了するまでは開始しません。The RDB persistence backup frequency interval does not start until the previous backup process has completed successfully. バックアップ間隔を 60 分に設定し、バックアップ プロセスが正常に完了するのに 15 分かかる場合、次のバックアップは、前回のバックアップの開始時刻から 75 分経つまで開始しません。If the backup frequency is 60 minutes and it takes a backup process 15 minutes to successfully complete, the next backup won't start until 75 minutes after the start time of the previous backup.

新しいバックアップが作成されると、古い RDB バックアップはどうなりますかWhat happens to the old RDB backups when a new backup is made?

最新のものを除くすべての RDB 永続化のバックアップは自動的に削除されます。All RDB persistence backups except for the most recent one are automatically deleted. この削除はすぐに行われないことがありますが、古いバックアップは無期限には保持されません。This deletion may not happen immediately but older backups are not persisted indefinitely.

どのような場合に 2 つ目のストレージ アカウントを使用すべきですかWhen should I use a second storage account?

AOF 永続化用の 2 つ目のストレージ アカウントは、キャッシュに対するセット操作の数が予想より多いと感じた場合に使用してください。You should use a second storage account for AOF persistence when you believe you have higher than expected set operations on the cache. 2 つ目のストレージ アカウントを設定することにより、キャッシュがストレージの帯域幅制限に達することを防止できます。Setting up the secondary storage account helps ensure your cache doesn't reach storage bandwidth limits.

AOF 永続化はキャッシュのスループット、待ち時間、またはパフォーマンスに影響しますかDoes AOF persistence affect throughout, latency, or performance of my cache?

キャッシュによる負荷が最大負荷を下回っている (CPU およびサーバー負荷が両方とも 90% 未満である) 場合、AOF 永続化のスループットへの影響は約 15 ~ 20% となります。AOF persistence affects throughput by about 15% – 20% when the cache is below maximum load (CPU and Server Load both under 90%). キャッシュがこれらの制限内にある場合、待ち時間の問題は発生しません。There should not be latency issues when the cache is within these limits. ただし、AOF が有効になっていると、キャッシュがより早くこれらの制限に達するようになります。However, the cache will reach these limits sooner with AOF enabled.

2 つ目のストレージ アカウントを削除するには、どうすればよいですかHow can I remove the second storage account?

AOF 永続化の 2 つ目のストレージ アカウントは、その 2 つ目のストレージ アカウントを最初のストレージ アカウントと同じように設定にすることで削除できます。You can remove the AOF persistence secondary storage account by setting the second storage account to be the same as the first storage account. 手順については、「AOF 永続化の構成」を参照してください。For instructions, see Configure AOF persistence.

再書き込みとは何ですか。キャッシュにどのように影響しますかWhat is a rewrite and how does it affect my cache?

AOF ファイルが十分な大きさになると、キャッシュに対する再書き込みが自動的にキューに登録されます。When the AOF file becomes large enough, a rewrite is automatically queued on the cache. 再書き込みにより、現在のデータ セットを作成するために必要な最小の操作セットで AOF ファイルのサイズ変更が行われます。The rewrite resizes the AOF file with the minimal set of operations needed to create the current data set. 再書き込み中はパフォーマンス制限に早く達するということを想定しておいてください (特に大型のデータセットを処理する場合)。During rewrites, expect to reach performance limits sooner especially when dealing with large datasets. 再書き込みの発生頻度は、AOF ファイルが大きくなるにつれて低下しますが、発生時にはかなりの時間を要します。Rewrites occur less often as the AOF file becomes larger, but will take a significant amount of time when it happens.

AOF が有効になっているキャッシュをスケーリングする場合に、どのようなことを想定すべきですかWhat should I expect when scaling a cache with AOF enabled?

スケーリング時の AOF ファイルが非常に大きい場合は、スケーリングの完了後にファイルが再度読み込まれるため、スケール操作に予想よりも長い時間がかかることを想定しておいてください。If the AOF file at the time of scaling is significantly large, then expect the scale operation to take longer than expected since it will be reloading the file after scaling has finished.

スケーリングの詳細については、「別のサイズにスケーリングしていて、スケーリング操作の前に作成したバックアップを復元したらどうなりますか」を参照してください。For more information on scaling, see What happens if I have scaled to a different size and a backup is restored that was made before the scaling operation?

AOF データはストレージ内でどのように整理されますかHow is my AOF data organized in storage?

AOF ファイルに格納されたデータは、ストレージへのデータの保存パフォーマンスを向上させるため、ノードごとに複数のページ BLOB に分割されます。Data stored in AOF files is divided into multiple page blobs per node to increase performance of saving the data to storage. 次の表は、各価格レベルで使用されるページ BLOB の数を示しています。The following table displays how many page blobs are used for each pricing tier:

Premium レベルPremium tier BLOBBlobs
P1P1 シャードあたり 44 per shard
P2P2 シャードあたり 88 per shard
P3P3 シャードあたり 1616 per shard
P4P4 シャードあたり 2020 per shard

クラスタリングが有効になっている場合は、前の表に示されているように、キャッシュ内の各シャードにそれぞれのページ BLOB のセットが含まれます。When clustering is enabled, each shard in the cache has its own set of page blobs, as indicated in the previous table. たとえば、3 つのシャードがある P2 キャッシュでは、AOF ファイルが 24 個のページ BLOB (シャードあたり 8 BLOB で 3 シャード) に振り分けられています。For example, a P2 cache with three shards distributes its AOF file across 24 page blobs (8 blobs per shard, with 3 shards).

再書き込み後、ストレージ内には 2 セットの AOF ファイルが存在します。After a rewrite, two sets of AOF files exist in storage. 再書き込みはバックグラウンドで発生して最初のファイル セットに追加され、一方で再書き込み中にキャッシュに送信されるセット操作は 2 つ目のファイル セットに追加されます。Rewrites occur in the background and append to the first set of files, while set operations that are sent to the cache during the rewrite append to the second set. バックアップはエラーが発生した場合に備えて再書き込み中に一時的に保存されますが、再書き込みの完了後すぐに削除されます。A backup is temporarily stored during rewrites in case of failure, but is promptly deleted after a rewrite finishes.

次のステップNext steps

Premium キャッシュ機能をさらに使用する方法を学習します。Learn how to use more premium cache features.