【要約】DynamoDB Streams + EventBridge Pipes で実現するマルチテナントのログ後処理 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
マルチテナントシステムを構築するエンジニアは、テナント増に伴うログ後処理の管理コスト増大に直面する。テナントごとにDynamoDBテーブルを分離している場合、以下の問題が発生する。
- ・テナントごとにLambdaを用意すると、関数の数が爆発的に増加する。
- ・共有Lambdaにイベントソースマッピングを追加する方式では、テナント追加のたびに共有スタックの更新が必要となり、スタック間の依存関係が生じる。
- ・書き込みのバースト時にLambdaの同時実行数が急増し、リソース制御が困難になる。
// Approach
開発者は、EventBridge PipesとSQSを介してイベントを集約するアーキテクチャを採用することで、これらの課題を解決する。具体的な手順は以下の通りである。
- ・各テナントのDynamoDBテーブルでStreamsを有効化する。
- ・テナントごとのスタック内でEventBridge Pipeを定義し、INSERTイベントのみをフィルタリングする。
- ・Pipeのターゲットとして、全テナントが共有するSQSキューを指定する。
- ・共有LambdaをSQSトリガーとして設定し、集約されたログを一括処理する。
// Result
この構成の導入により、システムの疎結合化と運用コストの劇的な削減が実現する。具体的な成果は以下の通りである。
- ・テナント追加時に共有Lambda側の設定変更が不要になり、デプロイの独立性が確保される。
- ・Pipesのフィルタリングにより、Lambdaの呼び出し回数を大幅に削減できる（例：1日7万回から1万回へ、約86%削減）。
- ・SQSによるバッファリングとDLQ（デッドレターキュー）の活用により、負荷平準化と耐障害性が向上する。
Senior Engineer Insight
> 実戦における設計として非常に優れている。特にPipesをテナントスタック内に閉じ込めることで、CI/CDのデプロイサイクルを分離できる点は、大規模運用において極めて重要だ。ただし、SQS標準キューの特性である「順序非保証」と「重複配信」への対策は必須である。Lambdaの実装において、必ずログID等を用いた冪等性の担保を徹底しなければ、データ整合性を損なうリスクがある点に注意せよ。