
A história de como nos encontramos à beira da falência antes mesmo de lançar o primeiro produto, como conseguimos sobreviver e quais lições aprendemos.
Em março de 2020, quando COVID atingiu o mundo, nossa startup Milkie Way também foi duramente atingida e quase encerrou. Gastamos US $ 72.000 pesquisando e testando internamente o Cloud Run com Firebase por várias horas.
Comecei a desenvolver o serviço Announce em novembro de 2019. O objetivo principal era lançar a primeira versão funcional mínima do produto, de forma que o código funcionasse em uma pilha simples. Usamos JS, Python e implantamos nosso produto no Google App Engine.
Com uma equipe muito pequena, nos concentramos em codificação, desenvolvimento de IU e preparação de produtos. Quase não gastei tempo gerenciando a nuvem - gastei apenas o suficiente para colocar o sistema em funcionamento e fornecer um processo básico de desenvolvimento (CI / CD).

Anúncio de mesa
A primeira versão não era muito conveniente, mas queríamos apenas lançar uma versão para experimentos e depois trabalhar na versão normal. Devido ao COVID, achamos que este é um bom momento para o lançamento, já que agências governamentais em todo o mundo podem usar o Announce para publicar alertas.
Não é ótimo gerar alguns dados na plataforma quando os usuários ainda não fizeram upload de seu conteúdo? Esse pensamento levou a outro projeto, Announce-AI, para geração de conteúdo. Ricos em dados são vários eventos, como alertas de terremoto e notícias locais possivelmente relevantes.
Alguns detalhes técnicos
Usamos Cloud Functions para começar a desenvolver o Announce-AI. Como nosso robô de scraping ainda estava em sua infância, decidimos usar esses recursos leves. Mas houve problemas com o dimensionamento porque as funções da nuvem têm um tempo limite de cerca de 9 minutos.
E de repente aprendemos sobre o sistema Cloud Run, que tinha um grande limite de uso gratuito! Sem entender completamente, pedi à equipe que implantasse a função de "teste" Announce-AI no Cloud Run e avaliasse seu desempenho. O objetivo era brincar com o Cloud Run para ganhar experiência.

Execução na nuvem do Google
Como temos um site muito pequeno, usamos um banco de dados Firebase para simplificar, já que o Cloud Run não tem nenhum armazenamento e a implantação do SQL Server ou outro banco de dados é excessiva para o teste.
Eu criei um novo projeto GCP ANC-AI Dev, configurei um orçamento de faturamento de nuvem de $ 7, salvei o projeto Firebase com um plano gratuito (Spark). O pior caso que imaginamos é ultrapassar o limite diário do Firebase.
Após algumas modificações, preparamos o código, fizemos algumas solicitações manuais e o deixamos em execução.
O pesadelo começa
No dia do teste, tudo correu bem, e voltamos ao desenvolvimento do Announce. No dia seguinte, depois do trabalho, no final da tarde, fui tirar uma soneca. Quando acordei, vi vários e-mails do Google Cloud, todos em intervalos de vários minutos.
Primeiro e-mail: atualização automática de nosso projeto Firebase

Segundo e-mail: orçamento excedido

Felizmente, meu cartão tem um limite de $ 100. Por conta disso, os pagamentos não foram processados e o Google suspendeu o serviço de nossas contas.
Terceira carta: cartão recusado

Pulei da cama, entrei no faturamento do Google Cloud e vi uma conta de cerca de US $ 5.000. Em pânico, ele começou a clicar nas teclas, sem entender o que estava acontecendo. No fundo, comecei a refletir sobre como isso poderia ter acontecido e como pagar a conta de $ 5.000, nesse caso.
O problema era que a pontuação continuava crescendo a cada minuto.
Em cinco minutos, ele mostrou $ 15.000, em 20 minutos - $ 25.000.Eu não entendi quando os números paravam de aumentar. Talvez eles cresçam indefinidamente?
Duas horas depois, o número parou em pouco menos de US $ 72.000.
Nesse momento, a equipe e eu estávamos na teleconferência, fiquei completamente chocado e não tinha absolutamente nenhuma ideia do que fazer a seguir. Desligamos o faturamento, fechamos todos os serviços.
Como em todos os projetos do GCP fechamos com um cartão, todas as nossas contas e projetos foram suspensos.
O pesadelo continua
Isso aconteceu na noite de sexta-feira, 27 de março - três dias antes do planejamento do lançamento da primeira versão. Agora o desenvolvimento foi interrompido porque o Google suspendeu todos os nossos projetos vinculados a um mapa. Meu moral estava abaixo do nível do solo e o futuro da empresa parecia incerto.

Todos os nossos projetos na nuvem estão em espera, o desenvolvimento está parado.Assim
que minha mente se resignou à nova realidade, à meia-noite eu decidi descobrir o que tinha acontecido normalmente. Comecei a redigir um documento com uma investigação detalhada do incidente ... e chamei-o de "Capítulo 11" [este é um capítulo da lei de falências - aprox. por.].
Os dois colegas que participaram do experimento também ficaram acordados a noite toda, pesquisando e tentando entender o que aconteceu.
Na manhã seguinte, sábado, 28 de março, liguei e escrevi cartas para uma dúzia de escritórios de advocacia para marcar uma reunião ou falar com um advogado. Eles estavam todos ausentes, mas consegui uma resposta de um deles por e-mail. Como os detalhes do incidente são tão complexos, mesmo para engenheiros, explicar isso a um advogado em um inglês simples não foi fácil por si só.
Para nós, como uma startup, não havia como recuperar US $ 72.000.
Nessa época, eu já havia estudado exaustivamente os capítulos 7 e 11 da lei de falências e preparado mentalmente para o que poderia acontecer a seguir.
Alguma trégua: lacunas do GCP
No sábado, após enviar e-mails aos advogados, comecei a ler e percorrer todas as páginas da documentação do GCP. Cometemos erros, mas não fazia sentido o Google nos deixar gastar US $ 72.000 drasticamente se não tivéssemos feito nenhum pagamento antes!

GCP e Firebase
1. Upgrade automático de uma conta Firebase para uma conta paga
Não esperávamos isso, e isso não foi avisado em lugar nenhum ao se registrar no Firebase. Nosso faturamento GCP foi conectado à execução do Cloud Run, mas o Firebase veio em um plano gratuito (Spark). O GCP do nada fez o upgrade para um plano pago e nos cobrou o valor necessário.
Acontece que eles chamam esse processo de "integração profunda do Firebase e do GCP".
2. Não há "limites" de faturamento. Os orçamentos estão atrasados em pelo menos um dia
O faturamento do GCP é efetivamente atrasado em pelo menos 24 horas. Na maioria dos documentos, o Google sugere o uso de orçamentos e o recurso de desligamento automático da nuvem. Porém, no momento em que a função de desligamento é acionada ou uma notificação é enviada ao usuário, o dano já está feito.
Demora cerca de um dia para sincronizar o faturamento, por isso notamos a fatura no dia seguinte.
3. O Google deveria ter levado $ 100, não 72 mil!
Como nenhum pagamento foi feito de nossa conta até agora, o GCP teve que primeiro cobrar uma taxa de $ 100 de acordo com as informações de pagamento e, se não pagasse, interromperia o serviço. Mas isso não aconteceu. Descobri o motivo mais tarde, mas isso também não é culpa do usuário!
A primeira conta para nós foi de cerca de US $ 5.000. O próximo é $ 72K.

O limite de faturamento para nossa conta é $ 100
4. Não confie no painel do Firebase!
Não apenas o faturamento, mas também a atualização do painel do Firebase levou mais de 24 horas.
De acordo com a documentação do Firebase Console, os números no painel podem ser "ligeiramente" diferentes dos relatórios de faturamento.
Em nosso caso, eles diferiram em 86.585.365,85%, ou 86 milhões de pontos percentuais. Mesmo quando a fatura chegou, o Firebase Console ainda mostrava 42.000 leituras e gravações por mês (abaixo do limite diário).
Novo dia, novo desafio
Depois de seis anos e meio no Google e escrevendo dezenas de documentos de projeto, relatórios de investigação e muito mais, comecei a escrever um documento para o Google, descrevendo o incidente e adicionando lacunas do Google ao relatório. A equipe do Google estará de volta ao trabalho em dois dias.
Correção: alguns leitores sugeriram que eu estava usando meus contatos internos do Google. Na verdade, não me comuniquei com ninguém e escolhi o caminho que qualquer desenvolvedor ou empresa normal seguiria. Como qualquer outro pequeno desenvolvedor, passei incontáveis horas conversando, consultando, redigindo longos e-mails e relatórios de bug. Em um dos artigos a seguir sobre Relatórios de Incidentes, mostrarei os documentos que enviei ao Google.

Último dia no Google
Além disso, foi necessário entender nossos erros e desenvolver uma estratégia de desenvolvimento de produto. Nem todos na equipe sabiam do incidente, mas estava claro que estávamos em apuros.
No Google, encontrei milhões de dólares em erros humanos, mas a cultura do Google salva funcionários (exceto que os engenheiros precisam escrever longos relatórios depois). Desta vez não havia Google. Nosso pequeno capital e nosso trabalho árduo estão em jogo.
Os constantes Himalaias nos dizem ...
Foi a primeira vez que recebi tal golpe. Isso pode mudar o futuro da nossa empresa e da minha vida. Esse incidente me ensinou várias lições de negócios, incluindo a mais importante - levar um golpe.
Na época, eu tinha uma equipe de sete engenheiros e estagiários, e o Google levou cerca de dez dias para nos responder sobre esse incidente. Nesse ínterim, tivemos que retomar o desenvolvimento, encontrar uma maneira de contornar a suspensão de contas. Apesar de tudo, tínhamos que nos concentrar nos recursos e no produto.

Poema "The Stalwart Himalayas Tell Us"
Por alguma razão, um poema da minha infância estava constantemente girando em minha cabeça. Era meu livro favorito e lembrei-me dele palavra por palavra, embora a última vez que o tenha lido há mais de 15 anos.
O que realmente fizemos?
Como uma equipe muito pequena, queríamos evitar gastos com hardware pelo maior tempo possível. O problema do Cloud Functions e do Cloud Run atingiu o tempo limite.
Uma instância irá raspar URLs continuamente da página. Mas após 9 minutos, haverá um tempo limite.
Então, tendo discutido casualmente o problema, anotei o código bruto no quadro-negro em alguns minutos. Agora eu percebi que aquele código tinha muitas falhas arquitetônicas, mas então queríamos ciclos rápidos de correção de bugs para aprender e tentar coisas novas rapidamente.

Conceito Announce-AI no Cloud Run
Para superar a limitação de tempo limite, sugeri usar solicitações POST (com uma URL como dados) para enviar trabalhos a uma instância e - iniciar várias instâncias em paralelo, em vez de enfileirar para uma. Como cada instância no Cloud Run descartará apenas uma página, nunca haverá um tempo limite, todas as páginas serão processadas em paralelo (bom escalonamento) e o processo é altamente otimizado, pois o Cloud Run é consumido com precisão de milissegundos.

Scraper Cloud Run
Se você olhar de perto, o processo está perdendo alguns detalhes importantes.
- Ocorre uma recursão exponencial contínua: as instâncias não sabem quando parar porque não há instrução break.
- As solicitações POST podem ter o mesmo URL. Se houver um link para a página anterior, o serviço Cloud Run ficará preso em uma recursão infinita, mas o pior de tudo, essa recursão é multiplicada exponencialmente (o número máximo de instâncias foi definido como 1000!)
Como você pode imaginar, isso resultou em uma situação em que 1.000 instâncias estão fazendo solicitações e gravando no Firebase DB a cada poucos milissegundos. Vimos que havia cerca de 1 bilhão de solicitações por minuto passando por leituras do Firebase em um ponto!

Resumo da transação de final de mês do GCP
116 bilhões de leituras e 33 milhões de gravações
A versão experimental de nosso aplicativo no Cloud Run fez 116 bilhões de leituras e 33 milhões de gravações no Firestore. Oh!
Custos de leitura do Firebase:
$ (0,06 / 100.000) * 116.000.000.000 = $ 69.600
16.000 horas de execução na nuvem
Após o teste, ao parar os logs, concluímos que a solicitação morreu, mas na verdade ela entrou em um processo em segundo plano. Como não desinstalamos os serviços (estávamos usando o Cloud Run pela primeira vez e não o entendíamos muito bem), vários serviços continuaram a ser executados lentamente.
Em 24 horas, todos esses serviços em 1.000 instâncias foram executados por um total de 16.022 horas.
Todos os nossos erros
Implante o algoritmo incorreto na nuvem
Já foi discutido acima. Encontramos uma nova maneira de usar solicitações POST sem servidor que não encontrei em nenhum lugar da Internet, mas a implantamos sem especificar o algoritmo.
Implante o Cloud Run com parâmetros padrão
Quando criamos o serviço Cloud Run, escolhemos os valores padrão para ele. O número máximo de instâncias é 1000 e a simultaneidade é de 80 solicitações. Não sabíamos que esses valores são, na verdade, o pior cenário para o programa de teste.
Se escolhermos max-instances = 2, o custo seria 500 vezes menor.
Se definirmos a simultaneidade = 1, nem notaremos a pontuação.
Usar o Firebase sem entender totalmente
Você só entende algo por experiência. Firebase não é uma linguagem para aprender, é uma plataforma de contêiner. Suas regras são determinadas por uma empresa Google específica.

Além disso, ao escrever código em Node.js, você precisa pensar sobre os processos de segundo plano. Se o código for para processos em segundo plano, não será fácil para o desenvolvedor saber que o serviço está sendo executado. Como aprendemos mais tarde, isso também causava a maior parte dos tempos limite de nosso Cloud Functions.
Bugs e soluções rápidas são uma má ideia na nuvem
A nuvem como um todo é como uma espada de dois gumes. Se usado corretamente, pode ser muito útil, mas se usado incorretamente, culpe a si mesmo.
Se você contar o número de páginas na documentação do GCP, poderá publicar vários volumes grossos. Leva muito tempo e um profundo entendimento de como os serviços em nuvem funcionam para entender tudo, incluindo cobrança e uso de funções. Sem surpresa, ele contrata funcionários individuais em tempo integral para isso!
Firebase e Cloud Run são realmente poderosos
Em seu pico, o Firebase processa cerca de um bilhão de leituras por minuto. Esta é uma ferramenta extremamente poderosa. Estamos jogando com o Firebase há dois ou três meses - e ainda descobrindo novos aspectos, mas até então eu não tinha ideia de quão poderoso é esse sistema.
O mesmo vale para Cloud Run! Se você definir o número de processos paralelos para 60, max_containers == 1000, então, com solicitações de 400 ms, o Cloud Run pode processar 9 milhões de solicitações por minuto!
60 * 1000 * 2,5 * 60 = 9.000.000 de solicitações por minuto
Em comparação, a pesquisa do Google processa 3,8 milhões de consultas por minuto.
Use monitoramento
Embora o Google Cloud Monitoring não interrompa o faturamento, ele envia alertas oportunos (atraso de 3 a 4 minutos). Não é fácil dominar a terminologia do Google Cloud no início, mas se você reservar um tempo, o painel, os alertas e as métricas tornarão sua vida um pouco mais fácil.
Essas métricas estão disponíveis apenas por 90 dias e não foram salvas conosco.
Nós sobrevivemos

Puxa, empolgado
Depois de examinar nosso longo relatório de incidente descrevendo a situação do nosso lado, após várias consultas, conversas e discussões internas, o Google nos perdoou pela despesa!
Obrigado Google!
Pegamos uma bóia salva-vidas e aproveitamos essa oportunidade para concluir o desenvolvimento do produto. Desta vez, com muito melhor planejamento, arquitetura e implementação muito mais segura.
O Google, minha empresa de tecnologia favorita, não é apenas uma ótima empresa para trabalhar. Também é uma ótima empresa para se trabalhar. O Google Tools é muito amigável ao desenvolvedor, tem ótima documentação (em sua maior parte) e está em constante evolução.
(Observação: esta é minha opinião pessoal como desenvolvedor individual. Nossa empresa não é patrocinada ou afiliada ao Google de forma alguma).
Qual é o próximo?
Depois desse incidente, passamos vários meses estudando a nuvem e nossa arquitetura. Em poucas semanas, meu entendimento melhorou tanto que pude estimar o custo de "limpar toda a Internet" com o Cloud Run com um algoritmo aprimorado.
O incidente me forçou a analisar profundamente a arquitetura do nosso produto e abandonamos o da primeira versão para construir uma infraestrutura escalável.
Na segunda versão do Announce, não criamos apenas um MVP, criamos uma plataforma na qual poderíamos desenvolver novos produtos em iterações rápidas e testá-los completamente em um ambiente seguro.
Esta viagem demorou muito ... Anuncielançado no final de novembro, cerca de sete meses após a primeira versão, mas é muito escalável, aproveita o melhor da nuvem e é altamente otimizado.
Também lançamos em todas as plataformas, não apenas na Internet.
Além disso, reutilizamos a plataforma para criar nosso segundo produto, Point Address . Ele também apresenta escalabilidade e boa arquitetura.