1. /
  2. /
  3. クラウド破産の実例と対策

クラウド破産の実例と対策

  • このエントリーをはてなブックマークに追加

最終更新

「クラウド破産」とは、クラウドサービスの使用料金が意図せず高額になる (例えば数日で数十万円など)、という事象を指す俗語です。クラウド破産につながる危険な行為や、それを避けるための注意点を紹介します。

目次



クラウド破産とは

「クラウド破産」とは、クラウドサービスの使用料金が意図せず高額になる (例えば数日で数十万円など)、 という事象を指す俗語です。

レアケースではありますが、リスクとしては確実に存在するもので、 請求ルールのわかりにくさ、開発者の理解不足、I/O リクエスト数など見積もりが困難、 インターネットからのアクセス数などコントロールできない領域に起因するもの、 などが原因として挙げられます。

クラウド破産ポイント

クラウド破産が起こりがちなポイントを下記にあげておきます。

危険度高

  • AWS・Azure・GCP 共通: アクセスキーやシークレットキーなどをソースにべた書きした上に GitHub などの公開リポジトリに上げてしまい、外部の第三者に不正利用されてしまう。
  • AWS の Amazon EBS プロビジョンド IOPS SSD (io1) ボリュームにて、過大な IOPS を長期間指定し続ける … io1 ストレージについて、よく理解せずに IOPS に上限値 32,000 を指定してしまうと 26万円/月の請求 (1 IOPS あたり、$0.074 なので、32,000×$0.074＝$2,368≒26万円くらい)。IOPS とは秒間の I/O 回数ののことで、32,000 とすると秒間 32,000 回の EBS 操作を AWS が保証する、ということになる。容量は関係なく、プロビジョンド IOPS に関する料金なので、4GB 確保しただけでも 26万円。1TB 確保しても 26万円。

危険度中

  • AWS・Azure・GCP 共通: ネットワーク転送量がかさんでしまう (Web に大量のアクセスが来た、DoS アタックを受けた、意図せずリージョンをまたいでしまった、など) … たかだか $0.140/GB と安心していたら、転送量が 10TB になり、16万円/月の請求。
  • AWS・Azure・GCP 共通: S3 などのストレージの料金がかさんでしまう (Web 公開のコンテンツに大量のアクセスが来た) … S3 は「リクエスト 1,000 件あたり 0.00037USD」であるが、例えば画像100ファイルがあり、Web サイトアクセス時にこの画像をリクエストするとして、それが何万 UU にもなると、結構な金額となってくる。
  • AWS EBS Magnetic volumes (磁気ディスク) で、膨大な I/O リクエストを行う … 100 万 I/O リクエストあたり $0.08 だが、ベンチマーク実行や swap ファイル配置などを行うと想定外に膨らむことがある。なお、Magnetic は旧世代であり、SSD の場合は I/O 課金がないので、素直に SSD を使うことをおすすめします。
  • Azure の Standard Managed Disks やページ BLOB にて、膨大な I/O リクエストを行う (ベンチマーク実行や swap ファイル配置など)。
  • AWS・Azure・GCP 共通: AWS Lambda・Azure Functions・Cloud Functions などのサーバレスアーキテクチャを、誤って大量に実行してしまう。 オンプレミスや IaaS などであれば CPU・メモリやインスタンスサイズによる事実上の制限があるが、 サーバレスだとバグや設定ミスにより何万回・何十万回でも実行できてしまい、サーバが重くなったりもしないため、気づきづらい。 (2018/05/17 追加)

危険度低

  • Amazon Glacier で、短時間に大量データを取り出す (料金計算ルールの変更により、2016/12 以降は発生しません)。
  • Google BigQuery で、LegacySQL で下記のようにテーブル ワイルドカード関数を使う際、クエリ全体で最低 10MB の処理量ではなく、テーブル単位 (test20170101・test20170102 など) ごとに最低 10MB と計算されるため、各テーブルサイズが数十バイトであったとしても、下記例だと10MB × 365 日＝3.6GB 程度の処理量になってしまう。
#LegacySQL
SELECT *
FROM TABLE_DATE_RANGE(
  mydataset.test,
  TIMESTAMP('2017-01-01'),
  TIMESTAMP('2017-12-31'))
  • ただし現時点で主に使われている StandardSQL では test テーブル全体で最低 10MB と計算されること、LegacySQL では 1クエリあたりのテーブル最大数が 1,000 であること、そもそも BigQuery で 1テーブルあたり 10MB 以下というケースはあまり考えづらいこと、3.6GB であっても $0.0000013 であることから、危険度低とした。参考: BigQueryのクエリー料金の些細な話(2018/05/23 追加)

対策

  • 毎日課金額を確認する。地味ですが、1日で数十万円に達することはほとんどありませんので、これが確実です。管理画面からログインしてもいいですが、AWS・GCP いずれも管理用スマホアプリで課金額が確認できます (Azure もアプリはありますが、課金額確認機能はない模様)。 ただ、毎日毎日チェックするかというと…めんどくさくなってしないんですよね。
  • 課金額通知を設定する。一定金額を超過するとアラートが届く仕組みがあります。AWS であれば CloudWatch か、AWS Budget。Azure は「課金アラート サービス」。GCP は「お支払い」の「予算とアラート」から。例えば 1000円などと設定してアラートが来たとしても、そのうち見ようと思って忘れてしまうことを防ぐため、1000円・2000円・5000円などと段階的に設定をしましょう。
  • 課金額を毎日 Slack 等に通知させるのもよい手です。参考資料はたくさんあります。
  • GitHub へのキーをあげてしまう件について
    • AWS が git-secrets という git プラグインを公開しています。キーらしきものが含まれている場合、コミットを失敗させるという方法です。AWS に限定した話ではないので、Azure・GCP でも使えます。Microsoft は Continuous Delivery Tools for Visual Studio という Visual Studio の拡張にて、チェック機能を実装しています。また、キーらしきものがコミットされると GitHub から「大丈夫か?」というメールが即座に届くそうです。
    • 仕事であれば、お金をケチらずにプライベートリポジトリでというのもよいかもしれません。
    • そもそもソースにキーを書かない。AWS ならば ~/.aws/credentials などのファイルや、環境変数など。Azure の WebApps ならアプリケーション設定などにキーを記載する。Kubernetes なら Secrets で管理するなど、いろいろある。
    • なお、GitHub などの公開リポジトリにキーが公開されないか監視している BOT がたくさんいます。 GitHub に AWS キーペアを上げると抜かれるってほんと？？？ – Qiita によると、GitHub にパブリックリポジトリを作成し、権限が何もない AWS アクセスキー・シークレットアクセスキーを公開すると、なんと13分で不正アクセスがあったとのこと。
  • 設計時に、アクセス数や I/O に比例して費用が発生する箇所がないか確認し、できればそのサービスの利用を避ける。利用せざるをえない場合、関係者にリスク周知した上で高額になった場合の対応方法を合意し、検知方法も確立しておく (そして日々の金額確認などめんどくさい作業は誰かに押し付ける)

クラウド破産の実例

下記、ブログ等で報告された事例を紹介します。よく読んで、これが自分の身に起こったらと考えて寒気を感じておきましょう。 そして今すぐ課金アラート設定を行うべきです！

事例を公開いただいた皆様に深く感謝します。

S3のコストを大幅に削減した話 (2022/04/13 追加)

Gunosy にて、ログを Glacier に保存するようにして S3 コストを削減しようとしたが、小さなファイルを大量に Glacier に保存した結果、PUT 料金がかさんで数万ドルの請求が発生した。結局複数ファイルを gzip で固めた上でアップロードすることでコスト削減に成功。

X.org の件

https://twitter.com/jingbay/status/1377640611063296005

ベンチャーがうっかり従量課金の翻訳サービスでクラウド破産しかかった話 (2020/09/02 追加)

具体的なサービス名は明記されていないが、おそらく Azure Cognitive Service の Translator (翻訳 API) を利用していたところ、開発していたアプリの不具合により同じ文章を何度も翻訳APIに渡してしまい、144万円の請求。営業経由で泣き落としたところ、マイクロソフト本社での判断となり、結果として請求免除。

やはり担当営業がついているのは心強いと感じた事例。

Google Maps API で50万以上使っていた話 (2019/12/16 追加)

GCP ではないが、Google Cloud な例として。Google Maps API で Geocoding API (住所から緯度経度を求めるなど) の API を月間 123万回叩きまくった。1回あたり $0.004 程度だが、123万回叩くと 54万円ほど。住所が変わったときだけ API を叩くべきところを、設計ミス/実装ミスで 15分起きに全住所の Geocoding を取得していた。Google に経緯を説明し、全額返金。

AutoMLで破産しないように気をつけたいポイント(2019/06/11 追加)

GCP の機械学習サービス AutoML で、物体検出のために 27,000枚の画像を使ってモデル構築を行った結果、26万円の請求。バジェット (時間上限) を設定していなかった?

AWSから120万円の高額請求が来た話(2018/10/15 追加)

開発合宿にて GitHub の公開レポジトリに AWS のキーを公開してしまったため、不正利用され、 請求額が 約 $11,000 (123万円) になっていた。 AWS に相談し、支払い免除。

はじめてのクラウド破産体験★LambdaのトリガーにS3を設定するときに気を付けること！！

オブジェクトストレージ S3 にファイルを PUT すると Lambda が実行されるようトリガーを設定していたが、 Lambda にて処理結果を S3 に PUT していたため、無限ループ状態となり、 1分間に数千回の Lambda が実行される。気づいたときには数万円の課金発生。

クラウド破産 – Togetter

EC2 + Magnetic な EBS (30 テラバイトx3) 上で Apache Cassandra (分散データベースエンジン) を動かして、 兆レベルのレコード数を突っ込むなどいろいろ試していたら、 EBS の I/O が莫大になり、数日で 25 万円の課金。

AWS の IOPS 課金でパケ死しかけた (Web Archive)

EC2 + EBS で、MongoDB のベンチマークを実行した際、プロビジョンド IOPS を多めに確保したため、 $150 程度の想定外課金が発生した。

初心者がAWSでミスって不正利用されて$6,000請求、泣きそうになったお話。

30時間耐久 Rails ハッカソンにて、AWSのアクセスキーとシークレットキーをソースに記述し、GitHub に上げてしまう。 AWS 初心者であったため、その危険性を理解していなかった。不正利用され、50万円の請求。 AWS に相談し、支払い免除。

AWSが不正利用され300万円の請求が届いてから免除までの一部始終

GitHub でプライベートで運用していたリポジトリを、とある事情でパブリックに変更。 しかし GitHub 上のソースにアクセスキーとシークレットキーを記載していたことを失念していた。 その結果、c4.8xlarge インスタンス ($2.016/h) が大量に実行され、300万円の請求が届いた。 AWS に相談し、支払い免除。

AWSでmicroインスタンスを使っていたら想定以上に課金された話

Magnetic な EBS を swap 領域として使用し、さらにメモリ少なめな micro インスタンスを使っていたため、 数ドル請求のはずが 80ドルの請求に。

BigQueryで150万円溶かした人の顔

  • このエントリーをはてなブックマークに追加

SNSでもご購読できます。

Leave a Reply

*

CAPTCHA