Azure Cache for Redis とオペレーショナル エクセレンス
Azure Cache for Redis は Redis (Remote Dictionary Server) ソフトウェアを基にしたインメモリ データ ストアを提供します。 アプリケーションに対してスループットが高く待機時間の短いデータ アクセスを提供する、セキュリティで保護されたデータ キャッシュおよびメッセージング ブローカーです。
オペレーショナル エクセレンスをサポートするベスト プラクティスを次に示します。
以下のセクションでは、Azure Cache for Redis に特有の設計上の考慮事項、構成チェックリスト、推奨される構成オプションについて説明します。
設計上の考慮事項
Azure Cache for Redis のサービス レベル アグリーメント (SLA) は、Standard および Premium レベルのキャッシュのみを対象とします。 Basic レベルは対象外です。
Redis はキーと値のペアのインメモリ キャッシュであり、Basic レベルを除き、既定では高可用性 (HA) があります。 Azure Cache for Redis には次の 3 つのレベルがあります。
Basic: "運用環境のワークロードにはお勧めしません"。 Basic レベルは、次の場合に最適です。
- 単一ノード
- 複数のサイズ
- 開発
- テスト
- クリティカルでないワークロード
Standard: Microsoft が管理しているプライマリとセカンダリの 2 つのノード構成にレプリケートされたキャッシュ。高可用性の SLA が付きます。
Premium: Standard レベルのすべての機能を含むほか、次の機能が含まれます。
- Basic レベルまたは Standard レベルと比較して高速なハードウェアと高いパフォーマンス。
- キャッシュ サイズが大きい (最大
120GB)。 - データ永続化。Redis データベース ファイル (RDB) と追加専用ファイル (AOF) が含まれます。
- VNET のサポート。
- クラスタリング
- geo レプリケーション: セカンダリ キャッシュは別のリージョンに存在し、ディザスター リカバリーのためにプライマリからデータをレプリケートします。 セカンダリにフェールオーバーするには、キャッシュを手動でリンク解除する必要があり、そうするとセカンダリを書き込み用に使用できます。 Redis に書き込むアプリケーションは、セカンダリのキャッシュ接続文字列を使用して更新する必要があります。
- Availability Zones: 可用性ゾーン全体にわたってキャッシュとレプリカをデプロイします。
注意
既定では、各デプロイにはシャードあたり 1 つのレプリカがあります。 複数のレプリカを持つデプロイでは、永続化、クラスタリング、geo レプリケーションは現時点ではすべて無効になっています。 ノードはすべてのゾーンに均等に分散されます。 レプリカのカウントはゾーン
>=数以上でなければなりません。 - インポートとエクスポート。
Microsoft では、お客様がキャッシュ エンドポイントと Microsoft のインターネット ゲートウェイの間で 99.9% 以上の時間接続できることを保証します。
チェック リスト
オペレーショナル エクセレンスを念頭に Azure Cache for Redis を構成しましたか?
- 更新のスケジュールを設定する。
- キャッシュを監視しアラートを設定する。
- VNET 内にキャッシュをデプロイする。
- ソリューション内で適切なキャッシュの種類 (ローカル、ロール内、マネージド、Redis) を使用する。
- ビジネス要件に応じて、キャッシュのコピーを Azure Storage に保存するか、geo レプリケーションを使用する、データ永続化を構成する。
- Redis への接続マルチプレクサーの静的実装またはシングルトン実装を 1 つ使用し、ベスト プラクティス ガイドに従う。
- 「Azure Cache for Redis を管理する方法」を参照する。
構成に関する推奨事項
次の表に記載されている推奨事項を参照して、オペレーショナル エクセレンスを実現するために Azure Cache for Redis 構成を最適化します。
| 推奨 | Description |
|---|---|
| 更新のスケジュールを設定する。 | Redis Server の更新がキャッシュに適用される日付と時刻をスケジュールします。これには Azure の更新や VM オペレーティングシステムの更新は含まれません。 |
| キャッシュを監視しアラートを設定する。 | 例外、高い CPU 使用率、高いメモリ使用率、サーバーの負荷、および削除されたキーに対するアラートを設定して、キャッシュをスケーリングするタイミングに関する分析情報を取得します。 キャッシュをスケーリングする必要がある場合、データを移行するスケーリング イベント中に CPU 使用率が増加するため、スケーリングを行うタイミングを理解することが重要です。 |
| VNET 内にキャッシュをデプロイする。 | キャッシュに接続できるトラフィックを顧客がさらに制御できるようにします。 キャッシュ ノードとシャード (クラスター) をデプロイするのに十分なアドレス空間がサブネットに確保されている必要があります。 |
| ソリューション内で適切なキャッシュの種類 (ローカル、ロール内、マネージド、Redis) を使用する。 | データをキャッシュする場合、分散アプリケーションでは通常、次の戦略のどちらか、または両方を実装します。 - プライベート キャッシュ (アプリケーションまたはサービスのインスタンスが実行されているマシン上でデータがローカルに保持されている) を使用する。 - 共有キャッシュ (複数のプロセスやマシンがアクセス可能な共通ソースとして機能) を使用する。 いずれの場合でも、クライアント側とサーバー側でキャッシュを実行できます。 クライアント側キャッシュは、システムのユーザー インターフェイスを提供するプロセスによって実行されます。たとえば、Web ブラウザーやデスクトップ アプリケーションなどのプロセスです。 サーバー側キャッシュは、リモートで実行されるビジネス サービスを提供するプロセスによって実行されます。 |
| ビジネス要件に応じて、キャッシュのコピーを Azure Storage に保存するか、geo レプリケーションを使用する、データ永続化を構成する。 | "データ永続化": マスターとレプリカが再起動すると、データはストレージ アカウントから自動的に読み込まれます。 "geo レプリケーション": セカンダリ キャッシュはプライマリからリンク解除する必要があります。 セカンダリがプライマリになり、"書き込み" を受信できます。 |
| 「Azure Cache for Redis を管理する方法」を参照する。 | キャッシュの再起動でデータ損失が発生する状況と、アプリケーションの回復性をテストする方法について説明します。 |
ソース成果物
Premium レベルでない Redis インスタンスを識別するには、次のクエリを使用します。
Resources
| where type == 'microsoft.cache/redis'
| where properties.sku.name != 'Premium'