1. DynamoDBを
導入した話
ビズリーチ
プロダクト開発部
北川 俊広

2. 自己紹介
● 北川 俊広
● 2016/03 ビズリーチ入社
● DBA
● ビズリーチサービスの DB 周りを担当
● 使ったことがある DB
PostgreSQL, MySQL, DynamoDB

3. 目次
● DynamoDBの仕様と特徴
● MySQLのテーブルをDynamoDBに移行する
● 日々の運用

4. DynamoDBの仕様と特徴

5. DynamoDBとは
● 完全マネージド型の NoSQL データベースサービス
● ユーザは以下を心配する必要なし
○ ハードウェア
○ 設定、構成
○ レプリケーション
○ ソフトウェア修正プログラムの適用
○ クラスターのスケーリング
● 高速で予測可能なパフォーマンス
● 高いスケーラビリティ
● ストレージの容量制限なし

6. DynamoDBの概念
● テーブル
一般的なデータベースと同様にテーブルにデータを格納する。
● アイテム（項目）
テーブルには複数のアイテム（項目）が含まれる。
RDBMSでいうところのレコード。最大400KBまで。
● 属性
アイテムは１つ以上の属性で構成される。
RDBMSでいうところのフィールド。
● プライマリキー
アイテムを一意に識別するためのキー。省略不可。

7. プライマリーキーの種類
● パーティションキー（Hash key）
１つの属性で構成されるシンプルなプライマリーキー。
ハッシュ関数によってパーティションが決まる。
２つ以上のアイテムで同じパーティションキーを使用することはできない。
● パーティションキー（Hash key）とソートキー（Range key）
２つの属性で構成される複合プライマリーキー。
パーティションキーにより保存されるパーティションが決まり、ソートキーでソートさ
れてデータが格納される。一意性は、パーティションキーとソートキーの組み合わせ
で判断される。

8. インデックス
プライマリキー以外の属性を使用してデータを読みたい場合は、セカンダリインデックス
が利用できる。インデックスを張る属性は一意性がなくてもよい。
● グローバルセカンダリインデックス（GSI）
テーブルと異なるパーティションキーとソートキーを持つインデックス。ソートキーは
必須ではない。
● ローカルセカンダリインデクス（LSI）
テーブルと同じパーティションキーと異なるソートキーを持つインデックス。
それぞれ、１テーブルにつき５つまで作成でき、射影する属性は選択できる。

9. テーブルの具体例
● Primary key
○ RId_CId (Partition key)
○ AccessTM (Sort Key)
● GSI
○ RId (Partition key)
○ AccessTM (Sort key)
RId_CId AccessTM AccessDate RId
Footprint テーブル

10. データ型
● スカラ型
数値、文字列（UTF-8）、バイナリ、ブール、null
● ドキュメント型
リスト：[“Bizreach”, “CareerTreck”, 2009]
マップ：JSONオブジェクト
● セット型
数値セット、文字セット、バイナリセット
文字列の長さは０より大きい必要があるため、空文字は格納できない。

11. 日付・時刻は？
● ISO 8601 形式（文字列）
○ 2017-06-13
○ 2017-06-13T19:45:00Z
○ 20170613T194500Z
● UNIX 時間（数値）
○ エポック時間: 1970 年 1 月 1 日 12:00:00 AM UTC からの経過秒数
○ Time To Live(TTL)機能を使用する場合は必須の属性

12. 読み込み整合性
● 結果整合性のある読み込み（デフォルト）
応答で古いデータが返る可能性がある。
● 強い整合性のある読み込み
常に最新のデータが返る。
GSIは、結果整合性のある読み込みのみサポート。

13. プロビジョニングされたスループット
＝キャパシティーユニット
● 読み込みキャパシティーユニット１
最大サイズ 4 KB の項目について、1 秒あたり 1 回の強力な整合性のある読み込
み、あるいは 1 秒あたり 2 回の結果的に整合性のある読み込みを表す。
● 書き込みキャパシティーユニット１
最大サイズ 1 KB の項目について、1 秒あたり 1 回の書き込みを表す。
プロビジョニングされたスループットを超えると、リクエストは HTTP 400 コード (Bad
Request) と ProvisionedThroughputExceededException で失敗する。ただし、バースト
キャパシティという予備のキャパシティがあるので、必ず失敗するわけではない。

14. キャパシティー設定

15. Scan

16. Query

17. ScanとQueryのスループット消費
● 処理された項目の累計サイズをもとにスループットが計算される。
● たとえば1KBの項目を100個取り出した場合
(100 * 1024 bytes = 100 KB) / 4 KB = 25 読み込みキャパシティーユニット
● 項目サイズは属性名と属性値の長さの合計
「キャパシティーユニットの消費を最適化するには、属性名の長さをできるだけ短く
することをお勧めします。」開発者ガイドより

18. 料金（東京リージョン）
● 書き込みスループット
書き込みキャパシティー 10 ユニットごとに 0.00742USD/hour
● 読み込みスループット
読み込みキャパシティー 50 ユニットごとに 0.00742USD/hour
● 毎月最初の 25 GB の保管は無料、それ以降は月額 0.285USD/GB

19. MySQLのテーブルを
DynamoDBに移行する

20. 移行しづらいテーブル
● １行のサイズが大きい
● バッチ処理などで大量にデータを取得する
● RDBMSの特性を多用している
○ Join
○ サブクエリ
○ 集約関数

21. テーブル移行スケジュール
MySQLから読み込み
MySQLへの書き込み
DynamoDBへの書き込み
DynamoDBへ
過去データコピー
DynamoDBから読み込み

22. MySQLからDynamoDBへの
過去データコピー

23. MySQLからデータを取得する
※ファイル内にプライマリキーの重複が
あるとインポートできない！

24. 書き込みキャパシティーの調整

25. パーティション分割問題 (1/2)

26. パーティション分割問題 (2/2)

27. インポート

28. 読み込み書き込みキャパシティーの調整

29. インポート結果の確認
Redshift にコピーして確認するのが便利
CREATE TABLE operator_login_log_temp (opid BIGINT, lt TEXT, ….);
COPY operator_login_log_temp FROM 'dynamodb://OperatorLoginLog' credentials
'aws_access_key_id=<Your-Access-Key-ID>;aws_secret_access_key=<Your-Secret-
Access-Key>' readratio 50;
※ DynamoDB の属性名に Redshift の予約語を使用しないように注意

30. 読み込みキャパシティーの調整

31. 日々の運用

32. キャパシティー調整
● バッチ処理
● Redshift へのデータコピー
● バックアップ
弊社では、キャパシティを調整する仕組みを Lambda で自前実装。
キャパシティは aws cli でも変更できるので、一番お手軽なのは cron での変更。
スループットに応じて自動調整を行いたい場合は、Dynamic DynamoDB が便利。
https://dynamic-dynamodb.readthedocs.io/

33. スループットの変動に注意
● 日々スループットを確認
● 新機能のリリースなどは注意
● メンテナンス明けのスループット変動に注意

34. ご静聴ありがとうございました