Azure Cache for Redis に関する FAQAzure Cache for Redis FAQ

Azure Cache for Redis についてよく寄せられる質問に対する回答、パターン、ベスト プラクティスについて説明します。Learn the answers to common questions, patterns, and best practices for Azure Cache for Redis.

ここに質問の答えがない場合はどうすればいいですか。What if my question isn't answered here?

質問がここに表示されていない場合はご連絡ください。答えを見つけるお手伝いをします。If your question isn't listed here, let us know and we'll help you find an answer.

  • この FAQ の最後に掲載されているコメントに質問を投稿し、Azure Cache チームや他のコミュニティ メンバーとこの記事についてやり取りすることができます。You can post a question in the comments at the end of this FAQ and engage with the Azure Cache team and other community members about this article.
  • さらに多くの人と情報交換する場合は、 Azure Cache MSDN フォーラム に質問を投稿すれば、Azure Cache チームや他のコミュニティ メンバーとやり取りすることができます。To reach a wider audience, you can post a question on the Azure Cache MSDN Forum and engage with the Azure Cache team and other members of the community.
  • 機能要求を作成する場合は、要求とアイデアを Azure Redis Cache のユーザーの声に送信することができます。If you want to make a feature request, you can submit your requests and ideas to Azure Cache for Redis User Voice.
  • また、 Azure Cache 外部フィードバックにメールをお送りいただくこともできます。You can also send an email to us at Azure Cache External Feedback.

Azure Cache for Redis の基本Azure Cache for Redis basics

このセクションの FAQ では、Azure Cache for Redis の基本について説明します。The FAQs in this section cover some of the basics of Azure Cache for Redis.

以下の FAQ では、Azure Cache for Redis に関する基本的な概念と質問を取り上げており、回答は他の FAQ セクションのいずれかに示されています。The following FAQs cover basic concepts and questions about Azure Cache for Redis and are answered in one of the other FAQ sections.

計画に関する FAQPlanning FAQs

開発に関する FAQDevelopment FAQs

セキュリティに関する FAQSecurity FAQs

運用に関する FAQProduction FAQs

監視とトラブルシューティングに関する FAQMonitoring and troubleshooting FAQs

このセクションの FAQ では、監視とトラブルシューティングに関する一般的な質問について説明します。The FAQs in this section cover common monitoring and troubleshooting questions. Azure Cache for Redis インスタンスの監視とトラブルシューティングの詳細については、「Azure Cache for Redis を監視する方法」と、さまざまなトラブルシューティングのガイドを参照してください。For more information about monitoring and troubleshooting your Azure Cache for Redis instances, see How to monitor Azure Cache for Redis and the various troubleshoot guides.

事前のキャッシュ オファリングに関する FAQPrior Cache offering FAQs

Azure Cache for Redis とはWhat is Azure Cache for Redis?

Azure Cache for Redis は、人気のあるオープンソース ソフトウェア Redis が基になっています。Azure Cache for Redis is based on the popular open-source software Redis. これを使用すると、Microsoft によって管理されている、セキュリティで保護された専用 Azure Cache for Redis に Azure 内の任意のアプリケーションからアクセスできます。It gives you access to a secure, dedicated Azure Cache for Redis, managed by Microsoft, and accessible from any application within Azure. 詳細については、azure.com の Azure Cache for Redis の製品ページを参照してください。For a more detailed overview, see the Azure Cache for Redis product page on Azure.com.

Azure Cache for Redis の使用を開始する方法How can I get started with Azure Cache for Redis?

Azure Cache for Redis の使用を開始する方法はいくつかあります。There are several ways you can get started with Azure Cache for Redis.

Azure アカウントをお持ちでない場合は、次の操作を行います。If you don't already have an Azure account, you can:

Azure Cache for Redis のサービス内容と適切なサイズの選択What Azure Cache for Redis offering and size should I use?

Azure Cache for Redis には、さまざまなレベルのサイズ帯域幅高可用性SLA に関するオプションが用意されています。Each Azure Cache for Redis offering provides different levels of size, bandwidth, high availability, and SLA options.

Cache のオプションを選択するときの考慮事項を次に示します。The following are considerations for choosing a Cache offering.

  • メモリ:Basic レベルと Standard レベルでは、250 MB ~ 53 GB です。Memory: The Basic and Standard tiers offer 250 MB – 53 GB. Premium サービス レベルでは、最大 1.2 TB (クラスター) または 120 GB (非クラスター) が提供されます。The Premium tier offers up to 1.2 TB (as a cluster) or 120 GB (non-clustered). 詳細については、Azure Cache for Redis の価格に関するページを参照してください。For more information, see Azure Cache for Redis Pricing.
  • ネットワーク パフォーマンス:高いスループットを必要とするワークロードがある場合、Premium レベルでは、Standard や Basic と比較してより広い帯域幅が提供されます。Network Performance: If you have a workload that requires high throughput, the Premium tier offers more bandwidth compared to Standard or Basic. また、各レベル内では、キャッシュをホストする基盤の VM のため、キャッシュのサイズが大きいほど帯域幅も増えます。Also within each tier, larger size caches have more bandwidth because of the underlying VM that hosts the cache. 詳細については、次の表を参照してください。For more information, see the following table.
  • スループット:Premium レベルでは、提供されているうちで最大のスループットが提供されます。Throughput: The Premium tier offers the maximum available throughput. キャッシュ サーバーまたはクライアントが帯域幅の限界に達した場合、クライアント側でタイムアウトが発生する場合があります。If the cache server or client reaches the bandwidth limits, you may receive timeouts on the client side. 詳細については、後の表を参照してください。For more information, see the following table.
  • 高可用性/SLA:Azure Cache for Redis では、Standard/Premium キャッシュについて、少なくとも 99.9% の可用性を保証しています。High Availability/SLA: Azure Cache for Redis guarantees that a Standard/Premium cache is available at least 99.9% of the time. SLA の詳細については、Azure Cache for Redis の価格についてのページを参照してください。To learn more about our SLA, see Azure Cache for Redis Pricing. SLA は、Cache エンドポイントへの接続のみをカバーします。The SLA only covers connectivity to the Cache endpoints. SLA は、データ損失からの保護には対応していません。The SLA does not cover protection from data loss. Premium レベルの Redis データの保持機能を使用して、データ損失に対する復元性を高めることをお勧めします。We recommend using the Redis data persistence feature in the Premium tier to increase resiliency against data loss.
  • Redis データの永続化:Premium レベルでは、Azure Storage アカウント内のキャッシュ データを永続化できます。Redis Data Persistence: The Premium tier allows you to persist the cache data in an Azure Storage account. Basic/Standard のキャッシュでは、データはすべてメモリ内にのみ格納されます。In a Basic/Standard cache, all the data is stored only in memory. 基になるインフラストラクチャで問題が発生すると、データが失われる可能性があります。Underlying infrastructure issues might result in potential data loss. Premium レベルの Redis データの保持機能を使用して、データ損失に対する復元性を高めることをお勧めします。We recommend using the Redis data persistence feature in the Premium tier to increase resiliency against data loss. Azure Cache for Redis では、Redis 永続化の RDB オプションと AOF オプション (近日提供予定) が用意されています。Azure Cache for Redis offers RDB and AOF (coming soon) options in Redis persistence. 詳細については、Premium Azure Cache for Redis の永続化の構成方法についてのページを参照してください。For more information, see How to configure persistence for a Premium Azure Cache for Redis.
  • Redis クラスター:Premium サービス レベルで利用可能な Redis クラスタリングを使用すると、120 GB を超えるキャッシュを作成したり、複数の Redis ノード間でデータをシャード化したりできます。Redis Cluster: To create caches larger than 120 GB, or to shard data across multiple Redis nodes, you can use Redis clustering, which is available in the Premium tier. 各ノードは、高可用性対応のプライマリ/レプリカ キャッシュのペアで構成されています。Each node consists of a primary/replica cache pair for high availability. 詳細については、Premium Azure Cache for Redis のクラスタリングの構成方法に関するページを参照してください。For more information, see How to configure clustering for a Premium Azure Cache for Redis.
  • セキュリティとネットワークの分離の強化:Azure Virtual Network (VNET) のデプロイにより、Azure Cache for Redis のセキュリティと分離が強化されると共に、サブネット、アクセス制御ポリシー、アクセスをさらに制限する他の機能も提供されます。Enhanced security and network isolation: Azure Virtual Network (VNET) deployment provides enhanced security and isolation for your Azure Cache for Redis, as well as subnets, access control policies, and other features to further restrict access. 詳細については、Premium Azure Cache for Redis の Virtual Network のサポートを構成する方法に関するページを参照してください。For more information, see How to configure Virtual Network support for a Premium Azure Cache for Redis.
  • Redis の構成:Standard レベルと Premium レベルのどちらでも、キースペース通知のために Redis を構成できます。Configure Redis: In both the Standard and Premium tiers, you can configure Redis for Keyspace notifications.
  • 最大クライアント接続数:Premium レベルでは、Redis に接続できる最大数のクライアントが提供されます。キャッシュのサイズが大きいほど、接続の数は多くなります。Maximum number of client connections: The Premium tier offers the maximum number of clients that can connect to Redis, with a higher number of connections for larger sized caches. クラスタリングでは、クラスター化されたキャッシュで使用できる接続の数は増加しません。Clustering does not increase the number of connections available for a clustered cache. 詳細については、Azure Cache for Redis の価格に関するページを参照してください。For more information, see Azure Cache for Redis pricing.
  • Redis サーバー専用コア:Premium レベルでは、すべてのキャッシュ サイズに Redis 専用のコアがあります。Dedicated Core for Redis Server: In the Premium tier, all cache sizes have a dedicated core for Redis. Basic/Standard レベルでは、C1 サイズ以上に Redis サーバー専用コアがあります。In the Basic/Standard tiers, the C1 size and above have a dedicated core for Redis server.
  • Redis はシングル スレッドです。したがって、3 つ以上のコアを使用しても 2 つのコアを使用する場合と比べて追加のメリットはありません。ただし、一般に、VM のサイズが大きいほど、小さなサイズよりも多くの帯域幅を利用できます。Redis is single-threaded so having more than two cores does not provide additional benefit over having just two cores, but larger VM sizes typically have more bandwidth than smaller sizes. キャッシュ サーバーまたはクライアントが帯域幅の制限に達すると、クライアント側でタイムアウトが発生します。If the cache server or client reaches the bandwidth limits, then you receive timeouts on the client side.
  • パフォーマンスの向上:Premium レベルのキャッシュは、高速プロセッサを備えたハードウェアにデプロイされ、Basic レベルや Standard レベルと比べて優れたパフォーマンスを発揮します。Performance improvements: Caches in the Premium tier are deployed on hardware that has faster processors, giving better performance compared to the Basic or Standard tier. Premium レベルのキャッシュは、スループットが高く、待機時間が低くなっています。Premium tier Caches have higher throughput and lower latencies.

Azure Cache for Redis のパフォーマンスAzure Cache for Redis performance

次の表に、Azure Cache for Redis のエンドポイントに対して IaaS VM から redis-benchmark.exe を使用して、Standard および Premium キャッシュのさまざまなサイズをテストした際に測定された最大帯域幅を示します。The following table shows the maximum bandwidth values observed while testing various sizes of Standard and Premium caches using redis-benchmark.exe from an IaaS VM against the Azure Cache for Redis endpoint. SSL のスループットについては、Azure Cache for Redis エンドポイントに接続するため、Redis ベンチマークは stunnel と共に使用されています。For SSL throughput, redis-benchmark is used with stunnel to connect to the Azure Cache for Redis endpoint.

注意

これらの値は保証された値ではなく、これらの値の SLA もありません。これらの値は、標準的な値と考えてください。These values are not guaranteed and there is no SLA for these numbers, but should be typical. アプリケーションに最適なキャッシュ サイズを特定するには、アプリケーションに対してロード テストを実行する必要があります。You should load test your own application to determine the right cache size for your application. 定期的に新しい結果を公表しているため、これらの数字は変わる可能性があります。These numbers might change as we post newer results periodically.

この表からは次のような結論が得られます。From this table, we can draw the following conclusions:

  • キャッシュのサイズが同じ場合のスループットは、Standard レベルより Premium レベルの方が高くなります。Throughput for the caches that are the same size is higher in the Premium tier as compared to the Standard tier. たとえば、P1 のスループットは、6 GB キャッシュでは 180,000 要求/秒 (RPS) であるのに対し、C3 では 100,000 RPS となります。For example, with a 6 GB Cache, throughput of P1 is 180,000 requests per second (RPS) as compared to 100,000 RPS for C3.
  • Redis クラスタリングでは、クラスターのシャード (ノード) の数を増やすと、スループットもそれに比例して増加する。With Redis clustering, throughput increases linearly as you increase the number of shards (nodes) in the cluster. たとえば、10 個のシャードから成る P4 クラスターを作成すると、利用可能なスループットは 400,000 * 10 = 4 百万 RPS になります。For example, if you create a P4 cluster of 10 shards, then the available throughput is 400,000 * 10 = 4 million RPS.
  • キー サイズを大きくしたときのスループットは、Standard レベルより Premium レベルのほうが高い。Throughput for bigger key sizes is higher in the Premium tier as compared to the Standard Tier.
Pricing tierPricing tier SizeSize CPU コア数CPU cores 使用可能な帯域幅Available bandwidth 1 KB 値サイズ1-KB value size 1 KB 値サイズ1-KB value size
Standard のキャッシュ サイズStandard cache sizes メガビット/秒 (Mb/s) / メガバイト/秒 (MB/s)Megabits per sec (Mb/s) / Megabytes per sec (MB/s) 1 秒あたりの要求数 (RPS) 非 SSLRequests per second (RPS) Non-SSL 1 秒あたりの要求数 (RPS) SSLRequests per second (RPS) SSL
C0C0 250 MB250 MB 共有Shared 100 / 12.5100 / 12.5 15,00015,000 7,5007,500
C1C1 1 GB1 GB 11 500 / 62.5500 / 62.5 38,00038,000 20,72020,720
C2C2 2.5 GB2.5 GB 22 500 / 62.5500 / 62.5 41,00041,000 37,00037,000
C3C3 6 GB6 GB 44 1000 / 1251000 / 125 100,000100,000 90,00090,000
C4C4 13 GB13 GB 22 500 / 62.5500 / 62.5 60,00060,000 55,00055,000
C5C5 26 GB26 GB 44 1,000 / 1251,000 / 125 102,000102,000 93,00093,000
C6C6 53 GB53 GB 88 2,000 / 2502,000 / 250 126,000126,000 120,000120,000
Premium のキャッシュ サイズPremium cache sizes シャードあたりの CPU コア数CPU cores per shard メガビット/秒 (Mb/s) / メガバイト/秒 (MB/s)Megabits per sec (Mb/s) / Megabytes per sec (MB/s) 1 秒あたりの要求数 (RPS) 非 SSL、シャードあたりRequests per second (RPS) Non-SSL, per shard 1 秒あたりの要求数 (RPS) SSL、シャードあたりRequests per second (RPS) SSL, per shard
P1P1 6 GB6 GB 22 1,500 / 187.51,500 / 187.5 180,000180,000 172,000172,000
P2P2 13 GB13 GB 44 3,000 / 3753,000 / 375 350,000350,000 341,000341,000
P3P3 26 GB26 GB 44 3,000 / 3753,000 / 375 350,000350,000 341,000341,000
P4P4 53 GB53 GB 88 6,000 / 7506,000 / 750 400,000400,000 373,000373,000
P5P5 120 GB120 GB 2020 6,000 / 7506,000 / 750 400,000400,000 373,000373,000

stunnel の設定や redis-benchmark.exe などの Redis ツールのダウンロードの詳細については、「Redis コマンドの実行方法 」セクションを参照してください。For instructions on setting up stunnel or downloading the Redis tools such as redis-benchmark.exe, see the How can I run Redis commands? section.

キャッシュを配置するリージョンIn what region should I locate my cache?

最大限のパフォーマンスと最短の待機時間を実現するには、キャッシュ クライアント アプリケーションと同じリージョンに Azure Cache for Redis を配置します。For best performance and lowest latency, locate your Azure Cache for Redis in the same region as your cache client application.

Azure Cache for Redis の課金方法How am I billed for Azure Cache for Redis?

Azure Cache for Redis の価格はここに記載されています。Azure Cache for Redis pricing is here. 価格ページには、1 時間単位の価格が表示されます。The pricing page lists pricing as an hourly rate. キャッシュは、キャッシュが作成された時間から削除された時間までの期間に関して、分単位で課金されます。Caches are billed on a per-minute basis from the time that the cache is created until the time that a cache is deleted. キャッシュの課金を停止または一時停止するオプションはありません。There is no option for stopping or pausing the billing of a cache.

Azure Cache for Redis を Azure Government Cloud、Azure China Cloud、または Microsoft Azure Germany で使用できるかCan I use Azure Cache for Redis with Azure Government Cloud, Azure China Cloud, or Microsoft Azure Germany?

はい。Azure Cache for Redis は、Azure Government Cloud、Azure China 21Vianet Cloud、Microsoft Azure Germany で使用できます。Yes, Azure Cache for Redis is available in Azure Government Cloud, Azure China 21Vianet Cloud, and Microsoft Azure Germany. ただし、Azure Cache for Redis のアクセスと管理を行うための URL については、これらのクラウドと、Azure パブリック クラウドとで異なります。The URLs for accessing and managing Azure Cache for Redis are different in these clouds compared with Azure Public Cloud.

クラウドCloud Redis の DNS サフィックスDns Suffix for Redis
パブリックPublic *.redis.cache.windows.net*.redis.cache.windows.net
米国政府US Gov *. redis.cache.usgovcloudapi.net*.redis.cache.usgovcloudapi.net
ドイツGermany *.redis.cache.cloudapi.de*.redis.cache.cloudapi.de
中国China *.redis.cache.chinacloudapi.cn*.redis.cache.chinacloudapi.cn

その他のクラウドで Azure Cache for Redis を使用するときの考慮事項の詳細については、次のリンクを参照してください。For more information on considerations when using Azure Cache for Redis with other clouds, see the following links.

Azure Government Cloud、Azure China 21Vianet Cloud、Microsoft Azure Germany での PowerShell を使用した Azure Cache for Redis の利用の詳細については、他のクラウドに接続する方法 - Azure Cache for Redis PowerShell に関するページを参照してください。For information on using Azure Cache for Redis with PowerShell in Azure Government Cloud, Azure China 21Vianet Cloud, and Microsoft Azure Germany, see How to connect to other clouds - Azure Cache for Redis PowerShell.

StackExchange.Redis 構成オプションについてWhat do the StackExchange.Redis configuration options do?

StackExchange.Redis には多くのオプションが用意されています。StackExchange.Redis has many options. ここでは、いくつかの一般的な設定について説明します。This section talks about some of the common settings. StackExchange.Redis オプションの詳細については、 StackExchange.Redis の構成に関するページを参照してください。For more detailed information about StackExchange.Redis options, see StackExchange.Redis configuration.

構成オプションConfigurationOptions 説明Description 推奨Recommendation
AbortOnConnectFailAbortOnConnectFail true の場合、ネットワーク障害の後に再接続が行われません。When set to true, the connection will not reconnect after a network failure. StackExchange.Redis が自動的に再接続するように、false に設定します。Set to false and let StackExchange.Redis reconnect automatically.
ConnectRetryConnectRetry 初期接続中に接続試行を繰り返す回数。The number of times to repeat connection attempts during initial connect. 次の注意事項を参考にしてください。See the following notes for guidance.
ConnectTimeoutConnectTimeout 接続操作のタイムアウト (ミリ秒単位)。Timeout in ms for connect operations. 次の注意事項を参考にしてください。See the following notes for guidance.

通常は、クライアントの既定値で十分です。Usually the default values of the client are sufficient. ワークロードに基づいてオプションを微調整できます。You can fine-tune the options based on your workload.

  • 再試行Retries

    • 一般的に ConnectRetry と ConnectTimeout に関しては、フェイル ファストして再試行することをお勧めします。For ConnectRetry and ConnectTimeout, the general guidance is to fail fast and retry again. これは、ワークロードと、クライアントが Redis コマンドを発行してから応答を受け取るまでに要する時間の平均に基づいたガイダンスです。This guidance is based on your workload and how much time on average it takes for your client to issue a Redis command and receive a response.
    • 自分で接続の状態を確認して再接続するのではなく、StackExchange.Redis が自動的に再接続するように設定します。Let StackExchange.Redis automatically reconnect instead of checking connection status and reconnecting yourself. ConnectionMultiplexer.IsConnected プロパティは使用しませんAvoid using the ConnectionMultiplexer.IsConnected property.
    • 問題の肥大化 - ある問題が発生し、再試行によって問題が肥大化して、解決しないことがあります。Snowballing - sometimes you may run into an issue where you are retrying and the retries snowball and never recovers. 問題の肥大化が発生した場合は、Microsoft Patterns & Practices グループ発行の「再試行に関する一般的なガイダンス」に説明されている指数バックオフ再試行アルゴリズムの使用を検討する必要があります。If snowballing occurs, you should consider using an exponential backoff retry algorithm as described in Retry general guidance published by the Microsoft Patterns & Practices group.
  • タイムアウト値Timeout values

    • ワークロードを考慮したうえで値を適宜設定します。Consider your workload and set the values accordingly. 大きな値を保存する場合は、タイムアウトを大きな値に設定します。If you are storing large values, set the timeout to a higher value.
    • StackExchange.Redis が再接続できるように、 AbortOnConnectFail を false に設定します。Set AbortOnConnectFail to false and let StackExchange.Redis reconnect for you.
    • アプリケーションに対して ConnectionMultiplexer インスタンスを 1 つ使用します。Use a single ConnectionMultiplexer instance for the application. ConnectionMultiplexer クラスを使用してキャッシュに接続する」に示されているように、LazyConnection を使用して、Connection プロパティから返される単一のインスタンスを作成できます。You can use a LazyConnection to create a single instance that is returned by a Connection property, as shown in Connect to the cache using the ConnectionMultiplexer class.
    • 診断用には、 ConnectionMultiplexer.ClientName プロパティを、アプリ インスタンスの一意な名前に設定します。Set the ConnectionMultiplexer.ClientName property to an app instance unique name for diagnostic purposes.
    • カスタム ワークロードに対しては複数の ConnectionMultiplexer インスタンスを使用します。Use multiple ConnectionMultiplexer instances for custom workloads.
      • アプリケーションの負荷が変化する場合は、このモデルに従うことができます。You can follow this model if you have varying load in your application. 例:For example:
      • 1 つのマルチプレクサーを使用して、サイズの大きなキーを処理できます。You can have one multiplexer for dealing with large keys.
      • 1 つのマルチプレクサーを使用して、サイズの小さなキーを処理できます。You can have one multiplexer for dealing with small keys.
      • 使用する ConnectionMultiplexer ごとに、異なる接続タイムアウト値と再試行ロジックを設定できます。You can set different values for connection timeouts and retry logic for each ConnectionMultiplexer that you use.
      • 診断を容易にするために、各マルチプレクサーで ClientName プロパティを設定します。Set the ClientName property on each multiplexer to help with diagnostics.
      • このガイダンスにより、ConnectionMultiplexer あたりの待機時間が合理化される場合があります。This guidance may lead to more streamlined latency per ConnectionMultiplexer.

使用可能な Azure Cache for Redis クライアントについてWhat Azure Cache for Redis clients can I use?

Redis のメリットの 1 つが、クライアントが多数存在しており、さまざまな開発言語を多数サポートしている点です。One of the great things about Redis is that there are many clients supporting many different development languages. 現在のクライアントの一覧については、 Radis クライアントに関するページをご覧ください。For a current list of clients, see Redis clients. さまざまな言語とクライアントのチュートリアルについては、Azure Cache for Redis の使用方法に関するページとその関連記事を目次から見つけて参照してください。For tutorials that cover several different languages and clients, see How to use Azure Cache for Redis and it's sibling articles in the table of contents.

Azure portal を使用して、ホスト名、ポート、およびアクセス キーを取得するRetrieve host name, ports, and access keys by using the Azure portal

Azure Cache for Redis のインスタンスに接続するときには、キャッシュ クライアントにキャッシュのホスト名、ポート、およびキーが必要です。When connecting to an Azure Cache for Redis instance, cache clients need the host name, ports, and a key for the cache. クライアントによっては、これらの項目を参照するための名前が若干異なる場合があります。Some clients might refer to these items by slightly different names. この情報は、Azure Portal で取得できます。You can retrieve this information in the Azure portal.

アクセス キーおよびホスト名を取得するにはTo retrieve the access keys and host name

  1. Azure portal を使用してアクセス キーを取得するには、キャッシュに移動して、 [アクセス キー] を選択します。To retrieve the access keys by using the Azure portal, go to your cache and select Access keys.

    Azure Cache for Redis のキー

  2. ホスト名とポートを取得するには、 [プロパティ] を選択します。To retrieve the host name and ports, select Properties.

    Azure Cache for Redis のプロパティ

Azure Cache for Redis のローカル エミュレーターの有無についてIs there a local emulator for Azure Cache for Redis?

Azure Cache for Redis のローカル エミュレーターがなくても、ローカル コンピューターの Redis コマンド ライン ツールから、redis-server.exe の MSOpenTech のバージョンを実行して接続し、以下の例のように、ローカル キャッシュ エミュレーターと同じような使い心地を得ることができます。There is no local emulator for Azure Cache for Redis, but you can run the MSOpenTech version of redis-server.exe from the Redis command-line tools on your local machine and connect to it to get a similar experience to a local cache emulator, as shown in the following example:

private static Lazy<ConnectionMultiplexer>
      lazyConnection = new Lazy<ConnectionMultiplexer>
    (() =>
    {
        // Connect to a locally running instance of Redis to simulate a local cache emulator experience.
        return ConnectionMultiplexer.Connect("127.0.0.1:6379");
    });

    public static ConnectionMultiplexer Connection
    {
        get
        {
            return lazyConnection.Value;
        }
    }

必要に応じて、オンラインの Azure Cache for Redis の既定のキャッシュ設定とより正確に一致するように、redis.conf ファイルを構成します。You can optionally configure a redis.conf file to more closely match the default cache settings for your online Azure Cache for Redis if desired.

Redis コマンドの実行方法How can I run Redis commands?

Azure Cache for Redis でサポートされない Redis コマンドに関するセクションに示されているコマンドを除き、Redis コマンドのページに示されているすべてのコマンドを使用できます。You can use any of the commands listed at Redis commands except for the commands listed at Redis commands not supported in Azure Cache for Redis. Redis コマンドを実行するにはオプションがいくつかあります。You have several options to run Redis commands.

  • Standard または Premium キャッシュがある場合は、 Redis コンソールを使用して Redis コマンドを実行できます。If you have a Standard or Premium cache, you can run Redis commands using the Redis Console. Redis コンソールは、Azure Portal で Redis コマンドを安全に実行するための方法です。The Redis console provides a secure way to run Redis commands in the Azure portal.
  • Redis コマンド ライン ツールを使用することもできます。You can also use the Redis command-line tools. これらを使用するには、次の手順を実行します。To use them, perform the following steps:
  • Redis コマンド ライン ツールをダウンロードします。Download the Redis command-line tools.
  • redis-cli.exeを使用してキャッシュに接続します。Connect to the cache using redis-cli.exe. 次の例に示すように、-h スイッチを使用してキャッシュ エンドポイントを渡し、-a を使用してキーを渡します。Pass in the cache endpoint using the -h switch and the key using -a as shown in the following example:
  • redis-cli -h <Azure Cache for Redis name>.redis.cache.windows.net -a <key>

注意

Redis コマンド ライン ツールは SSL ポートを使用できません。ただし、stunnel などのユーティリティを使用すると、ツールを SSL ポートに安全に接続することができます。詳細については、ブログ記事「Azure Cache for Redis で Redis コマンドライン ツールを使用する方法」の記事を参照してください。The Redis command-line tools do not work with the SSL port, but you can use a utility such as stunnel to securely connect the tools to the SSL port by following the directions in the How to use the Redis command-line tool with Azure Cache for Redis article.

他のいくつかの Azure サービスと異なり Azure Cache for Redis の MSDN クラス ライブラリ リファレンスが提供されない理由Why doesn't Azure Cache for Redis have an MSDN class library reference like some of the other Azure services?

Microsoft Azure Cache for Redis は、広く支持されているオープン ソースの Azure Cache for Redis がベースとなっています。Microsoft Azure Cache for Redis is based on the popular open-source Azure Cache for Redis. これには、多くのプログラミング言語に対するさまざまな Redis クライアント によってアクセスできます。It can be accessed by a wide variety of Redis clients for many programming languages. 各クライアントは、Redis コマンドを使用して Azure Cache for Redis インスタンスを呼び出す独自の API を持ちます。Each client has its own API that makes calls to the Azure Cache for Redis instance using Redis commands.

クライアントはそれぞれ異なるため、MSDN には単独の一元的なクラス リファレンスは用意されていません。各クライアントで独自のリファレンス ドキュメントが管理されています。Because each client is different, there is not one centralized class reference on MSDN, and each client maintains its own reference documentation. リファレンス ドキュメントのほかに、チュートリアルもいくつか用意されています。チュートリアルでは、さまざまな言語とキャッシュ クライアントを使用して Azure Cache for Redis を使用する方法について説明します。In addition to the reference documentation, there are several tutorials showing how to get started with Azure Cache for Redis using different languages and cache clients. これらのチュートリアルについては、Azure Cache for Redis の使用方法に関するページとその関連記事を目次から見つけて参照してください。To access these tutorials, see How to use Azure Cache for Redis and it's sibling articles in the table of contents.

Azure Cache for Redis を PHP セッションのキャッシュとして使用できるかCan I use Azure Cache for Redis as a PHP session cache?

はい。Azure Cache for Redis を PHP セッションのキャッシュとして使用するには、session.save_path に Azure Cache for Redis インスタンスへの接続文字列を指定します。Yes, to use Azure Cache for Redis as a PHP session cache, specify the connection string to your Azure Cache for Redis instance in session.save_path.

重要

Azure Cache for Redis を PHP セッションのキャッシュとして使用する場合、次の例に示すように、キャッシュへの接続に使用するセキュリティ キーを URL エンコードする必要があります。When using Azure Cache for Redis as a PHP session cache, you must URL encode the security key used to connect to the cache, as shown in the following example:

session.save_path = "tcp://mycache.redis.cache.windows.net:6379?auth=<url encoded primary or secondary key here>";

キーが URL エンコードされていない場合、次のようなメッセージの例外が表示されます。Failed to parse session.save_pathIf the key is not URL encoded, you may receive an exception with a message like: Failed to parse session.save_path

Azure Cache for Redis を PhpRedis クライアントで PHP セッションのキャッシュとして使用する方法の詳細については、PHP セッション ハンドラーに関するページを参照してください。For more information about using Azure Cache for Redis as a PHP session cache with the PhpRedis client, see PHP Session handler.

Redis データベースとはWhat are Redis databases?

Redis データベースとは、単に同じ Redis インスタンス内でデータを論理的に切り離したものです。Redis Databases are just a logical separation of data within the same Redis instance. キャッシュ メモリは、すべてのデータベースで共有され、特定のデータベースの実際のメモリ使用量は、そのデータベースに格納されているキー/値によって異なります。The cache memory is shared between all the databases and actual memory consumption of a given database depends on the keys/values stored in that database. たとえば、C6 キャッシュは 53 GB のメモリを備え、P5 の場合は 120 GB になります。For example, a C6 cache has 53 GB of memory, and a P5 has 120 GB. この 53 GB/120 GB すべてを 1 つのデータベースに配置することも、複数のデータベースに分割することもできます。You can choose to put all 53 GB / 120 GB into one database or you can split it up between multiple databases.

注意

クラスタリングを有効にして Premium Azure Cache for Redis を使用すると、使用できるのはデータベース 0 だけになります。When using a Premium Azure Cache for Redis with clustering enabled, only database 0 is available. これは Redis に固有の制限事項です。Azure Cache for Redis の制限事項ではありません。This limitation is an intrinsic Redis limitation and is not specific to Azure Cache for Redis. 詳細については、「 クラスタリングを使用するためにクライアント アプリケーションを変更する必要がありますかFor more information, see Do I need to make any changes to my client application to use clustering?

Redis への接続に非 SSL ポートを有効にする必要がある状況When should I enable the non-SSL port for connecting to Redis?

Redis サーバーはネイティブで SSL をサポートしませんが、Azure Cache for Redis では SSL がサポートされます。Redis server does not natively support SSL, but Azure Cache for Redis does. Azure Cache for Redis に接続しようとしていて、クライアントが StackExchange.Redis のように SSL をサポートしている場合は、SSL を使用する必要があります。If you are connecting to Azure Cache for Redis and your client supports SSL, like StackExchange.Redis, then you should use SSL.

注意

既定では、新しい Azure Cache for Redis インスタンスの SSL 以外のポートは無効になっています。The non-SSL port is disabled by default for new Azure Cache for Redis instances. クライアントが SSL をサポートしていない場合は、Azure Cache for Redis でのキャッシュの構成に関するページの「アクセス ポート」セクションの指示に従って、非 SSL ポートを有効にする必要があります。If your client does not support SSL, then you must enable the non-SSL port by following the directions in the Access ports section of the Configure a cache in Azure Cache for Redis article.

redis-cli などの Redis ツールは SSL ポートを使用できません。ただし、stunnel などのユーティリティを使用すると、ツールを SSL ポートに安全に接続することができます。詳細については、ブログ記事「Announcing ASP.NET Session State Provider for Redis Preview Release (Redis 向け ASP.NET セッション状態プロバイダー プレビュー リリースの発表)」を参照してください。Redis tools such as redis-cli do not work with the SSL port, but you can use a utility such as stunnel to securely connect the tools to the SSL port by following the directions in the Announcing ASP.NET Session State Provider for Redis Preview Release blog post.

Redis ツールのダウンロードの詳細については、「 Redis コマンドの実行方法 」セクションを参照してください。For instructions on downloading the Redis tools, see the How can I run Redis commands? section.

いくつかの運用上のベスト プラクティスについてWhat are some production best practices?

StackExchange.Redis のベスト プラクティスStackExchange.Redis best practices

  • AbortConnect を "false" に設定してから、ConnectionMultiplexer による自動再接続を待ってください。Set AbortConnect to false, then let the ConnectionMultiplexer reconnect automatically. 詳細についてはこちらをご覧くださいSee here for details.
  • ConnectionMultiplexer は再利用し、要求ごとに新しく作成しないようにしてください。Reuse the ConnectionMultiplexer - do not create a new one for each request. こちらに記載されている Lazy<ConnectionMultiplexer> パターンをお勧めします。The Lazy<ConnectionMultiplexer> pattern shown here is recommended.
  • 値が小さいほど Redis のパフォーマンスは向上するため、大きなデータは複数のキーに分割することを検討してください。Redis works best with smaller values, so consider chopping up bigger data into multiple keys. この Redis に関する議論では、100 KB は大きいと見なされています。In this Redis discussion, 100 kb is considered large. 値が大きい場合に生じる可能性のある問題の例については、 こちらの記事 を参照してください。Read this article for an example problem that can be caused by large values.
  • タイムアウトが起こらないように ThreadPool の設定 を構成してください。Configure your ThreadPool settings to avoid timeouts.
  • connectTimeout については既定の 5 秒以上を使用してください。Use at least the default connectTimeout of 5 seconds. この間隔により、ネットワーク ブリップが発生した場合に接続を再確立するための十分な時間が StackExchange.Redis に与えられます。This interval gives StackExchange.Redis sufficient time to re-establish the connection in the event of a network blip.
  • 実行中のさまざまな操作に関連するパフォーマンス コストを把握してください。Be aware of the performance costs associated with different operations you are running. たとえば、 KEYS コマンドは O(n) 操作であるため、使用しないでください。For instance, the KEYS command is an O(n) operation and should be avoided. redis.io のサイト に、Redis でサポートされる各操作の時間計算量の詳細が記載されています。The redis.io site has details around the time complexity for each operation that it supports. 各コマンドをクリックして、操作ごとの時間計算量を確認してください。Click each command to see the complexity for each operation.

構成と概念Configuration and concepts

  • 実稼働システムでは Standard レベルまたは Premium レベルを使用する。Use Standard or Premium Tier for Production systems. Basic レベルは単一ノード システムであり、データ レプリケーション機能や SLA がありません。The Basic Tier is a single node system with no data replication and no SLA. また、C1 以上のキャッシュを使用してください。Also, use at least a C1 cache. 通常、C0 キャッシュは単純な開発/テスト シナリオで使用されます。C0 caches are typically used for simple dev/test scenarios.
  • Redis は インメモリ データ ストアであることに注意してください。Remember that Redis is an In-Memory data store. こちらの記事 を参照し、データが失われる可能性のあるシナリオについて把握してください。Read this article so that you are aware of scenarios where data loss can occur.
  • 修正プログラムの適用やフェールオーバーによる接続の中断に対応できるようなシステムを開発する。Develop your system such that it can handle connection blips due to patching and failover.

パフォーマンス テストPerformance testing

  • 独自のパフォーマンス テストを作成する前に、 redis-benchmark.exe を使用して実現可能なスループットを確認してください。Start by using redis-benchmark.exe to get a feel for possible throughput before writing your own perf tests. redis-benchmark では SSL はサポートされていないため、テストを行うには、Azure Portal で非 SSL ポートを有効にする必要があります。Because redis-benchmark does not support SSL, you must enable the Non-SSL port through the Azure portal before you run the test. 例については、「 キャッシュのベンチマークを実行およびテストする方法For examples, see How can I benchmark and test the performance of my cache?
  • テストに使用するクライアント VM は、Azure Cache for Redis インスタンスと同じリージョンにある必要があります。The client VM used for testing should be in the same region as your Azure Cache for Redis instance.
  • Dv2 VM シリーズはハードウェアが強力であり、最良の結果が得られるため、クライアントにはこれらのシリーズを使用することをお勧めします。We recommend using Dv2 VM Series for your client as they have better hardware and should give the best results.
  • クライアント VM については、コンピューティング能力と帯域幅がテスト対象のキャッシュと同等以上であるものを選択してください。Make sure your client VM you choose has at least as much computing and bandwidth capability as the cache you are testing.
  • Windows を使用している場合は、クライアント コンピューターで VRSS を有効にしてください。Enable VRSS on the client machine if you are on Windows. 詳細についてはこちらをご覧くださいSee here for details.
  • Premium レベルでは、Redis インスタンスが CPU およびネットワークの両方が優れたハードウェアで実行されるため、ネットワーク待機時間およびスループットが改善します。Premium tier Redis instances have better network latency and throughput because they are running on better hardware for both CPU and Network.

一般的な Redis コマンドの使用に関するいくつかの考慮事項What are some of the considerations when using common Redis commands?

  • 完了するのに時間がかかる特定の Redis コマンドについては、その影響を完全に理解しないまま使用するのは避けてください。Avoid using certain Redis commands that take a long time to complete, unless you fully understand the impact of these commands. たとえば、運用環境で KEYS コマンドを実行しないでください。For example, do not run the KEYS command in production. キーの数によっては、復帰に時間がかかる可能性があります。Depending on the number of keys, it could take a long time to return. Redis はシングル スレッド サーバーであり、一度に 1 つずつコマンドを処理します。Redis is a single-threaded server and it processes commands one at a time. KEYS の後に他のコマンドが発行されている場合、それらのコマンドは Redis によって KEYS コマンドが処理されるまで処理されません。If you have other commands issued after KEYS, they will not be processed until Redis processes the KEYS command. redis.io のサイト に、Redis でサポートされる各操作の時間計算量の詳細が記載されています。The redis.io site has details around the time complexity for each operation that it supports. 各コマンドをクリックして、操作ごとの時間計算量を確認してください。Click each command to see the complexity for each operation.
  • キー サイズ - 小さなキー/値と大きなキー/値のどちらを使用するか。Key sizes - should I use small key/values or large key/values? これはシナリオによって異なります。It depends on the scenario. ご利用のシナリオで、より大きなキーが必要な場合は、ConnectionTimeout を調整してから、値を再度試して再試行ロジックを調整することができます。If your scenario requires larger keys, you can adjust the ConnectionTimeout, then retry values and adjust your retry logic. Redis サーバーの観点からは、値が小さいほど、パフォーマンスは向上します。From a Redis server perspective, smaller values give better performance.
  • これらの考慮事項は、サイズの大きな値を Redis に格納できないという意味ではありません。次の点を考慮する必要があります。These considerations don't mean that you can't store larger values in Redis; you must be aware of the following considerations. 待機時間は長くなります。Latencies will be higher. サイズの大きなデータ セットとサイズの小さなデータ セットがある場合は、前の「StackExchange.Redis 構成オプションについて」に説明したように、それぞれ異なるタイムアウト値と再試行回数が構成された複数の ConnectionMultiplexer インスタンスを使用できます。If you have one set of data that is larger and one that is smaller, you can use multiple ConnectionMultiplexer instances, each configured with a different set of timeout and retry values, as described in the previous What do the StackExchange.Redis configuration options do section.

キャッシュのベンチマークを実行およびテストする方法How can I benchmark and test the performance of my cache?

  • キャッシュ診断の有効化によってキャッシュの正常性を監視できるようにします。Enable cache diagnostics so you can monitor the health of your cache. Azure Portal でメトリックを表示できますが、任意のツールを使用して、メトリックを ダウンロードして確認 することも可能です。You can view the metrics in the Azure portal and you can also download and review them using the tools of your choice.
  • redis-benchmark.exe を使用して Redis サーバーのロード テストを実行できます。You can use redis-benchmark.exe to load test your Redis server.
  • ロード テスト用のクライアントと Azure Cache for Redis が同じリージョン内にあることを確認します。Ensure that the load testing client and the Azure Cache for Redis are in the same region.
  • redis-cli.exe を使用し、INFO コマンドを使用してキャッシュを監視します。Use redis-cli.exe and monitor the cache using the INFO command.
  • 負荷が高いことが原因でメモリの断片化が発生している場合は、キャッシュのサイズをスケール アップする必要があります。If your load is causing high memory fragmentation, you should scale up to a larger cache size.
  • Redis ツールのダウンロードの詳細については、「 Redis コマンドの実行方法 」セクションを参照してください。For instructions on downloading the Redis tools, see the How can I run Redis commands? section.

以下のコマンドは、redis-benchmark.exe の使用例です。The following commands provide an example of using redis-benchmark.exe. 正確な結果を得るために、以下のコマンドはキャッシュと同じリージョンにある VM で実行してください。For accurate results, run these commands from a VM in the same region as your cache.

  • 1 k ペイロードを使用してパイプライン SET 要求をテストするTest Pipelined SET requests using a 1k payload

    redis-benchmark.exe -h **yourcache**.redis.cache.windows.net -a **yourAccesskey** -t SET -n 1000000 -d 1024 -P 50

  • 1 k ペイロードを使用してパイプライン GET 要求をテストする。Test Pipelined GET requests using a 1k payload. 注:まず上の SET テストを実行し、キャッシュにデータを格納してください。NOTE: Run the SET test shown above first to populate cache

    redis-benchmark.exe -h **yourcache**.redis.cache.windows.net -a **yourAccesskey** -t GET -n 1000000 -d 1024 -P 50

ThreadPool 拡大の重要な詳細情報Important details about ThreadPool growth

CLR ThreadPool には、"Worker" スレッドと "I/O Completion Port" (IOCP) スレッドの 2 種類があります。The CLR ThreadPool has two types of threads - "Worker" and "I/O Completion Port" (IOCP) threads.

  • Task.Run(…) メソッドや ThreadPool.QueueUserWorkItem(…) メソッドの処理などには、Worker スレッドが使用されます。Worker threads are used for things like processing the Task.Run(…), or ThreadPool.QueueUserWorkItem(…) methods. これらのスレッドは、バック グラウンド スレッドで作業が発生する必要がある場合に、CLR でさまざまなコンポーネントによっても使用されます。These threads are also used by various components in the CLR when work needs to happen on a background thread.
  • IOCP スレッドは、ネットワークからの読み取りの場合など、非同期 IO が発生する場合に使用されます。IOCP threads are used when asynchronous IO happens, such as when reading from the network.

スレッド プールは、各種のスレッドについて「最小」設定に達するまで、新しい worker スレッドまたは I/O 完了スレッドをオンデマンドで (スロットルなしで) 提供します。The thread pool provides new worker threads or I/O completion threads on demand (without any throttling) until it reaches the "Minimum" setting for each type of thread. 既定では、スレッドの最小数はシステム上のプロセッサの数に設定されます。By default, the minimum number of threads is set to the number of processors on a system.

既存の (ビジー) スレッドの数がスレッドの "最小" 数に達すると、ThreadPool は新しいスレッドを挿入する速度を、500 ミリ秒ごとに 1 スレッドへとスロットルします。Once the number of existing (busy) threads hits the "minimum" number of threads, the ThreadPool will throttle the rate at which it injects new threads to one thread per 500 milliseconds. 通常、ご利用のシステムで、IOCP スレッドを必要とする作業のバーストが取得された場合、その作業は高速に処理されます。Typically, if your system gets a burst of work needing an IOCP thread, it will process that work quickly. ただし、作業のバーストが構成済みの「最小」設定を超えた場合は、次の 2 つの状態のうちどちらかが発生するまで ThreadPool が待機するので、多少の遅延が生じます。However, if the burst of work is more than the configured "Minimum" setting, there will be some delay in processing some of the work as the ThreadPool waits for one of two things to happen.

  1. 既存のスレッドの 1 つが空き状態になり、作業を処理する。An existing thread becomes free to process the work.
  2. 既存のスレッドが 500 ミリ秒間空いた状態にならないと、新しいスレッドが作成されます。No existing thread becomes free for 500 ms, so a new thread is created.

基本的に、これは、ビジー スレッド数が最小スレッド数より大きい場合、ネットワーク トラフィックがアプリケーションによって処理される前に 500 ミリ秒の遅延が生じる可能性があることを意味しています。Basically, it means that when the number of Busy threads is greater than Min threads, you are likely paying a 500-ms delay before network traffic is processed by the application. また、既存のスレッドが (私の記憶によると) 15 秒を超えてアイドル状態になると、そのスレッドはクリーンアップされ、拡大と縮小のこのサイクルが繰り返されることがあります。Also, it is important to note that when an existing thread stays idle for longer than 15 seconds (based on what I remember), it will be cleaned up and this cycle of growth and shrinkage can repeat.

StackExchange.Redis (ビルド 1.0.450 以降) からのエラー メッセージの例を見れば、ThreadPool の統計情報が出力されていることがわかります (IOCP と WORKER に関する下記の詳細を参照)。If we look at an example error message from StackExchange.Redis (build 1.0.450 or later), you will see that it now prints ThreadPool statistics (see IOCP and WORKER details below).

System.TimeoutException: Timeout performing GET MyKey, inst: 2, mgr: Inactive,
queue: 6, qu: 0, qs: 6, qc: 0, wr: 0, wq: 0, in: 0, ar: 0,
IOCP: (Busy=6,Free=994,Min=4,Max=1000),
WORKER: (Busy=3,Free=997,Min=4,Max=1000)

前の例では、IOCP スレッドについて、6 つのビジー スレッドが存在し、システムは 4 つの最小スレッドを許容するように構成されていることがわかります。In the previous example, you can see that for IOCP thread there are six busy threads and the system is configured to allow four minimum threads. この場合、6 > 4 であることから、クライアントは 500 ミリ秒の遅延を 2 回検出している可能性があります。In this case, the client would have likely seen two 500-ms delays, because 6 > 4.

IOCP スレッドまたは WORKER スレッドの拡大がスロットルされた場合、StackExchange.Redis がタイムアウトになる可能性があることに注意してください。Note that StackExchange.Redis can hit timeouts if growth of either IOCP or WORKER threads gets throttled.

推奨Recommendation

この情報に基づき、顧客が IOCP スレッドと WORKER スレッドの最小構成値を既定値よりも大きく設定することを強くお勧めします。Given this information, we strongly recommend that customers set the minimum configuration value for IOCP and WORKER threads to something larger than the default value. あるアプリケーションでは適切な値であっても別のアプリケーションで高すぎたり低すぎたりする可能性があるため、これをどのような値にする必要があるかについて画一的なガイダンスを提供することはできません。We can't give one-size-fits-all guidance on what this value should be because the right value for one application will likely be too high or low for another application. この設定は複雑なアプリケーションの他の部分のパフォーマンスにも影響を与える可能性があるので、各顧客は特定のニーズに合わせてこの設定を調整する必要があります。This setting can also impact the performance of other parts of complicated applications, so each customer needs to fine-tune this setting to their specific needs. 適切な値として、まず 200 または 300 に設定し、テストして必要に応じて調整します。A good starting place is 200 or 300, then test and tweak as needed.

この設定を構成する方法How to configure this setting:

  • この設定は、global.asax.cs 内の ThreadPool.SetMinThreads (...) メソッドを使用してプログラムによって変更することをお勧めします。We recommend changing this setting programmatically by using the ThreadPool.SetMinThreads (...) method in global.asax.cs. 例:For example:
private readonly int minThreads = 200;
void Application_Start(object sender, EventArgs e)
{
    // Code that runs on application startup
    AreaRegistration.RegisterAllAreas();
    RouteConfig.RegisterRoutes(RouteTable.Routes);
    BundleConfig.RegisterBundles(BundleTable.Bundles);
    ThreadPool.SetMinThreads(minThreads, minThreads);
}

注意

このメソッドによって指定された値はグローバル設定であり、AppDomain 全体に影響を与えます。The value specified by this method is a global setting, affecting the whole AppDomain. たとえば、4 コア マシンをお持ちの場合で、実行時の minWorkerThreads および minIoThreads を CPU あたり 50 に設定したい場合は、ThreadPool.SetMinThreads(200, 200) を使用します。For example, if you have a 4-core machine and want to set minWorkerThreads and minIoThreads to 50 per CPU during run-time, you would use ThreadPool.SetMinThreads(200, 200).

  • 最小スレッド数の設定は、通常、%SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\ にある Machine.config 内の <processModel> 構成要素の下にある minIoThreads または minWorkerThreads 構成設定を使用して指定することもできます。It is also possible to specify the minimum threads setting by using the minIoThreads or minWorkerThreads configuration setting under the <processModel> configuration element in Machine.config, usually located at %SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\. この方法で最小スレッド数を設定する方法は、一般的はにお勧めできません。これはシステム全体の設定だからです。Setting the number of minimum threads in this way is generally not recommended, because it is a System-wide setting.

    注意

    この構成要素で指定される値は、 "コアごと" の設定となります。The value specified in this configuration element is a per-core setting. たとえば、4 コア マシンをお持ちの場合で、実行時の minIoThreads 設定を 200 にしたい場合は、<processModel minIoThreads="50"/> を使用します。For example, if you have a 4-core machine and want your minIoThreads setting to be 200 at runtime, you would use <processModel minIoThreads="50"/>.

StackExchange.Redis を使用するときにサーバー GC を有効にしてクライアントでのスループットを向上させるEnable server GC to get more throughput on the client when using StackExchange.Redis

StackExchange.Redis を使用するときにサーバー GC を有効にすると、クライアントが最適化され、パフォーマンスとスループットを向上させることができます。Enabling server GC can optimize the client and provide better performance and throughput when using StackExchange.Redis. サーバー GC とそれを有効にする方法の詳細については、次の記事を参照してください。For more information on server GC and how to enable it, see the following articles:

接続のパフォーマンスに関する考慮事項Performance considerations around connections

各価格レベルには、クライアント接続、メモリ、および帯域幅についてさまざまな制限があります。Each pricing tier has different limits for client connections, memory, and bandwidth. 各キャッシュのサイズが特定の接続数まで許容される一方で、Redis への各接続はそれにオーバーヘッドが関連付けられています。While each size of cache allows up to a certain number of connections, each connection to Redis has overhead associated with it. このようなオーバーヘッドの例には、TLS/SSL 暗号化の結果としての CPU とメモリの使用量があります。An example of such overhead would be CPU and memory usage as a result of TLS/SSL encryption. 指定したキャッシュ サイズの最大接続数の上限は、負荷が低いキャッシュを想定しています。The maximum connection limit for a given cache size assumes a lightly loaded cache. 接続オーバーヘッドからの読み込みに加えて、クライアントの操作からの読み込みがシステムの容量を超える場合、現在のキャッシュ サイズが接続数の上限を超えていない場合でも、キャッシュ容量の問題が発生する可能性があります。If load from connection overhead plus load from client operations exceeds capacity for the system, the cache can experience capacity issues even if you have not exceeded the connection limit for the current cache size.

各レベルの異なる接続制限について詳しくは、Azure Cache for Redis の価格についてのページを参照してください。For more information about the different connections limits for each tier, see Azure Cache for Redis pricing. 接続と他の既定の構成について詳しくは、「既定の Redis サーバー構成」をご覧ください。For more information about connections and other default configurations, see Default Redis server configuration.

キャッシュの正常性とパフォーマンスの監視方法How do I monitor the health and performance of my cache?

Microsoft Azure Cache for Redis のインスタンスは、Azure Portal で監視できます。Microsoft Azure Cache for Redis instances can be monitored in the Azure portal. メトリックの表示、メトリック グラフのスタート画面へのピン留め、監視グラフの日付と時刻の範囲のカスタマイズ、グラフのメトリックの追加と削除、特定の条件が満たされた場合のアラートの設定を行うことができます。You can view metrics, pin metrics charts to the Startboard, customize the date and time range of monitoring charts, add and remove metrics from the charts, and set alerts when certain conditions are met. 詳細については、Azure Cache for Redis の監視に関するページを参照してください。For more information, see Monitor Azure Cache for Redis.

Azure Cache for Redis の [リソース] メニューにも、キャッシュの監視およびトラブルシューティングのためのツールがいくつか含まれています。The Azure Cache for Redis Resource menu also contains several tools for monitoring and troubleshooting your caches.

  • [問題の診断と解決] では、一般的な問題と、その問題を解決するための戦略に関する情報を確認できます。Diagnose and solve problems provides information about common issues and strategies for resolving them.
  • [リソース正常性] ではリソースが監視され、そのリソースが意図したとおりに動いているかどうかが示されます。Resource health watches your resource and tells you if it's running as expected. Azure Resource Health サービスの詳細については、「 Azure Resource Health の概要」を参照してください。For more information about the Azure Resource health service, see Azure Resource health overview.
  • [新しいサポート要求] には、キャッシュのサポート要求を開くためのオプションが用意されています。New support request provides options to open a support request for your cache.

これらのツールによって、Azure Cache for Redis インスタンスの正常性を監視し、キャッシュ アプリケーションを管理できます。These tools enable you to monitor the health of your Azure Cache for Redis instances and help you manage your caching applications. Azure Redis Cache の構成方法」の「サポートおよびトラブルシューティング設定」を参照してください。For more information, see the "Support & troubleshooting settings" section of How to configure Azure Cache for Redis.

タイムアウトが発生する理由Why am I seeing timeouts?

タイムアウトは、Redis との対話に使用されているクライアントで発生します。Timeouts happen in the client that you use to talk to Redis. Redis サーバーに送信されたコマンドは、キューに格納されます。コマンドは、最終的に Redis サーバーによって取得され、実行されます。When a command is sent to the Redis server, the command is queued up and Redis server eventually picks up the command and executes it. ただし、この処理中にクライアントがタイムアウトすることがあり、その場合は呼び出し元では例外が発生します。However the client can time out during this process and if it does an exception is raised on the calling side. タイムアウトの問題のトラブルシューティングについては、クライアント側のトラブルシューティングに関するページ、および「StackExchange.Redis のタイムアウトの例外」を参照してください。For more information on troubleshooting timeout issues, see client-side troubleshooting and StackExchange.Redis timeout exceptions.

クライアントがキャッシュから切断される理由Why was my client disconnected from the cache?

キャッシュが切断される一般的な理由のいくつかを次に示します。The following are some common reason for a cache disconnect.

  • クライアント側の原因Client-side causes
    • クライアント アプリケーションが再デプロイされた。The client application was redeployed.
    • クライアント アプリケーションがスケーリング操作を実行した。The client application performed a scaling operation.
      • Cloud Services または Web Apps では、これは自動スケーリングが原因である場合があります。In the case of Cloud Services or Web Apps, this may be due to autoscaling.
    • クライアント側のネットワーク レイヤーが変更された。The networking layer on the client side changed.
    • クライアントで、またはクライアントとサーバー間のネットワーク ノードで一時的なエラーが発生した。Transient errors occurred in the client or in the network nodes between the client and the server.
    • 帯域幅のしきい値制限に達した。The bandwidth threshold limits were reached.
    • CPU バインド型の操作の完了に時間がかかった。CPU bound operations took too long to complete.
  • サーバー側の原因Server-side causes
    • Standard キャッシュ プランで、Azure Cache for Redis サービスがプライマリ ノードからセカンダリ ノードへのフェールオーバーを開始した。On the standard cache offering, the Azure Cache for Redis service initiated a fail-over from the primary node to the secondary node.
    • Azure により、キャッシュがデプロイされているインスタンスに修正プログラムが適用されていた。Azure was patching the instance where the cache was deployed
      • Redis サーバーの更新または VM の一般的なメンテナンスの場合もこれに該当します。This can be for Redis server updates or general VM maintenance.

どの Azure Cache を利用すればよいですか。Which Azure Cache offering is right for me?

重要

昨年 お知らせしたとおり、Azure Managed Cache Service と Azure In-Role Cache サービスは 2016 年 11 月 30 日で提供が終了しました。As per last year's announcement, Azure Managed Cache Service and Azure In-Role Cache service have been retired on November 30, 2016. Azure Cache for Redis の使用をお勧めします。Our recommendation is to use Azure Cache for Redis. 移行については、Managed Cache Service から Azure Cache for Redis への移行についてのページを参照してください。For information on migrating, see Migrate from Managed Cache Service to Azure Cache for Redis.

Azure Cache for RedisAzure Cache for Redis

Azure Cache for Redis は、一般公開されていて、最大サイズは 120 GB です。可用性の SLA は 99.9% です。Azure Cache for Redis is Generally Available in sizes up to 120 GB and has an availability SLA of 99.9%. 新しい Premium レベルは、最大 1.2 TB のサイズを提供し、クラスタリング、VNET、および永続化を 99.9% の SLA でサポートします。The new premium tier offers sizes up to 1.2 TB and support for clustering, VNET, and persistence, with a 99.9% SLA.

Azure Cache for Redis により、お客様は Microsoft によって管理されている、セキュリティで保護された専用の Azure Cache for Redis を使用できるようになります。Azure Cache for Redis gives customers the ability to use a secure, dedicated Azure Cache for Redis, managed by Microsoft. このサービスでは、Redis が提供する豊富な機能セットとエコシステムを利用し、Microsoft による信頼性の高いホスティングと監視を受けられます。With this offer, you get to leverage the rich feature set and ecosystem provided by Redis, and reliable hosting and monitoring from Microsoft.

キーと値のペアのみを処理する従来のキャッシュとは異なり、Redis は、データ型の性能が高いため人気があります。Unlike traditional caches that deal only with key-value pairs, Redis is popular for its highly performant data types. また、Redis は、このようなデータに対するアトミックな操作 (文字列の付加、ハッシュ内の値のインクリメント、リストへのプッシュ、積集合、和集合、および差集合の計算、並べ替えられた集合内で最高ランクのメンバーの取得など) の実行もサポートしています。Redis also supports running atomic operations on these types, like appending to a string; incrementing the value in a hash; pushing to a list; computing set intersection, union and difference; or getting the member with highest ranking in a sorted set. その他の機能として、トランザクションのサポート、パブリッシュ/サブスクライブ、Lua スクリプト、有効期限が制限されたキー、Redis を従来のキャッシュのように動作させるための構成設定があります。Other features include support for transactions, pub/sub, Lua scripting, keys with a limited time-to-live, and configuration settings to make Redis behave more like a traditional cache.

Redis を成功させているもう 1 つの重要な側面は、その周りに構築される健全で活発なオープン ソース エコシステムです。Another key aspect to Redis success is the healthy, vibrant open- source ecosystem built around it. また、その環境を複数の言語で使用できる多様な Redis クライアントに反映します。This is reflected in the diverse set of Redis clients available across multiple languages. このエコシステムと幅広いクライアントにより、Azure 内部に構築するほぼすべてのワークロードで Azure Cache for Redis を使用できます。This ecosystem and wide range of clients allow Azure Cache for Redis to be used by nearly any workload you would build inside of Azure.

Azure Cache for Redis の使用を開始することの詳細については、「Azure Cache for Redis の使用方法」と、Azure Cache for Redis のドキュメントに関するページを参照してください。For more information about getting started with Azure Cache for Redis, see How to Use Azure Cache for Redis and Azure Cache for Redis documentation.

Managed Cache ServiceManaged Cache service

Managed Cache Service は 2016 年 11 月 30 日に終了しました。Managed Cache service was retired November 30, 2016.

アーカイブされたドキュメントを参照するには、アーカイブされた Managed Cache Service に関するドキュメントを参照してください。To view archived documentation, see Archived Managed Cache Service Documentation.

In-Role CacheIn-Role Cache

In-Role Cache は 2016 年 11 月 30 日に終了しました。In-Role Cache was retired November 30, 2016.

アーカイブされたドキュメントを参照するには、アーカイブされた In-Role Cache に関するドキュメントを参照してください。To view archived documentation, see Archived In-Role Cache Documentation.