📙

DynamoDBのRCU/WCU計算は実務で起きるのか…？

2022/03/12に公開

AWS

エッセイ

dynamo

tech

CLPとSAAは取得済みなので、3冠目としてDVAを勉強しているのですが、その中でDynamoDBの読み込みキャパシティユニットや書き込みキャパシティユニットの計算を問われる問題に何度か出くわします。

しかしながら、あのように完全に数式化された状況は現実で起こるのでしょうか、、、と思ったので色々書き起こしてみました。

※この文章は真面目なものではなくエッセイです。

※RCU/WCUの問題の例

例えば以下のような計算例題に出会うことが多いです。

Q: DynamoDBに保存する項目の最大サイズは6KBで、1秒間に平均5個の読み込みが行われるアプリケーションがある。アプリケーションには強力な整合性を持った読み込みが期待される。必要なRCUはいくらか。

基本的にこの手の問題のポイントとなる変数は4つだと思っています。

項目サイズ
整合性
1秒当たりの読み込み
トランザクション

DynamoDBは 「1RCUで4KBの項目を1秒当たり結果整合性なら2個読み込める」 という定義があり（そもそもこれが分かりにくい）、強力な整合性なら1個に減り、トランザクション中の読み込みなら1個に対して2RCUかかる仕様になっています。※AWS: 読み込み/書き込みキャパシティーモード

なので、今回の問題であれば、
「4KBの項目を1秒当たり結果整合性なら1RCUで1秒あたり2個読み込める」
→「4KBの項目を1秒当たり強力な整合性なら1RCUで1秒あたり1個読み込める」
→「6KBの項目を1秒当たり強力な整合性なら2RCUで1秒あたり1個読み込める」
→「6KBの項目を1秒当たり強力な整合性なら10RCUで1秒あたり5個読み込める」

で、計10RCUが必要になるはずです。

実務でこんな分かりやすい場合は登場するの？

資格なんて意味がない！という価値観は個人的にはあまり受け入れていないのですが、こういったRCU/WCUの問題を解いていると、確かに「こんなこと資格勉強の時しか起こらないのでは…？」と考えてしまいます。

例えば

「コンスタントに毎秒5項目読み取られるのか？揺れもあるし深夜はもっと少ないだろ」
「トランザクション読み込みとただの読み込みが混じっていたらどうするんだ？」
「そんな簡単にプロビジョニング量を割り出せたら世の中苦労しない」

などですね。（私の心の声）

特に個人開発レベルだとオンデマンドモードで十分なので、プロビジョニング対してさらに想像力が発揮できません。

そこで、とりあえずDynamoDBのユースケースを調べてみることにしました。

DynamoDBのユースケース

DynamoDBのユースケースを簡単に調べてみると、大体以下のようなものがヒットします。

ユースケース	所感
ログ記録	出力が一定（サイズも一定）なログは存在しそう。24時間動くアプリだったら…
アプリケーションキャッシュ	サイズは一定。これも結局24時間動くなら…
ゲーム情報の保存	サイズはまちまちな予感。24時間動くなら…

ほんの少ししか調べていませんが、自分がグローバルに生きていないことに気づきました。

大体のユースケースに「24時間動くなら…」と書いていますが、グローバルなアプリだったら時差の関係上24/7でアクセスされるので、割とコンスタントなアクセスが存在することになり、プロビジョニングモードと相性がいいかもしれないですね。。

グローバルじゃなくても、24時間継続的に使用されるアプリケーション（例えば原子力発電所システムとか？）であれば安定したPut/Getが発生しそうだなと感じました。

とはいえ、資格試験の問題みたいに単純な世界でしょうか。。

オンデマンドやオートスケールについて

DynamoDBにはオンデマンドやオートスケールといった便利な機能があります。

そんなときは、「とりあえずオンデマンド！リリース後にRCU/WCUを見て判断しよう！」 みたいな考え方でいいのではないでしょうか。

整合性やトランザクションであればともかく、「項目サイズ」や「1秒当たりの読み込み量」を最初から予測するのはきっと難しいですよね。

曖昧な予想をしてピークに耐えられなかったら嫌ですし、プロダクトの成長が予想より早くて毎回毎回計算しなおすのも無駄です。

もしくは、ある程度のプロビジョニング予想で済ませて、そこにオートスケール機能をつけて対応するのも良いですね。

おわりに

まともな研究というより、エッセイのようになってしまってすみません。
自分の結論としては、「最初からまともに予想することなんて難しいから、オンデマンドやオートスケールでいいじゃん」になります。

コストパフォーマンスを考えるのもソリューションアーキテクトの役割ですが、かなり厳密なコストを求められるのでなければ、「いや、曖昧なプロビジョニングでピークを逃すよりかは実質安いはず！」という盾を使って1か月くらいオンデマンドで様子見をしたいところですね。