データ配信のベストプラクティス

ストリームスループットに基づいて DataFreshnessInSecondsパラメータを設定します。値が低いほど配信頻度は増加しますが、出力ファイルが小さくなる可能性があります。値を大きくすると、配信サイクルごとにより多くのデータが蓄積されます。

DataFreshness メトリクスに Amazon CloudWatch アラームを作成して、配信レイテンシーが許容しきい値を超えた場合に検出します。

同じ Kinesis Data Streams ストリームから複数の配信を作成できます。各配信は独立して動作するため、複数の送信先に同時にデータを配信できます。

配信を作成する前に AWS Glue 、スキーマレジストリにスキーマを登録します。配信では、登録されたスキーマを使用して送信先テーブル構造を定義します。

配信はスキーマの進化をサポートしていません。スキーマが変更された場合は、更新されたスキーマを使用して配信を削除して再作成する必要があります。

プロデューサー側のスキーマ検証を使用して、すべてのレコードがストリームに書き込まれる前に登録されたスキーマに準拠していることを確認します。これにより、失敗したレコード配信が最小限に抑えられます。

ダウンストリームコンシューマーのクエリパターンに一致する出力キーテンプレートを選択します。たとえば、クエリが時間範囲によって頻繁にフィルタリングする場合は、日付ベースのプレフィックスを使用します。

GZIP または ZSTD 圧縮を有効にしてストレージコストを削減し、ダウンストリーム分析ワークロードの読み取りパフォーマンスを向上させます。

データアクセスパターンに基づいて、適切な Amazon S3 ストレージクラスを選択します。頻繁にアクセスされるデータには STANDARD、アクセス階層間で Amazon S3 がオブジェクトを自動的に移動できるようにするには INTELLIGENT_TIERING、ミリ秒の取得が必要なアクセス頻度の低いデータには GLACIER_IR を使用します。

配信が書き込む特定のバケットまたはテーブルに IAM ポリシーをスコープします。ワイルドカードリソース ARNs は使用しないでください。

配信で使用される IAM ロールの信頼ポリシーに aws:SourceArnおよび aws:SourceAccount条件キーを含めます。これにより、特定の配信のみがロールを引き受けることができるようにすることで、混乱した代理問題を回避できます。

AWS CloudTrail ログ記録を有効にして、すべての配信 API コールと設定変更を監査します。

機密データにはカスタマーマネージド AWS KMS キーを使用します。これにより、キーローテーション、アクセスポリシー、監査証跡を完全に制御できます。

配信には必ずデッドレターキューを設定します。送信先に配信できないレコードは、後で検査するためにデッドレターキューに送信されます。

CloudWatch でDLQDeliverySuccessメトリクス (DeliveryToS3.DLQDeliverySuccess または DeliveryToIceberg.DLQDeliverySuccess) をモニタリングして、レコードがデッドレターキューにルーティングされるタイミングを検出します。

デッドレターキューエントリを定期的に検査して配信失敗のパターンを特定し、プロデューサーまたは配信設定レベルで修正アクションを実行します。

配信のメトリクスDataFreshnessと失敗レコードメトリクス (DeliveryToS3.FailedRecordCount または DeliveryToIceberg.FailedRowCount) に CloudWatch アラームを作成して、配信の問題をプロアクティブに検出します。

配信の CloudWatch Logs を有効にして、詳細な配信診断とエラーメッセージをキャプチャします。

配信バイトメトリクス (DeliveryToS3.BytesOut または DeliveryToIceberg.BytesOut) を追跡してスループットをモニタリングし、データボリュームの予期しない低下を特定します。