野中のre:Invent 2024 1 日目:DynamoDBデータモデリングのポイント

こんにちは。クラウドネイティブ技術部の野中です。

今年の12月2日から12月6日にかけて開催される re:Invent 2024 に現地参加しています！
このイベントには以前から参加したいと思っていたので、ついに念願が叶い、ワクワクが止まりません。

今回は、DynamoDBデータモデリングに関するセッションを受講しました。このテーマを選んだのは、実際の案件でもDynamoDBを採用している中で、自身の知識不足を感じる場面があったためです。セッションを通して得た内容を振り返りながら、皆さんと共有していきたいと思います。

1. DynamoDBとは？

DynamoDBは、AWSが提供するNoSQLのキーバリューストアおよびドキュメントデータベースです。スケーラビリティや低レイテンシを重視した設計で、以下のような特長を持ちます。

ユースケースとしては、ゲーム、チャットアプリ、IoTデータ管理、商品カタログなど、多種多様なアプリケーションに利用されています。

本セッションではDynamoDBの基本的なデータ構造を電話帳に例えて説明していました。以下のような形です。

例として、次のように設計できます。

PK（都市名）	SK（姓と名）	電話番号	郵便番号
東京	山田#太郎	03-1234-5678	100-0001
東京	佐藤#花子	03-9876-5432	100-0002
大阪	高橋#一郎	06-1122-3344	530-0001

都市内の全データを取得

   response = table.query(
       KeyConditionExpression=Key('PK').eq('東京')
   )

→ 東京に登録されたすべてのユーザー情報が取得されます。

特定の人物を検索

response = table.query(
    KeyConditionExpression=Key('PK').eq('東京') & Key('SK').eq('山田#太郎')
)

→ 山田太郎さんの詳細が返されます。

DynamoDBでは、ローカルセカンダリインデックス（LSI）とグローバルセカンダリインデックス（GSI）を使って複数の検索軸を提供します。

例えば、「東京」のデータを電話番号順で取得したい場合です。

PK（都市名）	SK（電話番号）	姓と名	郵便番号
東京	03-1234-5678	山田#太郎	100-0001
東京	03-9876-5432	佐藤#花子	100-0002

例えば、「郵便番号」をキーにデータを検索したい場合です。

DynamoDBの設計では、スケーラビリティとコスト効率を両立するための工夫が求められます。以下に、具体的な実践例と最適化の方法を紹介します。

目的: 特定のパーティションにトラフィックが集中するのを防ぎ、読み書きの負荷を均等化する。
方法: PKにランダムな接尾辞を付加してデータを分散。
例: 東京#0, 東京#1 のようにシャードを分けることで、負荷を複数のパーティションに分散。
注意点: シャードキーの管理にはアプリケーション側の工夫が必要。クエリの際にどのシャードを参照すべきかを適切に判断する仕組みを設ける必要があります。また、シャードキーをランダムに割り振ると範囲クエリが難しくなるため、アクセスパターンに応じて計画的に設計する必要があります。

目的: 項目サイズを削減し、ストレージコストと書き込み容量単位（WCU）を最適化。
方法:
- 項目データを圧縮（例: gzip）して保存。
- 圧縮されたデータはバイナリ形式でDynamoDBに格納可能。
注意点: 圧縮データを利用する場合、アプリケーション側で解凍処理を追加する必要があります。また、圧縮しても最大項目サイズ（400KB）を超える場合、データの分割やS3との併用を検討する必要があります。