あわやクラウド破産?! cron タスクの設定には慎重になろう
概要
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-schedule や node-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 の内容については個人の技術ブログに書きました。
Discussion