Azure Cache for Redis を管理する方法

  • [アーティクル]

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

注意

Azure を操作するには、Azure Az PowerShell モジュールを使用することをお勧めします。 作業を開始するには、Azure PowerShell のインストールに関する記事を参照してください。 Az PowerShell モジュールに移行する方法については、「AzureRM から Az への Azure PowerShell の移行」を参照してください。

再起動します

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

重要

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

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

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

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

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

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

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

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

  • プライマリ - プライマリ ノードが再起動されると、Azure Cache for Redis からレプリカ ノードへのフェールオーバーが行われ、そのノードがプライマリに昇格します。 このフェールオーバー中、キャッシュに接続できない短いインターバルが発生する可能性があります。
  • レプリカ - レプリカ ノードが再起動されても、通常は、キャッシュ クライアントに影響を与えることはありません。
  • プライマリとレプリカの両方 - 両方のキャッシュ ノードが再起動されると、キャッシュ内のすべてのデータが失われ、プライマリ ノードがオンラインに戻るまでキャッシュに接続できません。 データの永続化を構成した場合は、キャッシュがオンラインに戻ったときに、最新のバックアップが復元されます。 ただし、最新のバックアップの後に生じたキャッシュの書き込みはすべて失われます。
  • クラスタリングが有効になっている Premium キャッシュのノード - クラスタリングが有効になっている Premium キャッシュのノードを 1 つ以上再起動したとき、選んだノードの動作は、非クラスター化キャッシュの対応するノードを再起動する場合と同じです。

再起動に関する FAQ

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

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

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

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

重要

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

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

プライマリとレプリカのノードの両方を再起動すると、キャッシュ (または、クラスタリングが有効になっている Premium キャッシュを使用している場合はそのシャード) のすべてのデータが失われることがあります。 ただし、データが失われない可能性もあります。 データの永続化を構成した場合は、キャッシュがオンラインに戻ったときに、最新のバックアップが復元されます。 ただし、そのバックアップの作成後に発生したキャッシュ書き込みは失われます。

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

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

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

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

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

更新のスケジュール

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

Note

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次のステップ

Azure Cache for Redis の機能について