この物語はノンフィクションですが、業務と関係する内容のため、実際と異なる人名・地名・数値に置き換えた上でお伝えします。
これは、私がクラウド開発業務に携わっていた頃に起こった出来事です
ﾋｭ~~~………(怖い音)
L a m b d a 課 金 炎 上
体験者 Y・N (仮名)
当時の私は、AWSを使ったクラウドサービス開発の業務に従事していました
クラウドを使った業務はまだ1年目で、分からないことも多く、リーダーのSさんと相談しながら仕事を進める日々でした
「先輩、お疲れ様です」
「お疲れ様」
ある日、私が業務を終えようとした時のこと
「おや？」
ﾌｫ~~~ﾝ…… (怖い音)
開発環境にデプロイしたLambdaが、動き続けていたのです
Lambdaは、クラウド上でプログラムを実行できるマイクロサービスで、
サーバーを立ち上げずに使用できることが特徴
Lambdaや、その他のいわゆる「サーバーレス」なサービスの恩恵によって、
私たちは自前でサーバーを立ち上げることなく、またクラウド上でインスタンスを立ち上げることなく、
高いスケール性で、かつ費用を抑えて計算資源を利用できているのでした
そんな「サーバーレス」なはずのLambdaが、動き続けている
不審な挙動に私は一瞬、違和感を感じました
「でもこれは他プロジェクトでデプロイできていたものを、こっちのプロジェクトのCodePipelineに移植しただけだから、問題ないよな……」
今思えば、あの時の違和感を、無視するべきではなかったのです
ﾋｭ~~~……ﾄﾞﾛﾄﾞﾛﾄﾞﾛ……(怖い音)
翌日の朝
「SさんからSlackで緊急っぽい連絡がある、一体何だ」
【緊急】 AWSコスト増 (特にLambda)
ﾄﾞｩｰｰｰﾝ……(怖い音)
まさか自分ではないよな
そう思いました
鼓動が速くなるのを感じながら、AWS Cost Explolerを開いて状況を確認すると
「430USDだと……？ 嘘だろ……」
ﾊﾞｧｧｧｧﾝ(怖い音)
普段はすべてのサービスをひっくるめて50USDにも満たないような使用料です
その日の430USD、しかもLambda単独での430USDは、明らかにおかしな値でした
全身から嫌な汗が噴き出るのを感じました
自分は正しくデプロイしたはずだと思い込んでいたので、心当たりは全くありませんでした……
……
いや、
実は一つだけ、心当たりがありました
あの常駐しているLambdaです
ﾄﾞｩｰｰｰﾝ……(怖い音)
「Lambdaなのに常駐はおかしいな、何かあるな」
恐る恐る、CloudWatchを開き、Lambdaのメトリクスを確認した
その時
ﾊﾞﾝ (怖い音)
1分間のLambda起動数
40,000
ｳﾜｧｧｧｧｧｧｧｧｧ (怖い音)
これやん
……
プログラムを先方の関係者と確認したのですが、そもそも常駐することを前提として書かれていたソースコードで、
常駐していること自体は想定内とのことでした
Lambdaの起動時間は最長15分、つまり普通に使っている限り15分以内に終わるので、常駐させることはできない、というかそもそもそういう使い方をすることを想定したサービスではありません
でも常駐させたかった、そんな時に彼らはどうしたか
Lambdaの起動時間内に、もう一度同じLambdaを起動する、そうすると次から次へと切れ目なくLambdaが起動し続けるので、常駐させることが出来る
という黒魔術を使用していたのです
サーバーレスとは？？？ (怖い音)
デプロイ時の設定が正しければ、起動時間が残り3分になったタイミングで次のLambdaが起動するはずで
そうすると最初に起動してからは、同時実行数1~2でLambdaが動き続けるはず
ここで、私は自分の犯した誤ちに気づきました
デプロイ設定を誤って、別のLambdaと同じ値に設定してしまっており、起動時間の最大値を3分にしていた
つまりLambdaを起動すると瞬時にまた同じLambdaが起動する
結果、あり得ないペースで大量のLambdaを起動し続ける
無限地獄
そんな恐ろしい悪夢を、私自身の手で作り上げてしまったのです
ﾄﾞｩｰｰｰﾝ……(怖い音)
「本当にすみません、本当にすみません」
「開発用なので多少は大丈夫です、次は気を付けてください」
例のLambdaは、設定タブ -> 同時起動タブ を開き、同時実行数を0に設定するお祓いをすることで、沈静化させることができました
その後、正しい設定で再度デプロイし直し、今では静かに、ちゃんと同時実行数1で動き続けています
それにしても、あの時の荒れ狂うLambda、あれはいったい、どのような霊の仕業だったのでしょうか……
……
ﾋｭ~~~……ﾄﾞﾛﾄﾞﾛﾄﾞﾛ……(怖い音)
都内、某スタジオ
恐れおののく子供、泣いてしまう子供
「諸君、落ち着きたまえ こんな時は例のおまじないをしよう」
「はい、ゴローさん」
イワコデジマ イワコデジマ
本怖（ほんこわ） 五字切り
皆（かい）
祷（とう）
怖（ほう）
無（ぶ）
弱気（じゃっき） 退散
ﾁﾘﾝﾁﾘﾝ (鈴の音)
喝（か）ッ――――――！！！
本日はスタジオに霊能研究家、久遠田 寒輪（くおた かんわ）先生にお越しいただきました
先生はAWSマネージドサービスを利用する際の利用上限 (クォータ) に詳しく、クォータを緩和するベストな方法に関して他の追随を許さない、ノウハウをお持ちです
「先生、体験者 (Y・Nさん) がこのようなミスをすることを防ぐ手段はなかったのでしょうか」
「事後対応の話になってしまいますが、まずはコストが増大した際に即座にアラームを上げられるようにすること。AWSにはその機能があります。
またこのケースではLambdaが1つだけ起動していれば良いので、Lambdaの実行数が増大しないように、同時実行数を1~2に設定しておくのも有効かもしれませんね。何もしないと、今回のようなミスをしてしまったときに最大同時実行数の1000 (これも大事なクォータの一つですね♡) まで容易に到達してしまうでしょうから。」
「なるほど」
「あとは、そもそも処理を常駐させたいときにLambdaを使うのが果たして正しいのか？というところから考え直した方が良いのかもしれませんね。」
「ド正論だな」
闇を照らす霊訓（れいくん）
不審な挙動を検知できるよう、CloudWatch Metrics + Alarmを利用したリソース監視や、利用コストの閾値アラーム設定などを行っておく
Lambdaの同時実行数があらかじめ決まっている場合は、その数を予約実行数として設定することで、それ以上は起動しないようにできる
サーバーレスな構成で無理が生じた時、そもそもサーバーレスが妥当なのか今一度検討する
「みんなもこの教訓を活かして、健やかなサーバーレスサービスを作りましょう」
「はい、ゴローさん」
「でもゴローさん、せっかくサーバーレスな構成でシステムを作ったのに背後でLambdaが常に動いてなければいけないのってもはやサーバーレスじゃないですよね」
ﾜﾊﾊﾊ (スタジオ爆笑)
「うるさいなあ、大人の都合です」