次の方法で共有

開発

  • [アーティクル]

接続の回復力とサーバーの負荷

クライアント アプリケーションを開発する際には、接続の回復力とサーバー負荷の管理に関連するベスト プラクティスを考慮してください。

キーを増やすことと値を小さくすることを検討する

Azure Cache for 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**)

この要求/応答を測定するのは困難です。 大きい要求や応答を追跡するように、クライアント コードをインストルメント化する必要があります。

大きい応答サイズの解決策はさまざまですが、次のものが含まれます。

  • アプリケーションを少数の大きい値ではなく、多数の小さい値用に最適化します。
  • より高い帯域幅機能を使用できるように仮想マシン (VM) のサイズを増やします。
    • クライアントまたはサーバー VM の帯域幅を増やすと、より大きい応答のデータ転送時間が削減される可能性があります。
    • 両方のコンピューターの現在のネットワーク使用量を現在の VM サイズの制限と比較します。 サーバーのみ、またはクライアントのみの帯域幅を増やすだけでは十分でない可能性があります。
  • アプリケーションが使用する接続オブジェクトの数を増やします。
    • ラウンド ロビン方式を使用して、さまざまな接続オブジェクト経由で要求を発行します。

キーの配布

Redis クラスタリングを使用する予定の場合は、まず「キーに関する Redis クラスタリングのベスト プラクティス」をお読みください。

パイプライン処理の使用

Redis パイプライン処理をサポートする Redis クライアントを選択してみます。 パイプラインを使用すると、ネットワークを効率的に使用して、最高のスループットを実現できます。

コストのかかる操作を避ける

一部の REDIS 操作 (KEYS コマンドなど) はコストが高いため、避ける必要があります。 長期実行コマンドに関する考慮事項については、長期実行コマンドに関する記事を参照してください。

適切な層を選択する

運用システムには、Standard、Premium、Enterprise、または Enterprise Flash の各レベルを使用します。 運用環境では Basic レベルを使用しないでください。 Basic レベルは単一ノード システムであり、データ レプリケーション機能や SLA がありません。 また、C1 以上のキャッシュを使用してください。 次の理由から、C0 キャッシュは単純な Dev/Test シナリオ専用です。

  • CPU コアを共有する
  • メモリをほとんど使用しない
  • 近隣ノイズの問題の影響を受けやすい

適切な層を選択し、接続設定を検証するために、パフォーマンス テストを行うことをお勧めします。 詳細については、「パフォーマンス テスト」を参照してください。

キャッシュと同じリージョンのクライアント

キャッシュ インスタンスとアプリケーションを同じリージョンに配置します。 異なるリージョンのキャッシュに接続すると、待ち時間が大幅に増加し、信頼性が低下する可能性があります。

Azure の外部から接続することはできますが、これは、特に Redis をキャッシュとして使用しているときにはお勧めできません。 Redis サーバーを単なるキー/値ストアとして使用している場合は、待ち時間は一番の問題ではない可能性があります。

パブリック IP アドレスではなくホスト名に依存する

キャッシュに割り当てられたパブリック IP アドレスは、スケール操作やバックエンドの改善が原因で変更される場合があります。 明示的なパブリック IP アドレスではなく、ホスト名に依存することをお勧めします。 各種レベルに対する推奨の形式を次に示します。

レベル フォーム
Basic、Standard、Premium <cachename>.redis.cache.windows.net
Enterprise、Enterprise Flash <DNS name>.<Azure region>.redisenterprise.cache.azure.net.

適切な Redis バージョンを選択する

キャッシュの作成時に使用される Redis の既定のバージョンは、今後変わる可能性があります。 新しいバージョンのオープン ソース Redis がリリースされたときは、Azure Cache for Redis で新しいバージョンが採用される場合があります。 アプリケーションに特定のバージョンの Redis が必要な場合は、キャッシュの作成時に Redis のバージョンを明示的に選択することをお勧めします。

Enterprise レベルの具体的なガイダンス

Enterprise および Enterprise Flash レベルは、オープンソース Redis ではなく Redis Enterprise 上に構築されているため、開発のベスト プラクティスにはいくつかの違いがあります。 詳細については、Enterprise レベルと Enterprise Flash レベルのベスト プラクティスに関する記事をご覧ください。

TLS 暗号化を使用する

Azure Cache for Redis では、TLS で暗号化された通信が既定で必要です。 現在、TLS バージョン 1.0、1.1、および 1.2 がサポートされています。 ただし、TLS 1.0 と 1.1 は業界全体で非推奨になる予定であるため、可能であれば TLS 1.2 を使用してください。

お使いのクライアント ライブラリまたはツールで TLS がサポートされていない場合は、Azure portal または管理 API を使用して、暗号化されていない接続を有効にすることができます。 暗号化された接続ができない場合は、キャッシュとクライアント アプリケーションを仮想ネットワークに配置することをお勧めします。 仮想ネットワーク キャッシュ シナリオで使用されるポートの詳細については、こちらの表を参照してください。

Azure TLS 証明書の変更

Microsoft では、異なる証明機関 (CA) のセットからの TLS サーバー証明書を使用するように、Azure サービスが更新されています。 この変更は、2020 年 8 月 13 日から 2020 年 10 月 26 日 (推定) のフェーズでロール アウトされます。 Azure では、現在の CA 証明書が CA/ブラウザー フォーラムのベースライン要件の 1 つにでないため、この変更が行われます。 この問題は 2020 年 7 月 1 日に報告され、世界中の複数の一般的な公開キー基盤 (PKI) プロバイダーに適用されます。 現在、Azure サービスで使用されている TLS 証明書の多くは、Baltimore CyberTrust Root PKI に由来します。 Azure Cache for Redis サービスは、引き続き Baltimore CyberTrust Root に結び付けられます。 これは TLS サーバー証明書ですが、TLS サーバー証明書は、2020 年 10 月 12 日以降、新しい中間証明機関 (ICA) によって発行されます。

Note

この変更は、パブリック Azure リージョンのサービスに限定されます。 ソブリン (中国など) や政府のクラウドは除外されます。

この変更は私に影響しますか?

ほとんどの Azure Cache for Redis のお客様は、この変更の影響を受けません。 受け入れ可能な証明書のリストをアプリケーションが明示的に指定している場合は ("証明書のピン留め" と呼ばれるプラクティス)、アプリケーションが影響を受ける可能性があります。 Baltimore CyberTrust Root の代わりに中間証明書またはリーフ証明書をピン留めしている場合、証明書の構成を変更するには、直ちに対応する必要があります。

Azure Cache for Redis では、OCSP ステープリングはサポートされていません。

次の表に、ロール アウトされる証明書に関する情報を示します。 アプリケーションで使用される証明書によっては、Azure Cache for Redis インスタンスへの接続が失われないように、それを更新する必要がある場合があります。

CA の種類 Current ローリング後 (2020 年 10 月 12 日) アクション
Root 拇印: d4de20d05e66fc53fe1a50882c78db2852cae474

有効期限: 2025 年 5 月 12 日月曜日、午後 4:59:00

件名:
CN = Baltimore CyberTrust Root
OU = CyberTrust
O = Baltimore
C = IE		 変更なし None
中間 拇印:
CN = Microsoft IT TLS CA 1
Thumbprint:417e225037fbfaa4f95761d5ae729e1aea7e3a42

CN = Microsoft IT TLS CA 2
Thumbprint:54d9d20239080c32316ed9ff980a48988f4adf2d

CN = Microsoft IT TLS CA 4
Thumbprint:8a38755d0996823fe8fa3116a277ce446eac4e99

CN = Microsoft IT TLS CA 5
Thumbprint:Ad898ac73df333eb60ac1f5fc6c4b2219ddb79b7

有効期限: ‎2024 年 ‎5 月 ‎20 日‎金曜日、午前 5:52:38

件名:
OU = Microsoft IT
O = Microsoft Corporation
L = Redmond
S = Washington
C = US
 拇印:
CN = Microsoft RSA TLS CA 01
Thumbprint:703d7a8f0ebf55aaa59f98eaf4a206004eb2516a

CN = Microsoft RSA TLS CA 02
拇印: b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75

有効期限: ‎2024 年 ‎10 月 ‎8 日火曜日、‎午前 12:00:00;

件名:
O = Microsoft Corporation
C = US
 必須

どのような対応が必要ですか?

アプリケーションでオペレーティング システムの証明書ストアを使用する場合、またはその他の間で Baltimore ルートをピン留めする場合は、何もする必要はありません。

アプリケーションで中間証明書またはリーフ TLS 証明書をピン留めする場合は、次のルートをピン留めすることをお勧めします。

Certificate Thumbprint
Baltimore Root CA d4de20d05e66fc53fe1a50882c78db2852cae474
Microsoft RSA Root Certificate Authority 2017 73a5e64a3bff8316ff0edccc618a906e4eae4d74
Digicert Global Root G2 df3c24f9bfd666761b268073fe06d1cc8d4f82a4

ヒント

中間証明書とリーフ証明書の両方が頻繁に変更されることが想定されます。 それらに対して依存関係を使用しないことをお勧めします。 代わりに、アプリケーションをルート証明書にピン留めします。これは、ロール アウトの頻度が低いためです。

中間証明書を引き続きピン留めするには、ピン留めされた中間証明書リストに次を追加します。これには、将来の変更を最小限に抑えるための追加がいくつか含まれます。

CA の共通名 Thumbprint
Microsoft RSA TLS CA 01 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a
Microsoft RSA TLS CA 02 b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75
Microsoft Azure TLS 発行元 CA 01 2f2877c5d778c31e0f29c7e371df5471bd673173
Microsoft Azure TLS 発行元 CA 02 e7eea674ca718e3befd90858e09f8372ad0ae2aa
Microsoft Azure TLS 発行元 CA 05 6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5
Microsoft Azure TLS 発行元 CA 06 30e01761ab97e59a06b41ef20af6f2de7ef4f7b0

アプリケーションでコード内の証明書が検証される場合は、新しくピン留めされた証明書のプロパティ (発行者、拇印など) を認識するように変更する必要があります。 この追加の検証では、すべてのピン留めされた証明書を今後に対応するように扱う必要があります。

クライアント ライブラリ固有のガイダンス

詳細については、クライアント ライブラリに関する記事を参照してください。

次のステップ