検証＆得た知見を社内勉強会で発表

1. DynamoDB
はじめの一歩
sh-ogawa

2. はじめに
DynamoDBの検証に伴い、ドキュメントを読み込んだので、知見を共有。
DynamoDBを使用する際に、
地雷を踏まない（であろう）アーキテクチャ設計が行えるようになることを目
的とする。

3. (; ･`д･´)

4. 検証しただけで運用はしてないので、
ハードルは少し下げさせていただく！！

5. 質問は都度していただいてＯＫです

6. 答えられるかは判らないけど

7. コンテンツ
● DynamoDBとは
● 重要な用語
● 仕組み
● 課金体系
● メリット
● デメリット
● 事故らないためのアーキテクチャ設計

8. DynamoDBとは
● AWS上で利用可能なフルマネージドなNoSQLデータベースサービス
● スキーマレス
● ３つの施設間でデータが同期的にレプリケート
● SSDに保存
● データの操作はHTTP(S)リクエストで行う

9. 重要な用語

10. 重要な用語
キャパシティーユニット

11. 重要な用語
これだけ覚えれば大丈夫

12. 重要な用語
● キャパシティーユニット(CU)
１秒間に消費できるリソースを定義する単位。
読込みと書込みのそれぞれに設定する。

13. 重要な用語
● キャパシティーユニット(CU)
１秒間に消費できるリソースを定義する単位。
読込みと書込みのそれぞれに設定する。
「例えば、読込みキャパシティーユニットに「10」を設定した場合、
１秒間に利用できる読込みリソースは「10」である」と云える(超重要)
※消費リソースの算出方法は後ほど・・・

14. 仕組み

15. 仕組み
保存するストレージは
物理的に分かれている

16. 仕組み
どのストレージに書か
れるかは、PKの値で
決まる

17. 仕組み
PKとは・・・
プライマリキーのこと。
以下のどちらかで作成可能
・HASH
・HASH + Sort Key
なので、RDBMSで云うところの複合PKは、２個までしか選べない
3個以上選びたい場合は、ロジックでキーを作ってカバー！！

18. 課金体系
無料利用枠を超えると課金が発生する
無料利用枠
● ２億リクエスト／月
※25の読込書込キャパシティユニットで超えない程度
● 25GBのデータストレージ（データ + インデックス分）
● DynamoDBストリームからの250万件読込み／月

19. 課金体系
無料利用枠を超えると課金が発生する
無料利用枠
● ２億リクエスト／月
※25の読込書込キャパシティユニットで超えない程度
● 25GBのデータストレージ（データ + インデックス分）
● DynamoDBストリームからの250万件読込み／月
何言ってるのか判りづらいけど、
ストレージ以外は毎月無料枠があるよ！
ってことです。

20. 課金体系
無料利用枠を超えると課金が発生する
無料利用枠
● ２億リクエスト／月
※25の読込書込キャパシティーユニットで超えない程度
● 25GBのデータストレージ（データ + インデックス分）
● DynamoDBストリームからの250万件読込み／月

21. 課金体系
25の読込書込キャパシティーユニットで超えない程度

22. 課金体系
(; ･`д･´)意味不明！！

23. 課金体系
キャパシティーユニットの消費量について教えます

24. 課金体系
● 読込みキャパシティーユニット(RCU)
１つのキャパシティーユニットで、1秒間に最大4KBを
「１回の整合性のある強力な読込み」
or
「２回の結果的に整合性のある読込み」
を行える。

25. 課金体系
意味・・・判るよね？

26. 課金体系
データ量で表すとこや！

27. 課金体系
● １キャパシティーユニットで1KBを読み込む
強力な～ ・・・1消費するので１秒間で１回読める
結果的に～・・・1消費するので１秒間で２回読める（スループット２倍）
● １キャパシティーユニットで4KBを読み込む
強力な～ ・・・1消費するので１秒間で１回読める
結果的に～・・・1消費するので１秒間で２回読める（スループット２倍）
● １キャパシティーユニットで5KB読み込む
強力な～ ・・・2消費するので２秒間で１回読める
結果的に～・・・2消費するけど１秒間で１回読める（スループット２倍だから）

28. 課金体系
なので、
１秒間で読み込めるようにするには
キャパシティーユニットを増やす

29. 課金体系
こうなる

30. 課金体系
● １キャパシティーユニットで1KBを読み込む
強力な～ ・・・1消費するので１秒間で１回読める
結果的に～・・・1消費するので１秒間で２回読める（スループット２倍）
● １キャパシティーユニットで4KBを読み込む
強力な～ ・・・1消費するので１秒間で１回読める
結果的に～・・・1消費するので１秒間で２回読める（スループット２倍）
● ２キャパシティーユニットで5KB読み込む
強力な～ ・・・2消費するので１秒間で１回読める
結果的に～・・・2消費するけど１秒間で２回読める（スループット２倍だから）

31. 課金体系
以下の計算式で考えてあげればOK（先にこっち出せとか言わないで・・・）
● 強力な～ ・・・（キャパシティユニットの値）×４KB／秒
● 結果的に～・・・（キャパシティユニットの値 × 2）×４KB／秒

32. 課金体系
● 書込みキャパシティーユニット(WCU)
１つのキャパシティーユニットで、1秒間に最大1KBを書込める。

33. 課金体系
● １キャパシティーユニットで1KBを書き込む・・・１消費（１秒でイケる）
● １キャパシティーユニットで1.1KBを書き込む・・・２消費（２秒かかる）
● ２キャパシティーユニットで1.1KB読み込む・・・２消費（１秒でイケる）

34. 課金体系
こっちは1KB未満の端数切り上げ
という簡単な理屈ですね

35. 課金体系
無料利用枠
● ２億リクエスト／月
※25の読込書込キャパシティーユニットで超えない程度
● 25GBのデータストレージ（データ + インデックス分）
● DynamoDBストリームからの250万件読込み／月
有料枠
● 25GB以上のデータストレージに、0.285USD/GBを毎月払う

36. メリット
● どんなにデータを保存しても、パフォーマンスは安定している
※使い方を誤らなければ
● DSLに則ってJSONを書けばいいだけなので、専門スキルは不要
● 書込み元が多いほど、威力を発揮する

37. デメリット
● パフォーマンスを出させる場合、基本的に札束で殴るスタイル
（と言っても、そこまで高額なわけではない。
保存しているデータ量だけ注意してあげる）
● NoSQLなので、トランザクションの概念はない
（RDB使ってても、
厳密なトランザクション管理をしないといけない場面はほとんどない）

38. 事故らないためのアーキテクチャ設計
可能な限り
横に並べて殴る
（特に書込み）

39. 事故らないためのアーキテクチャ設計
これだけ

40. 事故らないためのアーキテクチャ設計
外部ライブラリ使ってデータを登録する場合は、
そのライブラリがちゃんとマルチスレッドか、
子プロセスを立ち上げてデータ登録をしていることを確認
しておく。

41. 利用シーン
● ログの集約
特にコンテナ化されているもの、マイクロサービス化したシステム群
● IoT周り
デバイスから直、フォグサーバ経由
● 膨大な履歴データの保持
何かのタイミングでスリムアップはした方が良いと思う

42. おしまい