Zenn
🍣

【AWS DynamoDB】サーバレスアプリケーションを開発するためにDynamoDBのテーブル設計した

に公開
AWS
DynamoDB
Serverless
tech

DynamoDBって何？

DynamoDBは、AWSが提供するキーバリュー・ドキュメント指向のNoSQL DBサービスです。従来のRDB（リレーショナルデータベース）とは異なり、スキーマレスな設計や高速なパフォーマンス、自動的なスケーリングが特徴です。

image.png

DynamoDBの主な特徴

  • フルマネージド: サーバーの管理やメンテナンスが不要
  • 高速なパフォーマンス: SSDストレージによる高速な読み書き
  • 高いスケーラビリティ: 自動的なスケールイン/スケールアウト
  • 柔軟なデータモデル: スキーマレスな設計で、様々なデータ構造に対応

個人的にはAPIでデータの登録・更新・削除ができるのはとても良い点だなと思っています。

DynamoDBのユースケース

  • 高トラフィックなWebアプリケーション
  • モバイルアプリケーションのバックエンド
  • IoTアプリケーション
  • ゲームアプリケーション

サーバーレスアプリケーションって何？

サーバーレスアプリケーションとは、サーバーの管理を必要としないアプリケーションのことです。AWS Lambdaなどのサーバーレスサービスを利用することで、インフラの管理から解放され、開発者はアプリケーションのロジックに集中できます。

サーバーレスアプリケーションのメリット

  • 高いスケーラビリティ: 需要に応じて自動的にスケール
  • コスト効率: 従量課金制で、使用した分だけ支払い
  • 開発効率: インフラの管理が不要で、開発に集中できる

比較的少ない人数での稼働が想定される時などは、サーバーやRDBを使用するよりも圧倒的に安いです。

サーバーレスアプリケーションのデメリット

  • コールドスタート: 初回アクセス時にレイテンシが発生
  • デバッグの複雑さ: 分散アーキテクチャのため、デバッグが難しい場合がある

AWS SAMを使用して、ローカル環境でテストコードを実行しておくことで、保守性は高められます。
ここでのテストコードは、PythonだったらPytestなどです。

NoSQLとリレーショナルDBの違い

NoSQLとリレーショナルデータベース（RDB）は、それぞれ異なる特性を持っています。NoSQLはスキーマレスな設計や高いスケーラビリティが特徴であり、RDBは厳格なスキーマやACID特性による高いデータ整合性が特徴です。

データモデルの違い

  • NoSQL: スキーマレスで、柔軟なデータモデル
  • RDB: 厳格なスキーマで、テーブル間の関係を定義

RDBの場合、カラムを追加するときにマイグレーションなどの操作が必要になりますが、NoSQLの場合はプライマリーキーを指定しておけばOKです。

スケーラビリティとパフォーマンス

  • NoSQL: 水平スケーリングが得意で、高いパフォーマンス
  • RDB: 垂直スケーリングが主で、複雑なクエリが得意

RDBはインデックスの設定などである程度のパフォーマンス改善ができますが、NoSQLの場合は難しい場合があります。

ユースケースに基づく選択

  • NoSQL: 高トラフィックなWebアプリケーションやIoTなど、大量のデータを高速に処理する場合
  • RDB: 会計システムや顧客管理システムなど、データの整合性が重要な場合

RDBはJOINなどをうまく使うことでクエリが大量に実行されてしまう「N+1問題」が発生しないようにすることができますが、NoSQLはJOINができないので、テーブル数ができるだけ少なくなるように設計を行う必要があります。

DynamoDBテーブル設計

今回のアプリケーションでは、ユーザーグループ、ユーザー、タスクを管理するために、以下のテーブルを設計しました。

DynamoDBを使用してやりたいこと

やりたいこととしては以下です。

  • 全てのレコードの取得
  • ある条件に合致する全てのレコードの取得
  • 特定の単一レコードの取得

この3パターンのデータの取得が可能となるように設計を行う必要があります。

全てのレコードを取得する方法

DynamoDBにはscanというAPIがあり、これを叩くことで、テーブルの全てのデータが取得できます。

ドキュメントには、以下のように記載されています。

指定されたテーブルまたはインデックスのすべての項目を取り出します。項目全体またはその属性のサブセットのみを取り出すことができます。オプションでフィルタリング条件を適用すると、関心のある値のみを返し、残りは破棄できます。

ランタイムがPythonのLambda関数を使用している場合、以下のように記載することができます。

import boto3
from boto3.dynamodb.conditions import Attr

def main():
    dynamodb = boto3.resource('dynamodb')
    table = dynamodb.Table('sample-table')

    options = {
        'FilterExpression': Attr('カラム名').contains('検索する値'),
    }
    res = table.scan(**options)   # scan() と指定した場合、テーブルのすべてのデータを取得します。

~以下省略~

ある条件に合致する全てのレコードの取得

DynamoDBにはqueryというAPIがあり、これを叩くことで、テーブルの全てのデータが取得できます。

ドキュメントには、以下のように記載されています。

特定のパーティションキーがあるすべての項目を取り出します。パーティションキーの値を指定する必要があります。項目全体またはその属性のサブセットのみを取り出すことができます。オプションで、ソートキーの値に条件を適用し、同じパーティションキーがあるデータのサブセットだけを取り出すことができます。テーブルにパーティションキーとソートキーの両方を持つテーブルがある場合、テーブルでこのオペレーションを使用できます。また、インデックスにパーティションキーとソートキーの両方がある場合、インデックスでこのオペレーションを使用できます。

import boto3
from boto3.dynamodb.conditions import Key

def main():
    dynamodb = boto3.resource('dynamodb')
    table = dynamodb.Table('sample-table')

    options = {
        'KeyConditionExpression': Key('パーティションキーのカラム名').eq('検索する値'),
        # 必要ならFilterExpressionも追加できます（キー以外での追加絞り込み）
        # 'FilterExpression': Attr('他のカラム名').contains('データ'),
    }

    res = table.query(**options)  # query() はパーティションキーが必須です

特定の単一レコードの取得

import boto3
from boto3.dynamodb.conditions import Key

def main():
    dynamodb = boto3.resource('dynamodb')
    table = dynamodb.Table('sample-table')

    options = {
        'KeyConditionExpression': Key('パーティションキーのカラム名').eq('検索する値') & Key('ソートキーのカラム名').begins_with('検索する値'),
        # 必要に応じて追加のフィルタも可能
        # 'FilterExpression': Attr('他のカラム名').contains('データ'),
    }

    res = table.query(**options)

DynamoDBからレコードを取得する上での注意点

これは個人的にですが、以下については注意すべきかなと思っています。

  • 原則として、「パーティションキーのみ」「パーティションキー＋ソートキー」の検索のみの処理に限定する

その理由として、「キーに指定していないカラムでの絞り込みは動作が遅くなる可能性があるからです。
キーに指定しているカラムでの絞り込みは、インデックスを使って絞り込むため、検索処理が高速です。

決して、キーに指定していないカラムでの絞り込みをしてはいけないということではないです。

検索の順序として、「パーティションキーのみ」「パーティションキー＋ソートキー」の絞り込みの後に、キーに指定していないカラムでの絞り込みを行うべきです。これであれば、動作が遅くなってしまうことを防げます。

条件タイプ 使うメソッド 処理速度 読み込みコスト 備考
パーティションキー KeyConditionExpression ◎ 超高速 最小限
パーティション + ソートキー KeyConditionExpression ◎ 高速 最小限
属性によるフィルタ FilterExpression △（後処理） 減らない レスポンス件数は減る

設計したテーブル一覧

今回は、以下のテーブルについて設計しました。

  • UserGroupsTable: ユーザーグループ情報を管理
  • UsersTable: ユーザー情報を管理
  • TasksTable: タスク情報を管理

各テーブルの設計詳細

UserGroupsTable

項目 内容
パーティションキー group_id
属性 group_id (String), group_name (String)
説明 ユーザーグループ情報を保持するテーブル

UsersTable

項目 内容
パーティションキー group_id
ソートキー user_id
属性 group_id (String), user_id (String), email (String), name (String), password (String)
説明 ユーザー情報を保持するテーブル。1つのグループに複数のユーザーが所属

TasksTable

項目 内容
パーティションキー user_id
ソートキー task_id
属性 user_id (String), task_id (String), task_name (String), task_description (String), due_date (String), status (Integer), priority (Integer)
説明 タスク情報を保持するテーブル。ユーザーごとにタスクを管理

DynamoDBテーブルのスキーマファイル

以下は、各テーブルのスキーマを定義したYAMLファイルです。各テーブルの主キー（パーティションキーとソートキー）と属性、説明を定義しています。（このファイルは開発をスムーズに進めるために作成しただけのものです。）

tables:
  - name: user-groups
    primaryKey:
      partitionKey: group_id
    attributes:
      - name: group_id
        type: String
    description: ユーザグループ情報を保持するテーブル

  - name: users
    primaryKey:
      partitionKey: group_id
      sortKey: user_id
    attributes:
      - name: group_id
        type: String
      - name: user_id
        type: String
      - name: email
        type: String
      - name: name
        type: String
      - name: password
        type: String
    description: ユーザ情報を保持するテーブル。ユーザは1つのグループに所属する。

  - name: tasks
    primaryKey:
      partitionKey: user_id
      sortKey: task_id
    attributes:
      - name: user_id
        type: String
      - name: task_id
        type: String
      - name: task_name
        type: String
      - name: task_description
        type: String
      - name: due_date
        type: String
      - name: status
        type: Integer
      - name: priority
        type: Integer
    description: タスク情報を保持するテーブル。ユーザ単位でタスクを管理する。

まとめ

RDBに比べて、設計が難しい...！

Discussion