はじめに
こんにちは。製造エネルギーサービス事業部の後藤です。
フューチャーでは、社内の有志メンバーが集まり、システム開発におけるベストプラクティスをまとめた「アーキテクチャ設計ガイドライン」の整備・公開しています。
これまでフロントエンドからバックエンド、クラウドインフラ、Git戦略など幅広い分野のガイドラインを公開してきましたが、この度新たに「DynamoDB設計ガイドライン」を公開しました！
本記事では、このDynamoDB設計ガイドラインの概要と、特に読んでいただきたい見どころ、ガイドライン作成活動の感想をお届けします。
フューチャーのアーキテクチャ設計ガイドラインとは？
フューチャーの設計ガイドラインは「社内の有志が作成する、良いアーキテクチャを実現するための設計ガイドライン」です。
エンタープライズ領域では、高度なセキュリティや保守運用性などの非機能要件が重視されます。社内で培ったエンタープライズシステム開発向けのノウハウを集約することで、以下のような目的を達成することを目指しています。
- 車輪の再発明を防ぐ: 設計者が悩むポイントを軽減し、本当に必要な設計に集中する
- 設計品質の標準化: プロジェクト間での品質のばらつきや属人性をなくす
- リスクの低減: 非機能要件や法令遵守などの考慮漏れを防ぐ
- 知見の共有: チーム・組織内での知見の共有を促進する
「答えを提供するのではなく、考えるための土台を提供する」というスタンスです。プロジェクト固有の要件に合わせて、評価・上書きして利用することを想定しています。
なぜDynamoDBのガイドラインを作ったのか
AWSが提供するフルマネージドなNoSQLデータベースである「DynamoDB」。
インフラのメンテナンスがほとんど不要で、アクセスパターンが決まっている場合の超高速処理やスケーリング性能は非常に魅力的です。
しかし、RDBMS（リレーショナルデータベース）と同じ感覚で設計・利用しようとすると、痛い目を見ます。
「SQLが使えない」「複雑な集計ができない」といった特性を正しく理解し、技術選定の段階から慎重に判断する必要があるため、今回その勘所をガイドラインとしてまとめることにしました。
DynamoDB設計ガイドラインの目次
本ガイドラインは、技術選定から運用・セキュリティまで、エンタープライズ開発で考慮すべき事項を網羅しています。
- はじめに
- DynamoDB選定
- 命名規則
- データモデリング
- インデックス設計
- API利用
- DynamoDB Streams
- 他のデータストアとの組み合わせ
- SDK
- テスト
- 性能
- コスト
- 可用性
- 監視
- セキュリティ
- 移行
ガイドラインの見どころ
1. 迷ったらRDBMSを選定する！〜DynamoDB採用のノックアウト要件〜
DynamoDBは万能ではありません。「予測可能なアクセスパターンに対して高トラフィックを低遅延で処理できる」という強みは、クエリの柔軟性との引き換えで成り立っています。
そのため、ガイドラインでは「以下の要件に該当する場合はDynamoDB採用のノックアウト要件とし、RDBMSを検討すべき」と推奨しています。
- 将来アクセスパターンが変化する場合（キーを基本的に変更できないため）
- リアルタイムかつ柔軟な分析・複雑な検索条件が必要な場合
- 複数のデータ集約をまたがる、厳格な一貫性が必要な場合（会計システムや在庫引当など）
「高負荷になりそうだからとりあえずDynamoDB」ではなく、Aurora（PostgreSQL）などのRDBMSで適切なチューニングを行えば、秒間700トランザクション（1トランザクションあたり3SQL程度）を処理できた実績もあるため、「まずはRDBMSで解決できない課題がある時にのみDynamoDBの採用を検討する」という考え方を推奨しています。
2. データモデリングは「1にも2にもアクセスパターン」
RDBMSとDynamoDBでは、設計アプローチ（プロセス）が全く異なります。ここを理解せずにテーブル設計をすると失敗します。
- RDBMSの設計: データの構造と正規化に重点を置いてデータモデルを設計し、その後でクエリを作成する（データ中心）
- DynamoDBの設計: アプリケーションがデータをどのように利用するか、「アクセスパターン」の分析とデータモデルの設計を同時に行う（アプリケーション中心）
DynamoDBは基本的にテーブルの結合（JOIN）ができず、キーを基準にデータにアクセスします。そのため、ビジネス要件から「従業員情報をIDで検索する」などのユースケースを洗い出し、それを満たせるテーブルとインデックスのスキーマを設計していく具体的なプロセスをガイドライン内で解説しています。
ガイドライン作成の裏側（会の流れと雰囲気）
今回のガイドライン作成は、社内の有志メンバーが集まり、約2ヶ月間（30分×全8回）のタスクフォース形式で実施しました。
- 募集・キックオフ: Slackで参加者を募集し、目次案と担当を決定。
- 非同期執筆: Google Docsの提案モードを使って各自が原稿を執筆。
- 定例レビュー: 週1回のミーティングでレビューと議論を実施。
ガイドライン作成に参加しての感想
今回、社内の有志活動としてこのガイドラインの執筆に参加しましたが、非常に得られるものが多かったです。
シニアで技術に強いメンバーが多く参加しており、手厚いレビューを受けられたことや、普段関わることの少ないスペシャリストたちと繋がりを持てたことは貴重な経験でした。また、異なるプロジェクトの要件や運用方法を知ることで、視野が大きく広がりました。
技術ブログの執筆やガイドライン作成といった「言語化・体系化」のアウトプット作業を通じて、確実に構成力や文章力が上がったと感じています。この力は普段の業務でも大いに活きています。
おわりに
今回公開したDynamoDB設計ガイドラインが、皆様のシステム開発における技術選定や設計の一助になれば幸いです。