Azure Cosmos DB 統合キャッシュ - 概要
適用対象: 
NoSQL
Azure Cosmos DB 統合キャッシュはインメモリ キャッシュで、要求のボリュームが拡大するのに伴い、コストを管理しやすくし、低遅延を実現するのに役立ちます。 統合キャッシュは簡単に設定できるため、キャッシュの無効化やバックエンド インフラストラクチャの管理のためのカスタム コードの作成に時間を費やす必要はありません。 統合キャッシュでは、Azure Cosmos DB アカウント内の専用ゲートウェイが使用されます。 専用ゲートウェイをプロビジョニングする場合は、ワークロードに必要なコアとメモリの数に基づいて、ノードの数とノード サイズを選択できます。 各専用ゲートウェイ ノードには、他のノードとは別の統合キャッシュがあります。
統合キャッシュは、専用ゲートウェイ内で自動的に構成されます。 統合キャッシュには、次の 2 つの部分があります。
- ポイント読み取り用の項目キャッシュ
- クエリ用のクエリ キャッシュ
統合キャッシュは、最も使われていない (LRU) 削除ポリシーを備えた、リードスルーとライトスルーのキャッシュです。 項目キャッシュとクエリ キャッシュは統合キャッシュ内で同じ容量を共有し、LRU 削除ポリシーが両方に適用されます。 データは、ポイント読み取りとクエリのどちらであるかに関係なく、最後に使用された日時に厳密に基づいてキャッシュから削除されます。 各ノード内のキャッシュされたデータは、その特定のノードから最近書き込まれたか読み取られた データによって異なります。 項目またはクエリが 1 つのノードにキャッシュされている場合、必ずしも他のノードにキャッシュされているとは限りません。
Note
統合キャッシュについてフィードバックはありますか? ご意見をお待ちしています。 ぜひ、Azure Cosmos DB エンジニアリング チーム (cosmoscachefeedback@microsoft.com) まで直接お寄せください。
統合キャッシュから利点を得られるワークロード
統合キャッシュの主な目的は、読み取り負荷の高いワークロードのコストを削減することです。 Azure Cosmos DB ならキャッシュなしでも既に高速であるため、低遅延であることは、便利ではありますが統合キャッシュの主な利点ではありません。
統合キャッシュにヒットするポイント読み取りとクエリの RU 料金は 0 になります。 バックエンド データベースからの読み取りに比べて、キャッシュ ヒットでは操作あたりのコストがはるかに低くなります。
次の特性に一致するワークロードでは、統合キャッシュがコストの削減に役立つかどうかを評価する必要があります。
- 読み取り負荷の高いワークロード
- 大きな項目に対して繰り返される多数のポイント読み取り
- 繰り返される多数の高 RU クエリ
- 読み取り用のホット パーティション キー
期待される削減効果の中でも最大の要素は、読み取りが繰り返される度合いです。 ワークロードで、同じポイント読み取りまたはクエリが短時間で絶えず実行される場合は、統合キャッシュの候補として最適です。 繰り返される読み取りに統合キャッシュを使用する場合は、最初の読み取りに RU を使用するだけです。 同じ専用ゲートウェイ ノードを介してルーティングされる後続の読み取り (MaxIntegratedCacheStaleness 期間内にあり、データが削除されていない場合) では、スループットは使用されません。
次のような一部のワークロードでは、統合キャッシュを考慮すべきではありません。
- 書き込み負荷の高いワークロード
- めったに繰り返されないポイント読み取りまたはクエリ
- 変更フィードを読み取るワークロード
項目キャッシュ
項目キャッシュは、ポイント読み取り (項目 ID とパーティション キーに基づくキー/値の検索) に使用されます。
項目キャッシュの設定
- 新しい書き込み、更新、および削除は、要求がルーティングされるノードの項目キャッシュに自動的に設定されます
- ポイント読み取り要求の項目のうち、要求がルーティングされるノードのキャッシュに項目がまだ存在しない場合 (キャッシュ ミス)、項目キャッシュに追加されます
- ReadMany などの複数のアイテムに対する読み取り要求は、個々のアイテムとしてのアイテム キャッシュではなく、セットとしてクエリ キャッシュに入力されます。
- トランザクション バッチの一部、または一括モードの要求は、項目キャッシュに設定されません
項目キャッシュの無効化と削除
各ノードには独立したキャッシュがあるため、1 つのノードのキャッシュでは項目が無効化または削除され、他のノードでは削除されない可能性があります。 特定のノードのキャッシュ内の項目は、次の条件に基づいて無効になり、削除されます。
- 項目の更新または削除
- 最も使われていない (LRU)
- キャッシュの保有時間 (つまり
MaxIntegratedCacheStaleness)
クエリ キャッシュ
クエリ キャッシュは、クエリをキャッシュするために使用されます。 クエリ キャッシュにより、クエリはキーと値の参照に変換されます。この場合、キーはクエリ テキスト、値はクエリ結果になります。 統合キャッシュにはクエリ エンジンがなく、各クエリのキーと値の参照のみが格納されます。 クエリ結果はセットとして保存され、キャッシュは個々の項目を追跡しません。 指定された項目は、複数のクエリの結果セットに表示される場合、クエリ キャッシュに複数回保存できます。 クエリの統合キャッシュの最大整合性制約に達し、クエリがバックエンド データベースから提供されない限り、基になる項目の更新はクエリ結果に反映されません。
クエリ キャッシュの設定
- ルーティングされたノードで、キャッシュにそのクエリの結果がない場合 (キャッシュミス)、そのクエリはバックエンドに送信されます。 クエリが実行された後、そのクエリの結果がキャッシュに格納されます
- 形状は同じだが、結果に影響を与えるパラメーターまたは要求オプション (最大項目数など) が異なるクエリは、独自のキー/値ペアとして保存されます
- ReadMany などの複数のアイテムに対する読み込み要求は、クエリ キャッシュに入力されます。 ReadMany の結果はセットとして格納され、異なる入力を持つ要求はそれぞれのキーと値のペアとして格納されます。
クエリ キャッシュの削除
クエリ キャッシュの削除は、要求がルーティングされたノードに基づいています。 クエリが 1 つのノードで削除または更新され、他のノードでは削除されない可能性があります。
- 最も使われていない (LRU)
- キャッシュの保有時間 (つまり
MaxIntegratedCacheStaleness)
クエリ キャッシュの操作
クエリの結果が複数のページにわたる場合でも、クエリ キャッシュを操作する際に特別なコードは不要です。 クエリが統合キャッシュにヒットするか、バックエンドのクエリ エンジンで実行されているかにかかわらず、クエリの改ページのベスト プラクティスとコードは同じです。
クエリ キャッシュでは、クエリの後続トークンが自動的にキャッシュされます (該当する場合)。 結果が複数のページにわたるクエリがある場合、統合キャッシュに格納されているすべてのページで、RU 料金は 0 になります。 クエリ結果の後続のページでバックエンドでの実行が必要な場合でも、前のページからの後続トークンがあるため、前の作業の重複を避けることができます。
重要
異なる専用ゲートウェイ ノード内の統合キャッシュ インスタンスには、互いに独立したキャッシュが備わっています。 データは、1 つのノード内にキャッシュされている場合、他のノードにもキャッシュされているとは限りません。 同じクエリの複数のページが、同じ専用ゲートウェイ ノードにルーティングされるとは限りません。
統合キャッシュの一貫性
統合キャッシュでは、セッションと最終的な整合性による読み取り要求のみがサポートされます。 一貫したプレフィックス、有界整合性制約、厳密な一貫性が設定されている読み取りの場合、統合キャッシュはバイパスされ、バックエンドで処理されます。
すべての読み取りのセッションまたは最終的な整合性のいずれかを構成する最も簡単な方法は、アカウントレベルでこれを設定することです。 ただし、一部の読み取りにのみ特定の整合性を設定する場合は、要求レベルで整合性を構成することもできます。
注意
他の整合性を使用する書き込み要求もキャッシュに設定されますが、キャッシュから読み取るには、要求にセッションまたは最終的な整合性が必要です。
"セッション" 整合性
セッション整合性は、1 つのリージョンのアプリケーションと世界中に分散された Azure Cosmos DB アカウントの両方で最も広く使用されている整合性レベルです。 セッションの整合性を使用して、単一のクライアント セッションで独自の書き込みを読み取ることができます。 一致するセッション トークンがないセッション整合性を持つ読み取りでは、RU 料金が発生します。 これには、有効なセッション トークンを明示的に渡さない限り、クライアント アプリケーションの起動時または再起動時の特定の項目またはクエリに対する最初の要求が含まれます。 統合されたキャッシュを使用すると、書き込みを実行しているセッションの外部のクライアントは、最終的な整合性を確認できます。
MaxIntegratedCacheStaleness
MaxIntegratedCacheStaleness は、選択した整合性に関係なく、キャッシュされたポイントの読み取りとクエリに対して許容される最大の staleness です。 MaxIntegratedCacheStaleness は、要求レベルで構成できます。 たとえば、MaxIntegratedCacheStaleness を 2 時間に設定した場合、データの経過時間が 2 時間未満であれば、要求からは、キャッシュされているデータのみが返されます。 繰り返し読み取りで統合キャッシュを使用する可能性を高めるには、MaxIntegratedCacheStaleness を、ビジネス要件で許容される限り最大の長さに設定する必要があります。
MaxIntegratedCacheStaleness は、最終的にキャッシュにデータを取り込む要求で構成されている場合、その要求がキャッシュされる期間には影響しません。 MaxIntegratedCacheStaleness では、キャッシュされたデータを読み取ろうとするときに整合性が適用されます。 グローバル TTL またはキャッシュ リテンション期間設定がないため、統合キャッシュがいっぱいであるか、現在キャッシュされているエントリの経過時間よりも短い MaxIntegratedCacheStaleness で新しい読み取りが実行された場合にのみ、データがキャッシュから削除されます。
これは、ほとんどのキャッシュの動作方法と比べて改善された点であり、次の他のカスタマイズが可能になります。
- ポイント読み取りまたはクエリごとに異なる失効期限要件を設定できます。
- 同じポイント読み取りまたはクエリを実行する場合でも、異なるクライアントは、異なる
MaxIntegratedCacheStaleness値を構成できます。 - キャッシュされたデータの読み取りの整合性を変更した場合、
MaxIntegratedCacheStalenessを変更すると読み取りの整合性に即座に影響します。
Note
最小の MaxIntegratedCacheStaleness の値は 0 で、最大値は 10 年です。 明示的に構成されない場合、MaxIntegratedCacheStaleness の既定値は 5 分です。
MaxIntegratedCacheStaleness パラメーターをより深く理解するために、次の例について考えてみましょう。
| 時刻 | Request | Response |
|---|---|---|
| t = 0 sec | MaxIntegratedCacheStaleness = 30 秒でクエリ A を実行する | バックエンド データベースから結果 (通常の RU 料金) が返され、キャッシュに設定される |
| t = 0 sec | MaxIntegratedCacheStaleness = 60 秒でクエリ B を実行する | バックエンド データベースから結果 (通常の RU 料金) が返され、キャッシュに設定される |
| t = 20 sec | MaxIntegratedCacheStaleness = 30 秒でクエリ A を実行する | 統合キャッシュから結果 (0 RU 料金) が返される |
| t = 20 sec | MaxIntegratedCacheStaleness = 60 秒でクエリ B を実行する | 統合キャッシュから結果 (0 RU 料金) が返される |
| t = 40 sec | MaxIntegratedCacheStaleness = 30 秒でクエリ A を実行する | バックエンド データベースから結果 (通常の RU 料金) が返され、キャッシュが更新される |
| t = 40 sec | MaxIntegratedCacheStaleness = 60 秒でクエリ B を実行する | 統合キャッシュから結果 (0 RU 料金) が返される |
| t = 50 sec | MaxIntegratedCacheStaleness = 20 秒でクエリ B を実行する | バックエンド データベースから結果 (通常の RU 料金) が返され、キャッシュが更新される |
MaxIntegratedCacheStaleness の構成の詳細情報。
統合キャッシュをバイパスする
統合キャッシュには、プロビジョニングされた専用ゲートウェイ SKU によって決まる制限されたストレージ容量があります。 既定では、専用ゲートウェイ接続文字列を使って構成されたクライアントからのすべての要求は統合キャッシュを通過し、キャッシュ領域を占有します。 統合キャッシュ要求のバイパス オプションを使って、キャッシュされる項目とクエリを制御できます。 この要求オプションは、項目の書き込みまたは読み取り要求の頻繁な繰り返しが予期されない場合に役立ちます。 アクセス頻度が低い項目の統合キャッシュをバイパスすると、繰り返しが多い項目のためのキャッシュ領域を節約し、RU 節約の可能性を高め、立ち退きを減らすことができます。 キャッシュをバイパスする要求は、引き続き専用ゲートウェイを介してルーティングされます。 これらの要求はバックエンドから処理され、RU コストが含まれます。
メトリック
統合キャッシュについていくつかの主要な DedicatedGateway および IntegratedCache メトリックを監視することは有用です。 これらのメトリックの詳細については、「サポート対象の Microsoft.DocumentDB/DatabaseAccounts のメトリック」を参照してください。
既定では、Azure portal の ([メトリック (クラシック)] ではなく) [メトリック] から、既存のすべてのメトリックを使用できます。
メトリックは、すべての専用ゲートウェイ ノード全体の平均、最大、または合計のいずれかです。 たとえば、5 つのノードが含まれる専用ゲートウェイ クラスターをプロビジョニングする場合、メトリックには 5 つのすべてのノード全体の集計値が反映されます。 個々のノードのメトリック値を特定することはできません。
一般的な問題のトラブルシューティング
次の例は、いくつかの一般的なシナリオでのデバッグ方法を示しています。
アプリケーションが専用ゲートウェイを使用しているかどうかを判断できない
DedicatedGatewayRequests を確認します。 このメトリックには、統合キャッシュにヒットするかどうかに関係なく、専用ゲートウェイを使用するすべての要求が含まれています。 アプリケーションが標準ゲートウェイを使っているか、元の接続文字列で直接モードを使っている場合、エラー メッセージは表示されませんが、DedicatedGatewayRequests はゼロになります。 アプリケーションが専用ゲートウェイ接続文字列で直接モードを使っている場合は、少数の DedicatedGatewayRequests が確認される可能性があります。
要求が統合キャッシュにヒットしているどうかを判断できない
IntegratedCacheItemHitRate と IntegratedCacheQueryHitRate を確認します。 これらの値が両方とも 0 の場合、要求は統合キャッシュにヒットしていません。 専用のゲートウェイ接続文字列を使っていること、ゲートウェイ モードで接続していること、セッションまたは最終的な整合性を使っていることを確認します。
専用ゲートウェイが小さすぎるかどうかを確認したい
IntegratedCacheItemHitRate と IntegratedCacheQueryHitRate を確認します。 大きい値 (たとえば、0.7 から 0.8 より大きい) は、専用ゲートウェイが十分な大きさであることを示しています。
IntegratedCacheItemHitRate または IntegratedCacheQueryHitRate が小さい場合は、IntegratedCacheEvictedEntriesSize を確認します。 IntegratedCacheEvictedEntriesSize が高い場合は、専用ゲートウェイのサイズを大きくした方がよい可能性があります。 実験するには、専用ゲートウェイのサイズを増やし、新しい IntegratedCacheItemHitRate および IntegratedCacheQueryHitRate を比較します。 専用ゲートウェイのサイズを大きくしても、IntegratedCacheItemHitRate または IntegratedCacheQueryHitRate が改善されない場合、統合キャッシュが効果を発揮するのに十分な回数、読み取りが繰り返されないことがあります。
専用ゲートウェイが大きすぎるかどうかを確認したい
専用ゲートウェイが大きすぎるかどうかを測定するのは、専用ゲートウェイが小さすぎるかどうかを測定するよりも困難です。 一般に、専用ゲートウェイのサイズは、小さい状態から始めて、IntegratedCacheItemHitRate および IntegratedCacheQueryHitRate が改善されなくなるまで徐々に大きくしていきます。 場合によっては、2 つのキャッシュ ヒット メトリックの両方ではなく、一方のみが重要になることがあります。 たとえば、ワークロードがポイント読み取りではなく主にクエリである場合、IntegratedCacheQueryHitRate の方が IntegratedCacheItemHitRate よりもはるかに重要です。
LRU ではなく MaxIntegratedCacheStaleness を超過したことが原因でほとんどのデータがキャッシュから削除される場合は、キャッシュが必要以上に大きい可能性があります。 IntegratedCacheItemExpirationCount および IntegratedCacheQueryExpirationCount の合計が IntegratedCacheEvictedEntriesSize とほぼ同じ大きさの場合は、専用ゲートウェイのサイズを小さくして実験を行い、パフォーマンスを比較できます。
専用ゲートウェイ ノードを追加する必要があるかどうかを知りたい
場合によっては、待機時間が予想外に長い場合、専用ゲートウェイ ノードのサイズではなく、数を増加することが必要になります。 DedicatedGatewayCPUUsage と DedicatedGatewayMemoryUsage を調べて、専用ゲートウェイ ノードを追加すると、待機時間が短縮されるかどうかを確認します。 統合キャッシュのすべてのインスタンスは互いに独立しているため、専用ゲートウェイ ノードを追加しても IntegratedCacheEvictedEntriesSize は減少しないことに留意してください。 ただし、ノードを追加すると、専用ゲートウェイ クラスターが処理できる要求量が向上します。
次の手順
- 統合キャッシュに関する FAQ
- 統合キャッシュの構成
- 専用ゲートウェイ
- Azure Cosmos DB への移行のための容量計画を実行しようとしていますか? 容量計画のために、既存のデータベース クラスターに関する情報を使用できます。
- 既存のデータベース クラスター内の仮想コアとサーバーの数のみがわかっている場合は、仮想コアまたは vCPU を使用した要求ユニットの見積もりに関するページを参照してください
- 現在のデータベース ワークロードに対する通常の要求レートがわかっている場合は、Azure Cosmos DB Capacity Planner を使用した要求ユニットの見積もりに関するページを参照してください