# DynamoDB と OpenSearch Service のゼロ ETL 統合を使用するためのベストプラクティス
DynamoDB は、Amazon OpenSearch Service との [DynamoDB のゼロ ETL 統合](OpenSearchIngestionForDynamoDB.md)を行うことができます。詳細については、「[DynamoDB plugin for OpenSearch Ingestion](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/configure-client-ddb.html)」および「[specific best practices for Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/bp.html)」を参照してください。
## 設定
+ 検索を実行する必要があるデータのみをインデックス化します。実装する際は、必ずマッピングテンプレート (`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 からの取り込みが遅くなり、遅延が発生する可能性があります。
**注記**
[https://docs.aws.amazon.com/redshift/latest/dg/r_GREATEST_LEAST.html](https://docs.aws.amazon.com/redshift/latest/dg/r_GREATEST_LEAST.html) は、引数のセットを指定すると最大値の引数を返す SQL 関数です。