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 を使用してデータ永続化を設定する方法
PowerShell と Azure CLI を使用してデータ永続化を設定する方法
データ暗号化の管理
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 の永続化に関するよく寄せられる質問への回答です。
- 以前に作成したキャッシュで永続化を有効にできますか
- AOF 永続化と RDB 永続化を同時に有効にすることはできますか
- geo レプリケーションではどのように永続化が行われるのですか。
- どちらの永続化モデルを選択すべきですか
- 別のサイズにスケーリングしていて、スケーリング操作の前に作成したバックアップを復元したらどうなりますか
- 2 つの異なるキャッシュ間で永続化するために同じストレージ アカウントを使用することはできますか。
- データ永続化で使用されているストレージに対して課金されますか。
- RDB および AOF 永続化の BLOB への書き込みはどのくらいの頻度で行われますか。また、論理的な削除を有効にする必要はありますか
- ストレージ アカウントにファイアウォール例外が発生すると永続化に影響する
- ストレージ アカウントで論理的な削除が有効になっているかどうかを確認するにはどうしたらよいですか?
RDB 永続化
- キャッシュの作成後に RDB バックアップ頻度を変更できますか
- RDB バックアップ頻度を 60 分に設定しているときに、バックアップの間隔が 60 分より長くなるのはなぜですか
- 新しいバックアップが作成されると、古い RDB バックアップはどうなりますか
AOF 永続化
- どのような場合に 2 つ目のストレージ アカウントを使用すべきですか
- AOF 永続化はキャッシュのスループット、待ち時間、またはパフォーマンスに影響しますか?
- 2 つ目のストレージ アカウントを削除するには、どうすればよいですか
- 再書き込みとは何ですか。キャッシュにどのように影響しますか
- AOF が有効になっているキャッシュをスケーリングする場合に、どのようなことを想定すべきですか
- AOF データはストレージ内でどのように整理されますか
- 複数のレプリカがある場合に AOF 永続化を有効化できますか?
以前に作成したキャッシュで永続化を有効にできますか
はい、永続化はキャッシュの作成時と、既存の Premium、 Enterprise、または Enterprise Flash キャッシュの両方に構成できます。
AOF 永続化と RDB 永続化を同時に有効にすることはできますか
いいえ、RDB または AOF を有効にすることはできますが、両方を同時に有効にすることはできません。
geo レプリケーションではどのように永続化が行われるのですか。
データの永続化を有効にした場合、キャッシュでは geo レプリケーションを有効にできません。
どちらの永続化モデルを選択すべきですか
AOF 永続化では、すべての書き込みがログに保存されます。これはスループットに大きな影響を与えます。 AOF と比較して RDB の永続化では、構成されたバックアップ間隔に基づいてバックアップを保存し、パフォーマンスへの影響を最小限に抑えます。 主な目的がデータ損失の最小化で、キャッシュでのスループットの低下に対処できるという場合は、AOF 永続化を選択してください。 キャッシュでのスループットを最適に維持したいものの、データ復旧メカニズムも必要という場合は、RDB 永続化を選択してください。
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 の機能について