8,000ドルを無駄にしてしまった1行のコード

• macOS向け画面録画アプリ Screen Studioの自動アップデートのバグ により、250MBのファイルが5分ごとに繰り返しダウンロードされる問題が発生
• その結果、1か月で 2PB（2,000,000GB）のトラフィック がGoogle Cloudで発生し、約8,000ドルの高額請求 につながった
• 原因は単純なコード漏れで、アップデートのダウンロード後に繰り返しリクエストを止めるロジックを入れ忘れたこと
• 一部のユーザーには インターネットサービスの契約解除など実害 まで発生し、開発チームは責任を痛感
• クラウドコストのアラート設定、コストを生むコードのレビュー、アップデートサーバーの制御装置の用意 といった教訓を強調

---

事故の概要

• Screen StudioはmacOS向けの デスクトップ画面録画アプリ で、自動アップデート機能 がある
• アップデートファイルの容量は 約250MB で、アプリは 5分ごとにサーバーを確認 する
• バグにより、アップデートが検出された後も 5分間隔のリクエストが止まらず、ダウンロードを続けてしまった

悲劇的なリファクタの始まり

• 以前はアップデートのポップアップが録画中の邪魔になり、UX上の問題があった
• これを改善するためのリファクタの途中で、アップデート後にタイマーを停止するロジックを削除してしまった
• その結果、アップデートファイルを 繰り返しダウンロードするロジックがアプリ内に組み込まれた状態 になった

恐ろしい前提条件: バックグラウンド実行状態

• ユーザーのかなりの割合が、アプリを 数週間にわたってバックグラウンドで起動したまま 使用していた
• この状態で数千のインスタンスが 5分ごとに250MBを自動ダウンロード していた

数字で見る惨事

• 5分ごとのダウンロード = 1日288回
• ユーザー1人あたりの1日のダウンロードトラフィック = 72GB
• 約30日間継続、ユーザー1,000人と仮定すると:
  • 250MB × 288 × 30 × 1,000 = 約2PBのトラフィック
• Google Cloudで発生した想定料金: 約8,000ドル

連鎖したミス

• Google Cloudのコストアラートが設定されていなかった
• 既存の月額料金が300ドル程度だったため、油断していた
• 最終的には クレジットカードの利用限度額超過で決済が止まり、そこで問題を認識 した

ユーザーへの被害

• あるユーザーはこのトラフィックが原因で、ISP（インターネットプロバイダ）からサービス契約解除 を通知された
• その地域には代替の提供事業者がなく、深刻な生活上の不便が生じた
• チームは 責任を認めて費用補償を提案 し、幸い状況は円満に解決した
• しかし、ユーザーに害を与えてしまった経験 は開発者に深い反省を残した

教訓の要約

• クラウドコストのアラートは必須
• 自動アップデートのロジックは極めて慎重に書く こと
• コストを発生させる可能性のあるコードはすべて特別にレビュー すること
• サーバー制御用のシグナル（例: 強制アップデートフラグ） を設計に含めること
• クラウド利用状況を定期的に点検 すること

[GN⁺]

Hacker Newsの意見

• 将来Web検索でこのスレッドを見つける人のために: screen.studioはmacOSの画面録画ソフトで、5分ごとにアップデートを確認する。だがこの投稿で説明されているバグは、5分ごとに250MBのアップデートファイルをダウンロードしてしまうというもの

  • 開発者たちはこれをすべて正常だと見なしているが、実際のダウンロードによって8,000ドルの帯域料金が発生した
  • 要約: 画面録画ソフトが5分ごとにアップデートを確認する。つまり1時間に12回
  • 私は開発者の判断をどの程度信頼できるかでソフトウェアを選ぶ。この判断が合理的か考えてみてほしい

• Screen StudioはmacOS向けの画面レコーダー。デスクトップアプリだ。最新版を簡単にインストールできるよう自動アップデートが必要だと主張している

  • しかし自動アップデートはいくつもの悪い結果を招いている
  • ユーザーの同意なしにアップデートをダウンロードし、クライアント側のトラフィックを発生させる
  • 5分ごとに繰り返しダウンロードが続く。ユーザーが従量課金接続かどうかを検知していたのか疑問
  • アップデートのポップアップが作業の流れを妨げるバグがある
  • ポップアップ自体がユーザーにとって悪い体験だ。アプリを閉じるときに許可を求め、それ以外はバックグラウンドで処理するのがよい
  • 一部のユーザーはアプリの外向き接続を注意深く監視しており、5分ごとのアップデート確認は過剰だ。アプリ実行中にやる必要はない。起動時に確認し、終了時に尋ねるのがよい
  • 上記のすべての問題を引き起こしたアプリ側の追加の複雑さ。開発者にもコストが発生する
  • このケースでは、App Storeがアップデートを処理する完璧な方法になり得る

• 画面録画アプリのような重要ではないアプリの開発者が、5分ごとにアップデートを確認すべきだと考えるのはばかげている

  • 1日1回で十分なはず

• 本当に5分ごとにアップデートを確認する必要があるのか疑問。起動時に1回で十分で、ユーザーが数日間つけっぱなしにする場合でも、1日1回かそれ以下でよい

• 私はコードレビューについて常に厳格だ。以前、マネージャーにもっとQAに任せろと言われたとき、「私たちは皆、職を失う可能性がある。たった1行の悪いコードで職を失うことだってある」と答えた

  • ジュニアでも経験豊富な開発者でも、潜在的なPII漏えいを書いてしまうことは多い。ほとんどのシステムでは法的問題を引き起こす可能性が非常に高い

• 数千人のユーザーがデータプラン上で不要に消費した帯域幅の問題

  • このような不注意なミスは、インターネット利用者全体に輻輳をもたらし得る
  • もしこのミスが8,000ドルのコストではなく、Google Cloudの無料枠や別のプランで吸収されていたなら、それでも深刻なバグと見なして迅速に修正しただろうかと疑問に思う
  • どれほど多くの誤った設計がトラフィックを生み、共通資源を消費しているのか

• 私がMacのデスクトップアプリケーションを配布していたとき:

  • 私たちはSparkleを使ってアップデートを処理していた。独自アップデータを選んだのは間違った選択だった
  • 私たちのアプリケーションは非常に複雑で、Monoと一緒に配布していた。それでも10MBほどだった。Windows版は2MBで、32ビットおよび64ビットのバイナリを含んでいた。なぜ彼らが250MBの画面録画アプリを配布しているのか不思議だ
  • 彼らは教訓を得ていないように見える。記事全体が彼らを愚かに見せている

• 要約で「より良いテスト」に触れられていないのが驚き

  • 「コードを慎重に書け」という提案は初歩的なミスのように見える
  • 開発者がユーザーのデバイスをテストベッドとして使っているのは非常に腹立たしい

• 私はサードパーティライブラリの採用には保守的だ（各ライブラリが長期的に問題を引き起こす可能性があるため）が、アプリのアップデートは価値がある

  • これは基本的に大きなエッジケースの1つであり、アプリに深刻なバグがある場合の復旧計画の重要な一部だ
  • このバグは、彼らの独自アップデータにある唯一の問題ではない。5分ごとに確認するのは狂っている。彼らがこれについて深く考えていなかったことを示している

• 私はProxy Auto-Configuration (PAC) ファイルを使う検閲回避プロキシサービスを運営している

  • ファイルに壊れたJSが含まれていたり、ファイルサイズが1MBを超えたりすると、システム全体に設定されている場合、すべてのアプリがサーバーにリクエストを送り続ける問題が発生する
  • その結果、私のサーバーにDDoS攻撃が発生し、BGPレベルでIPがブロックされることになった
  • 50万人以上のユーザーが毎日使っている。私のWebサーバーは月20ドルのVPSで無制限トラフィックを提供している。そのおかげで、私はOPのような状況にはならなかった