Kisah tentang bagaimana kami menemukan diri kami di ambang kebangkrutan, bahkan sebelum meluncurkan produk pertama, bagaimana kami berhasil bertahan dan pelajaran apa yang kami pelajari.
Pada bulan Maret 2020, saat COVID melanda dunia, perusahaan rintisan Milkie Way kami juga terpukul dan hampir tutup. Kami menghabiskan $ 72.000 saat meneliti dan menguji Cloud Run dengan Firebase secara internal selama beberapa jam.
Saya mulai mengembangkan layanan Umumkan pada November 2019. Tujuan utamanya adalah untuk merilis versi pertama fungsional minimum produk, sehingga kode tersebut bekerja pada tumpukan sederhana. Kami menggunakan JS, Python dan menerapkan produk kami di Google App Engine.
Dengan tim yang sangat kecil, kami fokus pada pengkodean, pengembangan UI, dan persiapan produk. Saya hampir tidak menghabiskan waktu untuk mengelola cloud - saya menghabiskan cukup waktu untuk mengaktifkan dan menjalankan sistem dan menyediakan proses pengembangan dasar (CI / CD).
Pengumuman Desktop
Versi pertama sangat tidak nyaman, tetapi kami hanya ingin merilis versi untuk eksperimen, dan kemudian mengerjakan versi normal. Karena COVID, menurut kami inilah saat yang tepat untuk meluncurkan karena lembaga pemerintah di seluruh dunia dapat menggunakan Umumkan untuk memublikasikan peringatan.
Bukankah bagus untuk menghasilkan beberapa data di platform ketika pengguna belum mengunggah konten mereka? Pikiran ini mengarah ke proyek lain, Announce-AI, untuk pembuatan konten. Kaya data adalah berbagai peristiwa seperti peringatan gempa bumi dan kemungkinan berita lokal yang relevan.
Beberapa detail teknis
Kami menggunakan Cloud Functions untuk mulai mengembangkan Announce-AI. Karena bot scraping kami masih dalam tahap awal, kami memutuskan untuk menggunakan fitur ringan ini. Namun ada masalah dengan penskalaan karena fungsi cloud memiliki waktu tunggu sekitar 9 menit.
Dan tiba-tiba kami mengetahui tentang sistem Cloud Run, yang kemudian memiliki batas penggunaan gratis yang besar! Tanpa memahaminya sepenuhnya, saya meminta tim untuk menerapkan fungsi "test" Announce-AI di Cloud Run dan mengevaluasi performanya. Tujuannya adalah bermain-main dengan Cloud Run untuk mendapatkan pengalaman.
Google cloud run
Karena kami memiliki situs yang sangat kecil, kami menggunakan database Firebase untuk kesederhanaan, karena Cloud Run tidak memiliki penyimpanan apa pun, dan penerapan SQL Server atau database lain terlalu berlebihan untuk pengujian.
Saya membuat proyek GCP ANC-AI Dev baru, menyiapkan anggaran penagihan cloud $ 7, menghemat proyek Firebase dengan paket gratis (Spark). Opsi terburuk yang kami bayangkan adalah melampaui batas Firebase harian.
Setelah beberapa modifikasi, kami menyiapkan kode, membuat beberapa permintaan manual, dan kemudian membiarkannya berjalan.
Mimpi buruk dimulai
Pada hari pengujian, semuanya berjalan dengan baik, dan kami kembali ke pengembangan Announce. Keesokan harinya setelah bekerja di sore hari, saya pergi tidur siang. Ketika saya bangun, saya melihat beberapa email dari Google Cloud, semuanya dalam interval beberapa menit.
Email pertama: peningkatan otomatis proyek Firebase kami
Email kedua: anggaran terlampaui
Untungnya, kartu saya memiliki batas $ 100. Karena itu, pembayaran tidak berhasil, dan Google menangguhkan layanan akun kami.
Surat ketiga: kartu ditolak
Saya melompat dari tempat tidur, memasukkan penagihan Google Cloud dan melihat tagihan sekitar $ 5.000. Dengan panik, dia mulai mengklik tombol, tidak mengerti apa yang sedang terjadi. Di latar belakang, saya mulai merenungkan bagaimana ini bisa terjadi dan bagaimana cara membayar tagihan $ 5000, dalam hal ini.
Masalahnya adalah skor terus bertambah setiap menit.
Dalam lima menit itu menunjukkan $ 15.000, dalam 20 menit - $ 25.000. Saya tidak mengerti kapan jumlahnya akan berhenti bertambah. Mungkinkah mereka akan tumbuh tanpa batas?
Dua jam kemudian, angkanya berhenti di bawah $ 72.000.
Pada saat ini, tim dan saya berada di telekonferensi, saya benar-benar terkejut dan sama sekali tidak tahu apa yang harus dilakukan selanjutnya. Kami mematikan penagihan, menutup semua layanan.
Karena di semua project GCP kami menyelesaikan dengan satu kartu, semua akun dan project kami ditangguhkan.
Mimpi buruk terus berlanjut
Ini terjadi Jumat malam, 27 Maret - tiga hari sebelum kami berencana meluncurkan versi pertama. Sekarang pengembangan telah berhenti karena Google telah menangguhkan semua proyek kami yang ditautkan ke satu peta. Semangat saya berada di bawah lantai, dan masa depan perusahaan tampaknya tidak pasti.
Semua proyek cloud kami ditunda, pengembangan dihentikan.
Begitu pikiran saya pasrah pada kenyataan baru, pada tengah malam saya memutuskan untuk mencari tahu apa yang biasanya terjadi. Saya mulai menyusun dokumen dengan penyelidikan terperinci atas insiden itu ... dan menyebutnya "Bab 11" [ini adalah bab dari undang-undang kebangkrutan - kira-kira. per.].
Kedua rekan yang berpartisipasi dalam percobaan juga terjaga sepanjang malam, meneliti dan mencoba memahami apa yang terjadi.
Keesokan paginya, Sabtu 28 Maret, saya menelepon dan menulis surat kepada selusin firma hukum untuk membuat janji atau berbicara dengan pengacara. Mereka semua sedang pergi, tetapi saya bisa mendapatkan tanggapan dari salah satu dari mereka melalui email. Karena detail insiden itu begitu rumit, bahkan untuk para insinyur, menjelaskan hal ini kepada pengacara dalam bahasa Inggris yang sederhana tidaklah mudah.
Bagi kami, sebagai start-up startup, tidak ada cara untuk memulihkan $ 72.000.
Saat ini, saya sudah mempelajari pasal 7 dan 11 secara menyeluruh tentang hukum kebangkrutan dan secara mental siap untuk apa yang mungkin terjadi selanjutnya.
Beberapa kelonggaran: celah GCP
Pada hari Sabtu, setelah mengirim email ke pengacara, saya mulai membaca dan memeriksa setiap halaman dokumentasi GCP. Kami memang membuat kesalahan, tetapi tidak ada gunanya Google membiarkan kami membelanjakan $ 72.000 secara dramatis jika kami belum melakukan pembayaran sebelumnya!
GCP dan Firebase
1. Upgrade otomatis akun Firebase menjadi akun berbayar
Kami tidak mengharapkan ini, dan ini tidak diperingatkan tentang hal itu di mana pun saat mendaftar di Firebase. Penagihan GCP kami dicolokkan ke eksekusi Cloud Run, tetapi Firebase menggunakan paket gratis (Spark). Tanpa alasan yang jelas, GCP mengupgrade ke paket berbayar dan menagih kami sesuai jumlah yang diminta.
Ternyata mereka menyebut proses ini sebagai "integrasi mendalam dari Firebase dan GCP".
2. Tidak ada "batasan" penagihan. Anggaran terlambat setidaknya satu hari
Penagihan GCP secara efektif tertunda setidaknya 24 jam. Di sebagian besar dokumen, Google menyarankan penggunaan anggaran dan fitur cloud shutdown otomatis. Tetapi pada saat fungsi shutdown dipicu atau pemberitahuan dikirim ke pengguna, kerusakan sudah terjadi.
Perlu waktu sekitar satu hari untuk menyinkronkan penagihan, itulah alasan kami mengetahui tagihan tersebut pada hari berikutnya.
3. Google seharusnya mengambil $ 100, bukan 72 ribu!
Karena belum ada pembayaran yang dilakukan dari akun kami sejauh ini, GCP harus mengambil biaya $ 100 terlebih dahulu sesuai dengan informasi penagihan, dan jika tidak membayar, hentikan layanan. Tetapi hal tersebut tidak terjadi. Saya menemukan alasannya nanti, tetapi ini juga bukan kesalahan pengguna!
Tagihan pertama bagi kami adalah sekitar $ 5000. Yang berikutnya adalah $ 72K.
Ambang penagihan untuk akun kami adalah $ 100
4. Jangan mengandalkan dasbor Firebase Anda!
Tidak hanya penagihan, tetapi juga memperbarui dasbor Firebase membutuhkan waktu lebih dari 24 jam.
Menurut dokumentasi Firebase Console, nomor dasbor mungkin "sedikit berbeda" dari laporan penagihan.
Dalam kasus kami, mereka berbeda sebesar 86.585.365,85%, atau 86 juta poin persentase. Bahkan saat faktur masuk, Konsol Firebase masih menunjukkan 42.000 baca dan tulis per bulan (di bawah batas harian).
Hari baru, tantangan baru
Setelah enam setengah tahun di Google dan menulis lusinan dokumen proyek, laporan investigasi, dan banyak lagi, saya mulai menulis dokumen untuk Google, menjelaskan insiden tersebut dan menambahkan celah Google ke laporan tersebut. Tim Google akan kembali bekerja dalam dua hari.
Koreksi: Beberapa pembaca menyarankan bahwa saya menggunakan kontak internal Google saya. Faktanya, saya tidak berkomunikasi dengan siapa pun dan memilih jalur yang akan diikuti oleh pengembang atau perusahaan normal mana pun. Seperti pengembang kecil lainnya, saya menghabiskan berjam-jam mengobrol, berkonsultasi, menyusun email panjang, dan melaporkan bug. Di salah satu artikel berikut tentang Incident Reporting, saya akan menunjukkan dokumen yang saya kirimkan ke Google.
Hari terakhir di Google
Selain itu, penting juga untuk memahami kesalahan kami dan mengembangkan strategi pengembangan produk. Tidak semua orang di tim tahu tentang insiden itu, tetapi cukup jelas bahwa kami berada dalam masalah besar.
Di Google, saya menghadapi jutaan dolar dalam kesalahan manusia, tetapi budaya Google menyelamatkan karyawan (kecuali insinyur yang harus menulis laporan panjang nanti). Kali ini tidak ada Google. Modal kecil kita sendiri dan kerja keras kita dipertaruhkan.
Himalaya yang teguh memberi tahu kita ...
Ini adalah pertama kalinya saya menerima pukulan seperti itu. Ini dapat mengubah masa depan perusahaan dan hidup saya. Kejadian ini mengajari saya beberapa pelajaran bisnis, termasuk yang paling penting - menerima pukulan.
Pada saat itu, saya memiliki tim yang terdiri dari tujuh insinyur dan magang, dan Google membutuhkan waktu sekitar sepuluh hari untuk menanggapi kami tentang insiden ini. Sementara itu, kami harus melanjutkan pengembangan, mencari cara untuk mengatasi penangguhan akun. Terlepas dari segalanya, kami harus fokus pada fitur dan produk kami.
Puisi "The Persistent Himalayas Tell Us"
Untuk beberapa alasan, sebuah puisi dari masa kecil saya terus berputar di kepala saya. Itu adalah buku favorit saya, dan saya mengingatnya kata demi kata, meskipun terakhir kali saya membacanya lebih dari 15 tahun yang lalu.
Apa yang sebenarnya telah kita lakukan?
Sebagai tim yang sangat kecil, kami ingin menghindari pengeluaran untuk perangkat keras selama mungkin. Masalah Cloud Functions dan Cloud Run adalah waktu tunggu.
Satu contoh akan terus mengikis URL dari halaman. Tetapi setelah 9 menit, akan ada waktu tunggu.
Kemudian, setelah membahas masalah dengan santai, saya mencatat kode mentah di papan tulis dalam beberapa menit. Sekarang saya menyadari bahwa kode itu memiliki banyak kekurangan arsitektural, tetapi kemudian kami menargetkan siklus perbaikan bug yang cepat untuk mempelajari dan mencoba hal baru dengan cepat.
Umumkan konsep AI di Cloud Run
Untuk mengatasi batasan batas waktu, saya menyarankan menggunakan permintaan POST (dengan URL sebagai data) untuk mengirimkan pekerjaan ke sebuah instance dan - meluncurkan beberapa instance secara paralel, daripada mengantri untuk satu instance. Karena setiap instance di Cloud Run hanya akan menyalin satu halaman, tidak akan pernah ada waktu tunggu, semua halaman akan diproses secara paralel (penskalaan yang baik), dan prosesnya sangat dioptimalkan karena Cloud Run digunakan dengan presisi milidetik.
Cloud Run Scraper
Jika Anda melihat lebih dekat, proses ini kehilangan beberapa detail penting.
- Terjadi rekursi eksponensial berkelanjutan: instance tidak tahu kapan harus berhenti karena tidak ada pernyataan break.
- Permintaan POST dapat memiliki URL yang sama. Jika ada link kembali ke halaman sebelumnya, maka layanan Cloud Run akan macet dalam rekursi tak terbatas, tetapi yang terburuk, rekursi ini dikalikan secara eksponensial (jumlah maksimum instans ditetapkan menjadi 1000!)
Seperti yang dapat Anda bayangkan, hal ini mengakibatkan situasi di mana 1000 instans membuat permintaan dan menulis ke Firebase DB setiap beberapa milidetik. Kami melihat ada sekitar 1 miliar permintaan per menit yang melalui Firebase dibaca pada satu titik!
Ringkasan Transaksi Akhir Bulan GCP
116 miliar membaca dan 33 juta menulis
Versi eksperimental aplikasi kami di Cloud Run melakukan 116 miliar pembacaan dan 33 juta penulisan ke Firestore. Oh!
Biaya pembacaan Firebase:
$ (0,06 / 100.000) * 116.000.000.000 = $ 69.600
16.000 jam Cloud Run
Setelah pengujian, dari menghentikan log, kami menyimpulkan bahwa permintaan tersebut mati, tetapi sebenarnya masuk ke proses latar belakang. Karena kami tidak mencopot pemasangan layanan (kami menggunakan Cloud Run untuk pertama kali dan saat itu tidak benar-benar memahaminya), beberapa layanan terus berjalan lambat.
Dalam 24 jam, semua layanan ini pada 1.000 instans berjalan dengan total 16.022 jam.
Semua kesalahan kita
Terapkan algoritme yang salah di cloud
Sudah pernah dibahas diatas. Kami memang menemukan cara baru untuk menggunakan permintaan POST tanpa server yang tidak saya temukan di tempat lain di internet, tetapi kami menerapkannya tanpa menentukan algoritme.
Terapkan Cloud Run dengan parameter default
Saat kami membuat layanan Cloud Run, kami memilih nilai defaultnya. Jumlah maksimum instance adalah 1000 dan konkurensi adalah 80 permintaan. Kami tidak tahu bahwa nilai-nilai ini sebenarnya adalah skenario terburuk untuk program pengujian.
Jika kami memilih max-instance = 2, biayanya akan menjadi 500 kali lebih sedikit.
Jika kita menetapkan konkurensi = 1, kita bahkan tidak akan melihat skornya.
Menggunakan Firebase tanpa memahami sepenuhnya
Anda hanya memahami sesuatu dari pengalaman. Firebase bukanlah bahasa untuk dipelajari, ini adalah platform kontainer. Aturannya ditentukan oleh perusahaan Google tertentu.
Selain itu, saat menulis kode Node.js, Anda perlu memikirkan proses latar belakang. Jika kode masuk ke proses latar belakang, tidak mudah bagi pengembang untuk mengetahui bahwa layanan sedang berjalan. Seperti yang kita pelajari nanti, ini juga menyebabkan sebagian besar waktu tunggu untuk Cloud Functions kita.
Bug cepat dan perbaikan cepat adalah ide buruk di cloud
Awan secara keseluruhan seperti pedang bermata dua. Jika digunakan dengan benar, ini bisa sangat berguna, tetapi jika digunakan secara tidak benar, salahkan diri Anda sendiri.
Jika Anda menghitung jumlah halaman di dokumentasi GCP, Anda dapat memublikasikan beberapa volume tebal. Butuh banyak waktu dan pemahaman mendalam tentang cara kerja layanan cloud untuk memahami segalanya, termasuk penagihan dan penggunaan fungsi. Tidak mengherankan, itu mempekerjakan karyawan penuh waktu individu untuk ini!
Firebase dan Cloud Run sangat kuat
Pada puncaknya, Firebase menangani sekitar satu miliar pembacaan per menit. Ini adalah alat yang sangat ampuh. Kami telah bermain dengan Firebase selama dua atau tiga bulan sekarang - dan masih menemukan aspek-aspek baru, tetapi sampai saat itu saya tidak tahu seberapa kuat sistem ini.
Hal yang sama berlaku untuk Cloud Run! Jika Anda menyetel jumlah proses paralel menjadi 60, max_containers == 1000, maka dengan permintaan 400 md, Cloud Run dapat memproses 9 juta permintaan per menit!
60 * 1000 * 2,5 * 60 = 9.000.000 permintaan per menit
Sebagai perbandingan, pencarian Google memproses 3,8 juta kueri per menit.
Gunakan pemantauan
Meskipun Google Cloud Monitoring tidak akan menghentikan penagihan, ia mengirimkan peringatan tepat waktu (penundaan 3-4 menit). Tidak mudah untuk menguasai terminologi Google Cloud pada awalnya, tetapi jika Anda meluangkan waktu, dasbor, peringatan, dan metrik akan membuat hidup Anda sedikit lebih mudah.
Metrik ini hanya tersedia selama 90 hari, metrik tersebut belum disimpan bersama kami.
Kami selamat
Fuh, terbawa
Setelah memeriksa laporan insiden panjang kami yang menggambarkan situasi dari pihak kami, setelah berbagai konsultasi, percakapan, dan diskusi internal, Google memaafkan kami atas biayanya!
Terima kasih Google!
Kami mengambil lifebuoy dan menggunakan kesempatan ini untuk menyelesaikan pengembangan produk. Kali ini dengan perencanaan, arsitektur, dan implementasi yang jauh lebih baik.
Google, perusahaan teknologi favorit saya, bukan hanya perusahaan yang hebat untuk bekerja sama. Ini juga perusahaan yang bagus untuk diajak bekerja sama. Alat Google sangat ramah pengembang, memiliki dokumentasi yang bagus (untuk sebagian besar), dan terus berkembang.
(Catatan: ini adalah pendapat pribadi saya sebagai pengembang individu. Perusahaan kami tidak disponsori atau berafiliasi dengan Google dengan cara apa pun).
Apa berikutnya?
Setelah kejadian ini, kami menghabiskan beberapa bulan mempelajari cloud dan arsitektur kami. Dalam beberapa minggu, pemahaman saya telah meningkat pesat sehingga saya dapat memperkirakan biaya untuk mengorek "seluruh internet" dengan Cloud Run dengan algoritme yang ditingkatkan.
Insiden tersebut memaksa saya untuk menganalisis arsitektur produk kami secara mendalam, dan kami meninggalkan versi pertama untuk membangun infrastruktur yang dapat diskalakan.
Di Announce versi kedua, kami tidak hanya membuat MVP, tetapi juga membuat platform tempat kami dapat mengembangkan produk baru dalam iterasi cepat dan mengujinya secara menyeluruh di lingkungan yang aman.
Perjalanan ini memakan waktu lama ... Umumkandiluncurkan pada akhir November, sekitar tujuh bulan setelah versi pertama, tetapi sangat skalabel, memanfaatkan cloud terbaik, dan sangat dioptimalkan.
Kami juga meluncurkannya di semua platform, tidak hanya di internet.
Selain itu, kami menggunakan kembali platform tersebut untuk membuat produk kedua kami, Alamat Titik . Ia juga menampilkan skalabilitas dan arsitektur yang baik.