Azure Managed Redis を使用した開発 (プレビュー)
接続の回復力とサーバーの負荷
クライアント アプリケーションを開発する際には、接続の回復力とサーバー負荷の管理に関連するベスト プラクティスを考慮してください。
キーを増やすことと値を小さくすることを検討する
Azure Managed Redis (プレビュー) は、値が小さいほど最適に動作します。 データを複数のキーに分散させるには、より大きなデータ チャンクを小さいチャンクに分割することを検討してください。 理想的な値の大きさについては、こちらの記事を参照してください。
要求または応答のサイズが大きい
大きい要求/応答が原因でタイムアウトが発生することがあります。 例として、クライアントで構成されているタイムアウト値が 1 秒であるとします。 アプリケーションは同時に 2 つのキー ("A" と "B" など) を (同じ物理ネットワーク接続を使用して) 要求します。 ほとんどのクライアントでは、要求 "A" と要求 "B" の両方がそれぞれの応答を待たずに次々に送信される、要求の "パイプライン処理" がサポートされます。 サーバーは同じ順序で応答を返します。 応答 'A' が大きい場合、その応答は、以降の要求のためのタイムアウトのほとんどを消費する可能性があります。
次の例では、要求 'A' と 'B' がすばやくサーバーに送信されます。 サーバーは、すばやく応答 'A' と 'B' を送信し始めます。 データ転送時間のため、サーバーがすばやく応答したとしても、応答 'B' は応答 'A' が終了するまで待つ必要があります。
|-------- 1 Second Timeout (A)----------|
|-Request A-|
|-------- 1 Second Timeout (B) ----------|
|-Request B-|
|- Read Response A --------|
|- Read Response B-| (**TIMEOUT**)
この要求/応答を測定するのは困難です。 大きい要求や応答を追跡するように、クライアント コードをインストルメント化する必要があります。
大きい応答サイズの解決策はさまざまですが、次のものが含まれます。
- アプリケーションを少数の大きい値ではなく、多数の小さい値用に最適化します。
- データをより小さい関連値に分割することをお勧めします。
- より小さい値が推奨される理由の詳細については、Redis に最適な値のサイズ範囲は何ですか? 100 KB では大きすぎますか? に関する投稿を参照してください。
- より高い帯域幅機能を使用できるように仮想マシン (VM) のサイズを増やします。
- クライアントまたはサーバー VM の帯域幅を増やすと、より大きい応答のデータ転送時間が削減される可能性があります。
- 両方のコンピューターの現在のネットワーク使用量を現在の VM サイズの制限と比較します。 サーバーのみ、またはクライアントのみの帯域幅を増やすだけでは十分でない可能性があります。
- アプリケーションが使用する接続オブジェクトの数を増やします。
- ラウンド ロビン方式を使用して、さまざまな接続オブジェクト経由で要求を発行します。
パイプライン処理の使用
Redis パイプライン処理をサポートする Redis クライアントを選択してみます。 パイプラインを使用すると、ネットワークを効率的に使用して、最高のスループットを実現できます。
コストのかかる操作を避ける
一部の REDIS 操作 (KEYS コマンドなど) はコストが高いため、避ける必要があります。 長期実行コマンドに関する考慮事項については、長期実行コマンドに関する記事を参照してください。
適切な層を選択する
Azure Managed Redis では、メモリ最適化、バランス、コンピューティング最適化、フラッシュ最適化のレベルが提供されます。 レベルの選択方法の詳細については、こちらを参照してください。 適切な層を選択し、接続設定を検証するために、パフォーマンス テストを行うことをお勧めします。 詳細については、「パフォーマンス テスト」を参照してください。
適切な可用性モードを選択する
Azure Managed Redis には、高可用性構成を有効または無効にするオプションが用意されています。 高可用性モードが無効になっている場合、AMR インスタンスのデータはレプリケートされないため、メンテナンス中に Redis インスタンスを使用できなくなります。 また、計画済みまたは計画外のメンテナンスが発生した場合は、AMR インスタンス内のすべてのデータが失われます。 高可用性は開発またはテスト ワークロードに対してのみ無効にすることをお勧めします。 高可用性を備えた Redis インスタンスのパフォーマンスも低下する可能性があります。これは、プライマリとレプリカのデータ シャード間の負荷分散に不可欠なデータ レプリケーションがないためです。
Redis インスタンスと同じリージョンのクライアント
Redis インスタンスとアプリケーションを同じリージョンに配置します。 別のリージョンにある Redis に接続すると、待ち時間が大幅に増加して、信頼性が低下します。
Azure の外部から接続することは可能ですが、これは、特に Redis をアプリケーションやデータベースのパフォーマンスを高速化するために使用している場合にはお勧めできません。 Redis サーバーを単なるキー/値ストアとして使用している場合は、待ち時間は一番の問題ではない可能性があります。
パブリック IP アドレスではなくホスト名に依存する
AMR インスタンスに割り当てられたパブリック IP アドレスは、スケール操作やバックエンドの改善が原因で変更される場合があります。 明示的なパブリック IP アドレスではなく、ホスト名に依存することをお勧めします。
TLS 暗号化を使用する
Azure Managed Redis では、TLS で暗号化された通信が既定で必要です。 現在、TLS バージョン 1.2 および 1.3 がサポートされています。 お使いのクライアント ライブラリまたはツールで TLS がサポートされていない場合は、暗号化されていない接続を有効にすることができます。
メモリ使用量、CPU 使用率メトリック、クライアント接続、ネットワーク帯域幅を監視する
Azure Managed Redis インスタンスを運用環境で使用する場合は、"使用メモリの割合"、"CPU" メトリック、"接続されたクライアント" のアラートを設定することをお勧めします。 これらのメトリックが一貫して 75% を超える場合は、インスタンスをより大きなメモリまたはより速いスループット レベルにスケーリングすることを検討してください。 詳細については、「スケーリングするタイミング」を参照してください。
データ永続化またはデータ バックアップの有効化を検討する
Redis は既定で一時的なデータ用に設計されているため、メンテナンスや停止などのさまざまな状況により、まれにデータが失われる可能性があります。 アプリケーションがデータ損失の影響を受けやすい場合は、データ エクスポート操作を使用して、データ永続化または定期データ バックアップを有効にすることをお勧めします。
データ永続化機能は、キャッシュがダウンしたときにデータの迅速な復旧ポイントを自動的に提供するように設計されています。 キャッシュ インスタンスにマウントされているマネージド ディスクに RDB または AOF ファイルを格納することで、迅速な復旧が可能になります。 ディスク上の永続化ファイルはユーザーがアクセスできないか、他の AMR インスタンスで使用できません。
多くのお客様は、永続化を使用して、キャッシュ上のデータの定期的なバックアップを取得したいと考えています。 この方法でデータ永続化を使用することはお勧めしません。 代わりに、インポート/エクスポート機能を使用します。 RDB 形式のデータのコピーを選択したストレージ アカウントに直接エクスポートし、必要な頻度でデータ エクスポートをトリガーできます。 このエクスポートされたデータは、任意の Redis インスタンスにインポートできます。 エクスポートは、ポータルから、または CLI、PowerShell、または SDK ツールを使用してトリガーできます。
クライアント ライブラリ固有のガイダンス
詳細については、「Azure Managed Redis クライアント ライブラリ」を参照してください。