次の方法で共有

Azure Cache for Redis を管理する方法

  • [アーティクル]

この記事では、Azure Cache for Redis インスタンスについて、再起動、更新プログラム チャネルと更新プログラムのスケジュールなどの管理タスクを実行する方法について説明します。

再起動します

左側の [再起動] では、キャッシュの 1 つ以上のノードを再起動できます。 この再起動機能により、アプリケーションにキャッシュ ノードの障害が発生した場合の回復性をテストすることができます。

重要

再起動を Enterprise レベルで使用することはまだできません。 再起動を他のすべてのレベルで使用することは可能です。

[再起動] メニュー オプションが強調表示されているスクリーンショット

再起動するノードを選び、 [再起動] を選択します。

再起動できるノードを示すスクリーンショット

クラスタリングが有効になっている Premium キャッシュがある場合は、再起動するキャッシュのシャードを選択できます。

シャードのオプションのスクリーンショット

キャッシュの 1 つ以上のノードを再起動するには、ノードを選択し、 [再起動] を選択します。 クラスタリングが有効になっている Premium キャッシュがある場合は、再起動するシャードを選び、[再起動] を選びます。 数分後、選択したノードが再起動され、さらに数分後にオンラインに戻ります。

クライアント アプリケーションへの影響は、再起動するノードによって異なります。

  • プライマリ - プライマリ ノードが再起動されると、Azure Cache for Redis からレプリカ ノードへのフェールオーバーが行われ、そのノードがプライマリに昇格します。 このフェールオーバー中に、キャッシュに接続できない短い間隔が存在する可能性があります。
  • レプリカ - レプリカ ノードが再起動されても、通常は、キャッシュ クライアントに影響を与えることはありません。
  • プライマリとレプリカの両方 - 両方のキャッシュ ノードが再起動されると、Azure Cache for Redis は両方のノードを正常に再起動しようとします。一方が正常に再起動されるまで待ってから、もう一方を再起動します。 通常、データ損失は発生しません。 ただし、予期しないメンテナンス イベントや障害により、データ損失が発生する場合もあります。 キャッシュを連続して何度も再起動すると、データ損失の確率が高くなります。
  • クラスタリングが有効になっている Premium キャッシュのノード - クラスタリングが有効になっている Premium キャッシュのノードを 1 つ以上再起動したとき、選んだノードの動作は、非クラスター化キャッシュの対応するノードを再起動する場合と同じです。

再起動に関する FAQ

アプリケーションのテストでは、どのノードを再起動する必要がありますか。

キャッシュのプライマリ ノードの障害に対するアプリケーションの回復性をテストするには、プライマリ ノードを再起動します。 レプリカ ノードの障害に対するアプリケーションの回復性をテストするには、レプリカ ノードを再起動します。

キャッシュを再起動することでクライアント接続を消去できますか。

はい。キャッシュを再起動すると、すべてのクライアント接続がクリアされます。 再起動は、ロジック エラーやクライアント アプリケーションのバグによって、すべてのクライアント接続が使い果たされているときに便利です。 価格レベルごとに、さまざまなサイズに対するさまざまなクライアント接続の制限があり、こうした制限に達すると、それ以上のクライアント接続は受け入れられなくなります。 キャッシュを再起動することで、すべてのクライアント接続がクリアされます。

重要

キャッシュを再起動してクライアント接続をクリアすると、Redis ノードがオンラインに戻ったときに、StackExchange.Redis が自動的に再接続されます。 根本的な問題が解決されない限り、クライアント接続はその後も消耗される可能性があります。

再起動すると、キャッシュのデータは失われますか。

プライマリとレプリカのノードの両方を再起動すると、キャッシュ (または、クラスタリングが有効になっている Premium キャッシュを使用している場合はそのシャード) のすべてのデータは安全であるはずです。 ただし、場合によってはデータが失われることがあります。 両方のノードを再起動する場合は注意が必要です。

ノードのいずれかを 1 つだけ再起動しても、通常、データが失われることはありませんが、失われる可能性もあります。 たとえば、プライマリ ノードが再起動されたときに、キャッシュの書き込みが実行中である場合、そのキャッシュの書き込みのデータは失われます。 また、一方のノードを再起動したときに、もう一方のノードが同じタイミングで故障したためにダウンした場合もやはりデータが失われます。

また、両方のノードを再起動してもデータがフラッシュされないことを認識する必要があります。 データをクリアする場合は、ポータル コンソールのフラッシュ手順を使用します。

PowerShell、CLI、またはその他の管理ツールを使用して、キャッシュを再起動できますか。

PowerShell での手順については、「To reboot an Azure Cache for Redis」(Azure Cache for Redis を再起動するには) をご覧ください。

Enterprise キャッシュを再起動できますか。

いいえ。 再起動を Enterprise レベルで使用することはまだできません。 再起動は、Basic、Standard、Premium レベルで使用できます。 [管理] の [リソース] メニューに表示される設定は、キャッシュのレベルによって異なります。 [再起動] は Enterprise レベルからキャッシュを使用しているときは表示されません。

データのフラッシュ

Azure Cache for Redis の Basic、Standard、または Premium レベルを使用する場合は、リソース メニューに [データのフラッシュ] が表示されます。 データのフラッシュ操作を使用すると、キャッシュにあるすべてのデータを削除またはフラッシュできます。 このフラッシュ操作は、スケーリング操作の前に使用して、キャッシュでのスケーリング操作を完了するのに必要な時間を短縮できます。 また、メモリ使用量を確認中に保持するために、開発/テスト キャッシュでフラッシュ操作を定期的に実行するように構成することもできます。

フラッシュ操作は、クラスター化されたキャッシュで実行される場合は、すべてのシャードから同時にデータをクリアします。

重要

以前は、フラッシュ 操作は geo レプリケートされた Enterprise のサービス階層のキャッシュでのみ使用されていました。 これで、Basic、Standard、Premium のサービス階層で使用できます。

キャッシュ インスタンスのリソース メニューで [データのフラッシュ] が選択されていることを示すスクリーンショット。

更新プログラム チャネルと更新プログラムのスケジュール

左側の [更新のスケジュール設定] では、更新プログラム チャネルとキャッシュ インスタンスのメンテナンス期間を選択できます。

Stable 更新プログラム チャネルを使用するすべてのキャッシュ インスタンスは、プレビュー更新プログラム チャネルを使用するキャッシュ インスタンスより数週間遅れて更新プログラムを受け取ります。 運用環境以外で重要度の低いワークロードの場合は、プレビュー更新プログラム チャネルを選択することをお勧めします。 最も重要な運用ワークロードの Stable 更新プログラム チャネルを選択します。 既定では、すべてのキャッシュは Stable 更新プログラム チャネルに既定で設定されます。

重要

キャッシュ インスタンスの更新プログラム チャネルを変更すると、キャッシュでファイルの部分置換イベントが発生し、適切な更新プログラムが適用されます。 メンテナンス期間中に更新プログラム チャネルを変更することを検討してください。

メンテナンス期間を使用すると、キャッシュをホストしている VM を更新できる曜日と時間を制御できます。 Azure Cache for Redis では、定義された時間枠の中で Redis サーバー ソフトウェアの更新を開始して完了するための最大限の努力が行われます。

重要

更新プログラム チャネルとメンテナンス期間は Redis サーバーの更新と、キャッシュをホストしている VM のオペレーティング システムの更新に適用されます。 更新プログラム チャネルとメンテナンス期間は、キャッシュ VM やその他の Azure ネットワーク コンポーネントをホストしているホストのホスト OS 更新には適用されません。 まれに、以前のモデルでキャッシュがホストされている場合、メンテナンス ウィンドウはゲスト OS の更新にも適用されません。 キャッシュの DNS 名でサフィックス cloudapp.net、chinacloudapp.cn、usgovcloudapi.net、cloudapi.de が解決される場合は、キャッシュが以前のモデル上にあるかどうかを確認できます。

現時点では、Enterprise レベルのキャッシュの更新プログラム チャネルやスケジュールされた更新を構成するするためのオプションはありません。

更新のスケジュール設定を示すスクリーンショット

メンテナンス期間を指定するには、目的の曜日をオンにし、曜日ごとにメンテナンス期間の開始時刻を指定します。 [OK] をクリックします。 メンテナンス期間は UTC であり、時間単位でのみ構成できます。

更新の既定の最小メンテナンス時間は 5 時間です。 この値は、Azure portal からは構成できませんが、PowerShell で New-AzRedisCacheScheduleEntry コマンドレットの MaintenanceWindow パラメーターを使用して構成できます。 詳しくは、「PowerShell、CLI、またはその他の管理ツールを使用して、スケジュールされている更新を管理できますか」をご覧ください。

更新のスケジュールに関する FAQ

更新スケジュール機能を使用しない場合、更新はどのタイミングで実行されますか。

メンテナンス時間を指定しない場合は、いつでも更新を実行できます。

スケジュールされたメンテナンス時間に行われるのは、どのような更新ですか。

スケジュールされたメンテナンス時間に行われるのは、Redis サーバーの更新だけです。 メンテナンス期間は、Azure の更新や、ホストのオペレーティング システムへの更新には適用されません。

PowerShell、CLI、またはその他の管理ツールを使用して、スケジュールされている更新を管理できますか。

はい、次の PowerShell コマンドレットを使用して、スケジュールされている更新を管理できます。

スケジュールされた更新機能の対象として管理されている更新を、[スケジュールされた更新] ウィンドウの外部で実行できますか。

はい。 通常、更新は、構成済みの [スケジュールされた更新] ウィンドウの外部では適用されません。 まれに発生する重要なセキュリティ更新は、セキュリティ ポリシーの一環として、パッチ適用スケジュール外で適用できます。

関連するコンテンツ

Azure Cache for Redis の機能について