２０１５１０３０

1. 現場で使えるDynamoDB
と冪等デザインパターン
2015.10.30 Yusuke Arai, Classmethod Inc.

2. 自己紹介
• 荒井祐輔 (モバイルアプリサービス部)
• 2014.11 AndroidチームにJOIN
• 2015.04 モバイルバックエンドのScalaチームにJOIN
• Scala や API Gateway のブログをよく書いてます
• 普段は Amazon DynamoDB を Scala から JavaSDK を介
して使用しています

3. 現場で使えるDynamoDB
と冪等デザインパターン

4. むしろ

5. もっと使おう！
DynamoDB
冪等だってあるんだよ！

6. 今回のもくろみ

7. もっとラフに
DynamoDB を
使ってほしい

8. 使ってみたいけど
何ができて
何ができないのか
よくわからない

9. 使いたいけど
個人アプリだから
マネーが…

10. とりあえず
RDSで…

11. 高可用性・高堅牢性
以外にも
DynamoDB を
使うべき
理由があります！

12. •DynamoDBってなんだ
•できること/できないこと
•もっと使うために
アジェンダ

13. •DynamoDBってなんだ
•できること/できないこと
•もっと使うために
アジェンダ

14. DynamoDB

15. KVS
NoSQL

16. スケーラブル

17. かつ

18. スキーマレス

19. 1アイテム
64KBまで
可能

20. フルマネージド

21. Capacity
Unit
単位で課金

24. 10書き込みユニット
秒間10書き込み
5.5 米ドル / 月

25. 50読み込みユニット
＝ 秒間50読み込み
5.5 米ドル / 月

26. •DynamoDBってなんだ
•できること/できないこと
•もっと使うために
アジェンダ

27. できること

28. Keyに対する
ValueのCRUD

29. 簡単なクエリやオーダー

30. できぬこと

31. JOIN

32. TRANSACTION
AND
COMMIT

33. 詳細なクエリやオーダー

34. マネーが
かかること

35. 大量のRead/Write

37. • できぬこと
• JOIN
• TRANSACTION AND COMMIT
• 詳細なクエリやオーダー
• マネーがかかること
• 大量のRead/Write

38. • できぬこと
• JOIN 頑張れる
• TRANSACTION AND COMMIT
• 詳細なクエリやオーダー
• マネーがかかること
• 大量のRead/Write

39. 詳細なクエリやオーダー
フレキシブルな検索を
提供するには
100%向いていない

40. ふと立ち止まる

41. このアプリに
フレキシブルな
検索機能は
必要だろうか

42. Remember:
You Ain t
Gonna
Need It

43. • できぬこと
• JOIN 頑張れる
• TRANSACTION AND COMMIT
• 詳細なクエリやオーダー 向いてない
• マネーがかかること
• 大量のRead/Write

44. • できぬこと
• JOIN 頑張れる
• TRANSACTION AND COMMIT
• 詳細なクエリやオーダー 向いてない
• マネーがかかること
• 大量のRead/Write

45. •DynamoDBってなんだ
•できること/できないこと
•もっと使うために
アジェンダ

46. TRANSACTION
大量のRead/Write

47. TRANSACTION

48. トランザクション
コミット
ロールバック
に相当する機能は用意
されていない

49. ないものはない

50. ないときつい
銀行口座のお金の振り込み
ゲーム内アイテムの受け渡し
ネットショップ買い物カゴ購入
なくてもいける
銀行口座の入金
ゲーム内アイテムの購入
買い物カゴを使わない単品購入
TRANSACTION

51. 現実的には
アプリケーションレイヤで
ある程度の堅牢さを
保証する必要が出てくる

52. 一連の処理が
どこかで失敗した
場合について考える
のは難しい

53. 処理のリトライの
しやすさを高めることで
"失敗" することを恐れない
ように持っていく

54. 冪等デザインパターン

55. 冪等デザインパターン

56. 何度実行しても
同じ結果になること
(※同じパラメータを渡した場合に)

57. 簡単な例

58. POST /api/v1/accounts/john/charge
{
"request_id": "ABCDEFG",
"charge_amount": 20000
}
user (Hash) request_id (Range) status
user (Hash) amount
john 5000
charge_events
users

59. POST /api/v1/accounts/john/charge
{
"request_id": "ABCDEFG",
"charge_amount": 20000
}
user (Hash) request_id (Range) status
john "ABCDEFG" "Start"
user (Hash) amount
john 5000
charge_events
users

60. POST /api/v1/accounts/john/charge
{
"request_id": "ABCDEFG",
"charge_amount": 20000
}
user (Hash) request_id (Range) status
john "ABCDEFG" "Start"
user (Hash) amount
john 25000
charge_events
users

61. POST /api/v1/accounts/john/charge
{
"request_id": "ABCDEFG",
"charge_amount": 20000
}
user (Hash) request_id (Range) status
john "ABCDEFG" "Finished"
user (Hash) amount
john 25000
charge_events
users

62. APIを冪等にしておけば
クライアントは
臆せずリトライできる

63. 一連の処理が
どこかで失敗しても
成功するまでリトライして
処理を続行させる

64. 大量のRead/Write

65. 直近50回の
つぶやきを
を表示

67. 50 Read
equals
50読み込みユニット

68. 5.5 米ドル / 月
…?

69. スレッド形式
の
掲示板

70. 最大
1000レス

71. 1000 Read
equals
1000読み込みユニット

72. 108 米ドル / 月
!?

73. バッチ処理で
クーポン情報を
2000件挿入

74. 2000 Writes
equals
2000書き込みユニット

75. 1,080 米ドル / 月
!?!?

76. NO

77. Burst
Capacity

78. 五分間分の
Capacity Unit
を確保している

79. Capacity
Unit が余ると
蓄積されていく

81. 10 Read Units
may handle
3000 Read Accesses
in the case of
Burst Capacity

82. リトライを
しっかり行えば
怖くない

83. ページング

85. Scan/Query
と
Limit

86. Scan/Queryは
読み込み件数ではなく
結果サイズに対して
Capacity Unit 消費

87. demo※時間があれば

88. まとめ

89. TRANSACTION
大量のRead/Write

91. 読み込み Burst Capacity = 1500 / 5min
書き込み Burst Capacity = 300 / 5min

92. Amazon
DynamoDB
は 1米ドル / 月 でも
それなりに活躍します

93. Amazon API Gateway
&
AWS Lambda
in 東京

94. DynamoDB
一択
※SimpleDB もあります
※そのうち Lambda in VPC も

95. もっとラフに
DynamoDB を
使っていこう！

96. ご清聴ありがとう
ございました