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 レプリケーションを使用する、データ永続化を構成する。
- Azure Redis Cache のコンテキストで再試行ポリシーを実装する。
- Redis への接続マルチプレクサーの静的実装またはシングルトン実装を 1 つ使用し、ベスト プラクティス ガイドに従う。
- 「Azure Cache for Redis を管理する方法」を参照する。
構成に関する推奨事項
次の表に記載されている推奨事項を参照して、サービスの信頼性を確保するように Azure Cache for Redis 構成を最適化します。
| 推奨 | Description |
|---|---|
| 更新のスケジュールを設定する。 | Redis Server の更新がキャッシュに適用される日付と時刻をスケジュールします。これには Azure の更新や VM オペレーティングシステムの更新は含まれません。 |
| キャッシュを監視しアラートを設定する。 | 例外、高い CPU 使用率、高いメモリ使用率、サーバーの負荷、および削除されたキーに対するアラートを設定して、キャッシュをスケーリングするタイミングに関する分析情報を取得します。 キャッシュをスケーリングする必要がある場合、データを移行するスケーリング イベント中に CPU 使用率が増加するため、スケーリングを行うタイミングを理解することが重要です。 |
| VNET 内にキャッシュをデプロイする。 | キャッシュに接続できるトラフィックを顧客がさらに制御できるようにします。 キャッシュ ノードとシャード (クラスター) をデプロイするのに十分なアドレス空間がサブネットに確保されている必要があります。 |
| Redis キャッシュ内のパーティション分割戦略を評価する。 | 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'