Build 2021でCosmos DBにIntegrated Cache（統合キャッシュ）がPreview機能として追加されたので触ってみました。
前提条件
- Cosmos DBの専用ゲートウェイ追加が必須
- 現状SQL API（Core API）のみサポート
- IPファイアウォールやPrivate Linkを使ってるCosmos DBアカウントは専用ゲートウェイ使えない（プロビジョニング不可）
- 可用性ゾーンが有効になっているCosmos DBアカウントは専用ゲートウェイ使えない（プロビジョニング不可）
あとPreviewなのでSLAが無いとかいろいろあります。
統合キャッシュの使い方
最初に専用ゲートウェイを展開します。
といってもDedicated GatewayのメニューからOnにしてSKUとインスタンス数を選択して保存するだけです。
SKUはAzure Cosmos DB 専用ゲートウェイ | Microsoft Docsにもありますが、D4s、D8s、D16sから選べます。それぞれvCPUが4、8、16、メモリが16GB、32GB、64GBです。
SKUは後から変更できない（一旦展開を止めないとだめそう）みたいですが、インスタンス数は増減可能です。
専用ゲートウェイの展開が完了すると、接続文字列に専用ゲートウェイ用の項目が増えるので控えておきます。（キーは同じで接続先が異なります）
専用ゲートウェイのFQDNは <account-name>.sqlx.cosmos.azure.com みたいになります。※実際にはアカウント名の後ろにリージョンが入りますけど。
複数リージョンのCosmos DBアカウントに専用ゲートウェイを展開する場合は各リージョンにプロビジョニングされるみたいなので料金にも気を付けましょう。
あとはクライアントから専用ゲートウェイ用の接続文字列を使って、ゲートウェイ接続モードでつなぎます。最後にキャッシュを得るためには整合性モードが最終的な整合性（Eventual）である必要があります。
Eventualではない場合はそのままバイパスされるので通常のリクエストと変わらない感じです。コード的な変更を最小限にしたい場合はキャッシュ用のCosmos DBクライアントのインスタンスを生成して専用ゲートウェイの接続文字列を使用、CosmosClientOptionsで接続モードをGatewayにしてEventualも指定したものを使うようにすればよいかもですね？
実際に試すと統合キャッシュでキャッシュにHitした場合、RequestCharge（消費RU）は0になるので想定通りです。
- 直接接続・標準ゲートウェイ （RequestChargeは2.19）
- ゲートウェイ接続・専用ゲートウェイ、ただし整合性がSessionなど（RequestChargeは2.19）
- ゲートウェイ接続・専用ゲートウェイ、整合性をEventualに（RequestChargeは0）
キャッシュにヒットしてる間はメトリクス見てもRUは消費してなさそうでした。
キャッシュの保有期間
今のところ常に5分のようです。（Preview中は）
その他制限などはドキュメントを参照ください。
メトリックについて
Metricが追加されてるのでそちらで見れます。
専用ゲートウェイのCPUやメモリ使用率はエラーになってしまうので未確認。
とりあえずCacheHitRateやDedicatedGatewayRequestsを見て判断しましょう。D4sで1インスタンスだと250リクエストぐらいで頭打ちしてたような感じがありましたが。実際にはアイテムの数やサイズにもよると思うので小さく初めて検証してみてください。
まとめ
というわけで初期費用が最小サイズでも時間あたり50円弱、月37000ちょいとお値段があるので一定以上のRU使ってる、読み取り負荷が高い、高RUなクエリが繰り返される、項目サイズが大きいアイテムの頻繁は読み込みなどの場合だとRUのコストを抑えて利点が得られそうです。（ドキュメント見ましょう）
インフラ的に他のサービスを意識しなくていいのと、クライアントコード的にも透過感あってわかりやすいのでワークロードに合えばコストに強い機能ですね。用量用法を守ってうまく活用しましょう。
ブチザッキ 