この記事は「NEXTSCAPE Advent Calendar 2020」の12日目です。

本記事ではAzure Cosmos DBのスケーリングとパーティションの関係について書きます。最初に結論だけ述べると、
一度物理パーティションの数が増加するようなスケーリングを行うと、その後物理パーティションの数が減少するようなスケーリングを行うことはできず、結果的にRUの割り当てに無駄が生じるので注意が必要です
という話になります。

※本記事は2020年12月時点での情報となります。

Azure Cosmos DBとは

Azure Cosmos DBとはMicrosoft Azure上で提供されるフルマネージドのデータベースサービスです。特徴としては以下が挙げられます。

NoSQL
グローバル分散（高スループットと高可用性の実現）
複数のデータモデルをサポート（JSONドキュメント、キーバリュー、グラフ）
弾力性

RUとは

また、Azure Cosmos DBでは、データベース操作のコストはRU: Request per Units（要求ユニット）という名の独自の概念で表現されます。RUによってスループットと料金コストが決定されます。公式の文章を引用すると以下になります。

1 KB の項目をポイント読み取りする (つまり、ID とパーティションキーの値で 1 つの項目をフェッチする) コストは、1 要求ユニット (または 1 RU) です。その他のすべてのデータベース操作にも、同様に RU を使用してコストが割り当てられます。 Azure Cosmos コンテナーの操作にどの API 使用するかに関係なく、コストは RU によって測定されます。データベース操作が書き込み、ポイント読み取り、またはクエリのいずれの場合でも、コストは常に RU で測定されます

割り当てるRUはAzureポータルから変更可能であり、このことがスケーラビリティを実現しています。

パーティションとは

一般的にパーティションとは、大規模なデータベースを小さなデータベースに分割するときの、個々の小さなデータベースを指します。また、この分割のことをパーティショニングと呼びます。

パーティショニングを行う主な理由は、スケーラビリティです。それぞれのパーティションは別々のノードに配置することができます。大規模なデータセットを数多くのディスクに分散配置できるので、クエリの負荷を大量のプロセッサに分散することができます。

Azure Cosmos DBの場合、2種類のパーティションがあります。それが論理パーティションと物理パーティションです。

Azure Cosmos DBの論理パーティション

論理パーティションとは、特定のプロパティの値をもとに（論理的に）パーティショニングすることです。
公式の文章を引用すると以下になります。

論理パーティションは、同じパーティションキーを持つ一連のアイテムで構成されます。たとえば、食物の栄養に関するデータが含まれているコンテナーでは、すべてのアイテムに foodGroup プロパティが含まれています。このコンテナーのパーティションキーとして foodGroup プロパティを使用できます。 Beef Products、Baked Products、Sausages and Luncheon Meats など、foodGroup に特定の値を持つアイテムのグループが、個別の論理パーティションを形成します。
Azureポータルから設定できるパーティションキーはこれに相当します。

Azure Cosmos DBの物理パーティション

一方物理パーティションは、実コンピューティングリソースでの分割を表します。内部的には、1 つまたは複数の論理パーティションが単一の物理パーティションにマップされます。

重要な仕様として、以下があります。

コンテナー内の物理パーティションの数は、次の構成によって決まります。

プロビジョニングされたスループットの数 (個々の物理パーティションからは、1 秒あたり最大 10,000 の要求ユニットのスループットを提供できます)。
データストレージの合計 (個々の物理パーティションには、最大 50 GB のデータを格納できます)。

論理パーティションと物理パーティションについては図で書いた方がわかりやすいかもしれません。
蒼の王座さんの記事の図が一例です。

Azure Cosmos DBのパーティションとスケーリングの関係

物理パーティション1つに対し、スループットとストレージについては以下の制約が存在します。

スループットの上限10,000RU/s
ストレージの上限50GB

この制約に関連し、Azure Cosmos DBには以下の仕様が存在します。

物理パーティション1つに対し10,000RU/sを超えるスループットを割り当てた場合、物理パーティションが自動で分割、増加する。
物理パーティション1つに対し50GBを超えるデータを格納しようとした場合、物理パーティションが自動で分割、増加する。

また、パーティションとRUの関係について、__プロビジョニングされたスループットは、物理パーティション間で均等に分割される__仕様が存在します。

このため、スループットのスケーリングを行うユースケースにおいて、以下が発生することに注意が必要です。

RUを増加させていくと、物理パーティションが自動で分割される
その後RUを減少させても、物理パーティションは分割されたままとなる
その結果、RUの割り当てが物理パーティションの数だけ按分され、パフォーマンスが劣化する

実演

適当なコンテナを作成し、400RUの状態でデータを投入します。このときメトリックから物理パーティションの数が1つであることが確認できます。

この後、RUを10100RUまで上げます。

そして再度データを投入すると、メトリックから物理パーティションの数が2つになっていることが確認できます。これはスケーリングに応じて物理パーティションが自動で分割、増加するためです。

この後、RUを400RUまで下げます。

RUを下げても物理パーティションの数は2つのままとなります。これはスケーリングに応じて物理パーティションが自動で減少しないためです。

注意すべきユースケース

「一時的にRUを増加させ、その後もとに戻す」ユースケースとしては、自分がかかわった範囲内では以下のような具体例が挙げられます。

データ移行に伴い、大量のデータを短時間で移行するためのスケーリング
Web APIサーバ側の性能テストを行うため、そのバックエンドであるCosmos DB側でRU超過を発生させないようにするためのスケーリング

上記のようなユースケースにおいて、注意すべき仕様となります。

まとめ

本記事では、Azure Cosmos DB、パーティショニング、RUについて簡単な説明をし、スケーリングにおける物理パーティションの注意すべき仕様について記載しました。すなわち、一度物理パーティションの数が増加するようなスケーリングを行うと、その後物理パーティションの数を減少させることはできず、スループットの割り当てに無駄が生じるという仕様です。

公式のフィードバックフォーラムにも物理パーティションの縮小機能を要望する投稿があるのですが、2019年1月からずっとステータスはplannedのままであり、しばらくは対応がなされない雰囲気を感じています。

したがってAzure Cosmos DBで10,000RU/sを超えるスループットや50GBを超えるデータを扱う場合、これらの仕様を理解したうえで、意図しないパフォーマンスの劣化を回避するよう注意する必要があることを覚えておくとよいと思います。

以上、ここまで読んでいただき誠にありがとうございました。

出典

※URLはすべて2020年12月12日アクセス
データ指向アプリケーションデザイン　6章「パーティショニング」
Azure Cosmos DB の概要
 Azure Cosmos DB でのパーティション分割と水平スケーリング
 Azure Cosmos DBの要求ユニット
 Azure Cosmos DB の自動スケーリングでプロビジョニングされたスループットについてよく寄せられる質問
 Cosmos DB のパーティショニング - 蒼の王座
 Improve scaling down experience: remove redundant physical partitions – Customer Feedback for ACE Community Tooling