本当にあったIT怖い話　AWSの設定ミスで300万円のコスト超過、1日1回だったはずの処理が1分で160万回に　当事者に聞く反省点（1/3 ページ）

　バックアップデータがあると思って安心していたのに、いざ障害時に取得できていなかったことが発覚したり、ネットワークアクセスの制限を強化しようと設定をいじったら、自分すらアクセスできない状態にして手詰まりになったり……もっとヒヤッとする事態も含め、IT業界には「本当にあった怖い話」がいろいろある。

　クラウドサービスの利用料金がいつの間にかに膨大になる「クラウド破産」もその一つだ。検索してみると、便利だからとあれもこれもとクラウドサービスを利用していたら料金が想像以上に大きく膨らんでしまい、課金額を見て目を回した経験談がいくつかのブログにつづられている。

　システムインテグレーションやセキュリティサービスを提供するラックも、そんな経験をしてしまった企業の一つだ。同社のエンジニアである阿久津悠人さん（セキュリティソリューション統括部 ソリューション推進第二部 クラウドソリューションサービスグループ）は、AWSで構築した検証環境である設定ミスをしてしまった。

　その結果、1日1回行うはずだった処理が1分間に160万回発生してしまい、約300万円のコスト超過につながったという。事故はどんな原因で起こってしまったのか。当事者である阿久津さんや、対処に当たった土井秀記さん（同）、片桐貴之さん（同）、田端俊さん（セキュリティソリューション統括部 プラットフォーム・サービス第三部 エンタープライズITサービス第二グループ）に、インシデントの詳細と得られた教訓を聞いた。

事件はエンジニアが自由に試せる「検証環境」で起こった

　まず、トラブルの背景を整理する。ラックによれば、昨今のクラウド化の流れを反映してか、クラウドサービスを活用したシステムインテグレーションの案件が増えているという。変化するニーズに応えるには、エンジニアも普段からクラウドサービスに触れ、最新の機能を自らの手で試して知見をためることが重要になる。

　そこで同社では、エンジニア向けにクラウド、例えばAWSの検証環境を用意し、自由に利用できるようにしてきた。「何かシステムを完成させる手前の検証環境というよりは、エンジニア自身が学習し、スキルを向上させたり、資格取得を支援したりするための環境として用意してきた」と土井さん。しかし今回のクラウド破産は、この検証環境で起こってしまった。

1日1回の処理が1分で160万回超に　不幸が重なり起きた想定外の課金

　課金につながった処理を書いた阿久津さんによると、原因になった仕組みは、クラウドベースの認証サービスである「Okta」のログを、長期にわたって保管できないかというアイデアを形にしたものだった。サーバレス実行環境「AWS Lambda」で記述した処理は以下のような仕組みだ。

1. OktaからJSON形式のログを取得し、Amazon S3上に配置する
2. ファイルが配置されたことをログ取得サービス「AWS CloudTrail」で検知したら、それをフラグとしてアプリケーション間のデータを接続する「Amazon EventBridge」が起動し、Amazon S3に配置されたJSONファイルをCSVに変換する

　しかし、Amazon EventBridgeのルール設定に考慮漏れがあった。本来ならば除外すべきだった変換後のCSVファイルに対してもAWS CloudTrail側でファイル配置を検知し、フラグを立てるという動作を行ってしまった。

　「これが、無限ループの橋渡しの役割になってしまった」と阿久津さん。これにより、本来は1日1回行うはずだった処理が1分に160万回以上発生していたという。環境設定というよりは、オペレーション上の問題だったといえるだろう。

　状況をさらに悪くさせたのは、このロジックを試したのがゴールデンウイーク直前の4月28日だったことだ。「谷間の平日も含めて、休んでいるメンバーが大多数という状況だった」（土井さん）

　クラウド破産のリスクはたびたび指摘されており、ある程度経験のあるエンジニアなら当然考慮している。クラウド事業者側もそうしたニーズを踏まえ、課金に関するアラートを出す仕組みを用意している。

　ラックも1日1回、毎朝午前9時半に課金額を関係者に通知する他、想定外の費用が発生した場合にはアラートを出す仕組みを構築していた。平日ならば、PCや手元のiPhoneでそのアラートをチェックできたはずだった。しかし長期休暇に入ってしまったため、アラートに気付き、対処するまでに時間がかかってしまった。

　「4月29日からこのロジックが動き始めたが、ゴールデンウイークに入ってしまったため、課金情報をチェックする人がいなかった。結果として、5月4日の朝に届いた費用を見て初めて事態を把握した」（土井さん）

　5月2日時点では0円だった課金が、3日にはいきなり146万円に。この通知を受けて担当者が対応を開始した5月4日夕方の時点では約300万円の課金が確定した状況となっていた。「普段から金額をウォッチしていたが、大幅に金額が跳ね上がっている状況を見て、まずは対応を進めなければと考えた」（田端さん）

この記事の著者

関連記事

• 

  背筋も凍るITホラー　気付いたら“野良SaaS”のコストが4倍に　「SaaSのお片付け」真っ最中のマネフォに現状を聞く

• 

  円安でも安くAWSを使う方法　SaaSスタートアップが弾き出した意外な試算

• 

  「クラウドの費用がいつの間にか膨大に」の防ぎ方　3大クラウドのコスト管理サービスを比較

• 

  10倍に膨れたAWS運用費をどう減らす？　ユーザー急増のnoteが挑む「コスト削減作戦」の裏側

• 

  「パブリッククラウドのアカウント数多すぎ」で起こる混乱をどう防ぐ？　DeNAがフルクラウド化で直面した悩みと対策