インデックスの重大な変更の処理 - Amazon DynamoDB
仕組みパイプライン中心のオプションインデックス中心のオプションオンラインオプションベストプラクティス

インデックスの重大な変更の処理

OpenSearch ではインデックスに新しい属性を動的に追加できます。ただし、マッピングテンプレートが特定のキーに設定されている場合は、そのキーを変更する際に追加のアクションが必要になります。さらに、変更によって DynamoDB テーブルの全データの再処理が必要になる場合は、新たなエクスポートを開始するための手順を実行する必要があります。

注記

これらのどのオプションでも、DynamoDB テーブルと指定したマッピングテンプレートで型が競合していると、問題が発生する可能性があります。デッドレターキュー (DLQ) を必ず有効にしてください (開発中の場合でも)。これにより、OpenSearch のインデックスでのインデックス作成時に競合を引き起こすレコードについて、何が間違っているのかを把握しやすくなります。

仕組み

以下は、インデックスの重大な変更を処理するときに実行されるアクションの概要です。詳細な手順については、以降のセクションで説明します。

  • パイプラインを停止して開始する: このオプションでは、パイプラインの状態をリセットし、パイプラインを新たにフルエクスポートで再開します。非破壊的なオプションであるため、DynamoDB 内のインデックスやデータは削除されません。これを行う前に新しいインデックスを作成しないと、インデックス内の現在の _version よりも古いドキュメントの挿入がエクスポートによって試行されるため、バージョンの競合によるエラーが多数発生する可能性があります。これらのエラーは無視して問題ありません。パイプラインの停止中は、パイプラインの料金が課金されることはありません。

  • パイプラインを更新する: このオプションでは、状態を変えることなく、パイプラインの設定をブルー/グリーン方式で更新します。パイプラインに大幅な変更 (既存のインデックスに新しいルート、インデックス、またはキーを追加するなど) を行った場合は、パイプラインの完全なリセットとインデックスの再作成が必要になる場合があります。このオプションではフルエクスポートは実行されません。

  • インデックスを削除して再作成する: このオプションでは、インデックスのデータ設定とマッピング設定が削除されます。マッピングに重大な変更を加える前にはこれを行う必要があります。インデックスに依存しているアプリケーションは、インデックスが再作成されて同期されるまで機能しません。インデックスを削除しても、新たなエクスポートは開始されません。インデックスの削除は、パイプラインを更新した後にのみ行ってください。そうしないと、設定を更新する前にインデックスが再作成される可能性があります。

インデックスを削除してパイプラインをリセットする (パイプライン中心のオプション)

開発途中の場合は、通常、この方法が最速のオプションになります。OpenSearch Service でインデックスを削除し、パイプラインの停止と開始を行って、全データの新たなエクスポートを開始します。これにより、マッピングテンプレートが既存のインデックスと競合したり、処理が不完全なテーブルからデータが失われたりすることがなくなります。

  1. AWS Management Consoleから、あるいは AWS CLI か SDK で StopPipeline API オペレーションを使用して、パイプラインを停止します。

  2. 新しい変更でパイプライン設定を更新します。

  3. REST API コールまたは OpenSearch ダッシュボードを使用して OpenSearch Service のインデックスを削除します。

  4. コンソールから、あるいは AWS CLI か SDK で StartPipeline API オペレーションを使用して、パイプラインを開始します。

    注記

    これにより新たなフルエクスポートが開始され、追加費用が発生します。

  5. 新しいインデックスを作成するための新たなエクスポートが生成されるため、予期しない問題がないか監視します。

  6. OpenSearch Service でインデックスが想定どおりであることを確認します。

エクスポートが完了し、ストリームからの読み取りが再開されると、DynamoDB テーブルデータがインデックスで使用できるようになります。

インデックスを再作成してパイプラインをリセットする (インデックス中心のオプション)

この方法は、パイプラインを DynamoDB から再開する前に OpenSearch Service でインデックスの設計を何度も繰り返す必要がある場合に適しています。これは、開発中に検索パターンのイテレーションを迅速に進めたい場合や、イテレーションのたびに新たなエクスポートの完了を待機したくない場合に役立ちます。

  1. AWS Management Consoleから、あるいは AWS CLI か SDK で StopPipeline API オペレーションを呼び出して、パイプラインを停止します。

  2. OpenSearch でインデックスを削除し、目的のマッピングテンプレートを使って再作成します。サンプルデータを手動で挿入して、検索が意図したとおりに機能しているかを確認できます。サンプルデータが DynamoDB のデータと競合する可能性がある場合は、次のステップに進む前に必ず削除してください。

  3. パイプラインにインデックステンプレートがある場合は、削除するか、OpenSearch Service で作成済みのテンプレートに置き換えます。インデックスの名前がパイプラインでの名前と一致していることを確認してください。

  4. コンソールから、あるいは AWS CLI か SDK で StartPipeline API オペレーションを呼び出して、パイプラインを開始します。

    注記

    これにより新たなフルエクスポートが開始され、追加費用が発生します。

  5. 新しいインデックスを作成するための新たなエクスポートが生成されるため、予期しない問題がないか監視します。

エクスポートが完了し、ストリームからの読み取りが再開されると、DynamoDB テーブルデータがインデックスで使用できるようになります。

新しいインデックスとシンクを作成する (オンラインオプション)

この方法は、マッピングテンプレートを更新する必要があるものの、現在インデックスを本番環境で使用している場合に適しています。このオプションでは、新しいインデックスを作成し、同期と検証が完了した後にアプリケーションをそのインデックスに移動する必要があります。

注記

これにより、ストリーム上に別のコンシューマーが作成されます。AWS Lambda やグローバルテーブルのようなコンシューマーが他にもあると、問題になる可能性があります。新しいインデックスをロードするキャパシティを確保するために、既存のパイプラインの更新を一時停止しなければならなくなる場合があります。

  1. 新しい設定と別のインデックス名を使用して新しいパイプラインを作成します。

  2. 新しいインデックスに予期しない問題がないか監視します。

  3. アプリケーションを新しいインデックスに切り替えます。

  4. すべてが正しく動作していることを確認したら、古いパイプラインを停止して削除します。

型の競合の回避とデバッグのベストプラクティス

  • 型の競合が生じた場合のデバッグを容易にするためには、デッドレターキュー (DLQ) を常に使用します。

  • マッピングが含まれるインデックステンプレートを必ず使用し、include_keys を設定します。OpenSearch Service は新しいキーを動的にマッピングしますが、これによって予期しない動作 (GeoPoint を想定していたところ、string または object として作成された場合など) やエラー (long 値と float 値が混在している number など) の問題が発生する可能性があります。

  • 既存のインデックスを本番環境で引き続き使用する必要がある場合は、前述のインデックスの削除手順を、パイプライン設定ファイル内のインデックスの名前を変更する手順に置き換えることもできます。これにより、新しいインデックスが作成されます。完了したら、新しいインデックスをポイントするようにアプリケーションを更新する必要があります。

  • 型変換の問題をプロセッサで修正する場合は、UpdatePipeline を使ってテストできます。そのためには、停止と開始の手順を行うか、デッドレターキューの処理を実行して、以前にスキップされたエラーのあるドキュメントを修正する必要があります。