いまさら聞けないDynamoDBのお話し

はじめに

こんにちは、園田です。

前回に引き続き、「いまさら聞けない」シリーズを開催したいと思います。

記念すべき第10弾はDynamoDBになります。

「好きなサービスはDynamoDBです。」と言っている割にはこれまでいまさらシリーズに出てこなかったDynamoDBが遂に登場です。

この記事を読んだ人が、「あれ、こいつあんまり分かって無くね。」と言われないように気を付けたいと思います。

言い訳ですが、NWエンジニアなのでDB関連はあんまり詳しくないんです。

とはいえ、弊社のAWSサービスである「CUVIC on AWS」では園田の趣味により、DBを使う場合はまずDynamoDBで出来ないかを検討しています。
メンバーからはRDBが使いたいとよく言われますが、DynamoDBが好きなので仕方ありません。
（ちゃんとRDBが適切と判断すればRDB使ってますよ。管理が楽なので出来ればDynamoDBがいいなと思っているだけです。）

というわけで、今回はいまさらシリーズという事で、DynamoDBの魅力と、使いどころをお伝えしたいと思います。

恒例のAWS資料を貼っておきます。

DynamoDBってなに？

恒例のDynamoDBってなに？、から始めましょう。
いまさらシリーズのテンプレートです。

とはいえ、そろそろ回答考えるのが面倒になってきたので、生成AIさんに聞いてみましょう。

とのことです。

ちなみにcopilotさんの事はきちんと「コパちゃん」と呼んであげてください。
ChatGPTの「ちゃっぴー」に対抗しないといけませんからね。

話が逸れたので戻しましょう。

上記の答えを見て思いましたが、辞書的に使うならAIさん使えますね。
「NoSQLって何？」みたいな感じでドンドン聞いていくと理解するのが早いような気がします。
まぁ、質問にもセンスが必要そうな気がしますが…。

という訳で、AIさんが「NoSQL型のデータベースサービス」と言っているので、そのお話をしましょう。

NoSQLってなに？

NoSQLって何なんですかね。
わりかし有名ですが、NoSQL = Not Only SQL、日本語に翻訳すると「SQLだけじゃない」という事ですね。

普通、Noだと「SQLじゃない」と大部分の人が思うので、ネーミングもうちょっと何とかならなかったんですかね。
後、「SQLだけじゃない」ことがNoSQLの本質ではないと思うので、本当にイケてないネーミングだと思います。

NoSQLの本質としては、
トランザクション処理の「強い整合性（ACID）」を犠牲にして、柔軟性と拡張性を高めたデータベース（DB）という事ですね。

ACIDについては、「いまさら聞けないRedshiftの話」で細かく述べていますので見てみてください。

一応「強い整合性（ACID）」についてちょっとだけお話しすると、
園田がAさんに1万円を振り込んだとします。
その際の以下の処理をトランザクションとして、確実に処理を実行するという事です。

確実に処理を実行するのって当たり前でしょ。
と思うかもしれませんが、実は意外と色々ハードルがあります。

具体的には

その際にAさんの口座が10万円あったとして、10万+1万の処理を園田さん、およびBさんが同時に実施した場合、本来Aさんの口座は12万になるはずなのに、11万になるかもしれません。

これらの具体例はいつの間にか1万円が消えてしまう。という事で現実世界ではあってはならない事象になります。

このような発生してはいけないことを発生しないように頑張っているのが、リレーショナルDB（RDB）になります。

基本RDBを使っておけばデータの整合性を守るという意味では大丈夫です。

とはいえ、「強い整合性（ACID）」を保持するためにRDBについては色々制約があります。
具体的には、

みたいな感じです。

強い力を発揮するためには制約があることは某漫画でクラピカさんが仰っています。
（リスクはバネ！！ 制約と覚悟が大きい程念は強く働く！！）

最後のスキーマが固定なんて、データを確実なものとするため、当たり前といえば当たり前です。事前に定義しない様なデータが入ったら普通困りますから。

でも、「世の中、前もって分かることばっかりじゃないからもうちょっと肩の力抜こーぜ」というのがNoSQLです。

DynamoDBの特徴

DynamoDBの話に戻しましょう。

DynamoDBの特徴ですが、NoSQLサーバのフルマネージドサービスなので、NoSQLサーバの特徴がそのままDynamoDBの特徴となります。

要するに、こんな感じです。
分かり易く、RDBと比較しておきましょう。

一応、DynamoDBとして拡張性について述べておきましょう。

DynamoDBはデフォルトでマルチAZ構成になっています。
というか、RDSと違ってマルチとかシングルとか選べません。

デフォルトでSLAは99.99%です。グローバルテーブルだと、99.999%以上となっています。
大変素晴らしい可用性です。

またストレージもS3と同様、使った分だけです。
勝手にDBの容量が増えていきます。

ということでAWSがマネージドしていることで拡張性と耐障害性は大変素晴らしいことになっていますね。

また、個人的に特筆すべき点は、いきなりテーブルを作れるところですね。
そもそもデータを入れるのはテーブルなので、利用者としてはテーブルさえあればよいのです。

「なんでテーブルが欲しいのに、データベースをわざわざ作るの？」、
「Excelより良いデータの入れ物が欲しいだけだよ。」
という園田のような人間にはとっても素晴らしいサービスです。

しつこいかもしれませんが、トランザクションにおいて強い整合性（ACID）はDB側ではもっていません。
アプリケーション側で矛盾が生じないようにする、もしくは矛盾が生じても問題ない場合のみ利用するようにしましょう。

後、DynamoDBの最大（？）の特徴は書き込み、読み込みの性能を利用者が定義できるところです。

現状は「オンデマンドキャパシティ」という設定にすると、書き込み、読み込み性能がリクエストに応じて自動的にスケーリングされるので性能としてはあまり意識することはないかもしれませんが、費用には大いに関係がある項目です。

この書き込み、読み込みの性能についてはきちんと意識しておきましょう。

DynamoDBの書き込み、読み込みの性能について

この書き込み、読み込みの性能について簡単にまとめてみましょう。
詳細を知りたい場合は、以下のページを参照ください。

DynamoDB の読み込みと書き込みのオペレーション

https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/read-write-operations.html

読み込みについては結果整合性か、強力な整合性かによって多少異なりますが、まぁ無視して良いでしょう。
結果整合性が良く分からない。という方は強力な整合性の方を使いましょう。

「強力な整合性」とは普通のデータ読み取りの事です。結果整合性は古いデータ読むかもしれないけど、その場合はごめんね。というものです。
S3は昔、結果整合性だったんですけどね。今は強力な整合性の方になっちゃいました。
なのでもうDynamoDBでも結果整合性って使わない気がします。

アーキテクチャはなるべく揃えたほうが分かり易いですから。

なお、園田のブログを読んでいる方はわかると思いますが、園田はこの「分かり易い」を何より重要視します。
普通の人は、分かり易い方がいいんです。
頭の良い人には付き合ってはいけません。
こっちはAで、こっちはBとか考えないと駄目とか正直やってられません。
（「メモリの無駄遣い♠」とヒソカさんも仰ってます）

また、話が逸れたので戻します。

まず読み込みですが、「1回で4KBの読み込みが可能」と記載しました。

こちらは最小単位を4KBとするので例えば2KBのデータを読み込むのでも1回の読み込みが必要です。
逆に6KBのデータを読むのであれば、2回の読み込みが必要です。

書き込みは、「1回で1KBの読み込みが可能」となります。
読み込みに比べて、書き込みはデータ容量が減っているのがポイントです。

費用の所でお話ししますが、そもそもDynamoは「大量に書き込む」というのに向いていません。

冒頭で、Dynamoが好きでまずはDynamoを検討する、と言いましたが意外と向いてないケース多いんすよ。DynamoDB。

この読み込み、書き込みの設定は「キャパシティ」にて設定が可能です。

こんな感じですね。

上記の設定は、読み込みが「5」、書き込みが「1」で設定しています。
なお、この場合、

となっています。

この設定で20KBを超えるデータを読み込んだらどうなるの？、と疑問に思うかもしれません。

例えば、100KBのデータを読み込んだとしましょう。
そうすると、100KB ÷ (5×4KB) =5 となります。

要するに読み込みが完了するに5秒かかるという訳です。

当然、その間データがもらえないのでアプリ側は待ちぼうけです。
たった100KBのデータを読み込むのに5秒もかかるなんて許せない。という方はこのキャパシティ設定を弄ってあげてください。

通常、RDBの場合、性能はサーバやディスクのスペックに依存します。
そのため、性能を上げたい場合はハードウェアを交換（AWSの場合はタイプ変更）をする必要がありました。

DynamoDBはそんなことをする必要はなく、「キャパシティ」の設定を変えればよいだけです。
超便利です。すごいですねー。

DynamoDBの費用（プロビジョン）

DynamoDBの費用はこんな感じです。
ぶっちゃけ、ほぼ全てキャパシティに依存すると言っても過言ではないでしょう。

うわー、全く良く分からん。という方もご安心ください。
多分このAWSの説明だとぱっと見、誰も分からないです。

まぁ、実際には計算もできますが、一応こんな感じでキャパシティ設定の際に「推定コスト」をAWSが出してくれます。

読み込みが「5」で、書き込みが「1」だと1.11 USDなんですって。

費用を注意深く見ると分かりますが、書き込みは読み込みの5倍費用が高いです。（0.000742 / 0.0001484 = 5）

なので、読み込みはそこまで影響しないと思って貰って大丈夫です。
（書き込みはほぼ無いけど、読み込みは大量にあるよ。という場合はちゃんと読み込み費用を意識してください。）

〇 プロビジョンキャパシティの参考費用

まぁ、大体こんな感じだよ。という参考にしていただければと思います。

残念ながらボリュームディスカウント（？）は効きません。

DynamoDBの費用（オンデマンド）

「おいおい、いまどきプロビジョンなんて使わねーよ。オンデマンドを出せよ。」
という方もいると思うので、オンデマンドの費用も載せておきましょう。

オンデマンドは、プロビジョンとは異なり、読み込み・書き込みを可変で必要なだけ提供してくれるモードになります。
この設定にしておけば、急に書き込みや読み込みが必要になっても、処理性能が間に合わずアプリが待ちぼうけになるという事はありません。

「じゃあ、全部オンデマンドでイイじゃん。」と思うかもしれませんがそんなことはありません。
便利な物は便利な物で何かしら制約が付くものです。（「リスクはバネ！！ 制約と覚悟が大きい程念は強く働く！！」）

ではオンデマンドの制約とは何でしょうか。

これは「費用」になります。

という訳でオンデマンドの費用を見ていきましょう。

うわー、全く良く分からん。（2回目）という方もご安心ください。
多分このAWSの説明だとぱっと見、誰も分からないです。

というかこれ絶対ワザと分かり難くしてるでしょ。という感じですね。
なんでプロビジョンは1WCU、1RCU当たりの費用で、オンデマンドは100万あたりになってんだよ。と誰しもが思うはずです。
※費用はAWSの公式サイトの記載をそのまま持ってきてます。園田が加工したわけではありません。まぁ、性質が異なるので併せられないのは分かるのですが。

仕方ないので、単位を揃えてみます。
1時間で100万リクエストの書き込みをこなす場合で計算します。

計算した結果の金額
0.206 USD

これならわかりますね。

という訳で、オンデマンドはプロビジョンの「約3.5倍費用が高い」と思ってください。

でもだいぶ安くなりましたね。オンデマンドが出た当初って、約7倍の費用だったんすよ。
結構、値下げしましたね。

プロビジョンとオンデマンドってどっちがいいの？

結論としては適材適所です。
アプリケーションの性質に合わせてご利用ください。

オンデマンドの費用で確認した通り、プロビジョンと同じ性能をオンデマンドに求める場合、費用が3.5倍になります。

そのため、安定しているワークロードの場合、プロビジョンが向いているでしょう。
想定の2倍ぐらいの性能を確保したとしてもオンデマンドより安い費用で利用が可能です。

逆に安定していないワークロードの場合、いきなり書き込み、読み込みが通常の100倍になるとか、そんな場合は通常の100倍の費用をプロビジョンで確保すると高くなるので、オンデマンドの方がいいですね。

突然のスパイクにも耐えられる構成になります。

ちゃんと頭を使わないといけない、というのもDynamoDBの良いところです。
「きちんと要件定義して設計しろよ。」という無言の圧力を感じます。
ステキです。

DynamoDBのステキな所まとめ

まとめです。

まぁ、大体こんな感じの事を知っておけば良いでしょう。

あくまでDynamoDBはNoSQLなので整合はアプリ側で確保する必要があります。
また、SQLで条件を指定することも難しいです。というか出来ません。

それを差し引いても良いところがあるので、使える所にはDynamoDB使いましょう。
というのがまとめになりますね。

なお、費用の話ですが、DynamoDBでデータの洗い替えとか絶対にやめてください。
書き込みキャパシティの費用がとんでもないことになります。

ホント製品（サービス）を理解した上での設計が非常に重要です。

クラウドじゃなくても設計重要ですけど、クラウドは大体お金に跳ね返ってきます。

大ダメージを食らう前にきちんと設計お願いします。

終わりに

という訳で、「いまさら聞けないDynamoDBの話」でした。

現在、皆さんが髭を剃る際は、自宅で髭剃りを利用していると思います。
（電気シェーバーとT字カミソリとか、いろんな種類がでていますね。）

今では自宅で髭を剃るのは当たり前ですが、所謂安全カミソリが出来る前は「床屋に行って髭を剃る」ことが当たり前でした。
そのため、頻繁に床屋さんにいって、髭を剃っていたわけです。

なので、床屋さんに行くことは「常識」だったわけです。
（まぁ、自分でも剃ることもできましたが、技術がいるし危ないので現実的ではなかったのです。）

ただ、利用者は「床屋さんに行きたい」わけではなく「（きれいに、安全に）髭を剃りたかった」だけなのです。
結果として、安全カミソリが出来たことで、床屋さんで髭を剃ることは無くなりました。

この安全カミソリは、ユーザの実際にしたいことをきちんと把握し、世界を変えた例ではないでしょうか。

ITの世界もデータの入れ物が欲しいだけで、別にデータベースが欲しいわけではありません。

AWSはクラウドで色々なこれまでの常識（normal）を変えていますが、DynamoDBはそれをよく表しているサービスだなと強く感じます。

クラウドサービスを体現したようなDynamoDBを皆さんもぜひ使ってみてください。

ではまた、別の記事でお会いしましょう。