Zenn
💽

YouTube作業BGM動画作成サービスの舞台裏〜第5章 DynamoDB - テーブル設計と選定理由

に公開
DynamoDB
RDBMS
tech

こんにちは、皆さん。今日は「なぜ我々のYouTube作業BGM動画生成サービスでRDBMSを捨ててDynamoDBを選んだのか」という話をしたいと思います。

データベース選びは、結婚相手を選ぶくらい重要です。間違えると後で泣きを見ることになりますからね。

DynamoDBとの運命の出会い

私たちのサービスは単純です。　ユーザーが音楽ファイルと静止画をアップロードすると、素敵なBGM動画を生成します。　シンプルなコンセプトですが、裏側ではAWS Lambdaがffmpegを呼び出して汗だくで動画を作っています。

「そんなの普通にMySQLでいいじゃん」　と思われるかもしれませんが、そこでちょっと待った。データベースは単なるデータの収納箱ではありません。システムの心臓部なのです。

DynamoDB テーブル設計 - シンプルさは最高の美徳

私たちのDynamoDBテーブル設計はとてもシンプルです。「JobStatusTable」という単一テーブルがすべてを司ります。

JobStatusTable
- jobId (パーティションキー): 処理を一意に識別するUUID
- status: queued, processing, completed, failed のいずれか
- progress: 0〜100の進捗率
- message: 「働いてます」的なメッセージ
- audioFiles: 音声ファイルのS3キーリスト
- imageFile: 画像ファイルのS3キー
- configuration: 様々な設定を詰め込んだマップ型
- result: 完成動画のURLやメタ情報を含むマップ型

私たちのシステムは、処理IDで問い合わせて状態を確認するというシンプルなアクセスパターンしかありません。高級レストランのフルコースではなく、おふくろの味の定食屋のようなシンプルさです。

マップ型 - 隠れた柔軟性の秘密兵器

DynamoDBの隠れた主役は「マップ型」です。これは、データのタンスのようなもの。好きなだけ引き出しを用意して、その中に何でも突っ込めます。

例えば、"configuration"の中にこんな情報を入れています：

"configuration": {
  "totalDuration": 60,
  "resolution": {
    "width": 1920,
    "height": 1080
  },
  "quality": "medium",
  "loopAudio": true
}

RDBMSなら設定項目ごとにカラムを増やすか別テーブルを作るところですが、DynamoDBではマップ型という便利な引き出しに全部放り込めます。引き出しの中に更に小さな引き出しを入れられるという、タンスの匠の技です。

RDBMSとの真剣勝負 - 選定のための死闘

データベース選びは5つの観点で真剣勝負を行いました。

1. スケーラビリティ勝負

RDBMS: 「もっと負荷に耐えたいなら、もっと強いサーバーを用意しろ」
DynamoDB: 「負荷が増えても、減っても、私が自動で調整するよ」

勝者: DynamoDB（オートパイロットの快適さ）

2. 運用負荷とインフラ管理勝負

RDBMS: 「OS更新とかバックアップとか、色々やることあるけど頑張ってね」
DynamoDB: 「管理？何それ、おいしいの？」

勝者: DynamoDB（無管理の極楽浄土）

3. データモデルと柔軟性勝負

RDBMS: 「私はSQLというエレガントな言語で複雑な質問に答えられるわ」
DynamoDB: 「私はシンプルだけど、データ構造の自由度は負けないよ」

勝者: 引き分け（使い方次第）

4. コスト構造勝負

RDBMS: 「最低限のサーバー代は常に払ってね」
DynamoDB: 「使った分だけ払えばいいよ。閑散期はほぼタダだよ」

勝者: DynamoDB（特にスタートアップフェーズで）

5. サーバーレスとの統合勝負

RDBMS: 「Lambda関数からの接続？コネクションプール頑張って設定してね」
DynamoDB: 「Lambda？親友だよ。API一発で呼び出せるよ」

勝者: DynamoDB（圧勝）

DynamoDBを選んだ理由 - 最終決断の時

結局のところ、私たちがDynamoDBを選んだのは次の理由からです：

  1. 単純なアクセスパターン: IDで検索して状態を取得・更新する、それだけ
  2. 完全サーバーレス: Lambda, S3, API Gatewayとの相性抜群
  3. 初期コストの最小化: 使った分だけ払うモデルはスタートアップの味方
  4. 開発速度優先: インフラ管理から解放され、アプリ開発に集中できる
  5. 必要十分な機能: 複雑なSQLクエリが必要ない用途に最適

私たちのサービスでは、データベースに求めるのは「ジョブの状態を記録して、問われたら答える」というシンプルな機能だけ。それなら重厚長大なRDBMSより、軽快なDynamoDBが最適だったのです。

DynamoDBのリスクと向き合う勇気

何事にもリスクはつきもの。DynamoDBを選ぶということは、以下のリスクと向き合うということです：

  • 複雑な集計クエリが苦手: ユーザー別の利用統計を複雑に分析するなら別の手段が必要
  • 400KBの項目サイズ制限: 巨大なデータは分割する必要あり
  • 学習コスト: NoSQLの考え方はRDBMSと違うので脳の切り替えが必要

ただし、これらのリスクは私たちのユースケースでは許容範囲。必要になったら、DynamoDBをプライマリストレージとしつつ、分析用途に別のデータベースを追加する「二刀流」も検討できます。

まとめ - DynamoDBとの幸せな結婚生活

データベース選びは結婚のようなもの。相手の長所も短所も理解した上で、自分のライフスタイルに合った選択をすることが大切です。

私たちのYouTube作業BGM動画生成サービスには、シンプルで堅牢、コスト効率が良く、サーバーレスアーキテクチャにマッチするDynamoDBが最適でした。

もし皆さんもサーバーレスで何か作るなら、DynamoDBという良きパートナーを検討してみてはいかがでしょうか。きっと「テーブル」を超えた素敵な関係が始まるはずです。

Discussion