今回はSIOSのアドベントカレンダーの記念すべき1日目の記事です。
今年のアドベントカレンダーのテーマは「サイオス社員が今年一年で新たに学んだ技術」です！

そして私は絶賛学習中のAzure CosmosDBについて紹介していきたいと思います。
偉そうに書いていきますが、自分自身も入門したてなので、もし誤ってる点あったらコメントで指摘いただけると幸いです。

はじめに

冒頭でも述べましたが、Azure CosmosDBについて書いていきたいと思います。
私自身、ほとんどRDBMSしか触ったことがなく、NoSQLに関してはまったくの素人です。
「なんかJSONのままデータ保管しておけるんでしょ？」くらいの理解です。

ただ、先日のMicrosoft IgniteでもCosmosDBでハイブリット検索が行えるようになったという発表があり、生成AI関連でもCosmosDBの活用が注目されています。
それに、そもそもアプリケーションのDBとしてNoSQLはよく選択肢として挙がる部分なので、知っておかなくては…という思いから学習を始めました。

というところで、今回は基礎の基礎というところで、CosmosDBにおいて重要な概念であるRU(Request Unit)について超入門していきたいと思います。

• RUとは？
• スループット(RU/s)の制限
• RUと料金体系

など基本的なところを抑えていこうと思うのでぜひ最後までご覧ください。

RUとは

RUはRequest Unitの略称であり、CosmosDBにおいては非常に重要な指標です。

CosmosDBのデータベースの操作を行うにあたってはCPU, メモリ, IOPSなどの様々システムリソースが必要になりますが
それらが全て抽象化され、RUというメトリクスひとつに集約化されています。

そして、このRUの単位はスループット(RU/s)や利用料金にもかかわってきます。
つまり、ユーザーはRUだけを考えればいいという非常にシンプルな仕組みとなっています。

では「1RUで出来る操作はどのくらいか？」なんですが、公式ドキュメントには以下のように記載がありました。

1RU = 1 KB 項目の読み取り

これをベースとして膨大なデータ量の読み取りを行ったり、複雑なクエリを実行することでRUが増加していくことになります。
RUを計算する上で影響する要素としては以下のようなものがあります。

• アイテムのサイズ
• アイテムのインデックス付け
• アイテム プロパティの数
• インデックス付きプロパティ
• データの一貫性
• 読み取りの種類
• クエリのパターン
• スクリプトの使用

なお、また別の記事でも触れたいと思いますが、
CosmosDBのコンテナ設計を優れたものにすることで、同じデータの取り出しでも必要となるRUを小さくすることが可能です。
そのため、データモデリングやパーティションキーの設定が検索性能やコストにも直結します。

RUとCosmosDBの設定項目

では実際にCosmosDBのリソースを作成・利用していくうえで、このRUがどのように関わっていくかを見ていきたいと思います。
リソース作成画面をみてみます。

今回のポイントとしては、以下2点です。

• 容量モード
• 合計アカウント スループットを制限する

なお、これから色々検証の方していきますが、Global distributionの設定に関して無効 / 無効で設定したうえで検証の方進めていきます。
マルチリージョンにすると、プロビジョニングされるRU数が2倍になったりするのでその点注意です。

容量モード

CosmosDBをデプロイする際、容量モードというプロパティが存在しています。

選択肢としては2つ存在しています。

1. プロビジョニングされたスループット
2. Serverless

プロビジョニングされたスループット

「プロビジョニングされたスループット」に関しては、事前に使用可能な1秒あたりのRU(=RU/s=スループット)を設定する方法になります。

例えば1000RU/sと設定した場合は、1秒間に1000回のみ「1 KB 項目のポイント読み取り」を行えるといった形になります。

なお、この設定したRU/sの値を超えてしまった場合はCosmosDBから429のエラーが返されます。
ただしCosmosDB SDKを利用している場合は、自動で再送処理の方が行われるようです。

また、このプロビジョニングされたスループットについては更に2つのプロパティを持ちます。

1. Manual
2. Auto Scale

Manual

「Manual」は完全にRU/sを決め打ちするような設定になります。
例えばスループットを 1000 RU/s と設定した場合は、常にRU/sは1000に固定されます。
もちろんAzure Portal上などからこの値を手動で変更することは可能ですが、アプリの使用量などによって動的に変化することはありません。

AutoScale

「Auto Scale」は設定した範囲内で、アプリの使用量に応じてスループットが変動する設定となります。
例えば上限のスループットを 1000 RU/sとした場合、以下のレンジの間でスループットは変動します。

100 RU/s ~ 1000 RU/s

なお、この下限の値は上限のスループットの1/10の値となっています。

スループット制限のスコープ

このスループットを制限する対象ですが

• アカウント
• データベース
• コンテナ

それぞれで設定することが可能です。

アカウント

CosmosDBアカウント全体へのスループット制限については、Cost Managementブレードから確認できます。

現在、1000RU/sとして設定されており、このアカウント全体で1000RU/sまでのスループットをプロビジョニングすることが可能となります。
この後話していくなかで、データベースやコンテナに対してそれぞれスループットを割り当てますが、それらの合計がここで設定した値以下となる必要があります。

なお、選択肢を見ていただいても分かるように「制限無し」という設定も可能で
この場合は上限無くスループットを割り当てることが可能となります。

データベース

まずデータベースのスコープを確認します。
まず、サンプルのデータベースを作成していきましょう。

データエクスプローラからコンテナの作成を行います。
まだデータベースが存在していないので、データベースから作成していきます。

今回はrestaurant_dbというDBを作ることにします。
そして、Share throughput across containersにチェックボックスを入れます。

このチェックボックスを入れることで、このデータベースに含まれるコンテナ群でスループット量を共有するようになります。

そしてスループットの設定として、先程述べたAuto scaleからManualかを選択し、RU/sの値を設定します。
今回はAuto scaleを選択しており、値としては1000 RU/sを設定しました。

この時、先程紹介したようなレンジでRU/sが設定されていることが読み取れます。

ちなみにここで2000 RU/sを設定しようとすると怒られます。
これは、先ほどアカウント全体のスループットを1000RU/sに制限したためです。

そのため今回はデータベースのMAX RU/sの値を1000RU/sのままにして進めます。
続いてコンテナ(food_container)も作成していきます。

作成完了後、restaurant_dbに更にコンテナ(drink_container)を1つ追加します。

これでrestaurantというデータベースに対して、foodとdrinkという2つのコンテナが作成できました。

この状態でAzurePortalのCosmosDBのリソースから、Cost Managementのメニューを確認します。

この内容から以下のことが読み取れます。

• restaurantのデータベースには最大1000RU/sのスループットが割り当てられている
• foodとdrinkのコンテナでこの1000RU/sを共有している

イメージとしてはこんな感じです。

これがデータベースをスコープとしたスループットの制限となります。

コンテナ

次にコンテナをスコープとしたスループットの制限を確認します。

まず、事前準備としてCosmos DBアカウント全体のスループット許容量を増やしておきます。
ひとまず4000RU/s位にしておけば大丈夫です。

そして、新規にデータベースとコンテナを作成していきます。

この時のポイントとしては**Share throughput across containersにチェックボックスを入れません。**
そして、コンテナ(employee)に対してスループットの設定を行います。

作成が完了したら、もう一つcompanyのデータベースに対してコンテナ(department)を追加しておきます。

2つのコンテナの作成が完了したら、Cost Managementを見てみましょう。

ここからから以下のことが読み取れます。

• companyが持つコンテナそれぞれに対して1000RU/sが割り当てられている
• companyのデータベースとしては最大スループットが2000RU/sである

イメージとしてはこんな感じです。

このように、最大スループットに関してはデータベースに対しても割り当てられますし、コンテナに対しても割り当てられます。

データベースとコンテナ混合

これまでデータベースとコンテナそれぞれにスループットを割り当てる方法をご紹介しました。
これに加えて、データベースに対して割り当てつつ、さらにコンテナに対してもスループットを割り当てることも可能です。
実際やってみましょう。

先程作成したrestaurantのデータベースにコンテナを追加します。
そして、Provision dedicated throughput for this containerにチェックボックスを入れ、コンテナに対してスループットの設定を行います。

ではCostManagementを見てみましょう。

以下の内容が読み取れます。

• restaurantのデータベースとしては最大スループットが2000 RU/sである
• dessertコンテナに対してだけ1000RU/sが割り当てられているである。

イメージとしてはこんな感じです。

この時気になることとしては、

「restaurantのデータベースには1000 RU/sが割り当てられてるんだし、そのデータベースに含まれるdessertのコンテナにもスループットは割り当てられる？」

といった点かと思います。
結論から言うと、そういった割り当ては行われず、dessertのコンテナが利用できるのは1000RU/sまでとなります。

これは公式のドキュメントにも記載がありました。

参照：データベースとコンテナーでスループットを設定する

以上の内容から、プロビジョニングされたスループットの容量モードを選択した場合は
「どのスコープに対して」「どれだけのスループットを割り当てるべきか」が設計時のポイントとなりそうです。

スループットの変更

一度設定したスループットに関しても簡単に変更できます。
データエクスプローラのScaleという項目を選ぶと、AutoscaleかManualかの選択や、その設定における値も変更可能です。
アプリの利用状況などに合わせて柔軟に変更しましょう

Serverless

「Serverless」に関しては、事前に使用するRU/sを設定しません。
使用量に伴って自動でスケーリングされ、最大のスループットとしては 20,000 RU/sまで増加します。

つまり、サーバーレスを利用する場合は、これまでプロビジョニングされたスループットで述べてきたようなスループットの割り当てを考慮する必要がありません。
全てCosmosDB側で自動で行ってくれます。らくちんです。

そして料金体系に関しては、利用したRUの量に依存します。
つまり何RUを利用したかによって、料金が従量課金制のように増えていきます。

ただこの時、プロビジョニングされたスループットとServerlessで同じ量のRUを利用した場合は、Serverlessの方が使用料は高くなる傾向です。
(プロビジョニングされたスループットの設定値が適切である前提)

とはいいつつ、スループットを正確に見定めるのは難しいですし、アプリの新規開発時やアプリの利用量の予測が困難な場合はひとまずServerlessを選択するのが良いかと思います。

RUの計算

自分の作ってるアプリがどれだけRUを使うか分からない！！といった方も多いかと思います。
これについては以下2つの方法が用意されています。

• 実測で計算する
• 計算ツールによる予想

実測での計算

こちらは実際にクエリを実行して、その実行に対するRUを確認する方法です。

まず、先程作成したfood_containerにアイテムを1つ追加します。

このコンテナー対して、データエクスプローラから以下のクエリを実行します。

SELECT * FROM c

すると、結果が得られると思うのですが、Query StatsのRequest Chargeの値を確認します。

これが今回のクエリ実行にかかったRUの数です。
このように実際にクエリを実行してみて、どの程度のRU数になるかを実際確認してみましょう。

計算ツールによる予測

AzureにはCapacity Calculatorといった計算ツールが用意されており、これを利用することでおおよそのRU数を見積もることが可能です。

料金体系

CosmosDBの利用料金は主にRUとストレージ容量によって決まります。
プロビジョニングされたスループットの場合であれば、設定したRU/sに応じて時間単位で課金が行われます。

Serverlessの場合であれば、先程述べたように、利用したRU数とストレージ容量に応じて課金が行われます。

まとめ

今回は、CosmosDBを利用するうえで重要な指標であるRequest Unitについてご紹介しました。
メモリや、CPUなどのシステムリソースを抽象化した値であり、利用する側からしたらRUのみを考えればいいので非常にシンプルですね。

ただ、プロビジョニングされたスループットの設定においてはどのスコープに対して、どれだけの値を設定するかをしっかりと考える必要があります。
性能や価格などを考えるうえで肝となる指標であるため、しっかり理解していきたいところです。

まだまだCosmosDB深掘りしていきたいと思うので次もぜひ読んでいただければと思います。
ではまた！