Azure Cache for Redis は、 Redis (リモート ディクショナリ サーバー) ソフトウェアに基づくメモリ内データ ストアを提供します。 これはセキュリティで保護されたデータ キャッシュとメッセージング ブローカーであり、アプリケーションのデータへの高スループットと待機時間の短いアクセスを提供します。
信頼性をサポートする主な概念とベスト プラクティスは次のとおりです。
次のセクションでは、Azure Cache for Redis に固有の設計上の考慮事項、構成チェックリスト、および推奨される構成オプションについて説明します。
設計に関する考慮事項
Azure Cache for Redis サービス レベル アグリーメント (SLA) では、Standard レベルと Premium レベルのキャッシュのみが対象となります。 Basic レベルは対象外です。
Redis はキー値ペアのメモリ内キャッシュであり、Basic レベルを除き、既定では高可用性 (HA) を備えています。 Azure Cache for Redis には、次の 3 つのレベルがあります。
基本: 運用環境のワークロードには推奨されません。 Basic レベルは次の場合に最適です。
- 単一ノード
- 複数のサイズ
- 発達
- テスト
- 重要でないワークロード
Standard: 高可用性 SLA を使用して、Microsoft によって管理される 2 ノードプライマリおよびセカンダリ構成のレプリケートされたキャッシュ。
Premium: Standard レベルのすべての機能が含まれており、その他の次の機能が含まれます。
- Basic レベルまたは Standard レベルと比較して、ハードウェアとパフォーマンスが向上します。
- キャッシュサイズがより大きくなり、最大で
120GBになります。 - Redis Database File (RDB) と Append Only File (AOF) を含むデータ永続化。
- VNET のサポート。
- クラスタリング
- geo レプリケーション: セカンダリ キャッシュは別のリージョンにあり、ディザスター リカバリーのためにプライマリからデータをレプリケートします。 セカンダリにフェールオーバーするには、キャッシュのリンクを手動で解除してから、セカンダリを書き込み可能にする必要があります。 Redis に書き込むアプリケーションは、セカンダリのキャッシュ接続文字列で更新する必要があります。
- Availability Zones: 可用性ゾーン間でキャッシュとレプリカをデプロイします。
注
既定では、各デプロイにはシャードごとに 1 つのレプリカがあります。 永続化、クラスタリング、geo レプリケーションはすべて、現時点では、複数のレプリカを含むデプロイで無効になっています。 ノードはすべてのゾーンに均等に分散されます。 レプリカのカウントはゾーン
>=数以上でなければなりません。 - インポートとエクスポート。
Microsoft は、お客様がキャッシュ エンドポイントと Microsoft のインターネット ゲートウェイの間に接続できる時間の少なくとも 99.9% を保証します。
チェックリスト
回復性を念頭に置いて Azure Cache for Redis を構成しましたか?
- 更新のスケジュールを設定する。
- キャッシュを監視し、アラートを設定します。
- VNET 内にキャッシュをデプロイします。
- Redis Cache 内のパーティション分割戦略を評価します。
- ビジネス要件に応じて、キャッシュのコピーを Azure Storage に保存するか、geo レプリケーションを使用するように データ永続化 を構成します。
- Azure Redis Cache のコンテキストで再試行ポリシーを実装します。
- Redis への接続マルチプレクサーの静的実装またはシングルトン実装を 1 つ使用し、 ベスト プラクティス ガイドに従います。
- Azure Cache for Redis を管理する方法を確認します。
構成に関する推奨事項
サービスの信頼性のために Azure Cache for Redis 構成を最適化するための推奨事項の次の表を確認します。
| 勧告 | 説明 |
|---|---|
| 更新のスケジュールを設定する。 | Azure の更新プログラムや VM オペレーティング システムの更新プログラムを含まない、Redis Server の更新プログラムがキャッシュに適用される日時をスケジュールします。 |
| キャッシュを監視し、アラートを設定します。 | キャッシュをスケーリングするタイミングに関する分析情報を得るために、例外、高 CPU、高メモリ使用率、サーバー負荷、および削除されたキーのアラートを設定します。 キャッシュをスケーリングする必要がある場合は、スケーリング イベント中にデータを移行するために CPU が増加するため、スケーリングするタイミングを理解することが重要です。 |
| VNET 内にキャッシュをデプロイします。 | キャッシュに接続できるトラフィックをより詳細に制御できます。 キャッシュ ノードとシャード (クラスター) をデプロイするのに十分なアドレス空間がサブネットにあることを確認します。 |
| Redis Cache 内のパーティション分割戦略を評価します。 | Redis データ ストアをパーティション分割するには、Redis サーバーのインスタンス間でデータを分割する必要があります。 各インスタンスは 1 つのパーティションを構成します。 Azure Redis Cache では、ファサードの背後にある Redis サービスが抽象化され、直接公開されることはありません。 パーティション分割を実装する最も簡単な方法は、複数の Azure Redis Cache インスタンスを作成し、それらの間でデータを分散することです。 各データ項目を、データ項目を格納するキャッシュを指定する識別子 (パーティション キー) に関連付けることができます。 クライアント アプリケーション ロジックでは、この識別子を使用して、要求を適切なパーティションにルーティングできます。 このスキームは単純ですが、パーティション分割スキームが変更された場合 (たとえば、追加の Azure Redis Cache インスタンスが作成された場合)、クライアント アプリケーションの再構成が必要になる場合があります。 |
| ビジネス要件に応じて、キャッシュのコピーを Azure Storage に保存するか、geo レプリケーションを使用するように データ永続化 を構成します。 | データの永続化: マスターとレプリカが再起動すると、データはストレージ アカウントから自動的に読み込まれます。 Geo-レプリケーション: セカンダリ キャッシュのリンクをプライマリから解除する必要があります。 これでセカンダリがプライマリになり、 書き込みを受け取ることができます。 |
| Azure Redis Cache のコンテキストで再試行ポリシーを実装します。 | ほとんどの Azure サービスとクライアント SDK には、再試行メカニズムが組み込まれています。 これらのメカニズムは、各サービスの特性と要件が異なるため、異なります。 各再試行メカニズムは、特定のサービスに合わせて調整されます。 |
| Azure Cache for Redis を管理する方法を確認します。 | キャッシュの再起動でデータ損失が発生する方法と、アプリケーションの回復性をテストする方法について説明します。 |
ソース成果物
Premium レベルにない Redis インスタンスを識別するには、次のクエリを使用します。
Resources
| where type == 'microsoft.cache/redis'
| where properties.sku.name != 'Premium'