イベント用途に適したDynamoDB活用事例
フォースタートアップス株式会社 / 田畑 綾也
メンバー / フルスタックエンジニア・プロダクトエンジニア
| 利用プラン | 利用機能 | ツールの利用規模 | ツールの利用開始時期 |
|---|---|---|---|
オンデマンドキャパシティ | Amazon DynamoDBテーブル | 51名〜100名 | 2025年1月 |
| 利用プラン | オンデマンドキャパシティ |
|---|---|
| 利用機能 | Amazon DynamoDBテーブル |
| ツールの利用規模 | 51名〜100名 |
| ツールの利用開始時期 | 2025年1月 |
アーキテクチャ
アーキテクチャの意図・工夫
DynamoDB選定理由
DynamoDBは、社内イベントにおける来場者情報の保存先として採用しました。
以下の観点から、今回の要件と相性が良いと判断したことが選定理由です。
1. 従量課金により運用コストを抑えられる
常時稼働するDBインスタンスを持たず、読み書きリクエスト量に応じた課金体系であるため、アクセス頻度が限定的なイベント用途と相性が良いと判断しました。
2. インスタンス管理が不要で運用負荷が低い
マネージドサービスとしてDBインスタンスの運用管理が不要なため、イベントのような短期集中型のユースケースでも、運用負荷を最小限に抑えられる点にメリットがありました。
3. アクセスパターンが明確なユースケースに適している
来場者情報の取得・表示が中心であり、特定キーによる読み書きでデータ取得が完結する構成でした。
そのため、プライマリキーを用いたシンプルなアクセス設計を採用するDynamoDBと相性が良いと判断しました。
導入の背景・解決したかった問題
導入背景
社内イベントの会場で来場者情報をスクリーン表示するためのWebサービスで、来場者情報の保存先としてDynamoDBを採用し、以下を意図して構成を組みました。
- 来場者情報の保存・取得をシンプルかつ低コストに実現する
- 常時稼働インスタンスを持たず、利用量に応じた課金体系で運用する
- アクセスパターンが限定的なイベント用途に最適化されたデータストアを選ぶ
比較検討したサービス
- Amazon RDS
- Amazon DynamoDB
比較した軸
- 月額コストを抑えられるか
- 複雑なクエリが不要なユースケースに合っているか
- 運用時の管理負荷が低いか
導入の成果
改善したかった課題はどれくらい解決されたか
常時稼働インスタンスを持たず、利用量に応じた課金で運用できるため、イベント用途のようにアクセス頻度が限定的なサービスではコスト面でも相性が良いと感じました。
さらに、DBインスタンスの管理が不要なため、運用負荷も大きく抑えられました。
どのような成果が得られたか
移行後は実際のイベントで利用し、安定して動作することを確認できました。
必要な性能を確保しつつ、データストアの構成をシンプルに保てた点が大きな成果でした。
コスト面でも、RDSを利用する場合と比較して抑えることができ(検証期間やDB稼働時間などを踏まえると、今回のケースではざっくり1/3程度の試算となりました)、また、Terraformで管理することで、再現性や運用のしやすさも高められました。
導入時の苦労・悩み
導入時に悩んだのは、RDSではなくDynamoDBを選択すべきかどうかでした。
RDSは馴染みがあり、柔軟なクエリを書ける安心感があります。
一方で、今回のサービスは来場者情報の取得・表示が中心であり、複雑な検索機能は必要ありませんでした。
そのため、RDSの柔軟性よりも、DynamoDBの低コストさとシンプルなデータ取得性能を優先しました。
ただ、DynamoDBはRDBと設計思想が大きく異なるため、テーブル設計には苦労しました。
特に、実装初期にアクセスパターンを十分整理しないままパーティションキーを設計してしまい、途中で想定していた取得方法に適していないことに気づきました。
DynamoDBではプライマリキー(パーティションキー / ソートキー)を後から変更できないため、最終的にはテーブルを作り直して対応しました。
この経験から、DynamoDBでは実装前に「どのデータを、どのキーで、どのように取得するか」というアクセスパターンを整理したうえで、テーブル設計を行うことが重要だと感じました。
導入に向けた社内への説明
上長・チームへの説明
「アクセスパターンが明確で、複雑な検索が不要なデータ」をシンプル・低コストに扱えるデータストアとして、DynamoDBが適している点を説明しました。
イベント用途のように利用シーンが限定的なサービスであり、常時稼働インスタンスも不要だったため、特にコスト面でのメリットが大きく、運用負荷も抑えられるという点も伝えました。
活用方法
- スプレッドシートから取得した最新の来場者データをDynamoDBへ保存
- スクリーン表示に必要な来場者情報を取得
- 現在表示対象となる来場者情報のシンプルな保存・取得
よく使う機能
1. データ保存(PutItem)
- 来場者情報の保存先としてAmazon DynamoDBテーブルを利用しています
- PutItemで最新の来場者データを反映しています
2. データ取得(GetItem / Scan)
- 単一の来場者情報を取得する際はGetItemを利用しています
- 一覧表示用にはテーブル全体をScanで取得して利用しています
3. オンデマンドキャパシティモード
- キャパシティを事前に指定せず、読み書きリクエスト量に応じて課金されるオンデマンドキャパシティモードを利用しています。
- イベント用途のサービスでアクセス量の事前予測が難しかったため、アクセス量に応じて自動でスケールする点を理由に採用しました。
4. IAMによるテーブル操作権限の制御
- DynamoDBへアクセスする処理に対して、必要な操作権限のみを付与しています
- データ取得用とデータ更新用で、必要なDynamoDBアクション(GetItem/Scan/PutItem等)を分けて設定しています
ツールの良い点
- DBインスタンスの管理が不要で、運用負荷を抑えやすい
- アクセス頻度が限定的な用途では、オンデマンドキャパシティでコストを抑えやすい
- 複雑な検索が不要なサービスでは、シンプルなデータストアとして扱いやすい
- IAMでDynamoDBへの操作権限をテーブル/アクション単位で細かく制御できる
- スキーマレスのため、項目構造の追加・変更がアプリ側で柔軟に行える
ツールの課題点
- 事前にアクセスパターンを整理したうえで、テーブル設計を行う必要がある
- パーティションキーやソートキーの設計を誤ると、後から変更できず、テーブルの作り直しが必要になる場合がある
- JOINや柔軟な検索条件など、複雑なクエリには向いていない
- Scanに頼る設計になると、データ量が増えた際にパフォーマンスやコスト面で課題が出やすい
- 検索要件が増えた場合、GSIなどのインデックス設計を見直す必要がある
ツールを検討されている方へ
DynamoDBは、アクセスパターンが明確で、複雑なクエリが不要なサービスと相性が良いDBだと思います。
今回のようなイベント用途のように、特定のキーで読み書きが完結するサービスでは扱いやすく、必要なデータを安定して取得しやすい点がメリットです。
一方で、RDBのようにあとから自由にJOINしたり、複雑な検索条件を追加したりする用途には向いていません。
そのため、導入前に「どの画面で、どのデータを、どのキーで取得するか」を整理しておくことが重要だと思います。
今後の展望
DynamoDBは読み書き量に応じた課金体系のため、今後は読み書きコストおよびテーブル設計の最適化を進めていきたいです。
不要な書き込みを削減するため、更新があったデータのみをDynamoDBへ反映する構成を検討するとともに、読み書きリクエスト量を踏まえてオンデマンドキャパシティモードを継続するか、プロビジョンドキャパシティモードへ切り替えるかも判断したいです。
また、検索要件の増加に備え、Scanに依存しない取得方式を実現できるよう、キー設計やGSIの見直しも進めていきたいです。
フォースタートアップス株式会社 / 田畑 綾也
メンバー / フルスタックエンジニア・プロダクトエンジニア
よく見られているレビュー
フォースタートアップス株式会社 / 田畑 綾也
メンバー / フルスタックエンジニア・プロダクトエンジニア
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法


