本記事では、Amazon.co.jpのような大規模なECサイトの機能をモデルケースとして仮定し、Amazon OpenSearch Service、Amazon DynamoDB、Amazon RDSの3つのデータストアが、どのような設計思想に基づいて使い分けられるか、解説します。
1. 3つのデータストアによる役割分担
ECサイトにおける主要な機能を「検索」「カート」「注文管理」の3つに分類した場合、それぞれの特性に適したデータストアの構成例は以下の通りです。
| コンポーネント | 想定される担当機能 | 特徴 |
|---|---|---|
| OpenSearch | 商品検索 | 全文検索および複雑なフィルタリングに特化 |
| DynamoDB | ショッピングカート | 高頻度な書き込み・読み取りに対し、低遅延でスケールする |
| RDS(Aurora) | 注文履歴・在庫管理 | 強い整合性と複雑なデータ関連付け（JOIN）を保証する |
概略図
2. OpenSearch：全文検索と複雑なフィルタリング
商品検索窓において「黒 リュック 防水」といった複数のキーワードで検索を行う際、Amazon OpenSearch Serviceのような検索エンジンが活用されていると推測できます。
反転インデックス（倒置索引）による高速化
OpenSearchは、ドキュメント内の単語と、その単語が含まれる場所を対応付けた「反転インデックス」を事前に作成します。これにより、数億件のデータが存在する場合でも、全データを走査することなく、キーワードに合致する情報を即座に抽出することが可能です。
検索エンジン特有の機能
RDBでは困難な以下の処理を、検索エンジンが補完する構成が一般的です。
- 表記揺れ・曖昧検索: 「リュック」と「バックパック」を関連語として扱う処理。
- スコアリング: キーワードとの適合度に基づき、検索結果を表示順にランク付けする処理。
- ファセット集計: 検索結果に対し、「カテゴリ別」「ブランド別」の件数を瞬時に算出する処理。
読み取り負荷の分散
検索リクエストが膨大になる場合、書き込みを担うノードから、読み取り専用のレプリカノードへデータを同期させ、クエリを分散させることでシステム全体の可用性を維持する設計が採られます。
検索用のOpenSearchには最新の商品情報が必要ですが、RDSへの書き込みと同時に更新するのは困難です。
そこで、裏側でCDC(AWSサービスではAWS Database Migration Serviceなど)という仕組みを使って、RDSの変更を自動でOpenSearchに同期させる構成が一般的です。
3. DynamoDB：高頻度なアクセスと水平スケーリング
「ショッピングカートへの追加」のように、ユーザーごとに頻繁にデータが更新される箇所では、Amazon DynamoDBのようなNoSQLデータベースの利用が合理的です。
パーティショニングによる負荷分散
DynamoDBはデータを「パーティション」という単位に分割し、複数のサーバーへ分散して保存します。
- ハッシュ関数を用いて「どのデータがどのサーバーにあるか」を直接特定するため、データ量が増大しても1桁ミリ秒台の応答速度を維持する特性があります。
- トラフィックの増大に応じて、システム側が自動的にパーティションを分割し、スループットを調整します。
テーブルを作る際、パーティションキーという項目を指定する。DynamoDBはこの値をハッシュ化し保存先を決めます。
コスト効率：オンデマンドモード
オンデマンドモードを選択した場合、リクエストが発生した分だけ課金される仕組みとなります。アクセスがない時間帯の固定費を抑制しつつ、急激なアクセス増加にも事前プロビジョニングなしで対応できるメリットがあります。
運用の注意点：データ構造の制約
DynamoDBはデータを分散させる特性上、複数のテーブルを結合する「JOIN」操作ができません。複雑な条件での検索（Scan操作）を多用すると、パフォーマンスの低下やコストの急増を招くため、キーによる単純なアクセスに最適化されたデータ設計が求められます。
整合性の考え方と分散の仕組み
DynamoDBがデータを分散させつつ整合性を保てるのは、「1行のデータ単位（項目単位）で矛盾が起きなければ許容する」という設計思想に基づいているためです。これに対し、RDSはデータベース全体で厳格な整合性を保証する設計となっています。具体的には、以下の仕組みでデータを処理しています。
-
同一サーバーへの保存: パーティションキーによって決定された特定のサーバーに、1行分のデータがまとめて保存されます。
-
3つのAZへのレプリケーション: 書き込まれたデータは、裏側で3つのアベイラビリティゾーン（AZ）にあるストレージノードへ自動的に複製されます。
-
読み取りの制御: 通常は3台のうち応答の速いサーバーからデータを読み取ります（結果整合性）。オプションで「強力な整合性のある読み取り（Strongly Consistent Read）」を指定すると、常に最新の書き込みが反映されたサーバーから読み取ることが可能です。
4. RDS：データの整合性と厳格な管理
決済処理や在庫管理など、データの不整合が許されないコア領域では、Amazon RDS（MySQLやPostgreSQL等）が適しています。
トランザクションによる整合性の保証
分散型のNoSQLとは異なり、RDBは「ACID特性」に基づく強力な一貫性を提供します。「支払処理は完了したが、注文履歴が作成されない」といった矛盾を防ぐため、一連の処理を一つの単位（トランザクション）として管理します。
RDBの物理的限界と対策
1台のプライマリインスタンスが書き込みを統括するため、スケーラビリティには物理的な制約が伴います。
- スペックの限界: インスタンスの垂直スケール（スペックアップ）には上限が存在します。
- コネクションの限界: 同時接続数に制限があるため、サーバーレス環境等からの大量の同時アクセスには、プロキシ（RDS Proxy等）を用いた管理が必要になる場合があります。
- コスト構造: インスタンスの稼働時間に応じて課金されるため、低頻度なアクセスであっても一定の固定費が発生します。
5. 結論：ユースケースに応じたデータストアの選定
現代的なシステム設計においては、以下の観点でデータストアを選択する構成が標準的なアプローチの一つと考えられます。
- 信頼性と関連性: 厳格な整合性が必要な基幹データや、複雑なリレーションを持つ管理データには RDS を選択する。
- スケーラビリティとコスト: シンプルなKey-Valueアクセスであり、アクセスの増減が激しい、あるいは低頻度な処理には DynamoDB を活用し、管理コストと実行コストを最適化する。
- 検索体験: ユーザー向けの高度な検索機能を提供する場合、RDSやDynamoDBからデータを同期し、フロントエンドの検索窓として OpenSearch を配置する。
このように、データストアを組み合わせることで、大規模なトラフィックに耐えうる、コスト効率の良いシステム構成が実現できます。