🐥

あわやクラウド破産?! cron タスクの設定には慎重になろう

2 min read

概要

cron タスクの設定を誤って、Lambda が想定以上の回数実行されてしまった。
幸い、クラウド破産と言われるほどの請求額にはならなかったものの、再発防止のために原因と対策を考える。

何が起こったのか

Serverless framework を利用して、Lambda を定期実行する処理を作成した。

Lambda の設定はこの通り。

functions:
  foo: # 名称は仮です
    handler: handler.foo
    events:
      - schedule:
          # 毎日 AM 8:00に起動(JST)
          rate: cron(* 23 * * ? *)

cron 部分がこちら。

cron(* 23 * * ? *)

毎朝8時に実行するつもりが、8時台に毎分実行されてしまった。

正しくは以下のように設定するべきだった。(なんという凡ミス…)

cron(0 23 * * ? *)

何が原因だったのか

問題が起こった原因を考えてみる。

1. 中級者の慢心

cron の設定をしたのは、何も今回が初めてではない。

node-schedulenode-cronを利用して、定期処理を作成したことはある。

が、だからこそ慢心があったように思う。2重にも3重にも確認することなく、安易にデプロイしてしまった。

2. レビュー観点の欠如

ここまでの実装は aws の sandbox 環境で進めていた。要は、ひとまずお試し環境で動くものを作ってみよう、という段階だった。

なので、デプロイしてワンタイム実行するくらいで留めておけば良かった。
1度実行して成功したことを確認して、チームのコードレビューを挟めば良かったかもしれない。

cron 起動まではやりすぎだった、と今になって思う。
個人で実装を進めるあまり、他者からのレビューの観点を忘れていた。

3. 費用感の欠如

また、aws の費用感を自分は知らなさすぎた、という反省もある。

ふだんの自分の専門領域はフロントエンド開発で、AWS については知識不足だった。が、実装をしながら費用感を調べることはできた。

1回の実行に1万円がかかると分かっていれば、もっと慎重になれた。
1回の実行が1円だと分かっていれば、安心してトライ・アンド・エラーできた。

それすらも調べずにデプロイしたのは、良くなかった。

今後の対応策

それぞれの原因に対して、今後の対応策を考える。

1. 中級者の慢心

精神的な部分なので、対応策が難しい。

慢心せずいつでも慎重に、と言葉では言うことはできるけれど精神論でしか無く…。(良い対策がありましたら教授していただきたいところ…)

2. レビュー観点の欠如

今回の作業において、コードの github 管理化は作業の最後工程にあった。全てが完成してからレビュー依頼する、というもの。

が、早い段階で github 管理にし、レビューで approve をもらうことを cron 実行の前提とする。

3. 費用感の欠如

今さらだけど、以下のドキュメントに目を通した。(本当に今さらだ…)

このドキュメントに「計算ツール」というセクションがあり、Lambda の金額を試算することができる。

今回のケースを試算したところ、 0.01USDという結果になった。一安心…。

cron というか lambda を実装する際には、この試算を必須とし、試算結果を github の PR に付記することにする。

以上。

余談

ちなみに、今回実装した Lambda の内容については個人の技術ブログに書きました。

【パフォーマンス計測】severless framework を利用して、Lighthouse 計測結果の Datadog への送信を定期実行する(TypeScript 対応) - コンパイラかく語りき

Discussion

ログインするとコメントできます