Lambdaで開発をする時に気をつけるシリーズ④
諦めないその精神も、時に最悪を引き起こす
みなさんどうも、jey_desunですん
どうですか？つかってますか？Lambda
今回はやる気満々なLambdaの、そんなやる気満々が故に起こってしまったことをご紹介します。
再試行回数
非同期呼び出し － Lambda は、関数エラーを 2 回再試行します。関数にすべての受信リクエストを処理する十分なキャパシティがない場合、関数に送信されるまで、イベントはキューの中に数時間または数日間保持される可能性があります。正常に処理できなかったイベントを把握するために、デッドレターキューを設定できます。詳細については、「非同期呼び出し」を参照してください。さて、今日この記事で注目するのは上記の部分。
関数エラーを 2 回再試行します。 この部分
2 回再試行します。 これ
2 回 ここ
このデフォルトで設定されたやる気が、悲劇を生んでしまったのです。
起こってしまった悲劇
LINE公式アカウント
LINEの公式アカウントの開発をしていた当時、とりあえず作らねばやらねばな状況でLambda+Cloud Watch Eventでバッチを作っていた時です。バッチの内容としては、あらかじめ設定したメッセージと配信時間になったらユーザーにそのメッセージを送るというバッチでした。
リリースした当初は、まぁまぁ動いていましたが、lambdaをよく調べる時間もなくとりあえず作ってしまってから数ヶ月後...
起こってしまった悲劇、それは「2重配信」
代償の重さ
LINEの公式アカウントのプランにもよるのですが月に送れるメッセージ数を超えた場合、一通n円かかります。
ここは公式アカウントを使用するクライアントさんとの契約にもよりますが「2重配信などをしてしまった」「送るメッセージに不備があった」などという場合、送ってしまった分の金額を補填するみたいな契約で
例えば1通1円だとして、10万人に送ってしまった時の一番最悪の場合
送った2通分 * 10万 = 20万円
お詫び配信分 * 10万 = 10万円
配信し直し * 10万 = 10万円
これらを全て補填すると40万くらいの損害が起きます。
理由は違いますが僕は新卒時代にこれで開発費を吹っ飛ばした経験があります。
なにが起こったか
配信を起動させるところまではできていてその後の処理でエラーが起きていました。
そしてやる気満々なことを知らずに設定をよく理解していなかったところ、デフォルトの再試行回数である2回、関数が繰り返され計3回処理が実行されてしまい、多重配信が行われてしまったのです。
よく理解せずに使ってるとこうなるのいい例
今回起こった事象も、ちゃんと調べて知っていれば再試行回数を0回にするなり、再試行しても大丈夫なような作りにしたりすることで回避ができた問題でした。
結論
ちなみに結構起きた問題はこの時作ったものが多くて、Lambdaってなんぞやってところから4日で作ったから許してください
シリーズ一覧
Author And Source
この問題について(Lambdaで開発をする時に気をつけるシリーズ④), 我々は、より多くの情報をここで見つけました https://zenn.dev/jey_desun/articles/cd798742414113著者帰属：元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Collection and Share based on the CC protocol