私たちには、S3にファイルをアップロードする.NETクライアントアプリケーションがあります。バケットに登録されたイベント通知は、ラムダをトリガしてファイルを処理します。保守を行う必要がある場合は、イベント通知を削除し、後で処理を再開する準備ができたら、処理を中断します。ラムダ+キネシスのコストの制御
イベント通知が無効になっている間にS3でキューに入れられたファイルのバックログを処理するために、私たちは各ファイルにS3キーを持つレコードをkinesisストリームに書き込みます。そして、Lambda各キネシス記録を消費する。これは、ストリーム内の断片の数を制御して大きなバックログを処理しているときに、並行性を制御できるので、私たちにはうってつけです。私たちはもともとSNSを使用していましたが、何千ものファイルを再処理する必要があったときにSNSはLambdaを継続して実行し、同時実行のしきい値を超えました。そのため、Kinesisに切り替えました。
今私たちが直面している問題は、私たちがかろうじて使用するにもかかわらず、キネシスの費用が私たちを殺していることです。毎分150〜200ファイルがアップロードされ、ラムダはそれぞれの処理に約15秒かかります。数時間処理を中断した場合、処理するファイル数は数千に上ります。 128シャードストリームで簡単に再処理できますが、月額1,400ドルの費用がかかります。ラムダを毎月運営する現在の費用は300ドル未満です。リカバリのシナリオで同時実行レベルを制御できるようにするには、コストを400％増やす必要があります。
大きなバックログを再処理する前に、デフォルトでストリームサイズを小さくしてからサイズを変更しようとする可能性がありますが、1つのシャードから128までストリームのサイズを変更すると非常に時間がかかります。私たちが計画外の停止から回復しようとしている場合、ストリームをリサイズするのを待つことなく、座って座ることはできません。だから、私の質問は以下のとおりです。
誰もがキューを排出同時ラムダの数の上限を制御することができるためキネシスの破片を使用する代わりにパターンをお勧めしますか？
キネシスをより効率的に使用するための欠けているものがありますか？