DynamoDB との統合に関するベストプラクティス

DynamoDB を他のサービスと統合する際は、各サービスを使用する際のベストプラクティスに必ず従います。ただし、統合に特有のベストプラクティスもいくつか考慮する必要があります。

DynamoDB でスナップショットを作成する

• 一般的には、Amazon S3 へのエクスポートを使用して、初期レプリケーションのスナップショットを作成することをお勧めします。この方法は費用対効果が高く、スループットのためにアプリケーションのトラフィックと競合することもありません。また、新しいテーブルへのバックアップと復元の後に、スキャンオペレーションを実行することも検討してください。これにより、アプリケーションとのスループットの競合を避けることができますが、一般的にはエクスポートよりもコスト効率が大きく低下します。

• エクスポートを行う際は、必ず StartTime を設定します。これにより、変更データキャプチャ (CDC) をいつ開始するかを簡単に決定できます。

• S3 へのエクスポートを使用する際は、S3 バケットにライフサイクルアクションを設定します。通常、Expiration アクションは 7 日に設定しても問題ありませんが、自社で定められているガイドラインに従ってください。取り込み後にアイテムを明示的に削除した場合でも、このアクションは問題を特定するのに役立ち、不要なコストを削減し、ポリシー違反を防ぐことができます。

DynamoDB でデータ変更をキャプチャする

• ほぼリアルタイムの CDC が必要な場合は、DynamoDB Streams または Amazon Kinesis Data Streams (KDS) を使用します。どちらを使用するかを決める際、通常は、どちらがダウンストリームサービスで使いやすいかを検討します。パーティションキーレベルで順番どおりにイベント処理を行う必要がある場合、または非常に大きいアイテムがある場合は、DynamoDB Streams を使用します。

• ほぼリアルタイムの CDC が必要ない場合は、Amazon S3 への増分エクスポートを使用して、2 つの時点の間に発生した変更のみをエクスポートできます。

  S3 へのエクスポートを使用してスナップショットの生成を行った場合は、同様のコードを使用して増分エクスポートを処理できるため、特に便利です。通常、S3 へのエクスポートは以前のストリーミングオプションよりも若干安価ですが、どのオプションを使用するかを決める主な要素はコストではありません。

• 通常、DynamoDB ストリームの同時コンシューマーは、最大 2 人です。統合戦略を計画する際には、この点を考慮してください。

• スキャンを使用して変更を検出しないでください。これは小規模ではうまくいくかもしれませんが、すぐに実用的ではなくなります。

OpenSearch Service と DynamoDB のゼロ ETL 統合

DynamoDB は、Amazon OpenSearch Service との DynamoDB のゼロ ETL 統合を行うことができます。詳細については、「DynamoDB plugin for OpenSearch Ingestion」および「specific best practices for Amazon OpenSearch Service」を参照してください。

構成

• 検索を実行する必要があるデータのみをインデックス化します。実装する際は、必ずマッピングテンプレート (template_type: index_template、template_content) および include_keys を使用します。

• ログを監視して、タイプの競合に関連するエラーがないか確認します。OpenSearch Service は、キーのすべての値が同じタイプであることを前提としています。同じでない場合、例外が生成されます。このようなエラーが発生した場合は、プロセッサを追加して、特定のキーが常に同じ値であるかどうかを確認できます。

• 通常、document_id 値には primary_key メタデータ値を使用します。OpenSearch Service では、ドキュメント ID は DynamoDB のプライマリキーと同等です。プライマリキーを使用するとドキュメントを見つけやすくなり、アップデートが矛盾なく常にそのドキュメントにレプリケートされます。

  プライマリキー (例: document_id: "${getMetadata('primary_key')}") は、getMetadata 補助関数を使用して取得できます。複合プライマリキーを使用している場合は、補助関数によって連結されます。

• 通常、action 設定には opensearch_action メタデータ値を使用します。これにより、OpenSearch Service のデータが DynamoDB の最新の状態と一致するようにアップデートがレプリケートされるようになります。

  プライマリキー (例: action: "${getMetadata('opensearch_action')}") は、getMetadata 補助関数を使用して取得できます。フィルタリングなどの用途では、dynamodb_event_name を使用してストリームイベントタイプを取得することもできます。ただし、通常は設定に action を使用しないでください。

オブザーバビリティ

• ドロップされたイベントを処理するには、必ず OpenSearch シンクでデッドレターキュー (DLQ) を使用します。DynamoDB は一般的に OpenSearch Service ほど構造化されておらず、予期しない問題が発生する可能性は常にあります。デッドレターキューを使用すると、個々のイベントを回復できるだけでなく、回復プロセスを自動化することもできます。これにより、インデックス全体を再構築する必要がなくなります。

• レプリケーションの遅延が想定を超えたことを知らせるアラートを必ず設定します。通常は、アラートノイズがあまり大きくならないように、設定を 1 分にしておくと安全です。これは、書き込みトラフィックの急増度や、パイプラインの OpenSearch Compute Unit (OCU) 設定によって異なる場合があります。

  レプリケーションの遅延が 24 時間を超えると、ストリームはイベントをドロップし始め、インデックスを最初から完全に再構築しない限り、精度の問題が発生します。

スケーリング

• パイプラインに自動スケーリングを使用すると、ワークロードに合わせて OCU をスケールアップまたはスケールダウンできます。

• 自動スケーリングを使用しないプロビジョニングされたスループットテーブルでは、書き込みキャパシティユニット (WCU) を 1000 で割った値に基づいて OCU を設定することをお勧めします。最小値をその値より 1 OCU 低く (ただし 1 以上)、最大値をその値を 1 OCU 上回るように設定します。

  • 計算式:

    OCU_minimum = GREATEST((table_WCU / 1000) - 1, 1)
    OCU_maximum = (table_WCU / 1000) + 1

  • 例: あるテーブルでは 25000 の WCU がプロビジョニングされています。パイプラインの OCU は、最小値を 24 (25000/1000 - 1) に、最大値を 26 (25000/1000 + 1) 以上に設定する必要があります。

• 自動スケーリングを使用するプロビジョニングされたスループットテーブルでは、最小および最大 WCU を 1000 で割った値に基づいて OCU を設定することをお勧めします。最小値を DynamoDB の最小値より 1 OCU 低く設定し、最大値を DynamoDB の最大値より少なくとも 1 OCU 高く設定します。

  • 計算式:

    OCU_minimum = GREATEST((table_minimum_WCU / 1000) - 1, 1)
    OCU_maximum = (table_maximum_WCU / 1000) + 1

  • 例: あるテーブルには、最小 8000、最大 14000 に設定された自動スケーリングポリシーがあります。パイプラインの OCU は、最小値を 7 (8000/1000 - 1) に、最大値を 15 (14000/1000 + 1) に設定する必要があります。

• オンデマンドスループットテーブルでは、1 秒あたりの書き込みリクエストユニット数の一般的な最大値と最小値に基づいて OCU を設定することをお勧めします。利用可能な集計によっては、より長い期間にわたる平均値の算出が必要な場合があります。最小値を DynamoDB の最小値より 1 OCU 低く設定し、最大値を DynamoDB の最大値より少なくとも 1 OCU 高く設定します。

  • 計算式:

    # Assuming we have writes aggregated at the minute level
    OCU_minimum = GREATEST((min(table_writes_1min) / (60 * 1000)) - 1, 1)
    OCU_maximum = (max(table_writes_1min) / (60 * 1000)) + 1

  • 例: あるテーブルの書き込みリクエストユニット数の平均最小値は 1 秒あたり 300 で、平均最大値は 4300 です。パイプラインの OCU は、最小値を 1 (300/1000 - 1、ただし 1 以上) に、最大値を 5 (4300/1000 + 1) に設定する必要があります。

• 送信先の OpenSearch Service インデックスのスケーリングに関するベストプラクティスに従ってください。インデックスのスケーリングが十分でない場合、DynamoDB からの取り込みが遅くなり、遅延が発生する可能性があります。

注記

GREATEST は、引数のセットを指定すると最大値の引数を返す SQL 関数です。