Azure Cache for Redis Cache の障害が発生した場合、ノードがダウンするとデータ損失が発生する可能性があります。 Redis 永続化 を使用すると、キャッシュ インスタンスに格納されているデータを保持できます。 ハードウェア障害が発生した場合、キャッシュ インスタンスは、オンラインに戻ったときに永続化ファイルのデータでリハイドレートします。
この記事では、Redis の永続化と、Premium および Enterprise レベルの Azure Redis Cache インスタンスでデータ永続化を構成および管理する方法について説明します。 データ永続化機能は Basic レベルまたは Standard レベルでは使用できません。Enterprise レベルと Enterprise Flash レベルではプレビュー段階です。
データを保持する機能は、すべてのキャッシュ データをメモリに格納するため、キャッシュ インスタンスの持続性を高める重要な方法です。 永続化は、Azure Redis の 高可用性とディザスター リカバリー 戦略の重要な部分である必要があります。
重要
データ永続化機能は、Redis ノードの予期しない障害に対する回復性を提供します。 データ永続化は、データ バックアップでもポイントインタイム リカバリー (PITR) 機能でもありません。 破損したデータが Redis インスタンスに書き込まれると、破損したデータも保持されます。 Redis インスタンスのバックアップを作成するには、 エクスポート 機能を使用します。
可用性のスコープ
| レベル | Basic、Standard | プレミアム | Enterprise、Enterprise Flash |
|---|---|---|---|
| 使用可能 | いいえ | はい | はい (プレビュー) |
Redis データ永続化の種類
Azure Redis には、 Redis データベース (RDB) 形式と 追加専用ファイル (AOF) 形式の 2 種類のデータ永続化が用意されています。
RDB 永続化 では、キャッシュのスナップショットがバイナリ形式で保持され、 Azure Storage アカウントに保存されます。 バックアップ頻度を構成して、スナップショットを保持する頻度を決定します。 プライマリ キャッシュとレプリカ キャッシュの両方を無効にする致命的なイベントが発生した場合、キャッシュは最新のスナップショットを使用して自動的に再構築されます。 詳細については、RDB の利点と RDB の欠点を参照してください。
AOF 永続化 は、すべての書き込み操作をログに保存し、1 秒に 1 回ログを Azure Storage アカウントに保存します。 プライマリ キャッシュとレプリカ キャッシュの両方を無効にする致命的なイベントが発生した場合、キャッシュは格納された書き込み操作を使用して自動的に再構築されます。 詳細については、「 AOF の利点 と AOF の欠点」を参照してください。
要件と制限
データ永続化機能は、予期しない Redis ノードの障害に対する回復性を提供します。 データの永続化は、データ バックアップや PITR 機能ではありません。 破損したデータが Redis インスタンスに書き込まれると、破損したデータも保持されます。 Redis インスタンスをバックアップするには、 エクスポート 機能を使用します。
Azure Cache for Redis の永続化機能は、データ損失後にデータを同じキャッシュに自動的に復元することを目的としています。 永続化されたデータ ファイルを新規または既存のキャッシュにインポートすることはできません。
キャッシュ間でデータを移動するには、 データのインポート機能とエクスポート 機能を使用します。
新しいキャッシュに追加できるデータのバックアップを生成するには、PowerShell または Azure CLI を使用してデータを定期的にエクスポートする自動スクリプトを使用できます。
パッシブ geo レプリケーションまたはアクティブ geo レプリケーションを使用するキャッシュでは、永続化はサポートされていません。
データの暗号化
Redis 永続化では保存データが作成されるため、このデータを暗号化することが重要です。 暗号化オプションは、使用する Azure Redis レベルによって異なります。
データの永続化を設定する
Azure portal、Azure Resource Manager (ARM) テンプレート、PowerShell、または Azure CLI を使用して、Premium または Enterprise レベルの Azure Redis キャッシュのデータ永続化を作成および設定できます。
[前提条件]
- Azure Redis キャッシュに永続化を作成して追加するには、Azure サブスクリプションで Premium レベルまたはエンタープライズ レベルのキャッシュを作成するための書き込みアクセスとアクセス許可が必要です。
- Premium レベルのキャッシュの場合、キャッシュ データを格納するには、キャッシュと同じリージョンに Azure Storage アカウント が必要です。 認証方法として マネージド ID を 使用する場合は、キャッシュとは異なるサブスクリプションのストレージ アカウントを使用できます。
- Azure PowerShell の手順では、 Azure PowerShell がインストールされている必要があります。または、Azure Portal の PowerShell 環境で Azure Cloud Shell を使用する必要があります。
- Azure CLI の手順では、 Azure CLI をインストールするか、Azure portal で Bash 環境で Azure Cloud Shell を使用する必要があります。
Azure portal でデータ永続化を設定する
Azure portal では、Azure Redis Premium または Enterprise レベルのキャッシュ インスタンスを作成するときにデータ永続化を設定できます。
注
キャッシュの左側のナビゲーション メニューの [設定] の下にある [データ永続化] に移動して、以前に作成したキャッシュに永続化を追加することもできます。
Azure portal で Premium キャッシュを作成するには、「クイック スタート: オープンソースの Redis キャッシュを作成する」の手順に従い、[基本] タブの [キャッシュ SKU] に Premium を選択します。
[詳細設定] タブに入力したら、[データの永続化] でバックアップ ファイルの RDB または AOF 永続化のいずれかを選択し、関連する設定を構成します。
RDB の場合は、次の設定を構成します。
設定 価値 説明 認証方法 マネージド ID またはストレージ キーの選択 マネージド ID を使用すると、キャッシュとは異なるサブスクリプションのストレージ アカウントを使用できます。 サブスクリプション マネージド ID を含むサブスクリプションを選択します。 この項目は、 マネージド ID 認証を選択した場合にのみ表示されます。 バックアップ頻度 バックアップ間隔として、15 分、30 分、60 分、6 時間、12 時間、または 24 時間を選択します。 前のバックアップ操作が正常に完了すると、この間隔のカウントダウンが開始されます。 間隔が経過すると、新しいバックアップが開始されます。 ストレージ アカウント 使うストレージ アカウントを選びます。 ストレージ アカウントは、キャッシュと同じリージョンに存在する必要があります。 Premium ストレージ アカウントの方がスループットが高いため、お勧めします。 ストレージ キー 使用する 主キー または セカンダリ キー を選択します。 この項目は、 ストレージ キー 認証を選択した場合にのみ表示されます。 永続化ストレージ アカウントのストレージ キーを再生成する場合は、[ ストレージ キー] ドロップダウンからキーを再構成する必要があります。 AOF の場合は、次の設定を構成します。
設定 価値 説明 認証方法 マネージド ID またはストレージ キーの選択 マネージド ID を使用すると、キャッシュとは異なるサブスクリプションのストレージ アカウントを使用できます。 サブスクリプション マネージド ID を含むサブスクリプションを選択します。 この項目は、 マネージド ID 認証を選択した場合にのみ表示されます。 最初のストレージ アカウント 使うストレージ アカウントを選びます。 ストレージ アカウントは、キャッシュと同じリージョンに存在する必要があります。 Premium ストレージ アカウントの方がスループットが高いため、お勧めします。 最初のストレージ キー 使用する 主キー または セカンダリ キー を選択します。 この項目は、 ストレージ キー 認証を選択した場合にのみ表示されます。 ストレージ キーが再生成された場合は、[ストレージ キー] ドロップダウン リストから キー を再構成する必要があります。 2 つ目のストレージ アカウント 必要に応じて、セカンダリ ストレージ アカウントを選択します。 セカンダリ ストレージ アカウントを構成した場合、レプリカ キャッシュへの書き込みはこの 2 つ目のストレージ アカウントに保持されます。 2 つ目のストレージ キー 使用する 主キー または セカンダリ キー を選択します。 この項目は、 ストレージ キー 認証を選択した場合にのみ表示されます。 ストレージ キーが再生成された場合は、キーを再構成する必要があります。
「クイック スタート: オープンソースの Redis キャッシュを作成する」の残りの手順に従って、すべてのタブを完了し、キャッシュの作成を完了します。
RDB 永続化では、バックアップ頻度の間隔が経過すると、最初のバックアップが開始されます。
AOF永続化を用いることで、キャッシュへの書き込み操作は指定されたストレージ アカウントまたはアカウントに保存されます。 プライマリ キャッシュとレプリカ キャッシュの両方を停止する致命的なエラーが発生した場合は、保存された AOF ログを使用してキャッシュを再構築します。
![[Enterprise レベルの詳細] タブと [データの永続化] が赤いボックスで強調表示されているスクリーンショット。](media/cache-how-to-premium-persistence/cache-advanced-persistence.png)
Azure PowerShell を使用してデータ永続化を設定する
Azure PowerShell を使用して、Azure Redis Premium または Enterprise レベルのキャッシュを作成するときにデータ永続化を設定したり、以前に作成したキャッシュに永続化を追加したりできます。
Azure CLI を使用してデータ永続化を設定する
Azure CLI を使用して、Azure Redis Premium または Enterprise レベルのキャッシュを作成するときにデータ永続化を設定したり、以前に作成したキャッシュに永続化を追加したりできます。
永続化の FAQ
このセクションでは、Azure Redis Cache の永続化に関してよく寄せられる質問に対する回答について説明します。
- 既存のキャッシュで永続化を有効にできますか?
- AOF と RDB の両方の永続化を有効にできますか?
- 永続化はジオレプリケーションで機能しますか?
- どちらの永続化モデルを選択すべきですか
- スケーリング操作が復元される前とは異なるサイズにスケーリングし、バックアップを行うとどうなりますか?
- 2 つの異なるキャッシュ間で永続化するために同じストレージ アカウントを使用することはできますか。
- ストレージ データ永続化の使用に対して課金されますか?
- RDB と AOF 永続化がストレージに書き込む頻度はどのくらいですか? ソフト削除を有効にすべきですか?
- ストレージ アカウントのファイアウォール例外は永続化に影響しますか?
- ストレージ アカウントで論理的な削除が有効になっているかどうかを確認するにはどうしたらよいですか?
- キャッシュが配置されているサブスクリプションとは異なるサブスクリプションでストレージ アカウントを使用できますか?
RDB 永続化
- キャッシュの作成後に RDB バックアップの頻度を変更できますか?
- RDB バックアップの頻度が 60 分の場合、バックアップの間隔が 60 分を超えるのはなぜですか。
- 新しいバックアップが作成されると、古い RDB バックアップはどうなりますか
AOF 永続化
- どのような場合に 2 つ目のストレージ アカウントを使用すべきですか
- AOF 永続化はキャッシュのスループット、待機時間、またはパフォーマンスに影響しますか?
- 2 つ目のストレージ アカウントを削除するには、どうすればよいですか
- 書き換えとは何ですか。また、キャッシュにどのような影響がありますか?
- AOF が有効になっているキャッシュをスケーリングする場合に、どのようなことを想定すべきですか
- AOF データはストレージ内でどのように整理されますか
- 複数のレプリカがある場合に AOF 永続化を有効化できますか?
以前に作成したキャッシュで永続化を有効にできますか
はい。キャッシュの作成時、および既存の Premium、Enterprise、または Enterprise Flash キャッシュで永続化を構成できます。
AOF 永続化と RDB 永続化を同時に有効にすることはできますか
いいえ。RDB または AOF を有効にすることはできますが、一度に両方を有効にすることはできません。
geo レプリケーションではどのように永続化が行われるのですか。
geo レプリケーションが有効になっている場合、データ永続化は機能しません。
どちらの永続化モデルを選択すべきですか
AOF 永続化は 1 秒に 1 回ログに書き込みますが、RDB 永続化では、構成されたバックアップ間隔に基づいてバックアップが保存されます。 RDB 永続化は、AOF 永続化よりもスループットとパフォーマンスに対する影響が少なくなります。
主な目標がデータ損失を最小限に抑え、キャッシュのスループットを低く処理できる場合は、AOF 永続化を選択します。 キャッシュで最適なスループットを維持するが、データ復旧のメカニズムが必要な場合は、RDB 永続化を選択します。
詳細については、 RDB の利点、 RDB の欠点、 AOF の利点、 および AOF の欠点を参照してください。
AOF 永続化はキャッシュのスループット、待ち時間、またはパフォーマンスに影響しますか?
AOF 永続化はスループットに影響します。 AOF はプライマリ プロセスとレプリカ プロセスの両方で実行されるため、AOF 永続化のない同一のキャッシュよりも、AOF 永続化を使用するキャッシュの CPU とサーバーの負荷が高くなります。 AOF は、各書き込みと削除が数秒の遅延のみで保持されるため、メモリ内のデータとの最適な整合性を提供します。 トレードオフは、AOF の方がコンピューティング負荷が高いということです。
CPU とサーバーの負荷の両方が 90%未満である限り、スループットにはペナルティがありますが、キャッシュは正常に動作します。 CPU とサーバーの負荷が 90% を超えると、スループットが低下し、キャッシュによって処理されるすべてのコマンドの待機時間が長くなる可能性があります。 待ち時間の増大は、AOF 永続化がプライマリ プロセスとレプリカ プロセスの両方で実行され、使用中のノードの負荷が増加し、永続化がデータのクリティカル パスに配置されるためです。
別のサイズにスケーリングし、スケーリング操作の前に作成されたバックアップが復元された場合はどうなりますか?
- より大きなサイズにスケーリングした場合、影響はありません。
- サイズを小さくし、新しいサイズのデータベースの制限を超えるカスタム データベース設定がある場合、それらのデータベース内のデータは復元されません。 詳細については、「スケーリング中に影響を受けるカスタム データベース」を参照してください
- サイズを小さくし、最後のバックアップのすべてのデータを保持するのに小さいサイズの十分なスペースがない場合、復元プロセス中にキーが削除されます。 通常は allkeys-lru 削除ポリシーを使用して、キーが削除されます。
2 つの異なるキャッシュ間で永続化するために同じストレージ アカウントを使用することはできますか。
いいえ。別のストレージ アカウントを使用する必要があります。 永続化を設定するには、各キャッシュに独自のストレージ アカウントが必要です。
重要
また、永続化とキャッシュに対する定期的なエクスポート操作の実行には、個別のストレージ アカウントを使用します。
データ永続化で使用されているストレージに対して課金されますか?
- Premium キャッシュの場合、ストレージ アカウントの価格モデルに従って使用されるストレージに対して課金されます。
- Enterprise および Enterprise Flash キャッシュの場合、マネージド ディスク ストレージは価格に含まれており、追加料金は発生しません。
RDB および AOF 永続化の BLOB への書き込みはどのくらいの頻度で行われますか。また、論理的な削除を有効にする必要はありますか。
RDB および AOF 永続化は、1 時間ごと、数分ごと、または 1 秒おきに、ストレージ BLOB に書き込むことができます。 論理的な削除を実行すると、毎秒の書き込み操作を行うキャッシュの通常のデータ サイズでは、すぐにコストが高くなります。 ストレージ アカウントで論理的な削除を有効にすると、Azure Redis は古いバックアップ データを削除することでストレージ コストを最小限に抑えることができないことも意味します。
Azure Redis Premium レベルのデータ永続化に使用するストレージ アカウントで論理的な削除を有効にしないようにすることをお勧めします。 論理的な削除のコストの詳細については、「価格と課金」を参照してください。
キャッシュの作成後に RDB バックアップ頻度を変更できますか
はい。Azure portal、Azure CLI、または Azure PowerShell を使用して、RDB 永続化のバックアップ頻度を変更できます。
RDB バックアップ頻度を 60 分に設定しているときに、バックアップの間隔が 60 分より長くなるのはなぜですか
RDB 永続化のバックアップ頻度の間隔は、その前のバックアップ プロセスが正常に完了するまでは開始しません。 バックアップの頻度が 60 分で、バックアップ プロセスが完了するまでに 15 分かかる場合、次のバックアップは前回のバックアップの開始時刻から 75 分後まで開始されません。
新しいバックアップが作成されると、古い RDB バックアップはどうなりますか
最新のものを除くすべての RDB 永続化のバックアップは自動的に削除されます。 この削除はすぐに行われないことがありますが、古いバックアップは無期限には保持されません。 永続化に Premium レベルを使用していて、ストレージ アカウントで論理的な削除が有効になっている場合、既存のバックアップは引き続き論理的な削除状態になります。
どのような場合に 2 つ目のストレージ アカウントを使用すべきですか
キャッシュへの通常よりも高い SET 操作が予想される場合は、AOF 永続化に 2 つ目のストレージ アカウントを使用します。 セカンダリ ストレージ アカウントを使用すると、キャッシュがストレージ帯域幅の制限に達しないようにするのに役立ちます。 このオプションは、Premium レベルのキャッシュでのみ使用できます。
2 つ目のストレージ アカウントを削除するには、どうすればよいですか
AOF 永続化の 2 つ目のストレージ アカウントは、その 2 つ目のストレージ アカウントを最初のストレージ アカウントと同じように設定にすることで削除できます。 既存のキャッシュの設定を変更するには、キャッシュ ページの左側のナビゲーション メニューの [設定] で [データの永続化] を選択します。 永続化を完全に無効にするには、[データ永続化] ページで [無効] を選択します。
再書き込みとは何ですか。キャッシュにどのように影響しますか
AOF ファイルが十分な大きさになると、書き換えはキャッシュに自動的にキューに入れられます。 再書き込みにより、現在のデータ セットを作成するために必要な最小の操作セットで AOF ファイルのサイズ変更が行われます。
再書き込み中はパフォーマンス制限に早く達するということを想定しておいてください (特に大型のデータセットを処理する場合)。 AOF ファイルが大きくなると書き換えの頻度は低くなりますが、書き換えが発生するまでにかなりの時間がかかります。
AOF が有効になっているキャッシュをスケーリングする場合に、どのようなことを想定すべきですか
スケーリング時に AOF ファイルが大きい場合は、スケーリングの完了後にファイルが再読み込みされるため、通常よりもスケール操作に時間がかかることが予想されます。 また、別のサイズにスケールした場合、スケーリング操作の前に作成されたバックアップが復元されるとどうなりますか?
AOF データはストレージ内でどのように整理されますか
Premium レベルを使用する場合、AOF ファイルに保存されたデータは、シャードごとに複数のページ BLOB に分割されます。 既定では、BLOB の半分はプライマリ ストレージ アカウントに保存され、もう半分はセカンダリ ストレージ アカウントに保存されます。 複数のページ BLOB と 2 つの異なるストレージ アカウントにデータを分割すると、パフォーマンスが向上します。
キャッシュへの書き込みのピークレートが高くない場合は、この追加のパフォーマンスは必要ない可能性があります。 その場合、セカンダリ ストレージ アカウントの構成を削除し、すべての AOF ファイルを 1 つのプライマリ ストレージ アカウントに格納できます。 次の表は、各価格レベルで使用されるページ BLOB の合計数を示しています。
| Premium レベル | BLOB |
|---|---|
| P1 | シャードあたり 8 |
| P2 | シャードあたり 16 |
| P3の | シャードあたり 32 |
| P4 | シャードあたり 40 |
クラスタリングが有効になっている場合、キャッシュ内の各シャードには、前の表に従って独自のページ BLOB のセットがあります。 たとえば、3 つのシャードがある P2 キャッシュでは、AOF ファイルが 48 個のページ BLOB (シャードあたり 16 BLOB で 3 シャード) に振り分けられています。
再書き込み後、ストレージ内には 2 セットの AOF ファイルが存在します。 再書き込みはバックグラウンドで実行され、最初のファイルのセットに追加されます。 書き換え中にキャッシュに送信される SET 操作は、2 番目のファイルセットに追加されます。
書き換え中にエラーが発生した場合、バックアップは一時的に格納されます。 書き換えが完了すると、バックアップはすぐに削除されます。 ストレージ アカウントで論理的な削除が有効になっている場合、論理的な削除設定が適用され、既存のバックアップは引き続き論理的な削除状態になります。
ストレージ アカウントにファイアウォール例外がある場合、永続化に影響しますか?
はい。 Premium レベルで永続化する場合、 ストレージ アカウントでファイアウォール設定を 使用すると、永続化機能が機能しなくなる可能性があります。
エラー メトリックを表示することで、データの永続化中にエラーが発生したかどうかを確認できます。 このメトリックは、ストレージ アカウントのファイアウォール制限またはその他の問題により、キャッシュがデータを保持できないかどうかを示します。
ファイアウォールが設定されているストレージ アカウントでデータ永続化を使用するには、 マネージド ID ベースの認証 を使用してストレージに接続します。 マネージド ID を使用すると、キャッシュ インスタンスが 信頼されたサービスの一覧に追加され、ファイアウォール例外の適用が容易になります。 マネージド ID ではなくキーを使用してストレージ アカウントに対して承認した場合、ストレージ アカウントにファイアウォール例外が発生すると、永続化プロセスが中断される傾向があります。
複数のレプリカがある場合に AOF 永続化を有効化できますか?
Premium レベルでは、複数のレプリカで AOF 永続化を使用することはできません。 Enterprise および Enterprise Flash レベルではレプリカ アーキテクチャの方が複雑ですが、ゾーン冗長デプロイでエンタープライズ キャッシュを使用する場合は AOF 永続化がサポートされます。
ストレージ アカウントで論理的な削除が有効になっているかどうかを確認するにはどうしたらよいですか?
Azure portal で、キャッシュが永続化に使用するストレージ アカウントを選択し、左側のナビゲーション メニューの [データ管理] で [データ保護] を選択します。 [ データ保護 ] ページで、BLOB の 論理的な削除を有効に するかどうかを確認します。 Azure ストレージ アカウントでの論理的な削除の詳細については、「BLOB の 論理的な削除を有効にする」を参照してください。
キャッシュが配置されているサブスクリプションとは異なるサブスクリプションでストレージ アカウントを使用できますか?
ストレージ アカウントの認証方法としてマネージド ID を使用する場合にのみ、別のサブスクリプションのストレージ アカウントを選択できます。
関連コンテンツ
Azure Cache for Redis の機能について