低コスト高品質! NoSQL代表格の頼りになるDB

参考になった

レビュー投稿日の情報になります

Terra Drone株式会社 / 万年道半ばんちゅ

テックリード / テックリード / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名

最終更新日2025/12/04投稿日2025/12/08

利用プラン	利用機能	ツールの利用規模	ツールの利用開始時期	事業形態
オンデマンドキャパシティモード	データ永続化のためのメインDBとして	51名〜100名	2023年9月	B to B

利用プラン	オンデマンドキャパシティモード
利用機能	データ永続化のためのメインDBとして
ツールの利用規模	51名〜100名
ツールの利用開始時期	2023年9月
事業形態	B to B

アーキテクチャ

アーキテクチャの意図・工夫

主にDynamoDBのテーブル設計となりますが、以下の点が工夫したポイントとなります。

テーブルはアプリケーションに対して1つだけにする -> RDBMSと違い、複数テーブルをジョインするといった考え方がないので一つのテーブルだけで運用します
組織IDのような絶対的な区切りとなるような識別子をパーティションキー(PK)として使う -> 他の組織の人は他の組織の情報は必ず見られないようにする、等の要件で使われる識別子を使用します
PKで区切った後にどのエンティティか？を判別するためにソートキー(SK)の接頭辞にエンティティ名をつける -> user-xxxだったり、drone-yyyだったりを名付けます。接尾辞にはミリ秒またはマイクロ秒のエポックタイムなどを使用するとユニークな行を作ることができます
エンティティ固有の情報(droneであったら最大飛行時間など)も属性(列のこと)として保存します -> 一見RDBMSのアンチパターンであるスパースに見えますが、DyonamoDBでは問題ありません

上記のポイントを踏まえてテーブル設計を行った結果、以下のようなクエリを発行できるようになりました。

組織Xのユーザー一覧を見たい時はcompanyID=xxxx-xxxx-... && beginWith=user-というクエリを発行
ID指定で個別の情報を取得したい時はGSI(グローバルセカンダリーインデックス)に設定しているidという属性指定で検索(id=abc...)
仮に組織Xのユーザー一覧に対して簡単な検索、例えば名前の部分一致を行いたい場合はcompanyID=xxxx-xxxx-... && beginWith=user-を使い、かつ条件指定でcontain=teraなどのスキャン条件を加える
ユーザーロールSA(システムアドミン)のような組織を跨いだデータを全て見れるユーザー用のAPIは別に用意しスキャンを用いて全要素取得する(SAは一部社員を想定しており、それほど使わない&レスポンスの遅さが許容できるためスキャンを用いている)

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

Amazon RDSを使い続けた時の月間コストの大きさが悩みの種でした。また、開発環境など必ずしも24時間365日使われるDBではなかったため、不使用時間のコストも削減したいと言う気持ちもありました。

どのような状態を目指していたか

以下のような状態を目指しました。

利用時間分だけコストが発生すること
それによってリスト検索や1件のデータ取得が過度に遅くならないこと
データの可視化が簡単に、安くできること(データ可視化のために多くのコストをかけないこと)

比較検討したサービス

Amazon RDS
Amazon Aurora serverless v2
MongoDB Atlas

比較した軸

ランニングコストの低さ
サービス同士の接続のしやすさ
Terraformでの監理のしやすさ

選定理由

月間コストの低さ
VPCを作成しなくてもLambda(APIサーバー)と連携できる手軽さ

導入の成果

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

月間コストはAmazon RDSの1/10以下になりました。また、それによって検索効率が落ちたりしていない(むしろ1件の取得は早くなっている)ので、とても満足しています。

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

コスト削減のための夜間のインスタンス停止や使用のための再起動などが必要なくなったのがとてもストレスフリーです。また、社内サーバーにあるRedashからAWS IAM経由によってDynamoDBとデータ連携できるため社内からであればAWSのコンソールを開かずにデータを取得、可視化できるのでエンジニア以外の作業も楽になりました。

導入時の苦労・悩み

LSI(ローカルセカンダリーインデックス)は作成時しか設定できないので、それの計画
フロントエンド側で行いたい検索方法をどのようにDynamoDBで達成するか
(上と似ているのですが)APIを使用するユーザーロールごとのクエリの発行方法

導入に向けた社内への説明

上長・チームへの説明

Amazon RDSを使用し続けた際の月間コストとDynamoDBを使用した際のコストの違いを比較して説明しました。また、リスト検索や条件絞り検索などの要件について確認を行いました。

活用方法

PoC段階のプロジェクトのメインDBとして、また検索があまり重要ではないサービスなどのメインDBとして使っています。

よく使う機能

オンデマンドキャパシティモードでメインDBとして使用
(現在はその用途では使用してないですが)機体の飛行ログなどの一時保管庫として使用 -> DynamoDB Streamを使用し、機体のステート監理に使用
一定期間後のログ削除のためのTTL機能

ツールの良い点

他の選択肢と比べた時のランニングコストの安さ
インデックスを用いた時のクエリの実行速度と取得の速さ
コンソール上でDynamoDB内のデータが見れるのでデータ可視化の手軽さ

ツールの課題点

インデックスの貼り方を考えないといけない特殊性
既存DBとしてRDBMSなどを使用している時のデータマイグレートの大変さ(AWS DMSを使えば移行できるが、行志向データをNoSQLスキーマに考え直さなければいけない)
複雑な検索に耐えられないこと(複雑な検索はスキャンになってしまうためレスポンス速度が落ちる)

ツールを検討されている方へ

インデックスの効率のいい貼り方やコストに関わってくるキャパシティ(RCU/WCU)などDynamoDB固有の概念はあるものの、使いこなせればとても役に立つDBです。特にAWSのLambdaやAppsyncをAPIサーバーとして使っているのであれば連携がとても楽なので、素早くプロダクトを作りたい時や、サービス初期にまとまった売り上げが見込めない場合などにはとても助かるアーキテクチャになると思います。