アンサーにおけるDynamoDBの運用経験から、非経験者に向けてハマりポイントなどを解説しました。

1. 日本最大の即レスサービス
「アンサー」を支える
Amazon DynamoDB
2015/6/3
at AWS Summit Tokyo 2015 デベロッパーカンファレンス
nanapi Inc. Masahiro Akita

2. 自己紹介
•2011年4月nanapi入社 (5年目)
•主にサーバーサイドをやってます
•akiyan.com という個人ブログを書いてます
秋田 真宏 / あきやん
株式会社 nanapi エンジニア (社員)
2

3. アンサーとは
•即レスコミュニケーションサービス
•iOS / Android ネイティブアプリ展開
•リリースから約1年半
•2014年12月時点で累計1億コメント
3

4. こんな感じ
4

5. DynamoDBとは
•フルマネージドで管理不要なデータストア
•マルチAZに分散保存で高可用性
•設定値だけで自動スケール
•合計容量の限界なし
•スループット課金
•スキーマレス
•インデックスが作れる
5

6. デベロッパーにとってのDynamoDBとは
なんかすごい夢のデータストアサービス？
6

7. DynamoDBを運用する前のイメージ
•お金をかければかけたぶんだけスケール
するらしくてすごい
•KVS(NoSQL)だけどインデックスも張れ
るからRDBの代わりにもなりそう
•インデックスを張らなくても強引にRDB
的なこともできそう
7

8. DynamoDBを運用した後のイメージ
•DynamoDBはKVSである
•RDBの代わりとして使うべきではない
•前提を理解していればスケールする
•前提を理解していなければスケールしな
い
8

9. 今回の発表の立ち位置
アンサーにおけるDynamoDBの
運用後に得られた経験から
運用前の自分に向けて伝えたいこと
9

10. 話す内容
•DynamoDBの基礎と導入の経緯
•スループットにまつわるあれこれ
•スケーラビリティの確保
•インデックスとは何か
•インポートのベストプラクティス
•バックアップは難しい
•おすすめの学習方法
10

11. DynamoDBの基礎知識
11

12. DynamoDBの基礎の基礎
•テーブルの種類
•スループット
•主なAPI
12

13. テーブルの種類
•テーブルは2種類ある
•HASHテーブル
•HASH + RANGEテーブル
13

14. HASHテーブル
•一意なキーでItemが決定する、いわゆる
KVS的なテーブル
•できることがKVS以上でも以下でもない
ので、安心して使える
14

15. HASH + RANGE テーブル
•HASHキーとRANGEキーの2種類の値の組み
合わせでItemが決定する
•HASHとRANGEの組み合わせはユニークで
ある必要がある
•HASHキーのみでも取り出すことができる
•HASHキーに追加でRANGEキーを対象に範
囲など条件指定して取得が可能
•取得時にRANGEキーで昇順降順のソートが
可能
15

16. スループットとは
•DynamoDBが内部のパーティション(ス
トレージ)からItemを読み書きした容量
•ネットワークの転送量ではない
•必要なスループットは予め設定し、設定
値によって1時間単位で課金される
•設定値は「キャパシティーユニット (CU)」
と呼ぶ
•設定値の変更はオンラインで実行可能
16

17. 主なAPI
•getItem (1件取得)
•query (1HASHに対してRANGEキーで
検索複数取得)
•putItem (1件更新)
•updateItem (特定のカラムを更新、アト
ミックインクリメント等)
17

18. DynamoDBの導入経緯
18

19. RDBの限界
•RDS上のMySQLでマスタースレーブ構成
•1000万レコード級のALTERは辛い
•ALTERすると派手にスレーブ遅延する
•ALTERするときは一時的にマスターDBをス
ケールアップしてアクセスを集中させていた
•マスターDBのスケールアップの限界が見え
てきた
19

20. 少ない手間でスケールする点に注目
•DynamoDBは設定だけでスケールして限
界が無いのが素敵すぎるしフルマネージ
ドで管理不要
•レスポンスは十分速そう
•容量課金は安そう
•スループット課金はどれくらいになるか
わからないが、他のメリットが大きいの
で許容されるリスクとした
20

21. 実際の用途
•投稿内容のレプリカ
•スポット参加状態のレプリカ
•ユーザーログインセッション
•シーケンス生成器
21

22. スループットのコスト
22

23. コストはキャパシティーユニットの設定値で決まる
•キャパシティーユニットは読み書き別々に
設定する
•書き込みユニットは1WCUあたり1KBの
性能で、10ユニットで $0.00742
(Tokyo) / 時間
•読み込みユニットは1RCUあたり4KBの性
能で、50ユニットで $0.00742（Tokyo)
/ 時間
•性能は「秒間あたり」の性能となる
23

24. スループット課金額例
•毎秒 100KB の読み込みスループットを
確保するには 100KB / 4KB = 25 RCU
が必要
•$ 0.00742 * 25(RCU) * 24(hour) *
30(days) = $ 133 / Month
24
Itemサイズ平均 １KB
1リクエストあたり 10Item読み込み
秒間アクセス 10アクセス

25. スループット消費量の確認方法
•現在消費しているスループットはマネジ
メントコンソールから5分単位で確認でき
る
•リクエストごとに消費したスループット
は、APIの返り値で確認できる（ただしお
およそで、多めに盛られ気味）
25

26. スループット消費グラフ
26

27. 消費スループットのAPIの返り値
# aws dynamodb query … ̶return-
consumed-capacity TOTAL ¦
jq .ConsumedCapacity
{
"CapacityUnits": 1.5,
"TableName": expample_table
}
27

28. DynamoDBの主なコストはスループット
•DynamoDBのコストボトルネックはスルー
プット量になる
•容量課金は安い (そもそも大きなデータを
格納できないし、しないし、データが大
きいとスループットのほうが先に高額に
なる）
•転送量課金も安い（同一リージョン内な
ら無料）
28

29. スループット増大に注意
29

30. RDBのように使うとスループットが増えがち
•RDBのように多めのレコードを富豪的に
読み込もうとすると、スループット破産
する
•どうしてもRDB的に使うなら、テーブル
をカラムごとの利用頻度によって分割し
たり、アイテムごとにキャッシュしてス
ループット消費を抑えよう
30

31. スループット破産例
•例えば256KBのItemを50件読み込む要
件があると、少なくとも一度に「1,600
RCU」を消費する
•1600 RCU をプロビジョニングすると月
額 $170 (Tokyo) が必要
•この要件で毎秒あたり10ユーザーが同時
アクセスして遅延なく応答するには
16,000 RCU が必要になり月額 $1,900
の課金になる。
31

32. KVSのように使おう
•RDBのように使わずKVSのように使って
いれば現実的なスループットに収まるは
ず
•スループット消費を抑えようとすると、
結果的にKVS的な利用に限定される
•スループット課金額からして、DynamoDB
はそもそもKVS的な利用を想定している
と思う
32

33. KVS的な使い方とは
•KVSでは毎回大量のItemを読み書きした
りはしない
•KVSでは1Itemをやたら大きくしたりは
しない
•256KBはDynamoDBとしては大きすぎ
る部類。最大でも400KB
33

34. 節約できそうでできない
スループット
34

35. DynamoDBは一度に複数Itemの取得が可能
•「query」で、RANGEテーブルやインデッ
クスから一度に複数Itemを読み込むこと
ができる
•HASH のみか、HASH と RANGE の条
件指定での読み込みが基本
35

36. LIMITをつけてもスループットは節約できない
•「LIMIT」はquery APIのパラメータ
•パーティションから複数のItemを読み込ん
だ後に、結果セットの数を制限してくれる
•LIMITの指定でスループットは減ることは
ない
•HASH + RANGE テーブルで、RANGEの
指定無しでもLIMITをつければいかにもス
ループットが減りそうだが、減らない
36

37. HASH + RANGE テーブルでスループット消費を抑えるには
•先頭n件を取得する場合、スループットを
節約しようとするなら、適当なRANGEキー
を範囲指定しなければならない
•適当なRANGEキーの決定は通常は無理が
ある場合がほとんど
•スループット消費低減のためにインデック
スを用意すると、追加の書き込みスループッ
トが必要になるので悩ましい
•あちらを立てればこちらが立たず状態
37

38. そもそもn件取得はKVS的でない
•「先頭/末尾のn件を取得」という要件が、
そもそもKVS的でない (DynamoDBに向
いていない)
•時系列データをスループット消費の観点で
効率的に読み込むには前提と工夫が必要
•例えば「Itemは24時間以内に必ずexpire
する」などの前提があれば、RANGE値を
24時間のexpireに限定してクエリに指定
できる
38

39. フィルタを指定してもスループットは節約できない
•「フィルタ」はquery APIのパラメータ
•パーティションからItemを読み込んだ後
に、結果セットのデータを絞り込んでく
れる機能
•絞り込み条件にはあらゆるキーを指定出
来る
•読み込んだあとの絞り込みなので、スルー
プットは絞り込み前の結果で消費される
39

40. フィルタの使いどころ
•query は結果セットの容量に1MBの制限
がある
•結果セットが1MBを超えるようなリクエ
ストで、取得後に絞り込みが必要な場合
の、リクエスト回数の削減用
•転送量の削減にもなる
•アプリケーションサーバー側のCPU節約
としてもよい
40

41. LIMITとフィルタを組み合わせると、LIMITが先に適用される
•LIMITとフィルタを組み合わせると、
「LIMITで制限してからフィルタで絞り込
む」という挙動になり、LIMITの数より少
ない結果セットになる
•RDB脳からすると直感的でない挙動
41

42. スループットの主な節約手段
•キャッシュの活用
•「結果整合性」での読み込み
42

43. 「結果整合性」とは
•DynamoDBからの読み込みには「強い整
合性」と「結果整合性」の2種類があり、
場合によって選択可能
•「結果整合性」は「強い整合性」の読み
込みに比べて、 半分のスループットで読
み込める
43

44. 整合性をRDBに例えるなら
•「強い整合性」はマスターDBからの読み
込み相当。完了済みの書き込みAPIリクエ
ストの結果が確実に取得できる
•「結果整合性」はスレーブDBからの読み
込み相当。書き込み同期遅延(レプリカラ
グ)の発生が前提
•遅延が許される箇所であれば積極的に「結
果整合性」での読み込みを行う
44

45. スループットが足りない時は
45

46. いつスループットが足りなくなるのか
•一度のリクエストで消費できるスループッ
トは限られている
•プロビジョニングされたスループットと、
現在消費されているスループットの差で、
1度に消費できるスループット量が決まる
46

47. スループットが足りないときの挙動
•getItem(1件の取得)であれば、回復まで
待たされるかタイムアウトする
•query(複数件の取得)の場合、残量ぶんの
Itemを読み込んだらその次点で結果セッ
トを返す
•ゆえに、複数取得では1リクエストで全て
のItemを取得できないことがある
47

48. 複数取得では再帰実行が必須
•複数件を確実に取得するには、再帰的な
処理を仕込む必要がある
•APIの返り値に追加読み込み用の項目があ
るので、それを元に再帰実行するかを判
断できる
•結果セットの容量に1MBの制限があり、
こちらも同様の考慮が必要になる
48

49. スループットのオートスケーリングは無い
•DynamoDBの機能としてのオートスケー
リングは無く、サードパーティ製のスケー
ラがあり、公式から推奨されている
•KVS的な利用に限定していれば、そこそこ
の規模まで十分安く運用できるのでオート
スケールは最初は気にしなくていい
•スケールアップ回数は無限だが、スケール
ダウンは1日4回まで
49

50. 隠れスループットの存在
•設定値とは別に隠れたスループットが用意
されており、ユーザーも使用可能
•ただしこれはAWS側がメンテナンスのた
めに用意したスループットなので、いつで
も使えることを期待してはいけない
•とはいえ開発環境用の小さなスループット
設定のテーブルに対してバッチ実行をする
ときなどに、スループットがバーストして
いるように振る舞うのでそこそこ便利
50

51. スケーラビリティの確保
51

52. スケールに必要な前提とは
•ハッシュアクセスを分散させる
•パーティションの分割を想定する
52

53. ハッシュアクセスを分散させる
•同一HASHへの連続した書き込みは、分
散したHASH書き込みに比べて性能が低
い
•PVや投票のような激しい書き込み用途に
使う際は、HASHを分割して保存するな
ど工夫が必要
•RANGEが異なってもHASHが同じ場合は、
同一HASHとみなされる
53

54. パーティションの分割を想定する
•容量もしくはプロビジョニング量によってデータ
が複数のパーティションに分割され、プロビジョ
ニングされたスループットはパーティションごとに
均一に振り分けられる
•パーティション分割は容量が10GB単位、スループッ
トは RCUを3000で割った数とWCUを1000で割っ
た数の合算値で決まる
•パーティションが複数で、アクセスされるハッシュ
が偏ると、スループットを使い切れない場合がある
54

55. 容量増加で性能低下する場合がある
•10GBと3,000 RCUはそうそう到達しないが、
それでも想定する必要はある。特に容量
•アンサーではコメントデータをDynamoDB
に同期しているが、20GBを超えており3パー
ティション化されている
•アンサーのコメントはHASHがスポットID、
RANGEがコメントIDになっている
•スポットIDへのアクセスは十分に分散してい
るので、スループットを使いきれている
55

56. インデックスの特性
56

57. インデックスの実態は「自動で作られる別のテーブル」
•ローカルセカンダリインデックス(LSI)も、
グローバルセカンダリインデックス(GSI)
も、実態としては「別のテーブル」
•インデックスに対して読み込みにおいて
できることは HASH+RANGE テーブル
にできること以下になる
•多少の例外はあるが、やはり基本はテー
ブルと同じ
57

58. LSIの特性
•LSIの実態は「テーブルと同じHASHで別
のRANGEを持った複製テーブル」
•例えばテーブルの定義ではRANGEを「作
成日」にして、LSIでは「更新日」にする
など
•複製したぶんだけ容量が増え、書き込み
スループットも追加で要する
•スループットはテーブルと共有する
58

59. LSIの制限
•LSIはテーブル作成時にしか定義できない
のでよーく考えてつけるべき
•作成出来るLSIはテーブルあたり5つまで
•LSIは「強い整合性」での読み込みが出来
る（ラグなしで読み込める）
•アンサーではまともに使っている箇所は
ない
59

60. GSIの特性
•GSIの実態は「選択したカラムをHASHと
して複製したテーブル」
•RANGEありなし、どちらもOK
•例外として、GSIではHASH or
HASH+RANGEはユニークでなくても別々
のItemとして保存され、参照可能
•スループットは独自に設定する
60

61. GSIの制限
•テーブルとLSIでは1HASHあたり10GB
の容量制限があるが、GSIには無い
•テーブル作成後でも作れるし削除できる
•作成出来るGSIはテーブルあたり5つまで
•「強い整合性」での読み込みが出来ない
（ラグの発生を前提にしなければならな
い）
61

62. インデックスにも十分なスループットが必要
•書き込みリクエストにおいて、インデッ
クス側のみスループットが足りないとき
でも、テーブルへの書き込み性能が低下
する。
•インデックスの作り方によってはHASH
が集中するので、HASH集中による性能
低下が起きないか注意が必要
62

63. インデックスの運用は結構難しい
•追加の書き込みスループットが必要
•とりあえず作っておけばいいものではな
い
•RDBとの併用を考えるべき
63

64. インポートのベストプラクティス
64

65. マネジメントコンソールからインポートできる
•マネジメントコンソールから簡単にイン
ポート操作が行える
65

66. インポートの動作
•DataPipelineとして動作する
•インポートするファイルはS3を経由する
•インポート速度（スループット消費量）
は指定できる
66

67. データフォーマットはマニュアルに載ってる
•PHP SDKにエクスポート用のデータ列に
フォーマットして返す機能は見つけられ
なかった
•フォーマットはシンプルなので、マニュ
アル通りに自分でフォーマットすればよ
い
•「AWS Data Pipeline」の項目に記載さ
れている
67

68. データフォーマット
•STX/ETX/LF で区切られたそこそこシン
プルな行指向データ
「データエクスポートファイルの確認」
で検索するとヒットするはず
68

69. HASH分散しないと速度がでない
•素朴に時系列でデータを並べてインポート
したらスループットを使い切れなかった
•サポートに問い合わせると、同一HASHへ
の連続した書き込みが起きていて使い切っ
てないようだ、というアドバイスを得た
•HASHを分散して並べたデータをインポー
トさせたらちゃんとスループットが出た
•HASH分散超大事
69

70. HASH集中してるデータをインポートするには
•そうはいってもどうしてもHASHが集中し
ているデータをインポートする場合がある
•その場合はゆっくりじっくり時間をかけて
インポートするしかない…と思う
•アンサーで行ったのは最大で10日間
•インポート時にはタイムアウト時間を設定
する必要があり、UIからは9999時間まで
設定できそう
70

71. バックアップは難しい
71

72. マスターデータのバックアップをどうするか
•DynamoDB はレプリカやユーザーセッ
ションとして使い始めた
•どちらもDynamoDB自体のバックアップ
は不要
•慣れてきたのでDynamoDBをマスターデー
タとして使い始めてみた
•そういえばバックアップはどうしよう？
72

73. DynamoDBのバックアップに銀の弾丸なし
•結論として、大容量のテーブルに大して
は、現状で簡単なソリューションは無い
•全てのデータを読み込むことはできるが、
現実的な時間で完了させるにはスルー
プット消費がとんでもないことになる
•「データ全体にアクセスする」「大量の
Itemを一気に読み込む」といった要件に
ついて、DynamoDBは無頓着っぽい
73

74. データが消えることは無いはず
•3つのAZに複製されるのでItemが消える
ことはないはず
•大量のItemを一度に消す方法はテーブル
削除以外にはないので、誤操作のリスク
は限定的
•誤操作はIAMの権限で防止しよう
74

75. データの向き不向き
75

76. DynamoDBに向いているデータ
•例えば、スレッド型掲示板のコメント、
ユーザーの行動ログ
•遅延が許されない要件
•何らかの順序で小さく分割可能
•アクセスが分散すること
•際限なく増えるデータ
76

77. DynamoDBに向いていないデータ
•インデックスの必要性が高い
•データ全体の走査が必要
77

78. おすすめの学習方法
78

79. SlideShareのDynamoDB関係資料を通読
•AWS マイスターシリーズ
•AWS Black Belt Techシリーズ
•Deep Dive
•公式以外も有用なものが多い
79

80. 「よくある質問」の通読
•マジでよく書かれてる
•サポートに質問していた内容がほとんど
すべて載っていた
80

81. 手を動かす
•悩んだらテーブルを作ってクエリを打つ
•マネジメントコンソールからデータを編
集できる
•単発のクエリは aws cli が便利
81

82. DynamoDBを今後も使うか
82

83. DynamoDBは今後も使いたい
•使ってみてよかった。簡単にスケールす
るインフラは素敵だ
•KVS的な要件があれば今後も積極的に使
いたい
•前提さえ守れば運用はスループットを監
視するだけなので手間が少ない
•将来的に AWS Lamda との併用も魅力
83