サーバレスのMoonMailラムダアーキテクチャ

Question

システム全体をラムダ関数の集合にするという考えは非常に魅力的なので、私はこのプロジェクトを検討してきました。実際、数年前、私はMoonMailとほとんど同じソフトウェアを書いていましたが、いくつかの仕様が変更されたために更新が予定されています。ソフトウェアをLambdaに移植したり、MoonMailを使うように修正したりしています。私は（DynamoDBのテーブルの名前のような）リソース名を変更して再デプロイする際、警告や古いテーブルがなかったことに気づいた、サーバレスを使用して、私のテストでは

と：

私は、次の質問を持っていますその内容は破壊された。私は、データベース上のすべてのデータを削除する設定ファイルの余分な文字のような単純な間違いはかなり危険だと思います。あなたはこの種の問題にどのように対処していますか？

SESによる電子メールの送信に関して。特定のアカウントの送信制限に達すると、どのようにスロットリングを処理しますか？あなたは指数バックオフをしますか？私はコードベースでこれを見つけることができないようです。このような状況が発生したレポの一般的な領域で私を指摘できれば非常に感謝しています。

Answer 1

1. MoonMailのテーブル名はs-templates.jsonに格納されています。このファイルはあまり触れられていないため、まだこの問題は発生していませんが、危険はまだありますが、CFで名前を変更するだけでテーブルを削除しないようにAWSチームにアプローチします。
2. Cloud Watch invocationで送信の上限を再試行します（私が間違っている場合はMMチームが私を修正しますが、99％は確信していません）。

Answer 2

DynamoDBテーブルを作成するときに、DeletionPolicy: Retainを設定して、クラウドフォーメーションによって誤って削除されないようにすることができます。

LambdaがSNSによって呼び出された場合、SESの制限を超えた場合に失敗することがあります。その後、SNSはバックオフを使用して配信を再試行します。

Answer 3

私のアプローチは、ダイナモブロックを別のプロセスで作成することです。したがって、私のサーバーレス設定は読み取り専用であり、dbは作成されません。私は頻繁に私のデータベースを再作成するとは思わないので：