スタートアップ企業 Milkie Way の創業者 Sudeep Chauhan 氏は、Google Cloud Platform (GCP) で 7 ドルの課金予算と無料データベース プランを使用したテストで、一夜にして 72,000 ドルの請求書が生成され、ひどい請求書ショックを受けました。
「ベッドから飛び起きてGoogle Cloud Billingにログインしたら、約5,000ドルの請求書が目に入った」とチャウハン氏は会社のブログに書いている。「ものすごくストレスを感じ、何が起こったのかわからなかったので、いろいろクリックして何が起こっているのか理解しようとしました。何が起こったのか、どうやって5,000ドルの請求書を支払えるのか考え始めました。問題は、請求額が毎分増え続けたことです。2時間後、請求額は7万2,000ドルを少し下回る額に落ち着きました。」
元Google社員で、決済技術プログラムマネージャーを2年間務めたチャウハン氏にこのようなことが起こったことは特に驚きでした。一体何が起こったのでしょうか？
ウェブページをスクレイピングし、その結果をデータベースに保存するシステムを構築するというアイデアでした。彼のチームは、コンテナを実行するGCPサービスであるGoogle Cloud Runを選択しました。しかし、各インスタンスのコードがページを次々にスクレイピングするたびにタイムアウトして停止してしまうことが分かりました。そこで、各ページを実行時間制限内に取得・保存できるよう、ページを並列処理するマルチインスタンスシステムを構築しました。
開発者は、git リポジトリに「Google Cloud で実行」ボタンを組み込むよう招待されています... もちろん、Google によるものです
続きを読む
Chauhan氏は次のように書いています。「タイムアウト制限を克服するために、インスタンスにジョブを送信する際にPOSTリクエスト（URLをデータとして含む）を使用し、1つのインスタンスを逐次使用するのではなく、複数のインスタンスを並列に使用することを提案しました。Cloud Runの各インスタンスは1ページのみをスクレイピングするため、タイムアウトすることはなく、すべてのページを並列処理（スケール）できます。また、Cloud Runの使用量はミリ秒単位の精度であるため、高度に最適化されています。」
元Google社員は、ページ同士がリンクバックして「無限再帰」を引き起こす可能性を見落としていたと振り返っています。しかし、これはそれほど大きな問題にはならなかったはずです。彼は請求予算を7ドルに設定し、Firebaseデータベースは無料プランで使用していたからです。「想定していた最悪のケースは、Firebaseの無料プランの1日あたりの利用限度額を超えることでした」と彼は言います。さらに、アカウントのクレジットカードの限度額は100ドルでした。
残念ながら、ドキュメントによると、請求予算は「Google Cloud または Google Maps Platform の使用量/支出を自動的に制限するものではありません」。
チャウハン氏が1日のテストを終えて眠っている間に、Google は自動メールを送信し、無料の Firebase プランが「Google Cloud でのアクティビティによりアップグレード」され、これによりプロジェクトの「課金が開始された」ことを通知した。
彼はGCPのコスト管理に複数の問題を発見した。「請求の同期には約1日かかるため、請求に気づいたのは翌日だった」とチャウハン氏は述べた。さらに、「Firebaseダッシュボードの更新に24時間以上かかった」と同氏は述べた。ダッシュボードには1日の使用量の上限内と表示されていたが、実際は「8,600万パーセントポイント」も多かったという。
請求が同期されるまでに約1日かかるため、翌日に請求に気付きました。
GCP Cloud Runのデフォルト設定も影響していた。「インスタンスの最大数は1,000に、同時実行数は80にプリセットされています」と彼は言う。もしこれを2や1といった小さな値に修正していれば、請求書の衝撃は起こらなかっただろう。
これらの設定のおかげで、「Cloud Run でこのバージョンの Hello World デプロイメントを実行すると、Firestore に対して 1,160 億回の読み取りと 3,300 万回の書き込みが行われました」と Chauhan 氏は述べています。
コストの大部分はFirebaseの読み取り操作によるもので、10万回あたりわずか0.06ドルでした。これを1160億回掛けると69,600ドルになります。また、Cloud Runのコンピューティング時間が16,000時間もかかったという小さな問題もありました。これは、アプリケーションがサービスを削除せず、「バックグラウンドプロセス」で残していたことが一因です。
バグのあるコードのパフォーマンスは、それなりに印象的だった。「ピーク時には、Firebaseは1分間に約10億回の読み取りを処理できました」と彼は述べたが、並行処理機能を備えたCloud Runは「1分間に900万件のリクエストを処理できます」。
「クラウドでは、早く失敗して早く学ぶという考えは良くありません」とチャウハン氏は結論づけた。「GCPのドキュメントのページ数を数えてみると、おそらく小説数冊分以上でしょう。料金や利用方法を理解するのは時間がかかるだけでなく、クラウドサービスの仕組みを深く理解する必要があります。」
ハッピーエンドだ。「この件に関する長文の文書を作成し、私たちの言い分を伝え、様々な相談や話し合い、社内での議論を重ねた結果、Googleは一時的な措置として私たちの請求を放棄してくれました」とチャウハン氏は述べた。
このような寛容さは当てにはなりません。オートスケーリングやオンデマンドコンピューティングには欠点があり、コストの算出は困難です。注意が必要です。®
