¿Cuándo comenzar a pensar en la escalabilidad? [cerrado]

Estoy teniendo un problema divertido pero también terrible. Estoy a punto de lanzar una nueva aplicación (iPhone). Es un juego multijugador por turnos que se ejecuta en mi propio backend personalizado. Pero tengo miedo de lanzar.

Por alguna razón, creo que podría convertirse en algo grande y que su popularidad matará a mi pobre servidor solitario + base de datos MySQL.

Por un lado, estoy pensando que si está creciendo, será mejor que esté preparado y tenga una infraestructura escalable ya en su lugar.

Por otro lado, solo tengo ganas de salir al mundo y ver qué pasa.

A menudo leo cosas como "la optimización prematura es la raíz de todo mal" o personas que dicen que deberías construir tu juego asesino ahora, con las herramientas a mano, y preocuparte por otras cosas como la escalabilidad más adelante.

Me encantaría escuchar algunas opiniones sobre esto de expertos o personas con experiencia en esto. ¡Gracias!

En realidad es una elección bastante fácil.

En este momento, no tiene usuarios, y la escalabilidad no es un problema.

Idealmente, desea llegar al punto donde tiene millones de usuarios, y la escalabilidad se convierte en un problema.

En este momento, no tienes un problema de escalabilidad; tienes un problema de número de usuarios. Si trabaja en el problema de escalabilidad, no solucionará el problema de la cantidad de usuarios, lo que significa que habrá resuelto un problema que aún no tiene, y no habrá resuelto el problema que sí tiene. El resultado más probable es que su producto no lo logre, y todo su trabajo será en vano.

Si trabaja en el problema del número de usuarios, resolverá un problema que tenga en este momento y luego podrá concentrarse en el siguiente problema, que podría ser la escalabilidad.

Lo bueno de los problemas de escalabilidad es que, por definición, tenerlos generalmente significa que el negocio es bastante bueno, y esto a su vez significa que puede permitirse gastar dinero en la optimización de la escalabilidad. No pasará de cero usuarios a diez millones durante la noche, y si vigila el rendimiento del sistema, tendrá mucho tiempo para optimizar cuando llegue el momento.

Por supuesto, ayuda a tener en cuenta la escalabilidad al escribir el código que necesita en este momento, pero no tiene mucho sentido gastar docenas o incluso cientos de horas-hombre en una función de la que no sabe si Lo necesitará alguna vez, y el escenario más probable es que no lo necesite. En este momento, su principal preocupación es enviar. ¿Qué pasa después de eso? bueno, puedes preocuparte por eso más tarde.

No hay razón para optimizar hasta que sepa que se necesita optimización. ¿Cómo sabes que se necesita optimización? Tu medida.

Suponiendo que su servidor tiene algún tipo de interfaz basada en web, puede simular muchos usuarios utilizando herramientas como Apache JMeter . Aprenda a usar la herramienta, luego comience a probar su back-end. Debería poder aprender lo suficiente como para saber cuáles son los límites de su sistema. Luego puede combinar esa información con el número de usuarios que tiene y el número promedio que se ejecutan al mismo tiempo, para decidir cuándo escalar.

TL; DR Debe pensar en la escalabilidad antes de escribir la primera línea de código.

Lo primero es lo primero. Scalabilty! = Optimización

Debería pensar en la escalabilidad antes de escribir la primera línea de código. Esto no significa que construyas una infraestructura masiva si tu juego puede ser un éxito. Pensar en la escalabilidad significa:

• Asegurarse de que el código esté escrito para que se escale. He visto muchos proyectos en los que no se pensó en la necesidad de escalar. Los resultados son una base de código que no escalará sin importar el hardware que le arroje, o es prohibitivamente costoso de escalar.
• Descubre tu estrategia de escalado. Tenga un plan sobre cómo apoyar a todos los usuarios. Tiene una base de datos MySQL, ¿la va a fragmentar o agrupar u otra cosa? Estrategias como el fragmentación requieren cierta previsión porque impone requisitos a la arquitectura. Agrupamiento, menos. ¿Apoya las sesiones y cómo reaccionarán las sesiones con múltiples servidores front-end? ¿Necesitará sesiones fijas en su equilibrador de carga?
• Averigüe la estrategia de implementación. ¿Vas a usar AWS para escalar? ¿Puede aprovechar cualquier producto o servicio que le brinde un escalado dinámico fuera de la caja? Esto también implica comprender sus costos.

PERO parece que ya tienes una base de código. La pregunta ahora es cuándo comenzar a escalar. Esto depende completamente de su código.

Si su código se presta para escalar, entonces tiene la parte difícil. Puede obtener una cuenta de AWS, activar servidores según sea necesario y listo.

Si su código no escala o tiene cuellos de botella, entonces tiene trabajo que hacer. Debe identificar cuáles son sus cuellos de botella y solucionarlos. El "cuándo" es realmente difícil de saber. Algunos servicios se estancan, algunos se elevan constantemente y otros explotan. Decidir cuándo destinar recursos a algo como el escalado suele ser una función del negocio y es una evaluación de los riesgos.

En su posición , podría lanzar como "beta" y administrar las expectativas de los usuarios. De esa manera puedo sacar el producto y ver cómo se desarrolla.

Entonces, hay dos veces que debes pensar en la escalabilidad.

Primero, debe meditarse suavemente antes de escribir una sola línea de código. Esto es para garantizar que no se escriba en un agujero de escalabilidad y para asegurarse de que su código esté instrumentado para darle las medidas que necesita por segunda vez.

La segunda vez que se considera la escalabilidad es en un avance suficiente de cosas que se vuelven inaceptablemente lentas. Eso significa que necesita saber qué significa "demasiado lento" y cómo reacciona su cosa bajo carga. Si tiene un servicio cuyo controlador (probablemente qps) aumenta en un N% por mes, tiene tiempos bastante diferentes del "95% de los recursos de la máquina consumidos" si su uso de recursos es de carga al cuadrado o de carga lineal.

Con un juego por turnos, deberías tener un margen de seguridad decente (probablemente no tengas un solo mundo de juego, y si lo tienes, probablemente haya una geometría interna, lo que significa que no tienes "todos interactúan con todos cada uno a su vez "problemas").

Sin conocer los detalles, me tomaría uno o dos días para pensar dónde tiene problemas de escala y qué posibles estrategias tiene para resolverlos. Pero, esto es importante, piense. No lo hagas, solo piensa (y documenta). A menos que tenga problemas de escalabilidad que comiencen a manifestarse en unos pocos cientos de usuarios, debería tener tiempo para verificar la carga y aumentar los recursos de back-end.

Según su descripción, parece que hay dos resultados posibles:

• El juego es un fracaso y no te importa.
• El juego es exitoso y tu backend no podrá lidiar con la carga y el resultado sería un fracaso.

Hmmm

Aquí hay algunas preguntas que debe hacerse:

• ¿Cuántos usuarios puede manejar su backend actual con un rendimiento aceptable?
• ¿Tiene algún tipo de plan para limitar el impacto a los usuarios actuales si está viendo algún tipo de crecimiento rápido (por ejemplo, retirar temporalmente el juego de la tienda de aplicaciones)
• ¿Qué tan rápido puedes llegar a un mejor backend si tienes éxito?
• ¿Cuáles son las implicaciones comerciales de esperar? ¿Puedes alimentarte? Cuales son los riesgos?
• ¿Cuáles son las implicaciones comerciales de lanzar ahora dadas las respuestas a la pregunta anterior?

La respuesta a su pregunta debe hacerse evidente una vez que considere estos. Ningún experto puede decirle qué hacer sin más información, ya que cada sistema es diferente y cada negocio es diferente.

Su servidor será utilizado interactivamente por los usuarios. Esto significa que la latencia está afectando la experiencia del usuario de una manera muy profunda. La mala latencia siempre da como resultado una mala experiencia del usuario.

Al menos haga algunas pruebas de carga ad-hoc como lo describe Bryan.

Un enfoque mas serio

Realice algunas ejecuciones de simulación y descubra qué latencia afecta a su experiencia de usuario (ya sea utilizando una simulación de retardo de red o simplemente suspendida () dentro de su aplicación). Averigüe en qué latencia se está volviendo notorio, molesto e inutilizable.

Luego viene el primer paso en la dirección de la optimización. Elija un SLA para su servidor: por ejemplo, en el peor de los casos, 10% de llamadas con latencia molesta y 1% de llamadas con latencia inutilizable. Con esos límites, puede usar pruebas de carga para averiguar cuántos usuarios puede admitir su servidor.

La prueba de rendimiento pura sin medir la latencia (o al menos manualmente usando el servidor durante la prueba de carga) no es tan útil porque no le dice si los números de rendimiento medidos resultan en una experiencia de usuario soportable.

Una presentación muy bonita sobre la medición de la latencia por Gil Tene: http://www.infoq.com/presentations/latency-pitfalls

En la etapa de requisitos comerciales, que luego se utiliza para establecer una comprensión común del rendimiento de todos los elementos posteriores, tales como arquitectura, operaciones, desarrollo, control de calidad y monitoreo en producción. Si no establece una comprensión común de lo que se requiere por adelantado, tendrá que hacer que cada una de las partes de la organización haga suposiciones sobre el rendimiento (o no piense en ellas) al realizar tareas particulares a lo largo del ciclo de vida de la organización. solicitud. Esto es cierto si está involucrado en cascada, cascada corta, ágil o cualquiera que sea la metodología de desarrollo del momento que está en la lista de palabras clave de reanudar.

El rendimiento y la escalabilidad son difíciles. La funcionalidad es fácil. El código de escalado deficiente crecerá para llenar cualquier grupo de recursos que le proporcione, por lo que cambiar la burbuja de costos comprando hardware más grande solo le llevará mucho tiempo antes de que tenga que arreglar el código ineficiente o comprar aún más hardware. Dejar que esto dure en prioridad también es muy costoso. Hay decisiones de arquitectura y diseño que se toman al principio del ciclo de vida de la aplicación que pueden tener que revertirse por completo para cumplir con un requisito de llegada tardía relacionado con el rendimiento: piense en un fabricante de automóviles deportivos de alto rendimiento que tiene que cambiar de aluminio a fibra de carbono al final del ciclo de diseño para alcanzar una relación potencia / peso relacionada con el rendimiento y cómo esto afecta las herramientas, la capacitación, la construcción del automóvil, etc.

Pregunte a los arquitectos, desarrolladores y personal de operaciones de su organización cuáles son los requisitos de rendimiento para la aplicación. Si no se capturan de la empresa, no se sorprenda si recibe respuestas diferentes (o ninguna respuesta) de diferentes personas, incluso dentro del mismo grupo. Esos "supuestos" siempre vuelven para golpear a la organización en el despliegue.