先日シアトルで開催された Microsoft Ignite 2023 では Azure Cosmos DB のアップデートも Build 2023 程ではありませんが多く発表されました。例によって AI を意識したものが大きく扱われていますが、スケーラビリティの改善に繋がる機能もしっかり追加されています。
発表については公式ブログでまとまっているので、基本はこちらを参照すれば問題ないです。
ちなみに Build 2023 で発表された Cosmos DB のアップデートは以下の通りなので、興味があれば参照してください。Build 2023 で Private Preview だった機能が Ignite 2023 で Public Preview になったものもあります。
例によって個人的に気になっている機能について簡単にまとめます。一部の機能については詳細な検証が必要だと感じたら、別途検証結果をブログに書く予定です。
MongoDB vCore と Vector Search が GA
昨今の AI ブームと共に到来した Vector Search ブームに乗って、Cosmos DB の MongoDB vCore と Vector Search が GA しました。これまで MongoDB vCore がプレビューだったことを認識していませんでした。
MongoDB vCore の Vector Search については紹介記事が多いはずなので特に深堀りはしませんが、個人的には Ignite のセッションで発表された NoSQL API での Vector Search サポートの方を注目しています。
これを待っていた！
— miyake | ZEN (@kazuyukimiyake) 2023年11月16日
No SQL API でのベクター検索がまもなくらしい😍😍😍#MSIgnite pic.twitter.com/LqKHgVQ57g
恐らくは Function として実装されると考えていますが、この辺りは Preview が始まるのを待ちたいと思います。少し不安なのは 1536 次元の配列を読み書きするのに必要な RU が、思っているよりも大きくなりそうな点です。Cosmos DB の仕組み上は Native 実装が追加されても RU が減ることはないはずなので、コスト面は注意したいと考えています。
Dynamic Scaling Per Region and Per Partition が Public Preview
今回のアップデートの中で個人的に一番注目しているのがこの Dynamic Scaling Per Region and Per Partition です。基本は Autoscale を有効化しているコンテナーに対しての機能で、マルチリージョンや 50GB 以上のコンテナーを運用している場合には有効化するだけで、全体的なコスト最適化が期待できます。
マルチリージョンで Write と Read を分けているケースは分かりやすいのですが、物理パーティションが 2 つ以上存在するケースでは理解が難しいかも知れません。具体的な例はドキュメントに記載されているので、基本はこちらを読み込んでおけば問題ありません。
Cosmos DB は設定した最大 RU は物理パーティションの数だけ均等に分割され、一番多く RU を消費したパーティションの値を使って全体で消費した RU の計算が行われますが、Dynamic Scaling が有効な場合は物理パーティション毎の最大値を使った集計が行われるという仕組みです。従って物理パーティションが常に全て同じ RU を消費しているというケース以外では確実にコストダウンが見込めます。
Autoscale を利用している場合には確実に有効化しておきたい機能ではありますが、現時点では 11/15 以降に作成した Cosmos DB アカウントでのみ有効化が可能です。あくまでも Preview 中の制約だと考えていますので、GA 時には既存のアカウントでも有効化出来るようになると思います。
Cosmos DB を活用する上で RU からは逃げられないため、Autoscale と Burst Capacity そして今回の Dynamic Scaling を活用してコストを最適化しつつパフォーマンスとスケーラビリティを高めましょう。
Priority-based execution が Public Preview
Priority-based execution は Build 2023 で発表された時は Private Preview 扱いで、有効化するためにチームとのやり取りが必要だったのですが Ignite 2023 のタイミングで Public Preview に移行しました。
Cosmos DB では設定した RU 以上を必要とすると 429 を返してリトライという流れになりますが、Priority-based execution を使うとリクエスト単位で優先度を指定できるので、ユーザー操作に紐づくリクエスト以外は優先度を下げることで、応答性を改善するといった実装が可能になります。
デフォルトでは全てのリクエストは優先度 High に設定されていますが、このデフォルト値は Azure CLI などを使うと変更可能なので、デフォルトを Low にしつつ必要なリクエストだけ High にするというのも手です。
利用するには最新のプレビュー版 SDK のインストールが必要になるので、Azure Functions の Cosmos DB 拡張などを使っている場合は利用できません。
この機能は既存のアカウントでも有効化出来るようなので、比較的気軽に試せるものとなっています。但し Serverless には対応していないので Provisioned Throughput で作る必要があります。
Priority-based execution を有効化すると、Azure Portal にある Data Explorer からの操作がデフォルトで Low になるのが地味に便利そうです。本番向けに調査用のクエリを投げたい場合には、Data Explorer のせいでアプリ側で 429 が多発することがありました。
設定で変更できますが、基本は Low のままで問題ないはずです。正式版がリリースされた際には Azure Functions の CosmosDB Trigger を Low にして実行させる検証を行いたいと思っています。Change Feed は Checkpoint を持っているため 429 が発生した際のリトライが行いやすく、処理内容としても Priority-based execution と相性が良いはずです。
Cross-account container copy が Public Preview
これまで同一アカウント内でのコンテナーのコピーは Preview で公開されていましたが、アカウント間でのコピーも Public Preview となりました。これまで Data Factory を使うことが多かった Cosmos DB のコピーですが、Azure CLI だけで完結するようになりました。
Azure Portal からもコピー出来るようになって欲しいですが、同一アカウント内であってもサポートされていないため時間がかかりそうです。少し権限周りの割り当てが手間になりそうですが、Change Feed を使ってコピーするため安心感があります。
Change Feed を使って読み取りを行うということは、アプリケーションが稼働していて書き込みが発生するとデータの一貫性が損なわれる可能性があるということなので、オフラインにしてから処理を行う必要がある点には注意しておきたいですね。
Microsoft Copilot for Azure in Azure Cosmos DB
Ignite では Microsoft Copilot for Azure が発表されましたが、Cosmos DB についても Data Explorer 上でのクエリ作成を支援してくれる Copilot が追加されました。名前が異常に長いのが気になります。
Cosmos DB の SQL は T-SQL とも異なっているので多少癖がありますが、その辺りを上手く Copilot で書いてくれると楽は出来そうな気がします。しかし最近はクエリ作成に Copilot が必要となるようなデータ構造を設計しないので、個人的にはあまり使わない予感です。
