しばやん雑記

Azure とメイドさんが大好きなフリーランスのプログラマーのブログ

Build 2023 で発表された Azure Cosmos DB のアップデート

先日開催された Microsoft Build 2023 では Azure Cosmos DB の新機能が数多く公開されました。ぶっちゃけかなり大規模な機能追加となっているので、気になる機能は個別に検証しつつまずは全体として NoSQL API に関連するアップデートをまとめることにします。

とはいえ基本は Cosmos DB Blog で公開された以下の記事を参照してもらえれば問題ないです。

この中で一番使われているはずの NoSQL API に関係するアップデートは以下になります。GA / Preview 合わせてかなり多く、しかもそれぞれがかなり重要度が高い機能になっています。特に Burst Capacity は今すぐ有効化する価値があります。

特に挙動が気になる機能については個別に検証してブログにまとめる予定ですが、とにかく機能が多いのでまずはざっくりとアップデートをまとめます。

Burst Capacity が GA

Cosmos DB の Provisioned Throughput を利用している場合に、直近 5 分間のウィンドウで使用しなかった RU を貯めておいて、必要な際に消費する Burst Capacity が GA しました。

Autoscale よりも高速かつコストに影響しない形で利用できるので、無条件で有効化してよい機能だと考えています。アプリケーションへの影響は 429 が発生する頻度が減るといった程度なので、基本的にデメリットはないと考えてよいです。

既にプレビューの際に検証した結果を以下のエントリでまとめていますので、こちらも参照してください。GA したからと言って挙動が変わっているわけではありません。

Autoscale との組み合わせも効果的なので、Cosmos DB を Provisioned Throughput で利用している際には忘れずに有効化しておきたい機能です。

Hierarchical partition keys が GA

これまで Cosmos DB の Container では 1 つのパーティションキーのみ指定可能でしたが、それを最大 3 つまで指定できる機能がこの階層パーティションキーです。マルチテナントのシナリオで活躍します。

これまで単一のパーティションキーでは論理パーティションの上限 20GB に達する可能性がある、あるいはホットパーティションとなる可能性があるケースでは、合成パーティションキーを作成して分散させる戦略を取ってきましたが、階層パーティションキーを使うとその必要なくさらに効率的にクエリを実行できます。

合成パーティションキーでは一部の値だけ指定した場合のクエリはクロスパーティションで実行されるため、物理パーティションの数によっては効率が悪くなりますが、階層パーティションキーではプリフィックスが指定された場合には適切な物理パーティションにルーティングされるため、効率よくクエリが実行可能です。

このあたりの詳細は公式ドキュメントのテーブルがわかりやすいので目を通しておくと良いです。

実現できることは合成パーティションキーとほぼ同じですが、データを重複して持たせる必要がないのでサイズの削減に繋がり、更にルーティングも最適化されるので今後は合成パーティションキーを使った設計は必要なくなりそうです。

1TB Serverless Contianer が GA

Cosmos DB の Serverless では 50GB と 5000 RU が上限となっていましたが、1TB と 20000 RU まで利用できるようになりました。これでデータサイズがかなり大きいケースでも Serverless を利用することが出来るようになりました。

Serverless では物理パーティション当たりの RU が最大 5000 RU から 1000 RU までデータサイズが大きくなるにしたがって下がっていくため、Provisoned Throughput よりもパーティションキーの設計が重要になってきます。階層パーティションキーなどを使って効率よく分散する必要があります。

継続的バックアップの 7 日間モードが GA

これまで継続的バックアップは 30 日間保持するモードだけ GA していましたが、無償で利用可能な 7 日間保持するモードが GA しました。Analytical Store が必要なケース以外では継続的バックアップに切り替えるのを強くお勧めしています。

これまでの定期バックアップではリストアするためにサポートに連絡する必要がありましたが、継続的バックアップでは任意の時間のデータにユーザー主導で戻すことが出来るので使い勝手が格段に向上しています。

今回 GA した 7 日間保持するモードは無償なので移行して損はありません。

Log Analytics での Transformation (DCR) サポートが GA

Log Analytics に対して Cosmos DB の診断ログを送信する際に、テーブル単位で KQL を使ってフィルタリングやカラムの絞り込みを行う機能が GA しました。元々 Log Analytics に用意された Data Collection Rule と Transformation が Cosmos DB のログテーブルでも利用可能になったというアップデートです。

Cosmos DB の診断ログはパフォーマンス調査に非常に役立つのですが、その反面データ量が非常に多くなってしまいました。特に Cosmos DB のような低レイテンシなデータストアは高頻度でアクセスされるためログの量も膨大です。今回 GA した Data Collection Rule を使った Transformation を使うと KQL を利用して必要なデータのみフィルタリングして保存可能です。

例を挙げると Cosmos DB で Change Feed を利用している場合には leases Container に対して大量のアクセスが発生しますが、この Container に対するログは保存する必要がありませんので、Data Collection Rule を使うことで除外できます。

全てのバージョン、削除対応の Change Feed がプレビュー

名前が分かりにくいですが、以前は Full Fidelity Change Feed と呼ばれていた機能となります。4 年近く Private Preview のままでしたが、今回の Build でようやく Public Preview に到達したようです。

現在の Change Feed はデータを複数回変更しても、最後に変更された結果のみ取得出来るという Eventual な動作となっていますが、今回 Public Preview となった動作モードを使うと全ての変更と削除についても Change Feed として取得できるようになります。

この Change Feed の動作モードについては Full Fidelity と呼ばれていた頃に検証したことがあるので、以下の動画アーカイブを見てもらえればと思います。

現在の SDK では Java のみ Change Feed Processor でも新しいモードが使えるようになっています。.NET では Change Feed の Pull Model を利用する必要があるため、本格的に利用するには少しハードルが高いです。

正直なところ Azure Functions の CosmosDBTrigger が対応するまでは使いにくい状況が続きます。

NoSQL API での Materialized views がプレビュー

これまでも Azure Functions と Cosmos DB の Change Feed を利用して Materialized views を作るアーキテクチャを多く作ってきたと思いますが、簡単なクエリを書くだけで任意の Materialized views を作る機能がプレビューになりました。同様の機能は Azure Cosmos DB for Apache Cassandra でも Public Preview として提供されていました。

コードを書く必要がなく Container を作成するタイミングで SQL を使って Materialized views のスキーマを定義出来ますが、SQL で表現できることのみ実現可能という形になるため、Azure Functions を使った場合よりも柔軟性は低くなっています。

シンプルな Materialized views が必要なケースでは非常に便利ですが、追加でコンピューティングリソースのコストがかかりそうなので価格が気になるところです。実装は Change Feed の Pull Model がベースとなっているので、同期ラグがどのくらいになるのか注意ですね。

Computed properties がプレビュー

Materialized views に少し近いのですが、既存項目のプロパティを利用して実行時に新しいプロパティを定義できる機能がプレビューになりました。これまで C# 側の読み取り専用プロパティを使って、既存項目から新しい値を作ることをよく実装しましたが、Cosmos DB 側で定義可能になりました。

Computed properties も SQL を使って値の変換を定義するため、クライアント側で実装する場合に比べて実現できる変換は限界があるのですが、変換した値をインデックスの対象にできるというのが大きな特徴です。

デフォルトで Computed properties はインデックス対象になっていませんが、明示的にインデックス対象と指定することで変換後の値を使ってクエリを高速化できます。

同一アカウントへの PITR がプレビュー

これまで継続的バックアップを使って Point In Time Restore を実行する際には、新しいアカウントに対してのみ実行が可能という制約が付いていましたが、同一アカウントに復元する機能がプレビューになりました。

新しいアカウントに復元すると必然的に接続文字列の変更など多くの作業が発生してしまいますが、同一アカウントに復元出来ると Container 名の修正だけで済むため利便性が高いです。

これまで以上に継続的バックアップを利用する意味が出るため、早めに切り替えるのがおすすめです。

.NET / Java SDK で OpenTelemetry / Application Insights 統合がプレビュー

Cosmos DB 側のアップデートではないですが、ようやく .NET と Java の SDK で OpenTelemetry と Application Insights を利用したテレメトリの送信がプレビューになりました。これまでも Gateway を利用していれば Application Insights SDK によってデータが収集されていましたが、Direct の場合は全く収集されないという課題がありました。

今回のアップデートでは SDK レベルでテレメトリの送信が組み込まれているため、接続モードに依存せず常に利用が可能となりました。実際に Application Insights への送信を試しましたが、Direct を使っていても依存関係呼び出しが記録されていました。

実行した SQL は収集できていないようですが、今後のアップデートに期待したいです。