🤭

RDBからDynamoDBへ移行したい方へ

2023/01/31に公開

はじめに

RDB(RDS)からDynamoDBへ移行時の経験談をまじえながら、
DynamoDBのメリット・デメリットをわかりやすく紹介します。

DynamoDBを初めて触る方、RDBからDynamoDBへの移行を考えている方

AWSが提供するフルマネージドなKey-Value型のデータベースサービスです。
巨大なデータ量でも低いレイテンシーで読み書きすることができます。

プライマリーキーの設定が必須で、パーティションキーもしくはパーティションキー+ソートキーで構成されます。
テーブルには、プライマリーキーとその他属性を持ったアイテムが保存されます。

私が関わったシステムの移行前と移行後を簡易的な図で表現しています。
利用用途は、モバイルアプリが利用するWebAPIです。AWSのサーバーレスサービスで構成されています。

DBへの読み込み/書き込みは、モバイルアプリからのリクエスト以外に、
裏側で動く別のストリーム処理からのトラフィックが存在しています。
そのトラフィックのピーク時には、DBの最大接続数を超過していました。
そのため、定期的に裏側の処理を止める必要があり、スループットに課題がありました。

RDB時代の定義をそのまま引き継いで移行すると、DynamoDB特有の問題が出てきます。

RDBは柔軟なクエリが可能です。
一方、DynamoDBのクエリは、テーブルのプライマリーキーを利用するか、GSIを利用するかの2択です。
※フィルタの利用は可能、ただしクエリをかけたあとに実行されるので、パフォーマンス的によろしくない

従業員を管理するテーブルがあり、退職すると論理削除フラグをtrueにする運用になっているとします。
※このケースで、論理削除フラグがアンチパターンであるという意見は、一旦置かせてください。

会社に所属している従業員一覧を取得しようと思うと、論理削除フラグをパーティションキーに設定した
GSIを設定しなければなりません。
GSIの設定数には20という上限が存在し、追加すればするほどコストも増えていきます。

つまり、DynmaoDBを利用する場合は、先にアクセスパターンを想定して、テーブルの設計を行わないといけないのです。

ちなみに、GSIが増えていく問題を解決するために、一つの属性に複数の値を入れる「GSIオーバーローディング」というテクニックがあります。
ここでは解説しません、気になる方は調べてみてください。

RDBにもDynamoDBにも、それぞれ違ったメリット・デメリットが存在します。
システム要件にあった利用をこころがけて、テーブル設計に気をつけましょう。