最初の製品を発売する前に、破産の危機に瀕していたこと、どうやって生き残ったか、そしてどのような教訓を学んだかについての物語。



COVIDが世界を襲った2020年3月、私たちのスタートアップであるミルキーウェイも大きな打撃を受け、ほぼ閉鎖されました。Cloud Run with Firebaseの調査と内部テストを数時間行ったときに、72,000ドルを消費しました。



2019年11月にアナウンス サービスの開発を開始しました。主な目標は、製品の最小限の機能の最初のバージョンをリリースすることでした。そのため、コードは単純なスタックで機能しました。 JS、Pythonを使用し、Google AppEngineに製品をデプロイしました。



非常に小さなチームで、コーディング、UI開発、および製品の準備に重点を置きました。クラウドの管理にほとんど時間を費やしませんでした。システムを稼働させ、基本的な開発プロセス（CI / CD）を提供するのに十分な時間を費やしました。





デスクトップアナウンス



最初のバージョンはあまり便利ではありませんでしたが、実験用のバージョンをリリースしてから、通常のバージョンで作業したかっただけです。COVIDのおかげで、世界中の政府機関がアナウンスを使用してアラートを公開できるため、今が立ち上げの良い時期だと考えました。



ユーザーがまだコンテンツをアップロードしていないときに、プラットフォーム上でデータを生成するのは素晴らしいことではありませんか？この考えは、コンテンツ生成のための別のプロジェクト、Announce-AIにつながりました。データが豊富なのは、地震警報や関連する地域のニュースなど、さまざまなイベントです。

いくつかの技術的な詳細

Cloud Functionsを使用して、Announce-AIの開発を開始しました。スクレーピングボットはまだ初期段階だったため、これらの軽量機能を採用することにしました。しかし、クラウド機能のタイムアウトは約9分であるため、スケーリングに問題がありました。



そして突然、Cloud Runシステムについて知りました。CloudRunシステムには、大きな無料使用制限がありました。それを完全に理解することなく、私はチームに「テスト」機能のAnnounce-AIをCloud Runにデプロイし、そのパフォーマンスを評価するように依頼しました。目標は、CloudRunをいじって経験を積むことでした。





Google Cloud Run



サイトが非常に小さいため、簡単にするためにFirebaseデータベースを使用しました。これは、Cloud Runにはストレージがなく、SQLServerまたは別のデータベースの展開がテストには多すぎるためです。



新しいGCPANC-AI Devプロジェクトを作成し、クラウドの請求予算を7ドルに設定して、Firebaseプロジェクトを無料プラン（Spark）で保存しました。私たちが想像した最悪のオプションは、1日のFirebase制限を超えることです。



いくつかの変更を加えた後、コードを準備し、いくつかの手動リクエストを行ってから、実行したままにしました。

悪夢が始まる

テスト当日は順調に進み、アナウンスの開発に戻りました。仕事の翌日、午後遅くに昼寝をしに行きました。目を覚ますと、GoogleCloudからのメールが数分間隔でいくつか見られました。



最初のメール：Firebaseプロジェクトの自動アップグレード





2番目のメール：予算を超えました





幸い、私のカードには100ドルの制限があります。このため、支払いは行われず、Googleはアカウントのサービスを停止しました。



3番目の文字：カードが拒否されました。





ベッドから飛び降りてGoogle Cloudの請求を入力すると、約5000ドルの請求書が表示されました。パニックに陥った彼は、何が起こっているのか理解できずに、キーをクリックし始めました。バックグラウンドで、私はこれがどのように起こり得るか、そしてその場合、5,000ドルの請求書をどのように支払うかについて考え始めました。



問題は、スコアが毎分増加し続けることでした。



5分で15,000ドル、20分で25,000ドルを示しました。数字がいつ増加しなくなるのかわかりませんでした。多分彼らは無期限に成長しますか？



2時間後、数字は72,000ドル弱で止まりました。



この時までに、チームと私は電話会議に参加していました。私は完全にショックを受け、次に何をすべきかまったくわかりませんでした。請求をオフにし、すべてのサービスを終了しました。



すべてのGCPプロジェクトで1枚のカードで決済したため、すべてのアカウントとプロジェクトが停止されました。

悪夢は続く

これは、最初のバージョンのリリースを計画する3日前の3月27日金曜日の夜に発生しました。 Googleが1つのマップにリンクされているすべてのプロジェクトを一時停止したため、開発は停止しました。私のモラルはベースボードを下回り、会社の将来は不透明に見えました。





私たちのクラウドプロジェクトはすべて保留になり、開発は中止されました。



私の心が新しい現実に身を任せた途端、真夜中に私は通常何が起こったのかを理解することにしました。私は事件の詳細な調査を含む文書を書き始めました...そしてそれを「第11章」と呼びました[これは破産法の章です-およそ。あたり。]。



実験に参加した2人の同僚も一晩中起きていて、何が起こったのかを調べて理解しようとしました。



翌朝、3月28日土曜日、私は12の法律事務所に電話して手紙を書き、約束をしたり、弁護士に話しかけたりしました。全員が不在でしたが、そのうちの1人からメールで返信をもらうことができました。事件の詳細はエンジニアにとっても非常に複雑であるため、弁護士に平易な英語で説明すること自体は容易ではありませんでした。



私たちにとって、スタートアップのスタートアップとして、72,000ドルを回収する方法はありませんでした。



この時点で、私はすでに破産法の第7章と第11章を徹底的に研究し、次に起こるかもしれないことに精神的に備えていました。

少し休憩：GCPの抜け穴

土曜日に、弁護士にメールを送信した後、私はGCPドキュメントのすべてのページを読み、読み始めました。私たちは間違いを犯しましたが、以前に支払いをしていなかった場合、Googleに72,000ドルを劇的に費やさせる意味はありませんでした！





GCPとFirebase

1.Firebaseアカウントの有料アカウントへの自動アップグレード

私たちはこれを予期していませんでしたし、Firebaseに登録するときにどこでも警告されませんでした。GCPの請求はCloudRunの実行に組み込まれていましたが、Firebaseは無料プラン（Spark）の下にありました。明らかな理由もなく、GCPは有料プランにアップグレードし、必要な金額を請求しました。



彼らはこのプロセスを「FirebaseとGCPの緊密な統合」と呼んでいることがわかりました。

2.請求の「制限」はありません。予算は少なくとも1日遅れています

GCPの請求は、実質的に少なくとも24時間遅れます。ほとんどのドキュメントで、Googleは予算とクラウド自動オフ機能の使用を提案しています。ただし、シャットダウン機能がトリガーされるか、ユーザーに通知が送信されるまでに、損傷はすでに発生しています。



請求の同期には約1日かかります。そのため、翌日に請求に気づきました。

3. Googleは、72,000ドルではなく、100ドルを取るべきでした。

これまでのところアカウントからの支払いがないため、GCPは支払い情報に応じて最初に100ドルの料金を支払う必要があり、支払いがない場合はサービスを停止します。しかし、それは起こりませんでした。後で理由がわかりましたが、これもユーザーのせいではありません！



私たちの最初の請求額は約5000ドルでした。次は$ 72Kです。





私たちのアカウントの請求しきい値は$ 100です。

4.Firebaseダッシュボードに依存しないでください。

請求だけでなく、Firebaseダッシュボードの更新にも24時間以上かかりました。



Firebase Consoleのドキュメントによると、ダッシュボードの数値は請求レポートと「わずかに」異なる場合があります。



私たちの場合、それらは86,585,365.85％、つまり8600万パーセントポイント異なっていました。請求書が届いたときでも、Firebase Consoleは月に42,000回の読み取りと書き込みを表示していました（1日の制限を下回っています）。

新しい日、新しい挑戦

Googleで6年半勤務し、数十のプロジェクトドキュメント、調査レポートなどを作成した後、私はGoogle向けのドキュメントを作成し始め、インシデントについて説明し、レポートにGoogleの抜け穴を追加しました。 Googleチームは2日後に仕事に戻ります。



訂正：一部の読者は、私が社内のGoogle連絡先を使用していると示唆しています。実際、私は誰ともコミュニケーションをとらず、通常の開発者や会社がたどる道を選びました。他の小さな開発者と同じように、私はチャット、コンサルティング、長いメールの下書き、バグの報告に数え切れないほどの時間を費やしました。インシデントレポートに関する次の記事の1つで、Googleに提出したドキュメントを紹介します。





Googleの最終日



また、私たちの過ちを理解し、製品開発戦略を立てる必要がありました。チームの全員がこの事件について知っているわけではありませんが、私たちが大きな問題を抱えていることは明らかでした。



Googleで、私は数百万ドルの人為的ミスに直面しましたが、Googleの文化は従業員を救います（エンジニアが後で長いレポートを書かなければならないことを除いて）。今回はグーグルはありませんでした。私たち自身の小さな資本と私たちの努力が危機に瀕しています。

不動のヒマラヤは私たちに教えてくれます...

私は初めてそのような打撃を受けました。これは私たちの会社の未来と私の人生を変えるかもしれません。この事件は、最も重要なものを含むいくつかのビジネスの教訓を私に教えてくれました-ヒットしました。



当時、私には7人のエンジニアとインターンのチームがあり、この事件についてGoogleが対応するのに約10日かかりました。その間、開発を再開し、アカウントの停止を回避する方法を見つける必要がありました。すべてにもかかわらず、私たちは機能と製品に集中する必要がありました。





詩「スタルワート・ヒマラヤが教えてくれます」



どういうわけか、子供の頃の詩が頭の中で絶えず回転していました。それは私のお気に入りの本で、15年以上前に最後に読んだのですが、一言一句覚えていました。

私たちは実際に何をしましたか？

非常に小さなチームとして、ハードウェアへの支出をできるだけ長く避けたかったのです。 CloudFunctionsとCloudRunの問題はタイムアウトでした。



1つのインスタンスは、ページからURLを継続的に取得します。ただし、9分後、タイムアウトが発生します。



それから、何気なく問題について話し合った後、私は数分で黒板に生のコードを書き留めました。そのコードにはアーキテクチャ上の欠陥がたくさんあることに気づきましたが、新しいことをすばやく学び、試すための迅速なバグ修正サイクルを目指していました。





発表-CloudRunでのAIコンセプト



タイムアウトの制限を克服するために、POSTリクエスト（データとしてURLを使用）を使用してジョブをインスタンスに送信し、1つをキューに入れるのではなく、複数のインスタンスを並行して起動することを提案しました。Cloud Runの各インスタンスは1ページしか廃棄しないため、タイムアウトが発生することはなく、すべてのページが並行して処理され（適切にスケーリング）、Cloud Runはミリ秒の精度で消費されるため、プロセスは高度に最適化されます。





Cloud Run Scraper



よく見ると、プロセスにはいくつかの重要な詳細が欠けています。

1. 継続的な指数再帰が発生します。breakステートメントがないため、インスタンスはいつ停止するかわかりません。
   
   
2. POSTリクエストは同じURLを持つことができます。前のページに戻るリンクがある場合、Cloud Runサービスは無限の再帰でスタックしますが、最悪の場合、この再帰は指数関数的に乗算されます（インスタンスの最大数は1000に設定されています！）

ご想像のとおり、これにより、1000個のインスタンスが数ミリ秒ごとにFirebaseDBに要求と書き込みを行うという状況が発生しました。ある時点でFirebaseの読み取りを通過する1分あたり約10億のリクエストがあったことがわかりました。





GCP月末取引概要

1,160億回の読み取りと3,300万回の書き込み

Cloud Runのアプリの実験バージョンは、Firestoreに対して1,160億回の読み取りと3,300万回の書き込みを行いました。ああ！



Firebaseの読み取りコスト：

$（0.06 / 100,000）* 116,000,000,000 = $ 69,600

16,000クラウド実行時間

テスト後、ログを停止した結果、リクエストは終了したと結論付けましたが、実際にはバックグラウンドプロセスに入りました。サービスをアンインストールしなかったため（Cloud Runを初めて使用し、それを実際に理解していなかったため）、いくつかのサービスの実行が遅くなりました。



24時間で、1,000インスタンスのこれらすべてのサービスは合計16,022時間実行されました。

私たちのすべての間違い

誤ったアルゴリズムをクラウドにデプロイする

すでに上で議論されています。インターネット上の他の場所では見つけられなかったサーバーレスPOSTリクエストを使用する新しい方法を見つけましたが、アルゴリズムを指定せずにデプロイしました。

デフォルトのパラメータでCloudRunをデプロイする

Cloud Runサービスを作成したときに、デフォルト値を選択しました。インスタンスの最大数は1000で、同時実行は80リクエストです。これらの値が実際にテストプログラムの最悪のシナリオであることを私たちは知りませんでした。



max-instances = 2を選択した場合、コストは500分の1になります。



並行性を1に設定すると、スコアに気付くことさえありません。

完全に理解せずにFirebaseを使用する

あなたは経験から何かを理解するだけです。Firebaseは学習する言語ではなく、コンテナプラットフォームです。そのルールは特定のGoogle会社によって決定されます。







また、Node.jsでコードを作成するときは、バックグラウンドプロセスについて考える必要があります。コードがバックグラウンドプロセスに入る場合、開発者がサービスが実行されていることを知るのは簡単ではありません。後で学習したように、これによりCloudFunctionsのタイムアウトのほとんどが発生しました。

クイックバグとクイックフィックスはクラウドでは悪い考えです

全体としての雲は両刃の剣のようなものです。正しく使用すれば非常に便利ですが、正しく使用しない場合は自分のせいにしてください。



GCPドキュメントのページ数を数えると、いくつかの厚いボリュームを公開できます。請求や機能の使用など、すべてを理解するには、クラウドサービスがどのように機能するかについて多くの時間と深い理解が必要です。当然のことながら、それはこれのために個々のフルタイムの従業員を雇います！

FirebaseとCloudRunは本当に強力です

ピーク時には、Firebaseは1分あたり約10億回の読み取りを処理します。これは非常に強力なツールです。私たちはFirebaseで2、3か月遊んでいますが、まだ新しい側面を発見していますが、それまで、このシステムがどれほど強力であるかはわかりませんでした。



Cloud Runについても同じことが言えます！並列プロセスの数を60、max_containers == 1000に設定すると、400ミリ秒のリクエストで、CloudRunは1分あたり900万のリクエストを処理できます。

60 * 1000 * 2.5 * 60 = 1分あたり9,000,000リクエスト

比較すると、Google検索は1分あたり380万のクエリを処理します。

モニタリングを使用する

が監視Googleクラウドは、課金を停止することはありません、それは（3-4分遅延）タイムリーなアラートを送信ありません。最初はGoogleCloudの用語を習得するのは簡単ではありませんが、時間をかけると、ダッシュボード、アラート、指標によって生活が少し楽になります。



これらの指標は90日間のみ利用可能であり、保存されていません。

私たちは生き残った

ふぅ、夢中になった



私たちの側から状況を説明する長い事件報告を調べた後、さまざまな協議、会話、内部の議論の後、Googleは私たちに費用を許しました！

グーグルありがとう！

私たちは救命浮輪を手に取り、この機会を利用して製品開発を完了しました。今回は、はるかに優れた計画、アーキテクチャ、およびはるかに安全な実装を備えています。

私のお気に入りのテクノロジー企業であるG​​oogleは、一緒に仕事をするのに最適な企業ではありません。また、一緒に仕事をするのに最適な会社です。Google Toolsは非常に開発者に優しいものであり、（ほとんどの場合）優れたドキュメントがあり、常に進化しています。

（注：これは個人開発者としての私の個人的な意見です。当社はGoogleのスポンサーや提携は一切ありません）。

次は何ですか？

この事件の後、私たちはクラウドとアーキテクチャの研究に数か月を費やしました。数週間の間に、私の理解は非常に向上したので、改善されたアルゴリズムを使用してCloudRunで「インターネット全体」をスクレイピングするコストを見積もることができました。



この事件により、私は製品のアーキテクチャを深く分析する必要があり、スケーラブルなインフラストラクチャを構築するために最初のバージョンのアーキテクチャを放棄しました。



Announceの2番目のバージョンでは、MVPを作成しただけでなく、新しい製品を迅速に繰り返し開発し、安全な環境で徹底的にテストできるプラットフォームを作成しました。



この旅には長い時間がかかりました...発表最初のバージョンから約7か月後の11月末にリリースされましたが、拡張性が高く、クラウドを最大限に活用し、高度に最適化されています。



また、インターネットだけでなく、すべてのプラットフォームでリリースしました。



さらに、プラットフォームを再利用して、2番目の製品であるPointAddressを作成しました。また、スケーラビリティと優れたアーキテクチャを備えています。