イベント用途に適したDynamoDB活用事例

社内イベントの会場で来場者情報をスクリーン表示するためのWebサービスで、来場者情報の保存先としてDynamoDBを採用し、以下を意図して構成を組みました。

• 来場者情報の保存・取得をシンプルかつ低コストに実現する
• 常時稼働インスタンスを持たず、利用量に応じた課金体系で運用する
• アクセスパターンが限定的なイベント用途に最適化されたデータストアを選ぶ

• Amazon RDS
• Amazon DynamoDB

• 月額コストを抑えられるか
• 複雑なクエリが不要なユースケースに合っているか
• 運用時の管理負荷が低いか

改善したかった課題はどれくらい解決されたか

常時稼働インスタンスを持たず、利用量に応じた課金で運用できるため、イベント用途のようにアクセス頻度が限定的なサービスではコスト面でも相性が良いと感じました。

さらに、DBインスタンスの管理が不要なため、運用負荷も大きく抑えられました。

どのような成果が得られたか

移行後は実際のイベントで利用し、安定して動作することを確認できました。

必要な性能を確保しつつ、データストアの構成をシンプルに保てた点が大きな成果でした。

コスト面でも、RDSを利用する場合と比較して抑えることができ（検証期間やDB稼働時間などを踏まえると、今回のケースではざっくり1/3程度の試算となりました）、また、Terraformで管理することで、再現性や運用のしやすさも高められました。

導入時に悩んだのは、RDSではなくDynamoDBを選択すべきかどうかでした。

RDSは馴染みがあり、柔軟なクエリを書ける安心感があります。
一方で、今回のサービスは来場者情報の取得・表示が中心であり、複雑な検索機能は必要ありませんでした。

そのため、RDSの柔軟性よりも、DynamoDBの低コストさとシンプルなデータ取得性能を優先しました。

ただ、DynamoDBはRDBと設計思想が大きく異なるため、テーブル設計には苦労しました。

特に、実装初期にアクセスパターンを十分整理しないままパーティションキーを設計してしまい、途中で想定していた取得方法に適していないことに気づきました。

DynamoDBではプライマリキー（パーティションキー / ソートキー）を後から変更できないため、最終的にはテーブルを作り直して対応しました。

この経験から、DynamoDBでは実装前に「どのデータを、どのキーで、どのように取得するか」というアクセスパターンを整理したうえで、テーブル設計を行うことが重要だと感じました。

DynamoDBは、アクセスパターンが明確で、複雑なクエリが不要なサービスと相性が良いDBだと思います。

今回のようなイベント用途のように、特定のキーで読み書きが完結するサービスでは扱いやすく、必要なデータを安定して取得しやすい点がメリットです。

一方で、RDBのようにあとから自由にJOINしたり、複雑な検索条件を追加したりする用途には向いていません。

そのため、導入前に「どの画面で、どのデータを、どのキーで取得するか」を整理しておくことが重要だと思います。

DynamoDBは読み書き量に応じた課金体系のため、今後は読み書きコストおよびテーブル設計の最適化を進めていきたいです。

不要な書き込みを削減するため、更新があったデータのみをDynamoDBへ反映する構成を検討するとともに、読み書きリクエスト量を踏まえてオンデマンドキャパシティモードを継続するか、プロビジョンドキャパシティモードへ切り替えるかも判断したいです。

また、検索要件の増加に備え、Scanに依存しない取得方式を実現できるよう、キー設計やGSIの見直しも進めていきたいです。