Purpose-built Data Platformを選択する

1. 1つのデータベースに複数のアクセス方法を押し込めない

既存システムでは、1つのデータベースが複数の役割を兼ねていることがあります。

例えば商品データに対して、

商品IDを指定して取得する
+
商品名や説明文から検索する

という2種類のアクセスがあるとします。

どちらも同じ商品データを使用しますが、必要としている処理は同じではありません。

商品IDによる取得
→ 既知のキーから特定データを取得

全文検索
→ 多数のデータから検索条件に合う結果を探す

既存システムが1つのデータベースで両方を処理しているからといって、AWS上のターゲット構成でも1つのデータストアへまとめ続ける必要はありません。

ここでは、データそのものが同じかではなく、どのアクセス方法でそのデータを利用するかを分けて考えます。

2. 正規データと検索用データの役割を分ける

目的別データ構成では、同じ論理データを複数のサービスで利用する場合でも、それぞれを同じ役割にはしません。

例えば、

Amazon DynamoDB
→ 正規の更新先

Amazon OpenSearch Service
→ 検索用の派生インデックス

という構成にできます。

アプリケーション
    │
    ├─ 登録 / 更新 / キー取得
    │          ↓
    │     Amazon DynamoDB
    │          │
    │          └──── データ変更を反映 ────┐
    │                                     │
    └─ 全文検索                           ▼
               └──────────────→ Amazon OpenSearch Service

この構成では、同じ商品を2か所へ保存していても、どちらが正規の状態かを曖昧にしません。

検索インデックスは、正規データから検索に必要な形へ派生させたデータとして扱います。

3. 既習のアクセスパターンを役割分担へつなげる

既知のキーを使うアクセスと全文検索では、適したデータアクセス方式が異なることは前提知識とします。

ここでは個々のサービス選択を繰り返すのではなく、

既知のキーによる取得 / 更新
→ 正規データ側の経路

全文検索 / 関連度検索
→ 検索用派生データ側の経路

として、1つのワークロードの中で役割を分離します。

例えば、GET /products/12345という処理と、「防水 軽量 黒」という条件から商品を検索する処理を、それぞれ別のデータ経路として設計します。

このページで重要なのは、Amazon DynamoDBやAmazon OpenSearch Serviceを単体で選ぶことではなく、同じ業務データに対する異なるアクセスパターンを、正規データと検索用派生データへ割り当てることです。

4. Amazon DynamoDBとAmazon OpenSearch Serviceを組み合わせる

キー中心の正規データアクセスと検索アクセスを分離する場合、

Amazon DynamoDB
→ 登録 / 更新 / キー取得

Amazon OpenSearch Service
→ 全文検索 / 関連度検索

という役割分担を構成できます。

                    商品データ
                        │
          ┌─────────────┴─────────────┐
          │                           │
          ▼                           ▼
   正規データアクセス              検索アクセス
          │                           │
          ▼                           ▼
   Amazon DynamoDB          Amazon OpenSearch Service
          │                           ▲
          └──── 正規データから反映 ───┘

ポイントは、2つのサービスを使うこと自体ではありません。

どちらを正規の更新先とし、どちらを派生した検索経路とするかを明確にすることです。

5. 同じ論理データでも更新経路は1つにする

既存の商品データベースが、商品ID検索・全文検索・登録・更新をすべて処理している場合でも、ターゲット構成では各処理を別のサービスへ割り当てられます。

ただし、Amazon DynamoDBとAmazon OpenSearch Serviceの両方を独立した正規更新先として扱う必要はありません。

登録 / 更新
     ↓
Amazon DynamoDB
     ↓
検索用データを派生
     ↓
Amazon OpenSearch Service

この構成では、DynamoDBを正規の状態、OpenSearch Serviceを検索のために最適化した状態として役割を明確にできます。

6. 正規データから検索インデックスへ変更を反映する

DynamoDBを正規データストア、OpenSearch Serviceを検索用インデックスとして利用する場合は、両者のデータをどのように連携するかもターゲット構成に含めます。

OpenSearch Ingestionを利用してDynamoDBからAmazon OpenSearch Serviceへデータを取り込む構成を利用できます。

初期データとその後の変更では、利用する仕組みが異なります。

既存のDynamoDBデータ
        │
        ├─ 初期データ
        │      ↓
        │   ポイントインタイムリカバリを有効化
        │      ↓
        │   S3へのエクスポート
        │      ↓
        │   OpenSearchへ取り込み
        │
        └─ その後の変更
               ↓
          DynamoDB Streams
               ↓
          OpenSearchへ反映

初期スナップショットを使用する構成では、DynamoDBのポイントインタイムリカバリを有効にして、S3へのエクスポートを利用します。

その後の作成、更新、削除をOpenSearch Ingestionで継続的に取り込む場合は、DynamoDB Streamsを有効にし、OpenSearch Ingestionで利用可能なストリームビュータイプを構成します。

NEW_IMAGEまたはNEW_AND_OLD_IMAGESを利用できる構成があるため、NEW_AND_OLD_IMAGESだけを唯一の必須設定として扱わないことが重要です。必要な変更情報とパイプライン構成に応じて、対応するストリームビュータイプを選択します。

これにより、アプリケーションがDynamoDBとOpenSearch Serviceへ別途二重書き込みする処理を独自実装する必要性を減らせます。

7. 検索インデックスへの反映は同時完了とは限らない

DynamoDBからOpenSearch Serviceへの変更は、ほぼリアルタイムに取り込むことができます。

ただし、

DynamoDBへの更新完了
=
同じ瞬間にOpenSearchの検索結果も更新済み

と考えてはいけません。検索インデックスへの反映には遅延が発生する可能性があります。

例えば、注文更新直後に更新した注文の最新状態を必ず確認する処理では、正規データストアであるDynamoDBから必要な整合性で読み取ります。

一方、商品説明の全文検索で短い反映遅延を許容できるなら、OpenSearch Serviceの検索インデックスを利用できます。

最新状態が必須
→ 正規データ側で確認

検索性が重要
+
短い反映遅延を許容
→ 検索インデックス

要求されるデータ鮮度もアクセス経路の選択条件になります。

8. スケーラビリティもアクセス経路ごとに考える

DynamoDBとOpenSearch Serviceへ役割を分けると、2つの経路の負荷は同じように増えるとは限りません。

商品IDによるAPIアクセス
→ 急増

全文検索
→ ほぼ一定

という場合もあれば、

DynamoDBへの更新
→ 正常

検索インデックスへの反映
→ 遅延

のように、正規データ経路は正常でも、派生した検索データの取り込み経路だけに負荷が集中することもあります。

この場合はDynamoDBの処理能力だけを見るのではなく、

DynamoDB
      ↓
OpenSearch Ingestion
      ↓
Amazon OpenSearch Service

という検索用派生データの反映経路を確認します。

正規データアクセス、検索用データの取り込み、検索要求を同じ負荷として扱わず、それぞれの経路で発生している処理量を確認することが重要です。

9. 検索に不要なデータまで無条件にインデックス化しない

DynamoDBの項目に多数の属性があっても、そのすべてをOpenSearch Serviceで検索するとは限りません。

例えば商品データに商品ID、商品名、説明、カテゴリ、ブランド、公開状態、仕入原価、内部管理番号、更新処理用フラグ、内部監査情報が存在していても、検索対象が商品名、説明、カテゴリ、ブランド、公開状態だけなら、検索に必要な属性を中心にインデックスを構成できます。

DynamoDB
正規データ
        │
        ├─ 検索に必要
        │      ↓
        │   OpenSearchへ
        │
        └─ 検索に不要
               ↓
           正規データ側だけで保持

検索インデックスは、正規データの完全なコピーである必要はありません。

検索に必要なデータを選択することで、検索インデックスの容量や取り込み処理を不要に増やさないようにします。

10. 「二重書き込み」と「派生データへの反映」を区別する

次の構成は注意が必要です。

アプリケーション
   │
   ├─ DynamoDBへ書き込み
   │
   └─ OpenSearchへ書き込み

アプリケーションが2つのデータストアをそれぞれ独立して正規の更新先として扱うと、DynamoDB成功 / OpenSearch失敗のような部分失敗をアプリケーション側で処理する必要が生じます。

一方、

アプリケーション
      ↓
DynamoDB
      ↓
変更データを連携
      ↓
OpenSearch

という構成なら、正規の更新と検索用派生データへの反映を分離できます。

目的別データストアを複数使う場合も、どこで正規状態を決定するかを明確にします。

11. ターゲットデータ構成の判断フロー

既存データへの操作を確認
        │
        ▼
アクセスパターンを分離
        │
        ├─ 既知のキーによる取得 / 更新
        │          ↓
        │      DynamoDB側の経路
        │
        └─ 全文検索 / 関連度検索
                   ↓
              OpenSearch側の経路
        │
        ▼
正規の更新先を決定
        │
        ▼
検索用派生データを定義
        │
        ▼
正規データから検索インデックスへの
反映方法を決定
        │
        ▼
許容できる反映遅延を確認
        │
        ▼
各データ経路の処理量を確認

重要なのは、DynamoDBかOpenSearch Serviceかという二者択一ではありません。

同じワークロードの中でも、正規のキーアクセスと検索アクセスを異なるデータ経路へ分離し、それぞれに適したサービスを利用できます。

12. 判断ポイント

13. まとめ

アクセスパターンを分解
        ↓
正規の更新経路を決定
        ↓
検索経路を分離
        ↓
データ反映方法を設計
        ↓
データ鮮度の要件を確認
        ↓
各経路の処理量を確認

DynamoDBとOpenSearch Serviceを組み合わせる場合は、

DynamoDB
→ キー中心の正規データアクセス

OpenSearch Service
→ 検索用の派生インデックス

という役割分担を明確にすることが、ターゲットデータ構成を判断する中心になります。