Azure Managed Redis でのデータ損失のトラブルシューティング (プレビュー)

[アーティクル]
11/19/2024

この記事では、Azure Managed Redis (プレビュー) で発生する可能性がある実際のデータ損失または認識されたデータ損失を診断する方法について説明します。

部分的なキーの損失
大部分または完全なキーの損失
- キーのフラッシュ
- Redis インスタンスのエラー

Note

このガイドのトラブルシューティング手順のいくつかには、Redis コマンドを実行し、さまざまなパフォーマンスメトリックを監視する手順が含まれています。詳細および手順については、「追加情報」セクションの記事を参照してください。

部分的なキーの損失

Azure Managed Redis では、キーがメモリに格納された後でランダムに削除されることはありません。しかし、有効期限ポリシー、削除のポリシー、明示的なキーの削除コマンドに応じて、キーの削除が行われます。これらのコマンドは、CLI を使用して実行できます。

Azure Managed Redis インスタンスでプライマリノードに書き込まれたキーが、レプリカですぐには使用可能にならない可能性もあります。データは、非同期および非ブロッキング方式でプライマリからレプリカにレプリケートされます。

キャッシュからキーが消失していることに気付いた場合は、次の考えられる原因を確認してください。

原因	説明
キーの有効期限	設定されているタイムアウトが原因でキーが削除されます。
キーの強制削除	メモリ不足のためにキーが削除されます。
キーの削除	明示的な削除コマンドによってキーが削除されます。
非同期レプリケーション	データレプリケーションの遅延のため、レプリカでキーが使用できません。

キーの有効期限

Azure Managed Redis では、キーにタイムアウトが割り当てられ、その期間が経過するとキーは自動的に削除されます。 Redis キーの有効期限の詳細については、EXPIRE コマンドのドキュメントを参照してください。タイムアウト値は、SET、SETEX、GETSET、およびその他の *STORE コマンドを使用して設定することもできます。

有効期限が切れたキーの数に関する統計を取得するには、INFO コマンドを使用します。 Stats セクションに、有効期限が切れたキーの総数が示されます。 Keyspace セクションには、タイムアウトが設定されているキーの数と、平均タイムアウト値に関する追加情報が提供されます。


# Stats

expired_keys:46583

# Keyspace

db0:keys=3450,expires=2,avg_ttl=91861015336

さらに、キャッシュの診断メトリックを参照して、キーが消失したタイミングと、有効期限が切れたキーの急増との間に相関関係があるかどうかを確認することもできます。 keyspace 通知や MONITOR を使用してこれらの種類の問題をデバッグする方法については、Redis キースペースの消失のデバッグに関する記事の付録を参照してください。

キーの強制削除

Azure Managed Redis には、データを格納するためのメモリ領域が必要です。必要に応じて、使用可能なメモリを解放するためにキーが消去されます。 INFO コマンドの used_memory または used_memory_rss の値が、構成されている maxmemory 設定に近づくと、Azure Managed Redis はキャッシュポリシーに基づいて、メモリからのキーの強制削除を開始します。

INFO コマンドを使用して、強制削除されたキーの数を監視できます。

# Stats

evicted_keys:13224

さらに、キャッシュの診断メトリックを参照して、キーが消失したタイミングと、強制削除されたキーの急増との間に相関関係があるかどうかを確認することもできます。キースペース通知や MONITOR を使用してこれらの種類の問題をデバッグする方法については、Redis キースペースの消失のデバッグに関する記事の付録を参照してください。

キーの削除

Redis クライアントは、DEL コマンドまたは HDEL コマンドを発行して、Azure Managed Redis から明示的にキーを削除することができます。 INFO コマンドを使用して、削除操作の回数を追跡できます。 DEL コマンドまたは HDEL コマンドが呼び出された場合は、Commandstats セクションに一覧表示されます。

# Commandstats

cmdstat_del:calls=2,usec=90,usec_per_call=45.00

cmdstat_hdel:calls=1,usec=47,usec_per_call=47.00

非同期レプリケーション

高可用性が有効になっている Azure Managed Redis インスタンスは、プライマリノードと少なくとも 1 つのレプリカで構成されています。バックグラウンドプロセスを使用して、データがプライマリからレプリカに非同期的にコピーされます。 redis.io Web サイトでは、Redis データレプリケーションの一般的な動作について説明しています。クライアントが Redis に頻繁に書き込みを行うシナリオでは、レプリケーションが瞬時に行われることが保証されないため、部分的なデータ損失が発生する可能性があります。たとえば、クライアントがキーをプライマリに書き込んだ "後"、バックグラウンドプロセスがそのキーをレプリカに送信する "前" にプライマリがダウンした場合、キーは、レプリカが新しいプライマリとして引き継いだときに消失します。

大部分または完全なキーの損失

ほとんどまたはすべてのキーがキャッシュから消失している場合は、次の考えられる原因を確認してください。

原因	説明
キーのフラッシュ	キーは手動で削除されました。
Redis インスタンスのエラー	Redis サーバーが使用できません。

キーのフラッシュ

クライアントは FLUSHDB または FLUSHALL コマンドを呼び出して、Redis インスタンスからすべてのキーを削除できます。キーがフラッシュされているかどうかを確認するには、INFO コマンドを使用します。 Commandstats セクションには、FLUSH コマンドが呼び出されたかどうかが示されます。

# Commandstats

cmdstat_flushall:calls=2,usec=112,usec_per_call=56.00

cmdstat_flushdb:calls=1,usec=110,usec_per_call=52.00

Redis インスタンスのエラー

Redis は、インメモリデータストアです。データは、Redis キャッシュをホストする物理マシンまたは仮想マシン (VM) 上に保持されます。 Azure Managed Redis キャッシュは、既定でゾーン回復性キャッシュを提供することで、データ損失に対する高い回復性を提供します。そのようなキャッシュのプライマリシャードで障害が発生すると、レプリカシャードが自動的に引き継いでデータを提供します。これらの VM は、障害用と更新用の別々のドメインに配置され、両方が同時に使用できなくなる可能性を最小限に抑えます。ただし、大規模なデータセンターの停止が発生した場合は、それらの VM が同時にダウンする可能性があります。これらのまれなケースでは、データが失われます。

これらのインフラストラクチャ障害に対するデータの保護を強化するには、Redis のデータ永続化と geo レプリケーションを使用することを検討してください。

次の方法で共有