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

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

1. 1. 現場で使えるDynamoDB と冪等デザインパターン 2015.10.30 Yusuke Arai, Classmethod Inc.
2. 2. 自己紹介 • 荒井祐輔 (モバイルアプリサービス部) • 2014.11 AndroidチームにJOIN • 2015.04 モバイルバックエンドのScalaチームにJOIN • Scala や API Gateway のブログをよく書いてます • 普段は Amazon DynamoDB を Scala から JavaSDK を介 して使用しています
3. 3. 現場で使えるDynamoDB と冪等デザインパターン
4. 4. むしろ
5. 5. もっと使おう！ DynamoDB 冪等だってあるんだよ！
6. 6. 今回のもくろみ
7. 7. もっとラフに DynamoDB を 使ってほしい
8. 8. 使ってみたいけど 何ができて 何ができないのか よくわからない
9. 9. 使いたいけど 個人アプリだから マネーが…
10. 10. とりあえず RDSで…
11. 11. 高可用性・高堅牢性 以外にも DynamoDB を 使うべき 理由があります！
12. 12. •DynamoDBってなんだ •できること/できないこと •もっと使うために アジェンダ
13. 13. •DynamoDBってなんだ •できること/できないこと •もっと使うために アジェンダ
14. 14. DynamoDB
15. 15. KVS NoSQL
16. 16. スケーラブル
17. 17. かつ
18. 18. スキーマレス
19. 19. 1アイテム 64KBまで 可能
20. 20. フルマネージド
21. 21. Capacity Unit 単位で課金
22. 22. 10書き込みユニット 秒間10書き込み 5.5 米ドル / 月
23. 23. 50読み込みユニット ＝ 秒間50読み込み 5.5 米ドル / 月
24. 24. •DynamoDBってなんだ •できること/できないこと •もっと使うために アジェンダ
25. 25. できること
26. 26. Keyに対する ValueのCRUD
27. 27. 簡単なクエリやオーダー
28. 28. できぬこと
29. 29. JOIN
30. 30. TRANSACTION AND COMMIT
31. 31. 詳細なクエリやオーダー
32. 32. マネーが かかること
33. 33. 大量のRead/Write
34. 34. • できぬこと • JOIN • TRANSACTION AND COMMIT • 詳細なクエリやオーダー • マネーがかかること • 大量のRead/Write
35. 35. • できぬこと • JOIN 頑張れる • TRANSACTION AND COMMIT • 詳細なクエリやオーダー • マネーがかかること • 大量のRead/Write
36. 36. 詳細なクエリやオーダー フレキシブルな検索を 提供するには 100%向いていない
37. 37. ふと立ち止まる
38. 38. このアプリに フレキシブルな 検索機能は 必要だろうか
39. 39. Remember: You Ain t Gonna Need It
40. 40. • できぬこと • JOIN 頑張れる • TRANSACTION AND COMMIT • 詳細なクエリやオーダー 向いてない • マネーがかかること • 大量のRead/Write
41. 41. • できぬこと • JOIN 頑張れる • TRANSACTION AND COMMIT • 詳細なクエリやオーダー 向いてない • マネーがかかること • 大量のRead/Write
42. 42. •DynamoDBってなんだ •できること/できないこと •もっと使うために アジェンダ
43. 43. TRANSACTION 大量のRead/Write
44. 44. TRANSACTION
45. 45. トランザクション コミット ロールバック に相当する機能は用意 されていない
46. 46. ないものはない
47. 47. ないときつい 銀行口座のお金の振り込み ゲーム内アイテムの受け渡し ネットショップ買い物カゴ購入 なくてもいける 銀行口座の入金 ゲーム内アイテムの購入 買い物カゴを使わない単品購入 TRANSACTION
48. 48. 現実的には アプリケーションレイヤで ある程度の堅牢さを 保証する必要が出てくる
49. 49. 一連の処理が どこかで失敗した 場合について考える のは難しい
50. 50. 処理のリトライの しやすさを高めることで "失敗" することを恐れない ように持っていく
51. 51. 冪等デザインパターン
52. 52. 冪等デザインパターン
53. 53. 何度実行しても 同じ結果になること (※同じパラメータを渡した場合に)
54. 54. 簡単な例
55. 55. 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
56. 56. 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
57. 57. 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
58. 58. 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
59. 59. APIを冪等にしておけば クライアントは 臆せずリトライできる
60. 60. 一連の処理が どこかで失敗しても 成功するまでリトライして 処理を続行させる
61. 61. 大量のRead/Write
62. 62. 直近50回の つぶやきを を表示
63. 63. 50 Read equals 50読み込みユニット
64. 64. 5.5 米ドル / 月 …?
65. 65. スレッド形式 の 掲示板
66. 66. 最大 1000レス
67. 67. 1000 Read equals 1000読み込みユニット
68. 68. 108 米ドル / 月 !?
69. 69. バッチ処理で クーポン情報を 2000件挿入
70. 70. 2000 Writes equals 2000書き込みユニット
71. 71. 1,080 米ドル / 月 !?!?
72. 72. NO
73. 73. Burst Capacity
74. 74. 五分間分の Capacity Unit を確保している
75. 75. Capacity Unit が余ると 蓄積されていく
76. 76. 10 Read Units may handle 3000 Read Accesses in the case of Burst Capacity
77. 77. リトライを しっかり行えば 怖くない
78. 78. ページング
79. 79. Scan/Query と Limit
80. 80. Scan/Queryは 読み込み件数ではなく 結果サイズに対して Capacity Unit 消費
81. 81. demo※時間があれば
82. 82. まとめ
83. 83. TRANSACTION 大量のRead/Write
84. 84. 読み込み Burst Capacity = 1500 / 5min 書き込み Burst Capacity = 300 / 5min
85. 85. Amazon DynamoDB は 1米ドル / 月 でも それなりに活躍します
86. 86. Amazon API Gateway & AWS Lambda in 東京
87. 87. DynamoDB 一択 ※SimpleDB もあります ※そのうち Lambda in VPC も
88. 88. もっとラフに DynamoDB を 使っていこう！
89. 89. ご清聴ありがとう ございました