前置き
前回の続きです。
これまでの深い考察は、最終的に「どのデータストアを選ぶか？」という極めて実践的な意思決定に繋がります。
DynamoDBのようなデータストアを選定する思考プロセスは、これまでの議論をすべて活用した段階的なフィルタリングのプロセスです。
それは、ビジネスの「Why」から始まり、アーキテクチャの「How」を経て、最終的な技術選定に至る、合理的で多層的な意思決定です。
用いる思考のプロセス：要求の漏斗（ファネル）
このプロセスは、大きな要求から具体的な技術へと絞り込んでいく漏斗（ファネル）としてイメージできます。
この思考が詳しく載っている書籍として、以下の本を載せておきます。
実際、アーキテクチャを選定したり、言語の選定をしたりするときにも、
このフィルタリング思考は、超必須なものですので、アーキテクトの方は、皆さん常識にしてみてください。
funnel フェーズ1：戦略的・ドメイン駆動フィルタリング (「Why」と「What」)
まず、ビジネス戦略とドメインの特性から、データストアの 「種類」 を大きく絞り込みます。
1. ドメインの特性は何か？ (DDDの視点)
コアドメインか？
もし、企業の競争優位性の源泉となる非常に複雑なビジネスルールを持つドメインなら、
そのロジックを豊かに表現できるリレーショナルデータベース（RDB）とORMの方が適している場合があります。
汎用/支援サブドメインか？
一方で、ユーザー認証情報や商品カタログのように、アクセスパターンが比較的単純で、
大量の読み書きが想定されるドメインなら、Key-Value型やドキュメント型のNoSQLが強力な候補になります。→ DynamoDBが候補に浮上
2. イベントソーシングを採用するか？
もしシステムの中心をイベントの不変なストリームとして設計するなら、その記録場所に最適なデータストアが必要です。
要件
・特定の集約（Aggregate）の全イベントを時系列で高速に読み出したい。
・書き込み性能が非常に高い。
・データは不変（Immutable）。
評価
DynamoDBの主キー設計（パーティションキー＝集約ID、ソートキー＝バージョン/タイムスタンプ）は、このアクセスパターンに完璧に適合します。→ DynamoDBが最有力候補
3. データモデルとアクセスパターンは？
・システムが扱うデータは、固定的なスキーマを持つ正規化されたテーブル構造よりも、
柔軟なJSONのような構造の方が自然ですか？
・データのアクセス方法は、「ユーザーIDでユーザー情報を取得する」のように、
特定のキーに基づいたシンプルなクエリが99% ですか？
・複雑なJOINやアドホックな集計は不要ですか？
もし答えがYesなら、アクセスパターンに基づいて設計するDynamoDBのようなNoSQLは、
RDBよりも圧倒的に高いパフォーマンスを発揮します。→ DynamoDBの適合性がさらに高い
funnel フェーズ2：品質特性と多層防御によるフィルタリング
次に、カオス実験などを通じて明確になった非機能要件（品質特性）を満たせるか、という観点で技術を絞り込みます。
1. 可用性と耐障害性の要件は？ (カオス実験からの学び)
我々のデータカオス実験は、「単一リージョンの障害に耐えられなければならない」という結論を導き出しましたか？
要件
マルチリージョンでのアクティブ-アクティブ構成がネイティブでサポートされていること。
評価
DynamoDBのグローバルテーブルは、この要件を数クリックで満たせる数少ないマネージドサービスです。
自前でRDBのマルチリージョンレプリケーションを構築・運用する複雑さと比較すると、
圧倒的な優位性 があります。→ 他の選択肢に対する強力な差別化要因
2. バックアップと復旧の要件は？
我々のカオス実験は、「オペミスによるデータ破損から15分以内に復旧できなければならない (RTO=15分)」という結論を導き出しましたか？
要件
継続的なバックアップと、特定の時点への高速な復旧（Point-in-Time Recovery）機能が必須。（以下に参考記事を引用）
評価
DynamoDBのPITRと、DynamoDB Streams → S3
へのリアルタイムアーカイブの組み合わせは、まさにこの多層防御の思想を実現するためのものです。→ 戦略的な要件との一致
3. スケーラビリティとパフォーマンスの要件は？
ビジネスは、予測不能なトラフィックの急増（スパイク）に対応できる必要がありますか？（狩野モデルにおける「当たり前品質」）
要件
どんな負荷状況でも、一貫して1桁ミリ秒台のレイテンシを提供できること。
評価
DynamoDBは、そのアーキテクチャ上、データ量やリクエスト数にほぼ関係なく、安定した低レイテンシを提供します。
これは、サーバーのスペックを上げる（スケールアップ）ことで対応する従来のRDBとは根本的に異なる点です。→ DynamoDBのコアコンピタンス
funnel フェーズ3：運用的・現実的フィルタリング
最後に、チームのスキルやコストといった現実的な制約を考慮します。
1. 運用負荷をどれだけ許容できるか？
インフラのプロビジョニング、パッチ適用、スケーリングといった運用作業にエンジニアの時間を割きたいですか？
評価
DynamoDBはサーバーレスです。これらの運用作業はすべてAWSが管理します。
チームはアプリケーションのビジネスロジックに集中できます。
2. チームのスキルセットは？
チームは、RDBの正規化ではなく、NoSQLのアクセスパターンに基づいたデータモデリングに習熟していますか？
評価
ここが唯一の懸念点・学習コストとなる可能性があります。
しかし、上記のフェーズでDynamoDBが最適という結論が出ているなら、それはチームがプロジェクト期間を通じて、学ぶべきスキルセットを明確に示唆しています。
当然、見積もりには、その期間を盛り込んで考える必要があります。
まとめ
このフィルタリングの思考プロセスを経ることで、DynamoDBの選定は、単なる
「流行りの技術だから」という理由
ではなく、
ビジネス戦略、ドメインの特性、そしてカオス実験によって証明された非機能要件に完璧に合致する
論理的で必然的な帰結として導き出されるのです。