Azure Cache for Redis でのデータ損失のトラブルシューティング

[アーティクル]
06/01/2023

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

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

Note

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

部分的なキーの損失

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

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

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

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

キーの有効期限

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

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

# Stats

evicted_keys:13224

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

キーの削除

Redis クライアントは、DEL コマンドまたは HDEL コマンドを発行して、Azure Cache for 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

非同期レプリケーション

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

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

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

原因	説明
キーのフラッシュ	キーは手動で削除されました。
データベースの選択が正しくない	Azure Cache for Redis が既定以外のデータベースを使用するように設定されています。
Redis インスタンスのエラー	Redis サーバーが使用できません。

キーのフラッシュ

クライアントは、FLUSHDB コマンドを呼び出して、1 つのデータベース内のすべてのキーを削除することも、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

データベースの選択が正しくない

Azure Cache for Redis では、既定では db0 データベースが使用されます。別のデータベース (たとえば、db1) に切り替えて、そこからキーを読み取ろうとした場合、Azure Cache for Redis ではそれらは検出されません。各データベースは論理的に独立したユニットであり、異なるデータセットを保持しています。 SELECT コマンドを使用して、他の使用可能なデータベースを使用し、そのそれぞれでキーを検索してください。

Redis インスタンスのエラー

Redis は、インメモリデータストアです。データは、Redis キャッシュをホストする物理マシンまたは仮想マシン上に保持されます。 Basic レベルの Azure Cache for Redis インスタンスは、1 つの仮想マシン (VM) 上でのみ実行されます。その VM がダウンすると、キャッシュに格納されているすべてのデータが失われます。

Standard レベルと Premium レベルのキャッシュでは、レプリケートされた構成で 2 つの VM を使用することにより、データ損失に対してより高い回復性が提供されます。そのようなキャッシュのプライマリノードで障害が発生すると、レプリカノードが自動的に引き継いでデータを提供します。これらの VM は、障害用と更新用の別々のドメインに配置され、両方が同時に使用できなくなる可能性を最小限に抑えます。ただし、それでも大規模なデータセンターの停止が発生した場合は、それらの VM が同時にダウンする可能性があります。これらのまれなケースでは、データが失われます。

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