DynamoDB によるストリーミングデータ

AWS でのアプリケーション開発

Ricardo Sueiras

Principal Technologist

DynamoDB Streams の基礎

 

• データベースの変更にほぼリアルタイムで反応します。
• イベント駆動型パターンに基づいています。
• 挿入・変更・削除のたびにストリームレコードが生成されます。
• テーブルをポーリングせずにリアクティブなアプリを構築できます。
• デフォルトでは無効です。StreamSpecification で有効化します。
• 各ストリームはテーブルの ARN とは異なる独自の ARN を持ちます。

保持期間

 

• ストリームレコードは 24 時間保持されます。
  • 保持期間は固定で、変更できません。
• ビュータイプを変更するにはストリームを再作成する必要があります。
  • 新しいストリームには新しいストリーム ARN が生成されます。

ストリームと DynamoDB 読み取りキャパシティユニット

 

• ストリームの読み取りは読み取りキャパシティユニット（RCU）を消費しません。
• ストリームを有効にしてもプロビジョンドスループットに影響はありません。

ストリームレコード

• 各ストリームレコードには変更内容を示すメタデータが含まれます。
• ストリームは 3 種類のイベントを記録します。
  • INSERT
  • MODIFY
  • REMOVE

 

• ビュータイプにより各レコードに含まれるデータが決まります。
  • KEYS_ONLY: パーティションキーとソートキーのみ。
  • NEW_IMAGE: 変更後のアイテム全体。
  • OLD_IMAGE: 変更前のアイテム全体。
  • NEW_AND_OLD_IMAGES: 変更前後のアイテム。
• NEW_AND_OLD_IMAGES は監査用途に最適です。
• DynamoDB グローバルテーブルでは必須です。

• ストリームはパーティションキー単位で順序を保証します。
• Lambda はレコードをバッチ単位で処理します。
  • バッチが成功するたびにチェックポイントが記録されます。
  • 失敗したバッチは再試行されます。
  • 成功するかレコードが期限切れになるまで再試行が続きます。

 

 

• Lambda はもっとも一般的なストリームコンシューマーです。
• ポーリングベースのイベントソースマッピングを使用します。
• ストリームからレコードを読み取ります。
• レコードのバッチを関数に渡して呼び出します。

アーキテクチャパターン

 

• 代表的なエンドツーエンドのパターンを示します。
  • DynamoDB にアイテムの更新が書き込まれます。
  • 変更によりストリームレコードが生成されます。
  • レコードが Lambda をトリガーして処理が実行されます。

スケーリング

 

• ストリームは内部でシャードに分割されます。
  • Kinesis Data Streams と同様の仕組みです。
• 各シャードは最大 2 つの同時コンシューマーを許可します。
  • この上限を超えると読み取りスロットリングが発生しやすくなります。

• Lambda の同時実行数はシャード数に応じてスケールします。
• 以下のパラメータで処理を調整できます。
  • BatchSize: 1 回の呼び出しあたりの最大レコード数。
  • MaximumBatchingWindow: 部分バッチを待機する時間。
  • MaximumRetryAttempts: 失敗先に送る前の再試行回数。
  • MaximumRecordAgeInSeconds: この期間を超えたレコードを破棄。
  • ParallelizationFactor: シャードあたりの並列処理数（最大 10）。

フィルタリングとタンブリングウィンドウ

• Lambda はフィルター条件をサポートしています。
  • 関数が呼び出される前にレコードを除外できます。
  • 不要な呼び出しとコストを削減できます。
• Lambda はタンブリングウィンドウをサポートしています。
  • シャード内の複数バッチにまたがる状態を集計できます。

 

重複レコードの管理

• ストリームは各変更をちょうど 1 回記録します。
• Lambda は「少なくとも 1 回」のセマンティクスでレコードを処理します。
  • 再試行により同じレコードが再処理される場合があります。
• コンシューマーは冪等になるよう設計してください。
• 一般的なパターンとして、処理済みの eventID または SequenceNumber を保存します。
  • 処理済みのレコードはスキップします。
  • どちらも再試行をまたいで安定した値を保ちます。
  • 信頼性の高い冪等キーとして機能します。

 

障害処理

 

• ReportBatchItemFailures は失敗したレコードのみを再試行します。
• Lambda の失敗には以下の方法で対処します。
  • バッチを二分割する BisectBatchOnFunctionError。
  • 再試行の制御。
  • 再試行を使い果たしたポイズンバッチ向けの失敗先。

DynamoDB と Kinesis の連携

 

• テーブルの変更を Kinesis Data Streams に直接プッシュできます。
  • DynamoDB 向け Kinesis Data Streams 機能を使用します。
  • DynamoDB Streams とは連鎖せず、独立した並列機能です。
  • イベントは DynamoDB Streams を経由しません。
• 同じテーブルで両方を同時に使用できます。
  • それぞれ独立して動作します。
  • より広範なストリーミングおよび分析アーキテクチャを支えます。

モニタリング：よくある問題

 

• 注意すべき代表的な運用上の問題を示します。
  • ホットパーティション。
  • 再試行の失敗。
  • 重複処理。
  • スロットリングとコンシューマーの遅延。

モニタリング：CloudWatch メトリクス

• 監視すべき主要な CloudWatch メトリクスを示します。
  • Lambda Errors: コードまたは下流の問題を検出します。
  • IteratorAge: 値が大きい場合はコンシューマーの遅延を示します。
  • スロットリングメトリクス: 読み取り上限の超過を示します。
  • バッチ処理の失敗: DLQ に送信されたレコード。

 

セキュリティ

• ストリームへのアクセスは IAM 権限で制御されます。
• ストリームはテーブルの暗号化設定を継承します。
  • KMS による保存時のサーバーサイド暗号化を含みます。
• コンシューマーと下流プロセッサーには最小権限ポリシーを適用してください。

 

練習しましょう！

AWS でのアプリケーション開発