Inglés: Sudeep Chauhan
Este artículo cuenta la historia de que casi nos arruinamos antes de que el primer producto saliera al mercado, y finalmente sobrevivimos y aprendimos lecciones de él.
En marzo de 2020, estalló la epidemia de COVID-19, y nuestra start-up Milkie Way también sufrió un gran golpe y estuvo a punto de quebrar. Porque durante nuestras pruebas internas de Firebase y Cloud Run, quemamos accidentalmente $ 72,000 (aproximadamente 470,000 RMB) en unas pocas horas.
En noviembre de 2019, comenzamos a desarrollar el servicio https://announce.today, con la esperanza de crear una versión V1 de las funciones utilizables de los productos MVP. Como intento preliminar, nuestro código se basa en una pila subyacente simple, utiliza código JS, Python e implementa el producto en Google App Engine.
Debido a que el equipo es pequeño, nuestro enfoque está en escribir código, diseñar la interfaz de usuario y preparar el producto. No pusimos mucho esfuerzo en la administración de la nube. El objetivo en ese momento era simple: era suficiente para respaldar el proceso de desarrollo básico (CI / CD).
En esta aplicación web V1, la experiencia del usuario no es fluida. Pero no importa, nuestro atractivo es desarrollar algunos productos que los usuarios puedan experimentar y, al mismo tiempo, crear una mejor versión de Announce. Con la pandemia de COVID-19 azotando todos los ámbitos, creemos que este es el mejor momento para hacer cambios, y tal vez Announce se convierta en la opción ideal para que los gobiernos emitan anuncios a escala global.
En ese momento, los usuarios no habían creado ningún contenido, pero pensamos que sería mejor proporcionar algunos datos existentes en la plataforma. Así que establecimos el proyecto Announce-AI, que tiene como objetivo publicar automáticamente contenido enriquecido creado por AI. El rico contenido aquí se refiere a varios incidentes, terremotos y otras advertencias de seguridad, así como a noticias relevantes que pueden preocupar a los usuarios locales.
1 Detalles técnicos
Para desarrollar Announce-AI, decidimos utilizar Cloud Functions. Dado que el período de rastreo de nuestros datos aún es muy corto, Cloud Functions es una opción casi perfecta. Pero después de decidir expandirnos, inmediatamente nos encontramos con problemas: Cloud Functions tenía un período de tiempo de espera de hasta 9 minutos.
Así que comenzamos a estudiar Cloud Run y descubrimos que proporciona una capa considerable de uso de recursos gratuitos. Debe admitirse que en ese momento no sabíamos lo suficiente sobre Cloud Run, pero le pedimos apresuradamente al equipo que implementara la función de "prueba" Announce-AI en Cloud Fun. Pensamos que era muy simple en ese momento: familiarízate con Cloud Run lo antes posible y sigue aprendiendo mientras exploras.
En aras de la simplicidad, solo presentamos un sitio pequeño en el experimento y usamos Firebase como base de datos (porque Cloud Run no proporciona ninguna función de almacenamiento). La escala del sitio es realmente pequeña y no utiliza SQL Server ni ninguna otra base de datos comercial madura en absoluto.
Creé un nuevo proyecto de GCP llamado ANC-AI Dev, establecí un presupuesto de uso de recursos en la nube de $ 7 y elegí usar Firebase Project en el plan Free (Spark). En ese momento pensamos que el peor resultado sería nada más que exceder el límite diario gratuito de Firestore, ¿verdad?
Después de ajustar un poco el código, comenzamos el proceso de implementación, le hicimos algunas solicitudes manuales y luego lo dejamos en ejecución.
2 Aquí empieza la pesadilla,
todo salió bien el día de la prueba y volvimos al desarrollo de la ontología Announce. Después de salir del trabajo al día siguiente, dormí un rato. Después de despertar, encontré varios correos electrónicos de recordatorio de Google Cloud en mi buzón, y el intervalo entre correos electrónicos fue de solo unos minutos.
El primer correo electrónico: Firebase Project se actualiza automáticamente
Segundo correo electrónico: presupuesto excesivo
Afortunadamente, la tarjeta de crédito que uso tiene un límite de gasto de $ 100. Entonces los cargos se detuvieron y Google suspendió todas nuestras cuentas.
El tercer correo electrónico: Pago con tarjeta de crédito rechazado.
Salté de la cama, inicié sesión en Google Cloud Billing y vi una factura de aproximadamente $ 5,000. Para ser honesto, estaba tan asustado en ese momento que no podía pensar con normalidad. Miré a mi alrededor, tratando de averiguar qué salió mal, incluido cómo pagar la enorme suma de $ 5,000.
Pero el problema es que el monto de la factura aumenta cada minuto.
Después de 5 minutos, el monto de la factura aumentó a 15,000 dólares estadounidenses; 20 minutos después, el monto aumentó a 25,000 dólares estadounidenses. No estoy seguro de cuándo terminará esto, ¿o tal vez nunca se detendrá?
Después de 2 horas, la cantidad finalmente se fijó en $ 72,000.
En ese momento, mi equipo y yo estábamos ocupados revisando la situación como un loco. Estaba completamente estupefacto y no sabía qué hacer a continuación. Deshabilitamos la función de facturación y cerramos todos los servicios al mismo tiempo.
Dado que usamos la misma tarjeta de pago corporativa en todos los proyectos de GCP, Google ha cerrado por completo nuestras cuentas y proyectos.
3 La pesadilla continúa
Sucedió la noche del viernes 27 de marzo, tres días antes de que planeamos lanzar Announce V1. Como Google congeló todos los proyectos vinculados a la misma tarjeta de crédito, nuestro trabajo de desarrollo de productos estaba en un punto muerto. La moral es baja y el futuro de esta joven empresa es incierto.
Todos los proyectos en la nube se cerraron y el trabajo de desarrollo llegó a un punto muerto.
A la medianoche del día, finalmente lo superé y comencé a investigar. Grabé cada paso de la investigación en detalle en un archivo ... y llamé al archivo "Capítulo 11".
Los otros dos miembros del equipo también se unieron a la investigación y trabajaron sin cesar conmigo para explorar la verdad.
Al día siguiente, sábado 28 de marzo, llamé o envié un correo electrónico a más de una docena de bufetes de abogados para concertar una cita para una entrevista. La mayoría de los bufetes de abogados se negaron a aceptar el caso, y solo se envió un correo electrónico para permitirme explicar todo el proceso en detalle. Hay que admitir que incluso para los ingenieros este asunto es demasiado detallado, complicado y difícil de entender, no sé cómo explicárselo al abogado en un lenguaje sencillo y comprensible.
Como empresa autofinanciada, no podemos gastar 72.000 dólares.
En este punto, incluso estudié cuidadosamente el Capítulo 7 y el Capítulo 11 de la Ley de Quiebras, y estaba mentalmente preparado para todo lo que podría suceder a continuación.
4 Oportunidad de respiro: vulnerabilidades de GCP
El mismo sábado comencé a leer más contenido, especialmente las diversas entradas en la documentación de GCP. Bueno, cometimos un error, pero Google nos facturó 72.000 dólares sin completar un pago real. ¿Es esto normal? !
GCP y Firebase
- Actualice automáticamente su cuenta de Firebase a una cuenta de pago
Al registrarnos en Firebase, nunca pensamos que se actualizaría automáticamente, y definitivamente no se mencionó en la cláusula de solicitud. Nuestro proyecto de GCP acepta los términos del acuerdo, porque solo de esta manera podemos usar Cloud Run normalmente; pero no Firebase, usamos un plan gratuito. GCP se actualizó repentinamente y nos cobró tarifas enormes.
Los hechos han demostrado que lo diseñaron de esta manera, porque "Firebase está profundamente integrado con GCP".
- El llamado "límite" de facturación no existe y la gestión presupuestaria se ha retrasado al menos un día.
En realidad, la facturación de GCP se retrasó al menos un día. En la mayor parte de la documentación, Google recomienda que los usuarios usen Presupuestos y apaguen automáticamente la función de nube. ¿Pero adivina que? Cuando se activa la función de interrupción o se notifica al usuario de la nube, es posible que se haya producido el problema.
El proceso de facturación tarda aproximadamente un día completo, por lo que no recibimos el recordatorio de facturación hasta el día siguiente.
- ¡Google debería cobrarnos $ 100, no $ 72,000!
Dado que nuestra cuenta no se ha pagado realmente, GCP primero debe cobrar una tarifa de $ 100 según la información de facturación y detener el servicio cuando no se pueda continuar con el pago. Pero la situación real no es el caso. Más tarde, descubrí la razón, y el problema aún no tiene nada que ver con el usuario.
La primera tarifa de nuestra cuenta fue de aproximadamente $ 5,000 y el siguiente cargo se disparó a $ 72,000.
El límite de facturación para nuestra cuenta es de $ 100
4. ¡No confíe en el panel de Firebase!
No solo la función de facturación, sino que incluso el panel de Firebase tarda más de 24 horas en actualizarse normalmente.
Según la documentación de la consola de Firebase, los números de panel de la consola de Firebase pueden ser "ligeramente diferentes" del informe de facturación.
Tome nuestra situación como ejemplo, la diferencia entre los dos es tan alta como 85855365.85%, que es 860,000 veces. Y después de facturarnos, el panel de Firebase console aún mostraba que hubo 42,000 operaciones de lectura + escritura ese mes (por debajo del límite diario).
Editor de soporte
5Un nuevo día, un nuevo desafío
He trabajado en Google durante unos seis años y medio antes, y también he escrito docenas de documentos de descripción de proyectos e informes forenses. Combinando la experiencia laboral pasada, compilé un documento que resumía el incidente para Google y resumía los errores y omisiones de Google. Lógicamente hablando, el equipo de Google se pondrá a trabajar y se hará cargo el lunes dos días después.
Actualización: algunos lectores sugirieron que me pusiera en contacto directamente con mis colegas anteriores de Google. De hecho, no utilicé ninguno de mis contactos originales y utilicé los métodos habituales adoptados por desarrolladores / empresas comunes. Desde entonces, desperdicié innumerables horas en canales de chat, consultas, correos electrónicos redundantes y pequeños errores. A continuación, veamos los detalles del proceso de negociación.
El día
que dejamos Google Al mismo tiempo, estábamos solucionando los errores que cometimos aquí y formulando nuevas estrategias de desarrollo de productos. Todavía hay muchas personas en el equipo que no saben lo que sucedió, solo que la empresa está en un gran problema.
Como ex empleado de Google, tengo una gran experiencia en "cometer errores" y también causé pérdidas de millones de dólares a Google. Pero la cultura corporativa de Google salvó a los empleados (por supuesto, el ingeniero involucrado aún tenía que escribir un informe retrospectivo extenso sobre el incidente). Esta vez, ya no soy un Googler, tenemos fondos limitados y los resultados en los que hemos invertido mucho antes están en riesgo.
Primero veamos un número: 116 mil millones, que es la cantidad de veces que nuestro código de prueba lee la base de datos de Firestore en una hora.
Esta es la primera vez en mi vida que me he encontrado con un revés de este tipo, y puede cambiar por completo la dirección futura de toda la empresa e incluso mi vida. Podemos decir mucho sobre el problema, pero el más importante es una simple verdad: mantente firme.
Como gerente de una pequeña empresa, solo tengo un equipo de 7 ingenieros / pasantes. Google tardará unos 10 días en ponerse en contacto con nosotros. Mientras tanto, debemos reanudar el desarrollo y encontrar una solución para el cierre de la cuenta. Además, el trabajo de diseño de productos y funciones debe reiniciarse lo antes posible.
6 ¿Qué hicimos?
Debido a que el equipo es pequeño, queremos utilizar la arquitectura sin servidor tanto como sea posible. La idea básica de las soluciones sin servidor como Cloud Functions y Cloud Run para hacer frente a los problemas es el tiempo de espera.
Específicamente, la instancia continuará rastreando la URL en la página web, pero después de 9 minutos, la instancia expirará.
Puede ser que el fallo haya inspirado la sabiduría en mi mente. En unos minutos enumeré muchos problemas de diseño en la pizarra. No sé por qué. Antes de la implementación, todo lo que podemos pensar es cometer errores e intentarlo rápidamente.
En la versión "Hello World" de Announce-AI en Cloud Run,
para superar el límite de tiempo de espera, recomiendo usar una solicitud POST (usando la URL como datos) para enviar el trabajo a una instancia y usar varias instancias al mismo tiempo. de usar una sola instancia en serie. De esta manera, cada instancia en Cloud Run solo rastreará una página, por lo que nunca se agotará el tiempo de espera. Además, debido a que las operaciones de procesamiento de Cloud Run pueden tener una precisión de milisegundos, todas las páginas se procesarán al mismo tiempo y el rendimiento general se puede optimizar en gran medida.
El rastreador implementado en Cloud Run
Si observa de cerca, encontrará que faltan algunas partes importantes en el proceso:
Recursión exponencial ininterrumpida: dado que no hay una declaración de interrupción, la instancia no sabe cuándo interrumpir.
Las solicitudes POST pueden tener la misma URL. Si hay un enlace de reflexión a la página anterior, el servicio de Cloud Run caerá en una recursividad infinita y, en el peor de los casos, esta recursividad crecerá exponencialmente (¡establecemos el número máximo de instancias en 1000!).
Como puede imaginar, esto significa que se consultarán y escribirán continuamente hasta 1000 instancias en la base de datos de Firebase cada pocos milisegundos. Al observar el evento de publicación de datos, descubrimos que la cantidad de solicitudes por minuto de Firebase en un momento determinado aumentó a mil millones.
Resumen de transacciones de fin de mes de la cuenta de facturación de GCP
116 mil millones de lecturas y 33 millones de escrituras
En general, nuestra versión de "Hello World" implementada en Cloud Run ha realizado 116 mil millones de lecturas y 33 millones de escrituras ... ¡Dios mío!
Costo de las operaciones de lectura en Firebase:
(0,06 USD / 100.000) * 116.000.000.000 = 69.600 USD
1600 horas de cálculo de Cloud Run
Después de la prueba, asumimos que la solicitud se canceló debido a la detención del registro, pero de hecho solo se transfirió a un proceso en segundo plano. Dado que no eliminamos el servicio (esta es la primera vez que usamos Cloud Run y aún no conocemos las reglas específicas), muchos servicios continúan funcionando lentamente.
En 24 horas, cada una de estas versiones de servicio se expandió a 1,000 instancias, consumiendo 16,022 horas de computación.
7 ¿Qué error cometimos?
Implementación de algoritmos defectuosos en la nube
Basándonos en la discusión anterior, descubrimos una nueva forma de utilizar recursos sin servidor a través de solicitudes POST. De hecho, este es un método original, y no hay una referencia disponible en Internet. Desafortunadamente, hay grandes problemas de los que no nos dimos cuenta al principio.
Implementar Cloud Run con opciones predeterminadas
Al crear el servicio Cloud Run, elegimos usar los valores predeterminados en el servicio, es decir, las instancias máximas se establecen en 1000 y la concurrencia se establece en 80. Al principio, no sabíamos que estos valores preestablecidos podrían considerarse la combinación menos adecuada para nuestro programa de prueba.
Si establecemos instancias máximas en 2, nuestro costo será solo una quinta parte del costo actual, es decir, de 72 000 dólares estadounidenses a 144 dólares estadounidenses.
Si establecemos la concurrencia en 1, básicamente no se incurrirá en tarifas.
Usa Firebase sin comprenderlo completamente
Se debe adquirir algo de experiencia con la práctica. Firebase no es como un lenguaje de programación que se pueda aprender directamente. Es un servicio de plataforma en contenedores proporcionado por Google. Utiliza una gran cantidad de reglas predefinidas y el contenido de las reglas no tiene nada que ver con la intuición o inclinación del usuario.
Además, al escribir código en Node.js, debe prestar atención a los procesos en segundo plano. Si el código entra en un proceso en segundo plano, es difícil para los desarrolladores darse cuenta de que el servicio aún se está ejecutando y continuará ejecutándose durante un largo período de tiempo. Más tarde, descubrimos que esta es la razón por la que la mayoría de nuestras funciones en la nube también caducan.
No participe en "fallar rápido, aprender rápido" en la nube
La plataforma en la nube es como un arma de doble filo. Si se usa correctamente, de hecho es poderoso; pero si se usa incorrectamente, las consecuencias serán extremadamente graves.
Al revisar la documentación de GCP, encontrará que tiene más páginas que unas pocas novelas combinadas. En otras palabras, comprender los precios y el uso de la nube no solo requiere mucho tiempo, sino que también requiere que el personal relevante comprenda completamente cómo funcionan los servicios en la nube. Por lo tanto, no crea que agregar una "nube" delante de un título tradicional es una mentira, ¡esto es realmente un trabajo técnico!
Firebase y Cloud Run son realmente poderosos
En las horas pico, Firebase puede manejar alrededor de mil millones de lecturas por minuto, lo cual es realmente poderoso. Lo hemos estado probando en Firebase durante 2 o 3 meses, y aún continuamos aprendiendo, pero no hemos tocado sus límites en absoluto.
¡Lo mismo ocurre con Cloud Run! Cuando Concurrency == 60, max_containers == 1000 y cada solicitud tarda 400 milisegundos, Cloud Run puede manejar 9 millones de solicitudes por minuto.
60 * 1000 * 2.5 * 60 = 9,000,000 solicitudes / minuto
Por el contrario, la búsqueda de Google solo puede completar 3,8 millones de búsquedas por minuto.
Utilice la supervisión en la nube
Aunque Google Cloud Monitoring no dejará de facturar, puede enviar alertas de manera oportuna (con un retraso de solo 3 a 4 minutos). La estructura de creación de prototipos / nombres de Google Cloud tiene una cierta curva de aprendizaje, pero después de invertir tiempo y esfuerzo, los paneles, las alertas y los indicadores realmente pueden facilitarnos las cosas.
Estos indicadores se conservarán durante 90 días. Desafortunadamente, nuestros indicadores en este evento han expirado; de lo contrario, me complacería mostrárselos en este artículo.
8 Buenas noticias: ¡No cerramos!
Pero es muy colgado, demasiado colgado.
Después de leer detenidamente el informe sobre este incidente, después de una serie de consultas, debates e investigaciones internas, ¡Google directamente perdonó nuestra factura!
¡Gracias Google!
Hemos recuperado nuestra vitalidad y podemos seguir desarrollando Announce. Y esta vez, tenemos una mejor perspectiva, una arquitectura más sólida e ideas de implementación más seguras.
Google es la empresa de tecnología que más admiro, no solo porque es una gran empresa para la que vale la pena trabajar, sino también porque tiene una fuerte empatía. Google proporciona herramientas que se adaptan a los apetitos de los desarrolladores, concede gran importancia a la calidad de los documentos (en la mayoría de los casos) y está en constante evolución. (Nota del autor: Estos son solo mis sentimientos personales como desarrollador de software independiente, y de ninguna manera es un texto suave o un halago deliberado).
9 ¿Qué pasa después?
Después de experimentar este incidente, pasamos varios meses aprendiendo la arquitectura de la nube y nuestro propio sistema empresarial. Unas semanas más tarde, nuestro conocimiento ha mejorado a un nuevo nivel, por lo que comenzamos a utilizar un algoritmo mejorado para rastrear la "red completa" a través de Cloud Run.
En el análisis general posterior al hecho, decidimos abandonar la arquitectura de la versión V1 y utilizar una infraestructura más escalable para respaldar el producto.
En Announce V2, ya no creamos MVP; en su lugar, creamos una plataforma para iterar rápidamente nuevos productos y realizar pruebas integrales en un entorno seguro.
Esta experiencia realmente ralentizó nuestro ritmo ... V2 se dio a conocer oficialmente a fines de noviembre, aproximadamente 7 meses después de la fecha de lanzamiento de V1 originalmente planeada. Sin embargo, V2 es más escalable, puede hacer un uso más completo de los recursos de la nube y también tiene un mejor nivel de optimización.
También hemos podido implementarlo en todas las plataformas, no solo en la plataforma web.
Más importante aún, usamos la misma plataforma para construir el segundo producto Point Address. Estos dos productos no solo tienen una escalabilidad excelente, una arquitectura y una eficiencia excelentes, sino que también están construidos sobre la misma plataforma. Esto nos permite convertir rápidamente la inspiración empresarial en realidad e introducirla inmediatamente en productos reales.
Enlace original:
https://blog.tomilkieway.com/72k-1/
https://blog.tomilkieway.com/72k-2/