AmazonCloudFrontのInvaridation機能で20万円ぶっ飛ばした話

こんにちは!エンジニアのH.Yです。

皆様はAmazonCloudFront(以下 CF)をご存知でしょうか?
タイトルが不穏ですがこちらに触発されて私も書いてみようとなりました。
社内ブログで「会社に20万損させたよ」というエントリを書かせてもらえる弊社は寛大です。
ありがとうございます。そしてすいませんでした。ご迷惑おかけして申し訳ありません。

Invalidationって?


さて、CFを使用したことがある、という人でもInvalidation機能を使用したことがあるという人はあまり多くない印象があります。
ドキュメントはこちらです。
要は「指定されたパスの各CFエッジサーバに保存されているキャッシュを残りのキャッシュ時間に関係なく削除する機能」というものです。
詳しくはリンク先をご覧ください。

(今回損失を出す際に使用したのはAPIでしたが)Webコンソールを使用することでも本機能を使用することが出来ます。スクリーンショット_2016-09-26_午後7_27_40

 

AWSにログイン後、CFを選択します。スクリーンショット_2016-09-30_午後7_03_31

 

ディストリビューション一覧が表示されますので、キャッシュ削除したいオブジェクトがあるディストリビューションを選択し、「Distribution Settings」を押します。スクリーンショット_2016-09-30_午後7_03_40

 

詳細画面で「Invalidations」を選択し、「Criate Invaridation」を押します。

AWS4

削除したいパスを入力し、「Invalidate」を押せば直ちにオブジェクトのキャッシュ削除が開始されます。

どのようにして20万円損したのか


とあるサイトに動画を下図のような感じで配信する要件がありました。

system

①でFTP/PUTを受ける動画ファイルは不明なタイミングで内容が更新される可能性があります。
その際はCF上の動画キャッシュを更新する必要がある…と、言った状況でした。

と言ったこともあり、どうしようかと思っていたところInvalidationを発見し、料金・危険性等の確認を怠り使用したと言った流れです。

動画更新バッチは5分毎に叩かれ1回毎に約40個のパスをInvalidation処理し、約1ヶ月と少し放置した結果
60(分) * 24(時間) / 5(バッチ更新間隔) * 40(動画ファイル個数) * 35(日) = 約40万リクエスト
1リクエストによって$0.005ドルのコストですから約2000ドルかかってしまったというわけです

反省


結局ある程度古い動画が出ていても10分以内で更新されればいい、という判断が企画側で合ったため
対処方法に関してはCFのCache-Controlを10分程度に設定するだけで済みました…
仕様の確認不足というのもありましたが、それにしてもInvalidation処理の価格面に対する危険性をよく確認しなかったと言うのはエンジニアとして非常によろしくなかったと思っています。
まわりのエンジニアへの相談も不足していました

この機能のみならずですが、よくわからない機能を使用する前は自分での調査ももちろんですが慎重に検討・相談してから使用するよう心がけようと思います…

皆様は私のようなミスをしないよう気をつけてください
ではでは