はじめに：
弊社で開発しているプロダクトのデータベースについて、オンプレのRDBからAWSのNoSQLDBであるDynamoDBに移行しましたので、移行を経験した上で得た恩恵と移行の注意点についてお話しさせて頂きます。
DynamoDB移行による恩恵
今回移行対象となった記録データはユーザとともに増加傾向であり、大量のデータ保管が可能なAWSとの相性は良好でした。
本項では移行を行なったことで得られた恩恵について紹介いたします。
スケールアップが容易に
DBへの負荷への対処がオンプレに比べて容易なのが最大の恩恵となりました。
テーブルサイズにも実用的な制限がないのも魅力です。
オンプレDBと比べてカラム追加が簡易的
基本的に「入れれば入る」ようになっており、カラムについても数値や文字列などの基本的なものからJsonや配列まで使用可能です。
ただしカラム単位での削除ができないので、施策を入れる時に
- 事前の設計
- 今後の追加開発での考慮
がないと参照しないで無駄にサイズを圧迫するデータを生むだけなので気軽に追加ができるとはいえ注意が必要です。
各種AWSサービスとの連携
データをs3に保存し、Lambdaによる定期集計を実施するなどが可能になります。
移行によって実施できた施策も多々有ります。
AWS初心者で時間こそかかりましたが移行によるメリットは十分あったと思います。
DynamoDB移行における注意点
DynamoDBに移行するにあたり、考慮が必要な点について解説いたします。
検索機能が独特
実施可能な検索方法が
| キー | 実施可能な検索条件 |
|---|---|
| パーティションキー | 完全一致 |
| ソートキー | =、<、<=、>、>= Between、BeginWith（前方一致） |
と独特な検索条件となっており、これを踏まえた設計が必要になります。
例：
- 「2019年４月のデータのリストが欲しい」場合は日付を20190401のような数値に設定してBetween等で範囲検索して絞る
- 文字列での部分一致検索は出来ないのでリストを取ってきた後で別途絞る処理を入れる
一括での更新や削除ができない
NoSQLのため、まとめて更新や削除ができず、１件ずつ処理する必要があります。
更新対象リストを取得し、そのリストに対して１つずつ処理を適用していく形になると思います。
予約語
DynamoDBには予約語があり、これらの単語を使ってscanするとエラーになってしまいます。
予約語一覧：
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/ReservedWords.html
DynamoDBにて設定可能なTTL（Time To Live）も予約語なので、使用する場合は名称に気をつけるか、下記のようにwithNameMapを経由してあげる必要があります。
UpdateItemSpec updateItemSpec = new UpdateItemSpec()
.withPrimaryKey(
"id", Id,
"targetDate", targetDate)
.withUpdateExpression("set #t = :ttl") ←#tがttlだとエラーになる
.withValueMap(new ValueMap().withLong(":ttl", ttl))
.withNameMap(new NameMap().with("#t", "ttl")) ←これを追加
.withReturnValues(ReturnValue.UPDATED_NEW);
最大サイズの存在
移行において一番キモである「既存データのコンバート」において立ちふさがるのが最大項目サイズの存在です。
DynamoDBの最大項目サイズは400KBと制限されており、
- 移行後から登録されるデータ
- 移行元のデータ
の２点においてこの制限に引っかからないデータ設計が必要となります（特に移行元のデータ量が多い場合の想定が必須）
仮に入れるデータ量が多く、４００KBをオーバーする場合は
-
バイナリ型を使用する
- DynamoDBで完結するが結局最大サイズという問題がのしかかる
-
s3に別途データを設置してパスをDynamoDBで持つようにする
- 管理箇所が増えるが、シンプルでわかりやすい
といった工夫によって最大項目サイズの削減を行うことができます。
最大項目サイズを考慮して最初に十分な時間をかけて移行のための設計を行わないと制限に引っかかり、急遽データ構成を変更、なんてことも起こり得ます。
この最大項目サイズは移行が済んだ後でも当然意識する必要があるので、施策等で新しいカラムを追加する際にも注意が必要です。
最後に
DynamoDB移行はメリットがある分独特な特性を持ち、移行前後のデータ保証と共に今後のデータの利用方法もある程度予測しての設計が求められるので、移行の際は入念な設計とレビューが大事と感じました。
この記事が今後AWSへのデータ移行を行う方の参考になれば幸いです。