¿Qué tipo de servidor necesito para manejar 10 millones de solicitudes y consultas mySQL al día? [cerrado]

Soy un novato en la administración de servidores y estoy buscando un poderoso servicio de alojamiento para alojar mi nuevo sitio web. Este sitio web es básicamente un back-end de un juego móvil en línea y:

• manejar hasta 10 millones de solicitudes HTTPS y consultas mySQL por día
• almacenar hasta 2000 GB de archivo en el disco duro
• transfiera probablemente 5000 GB de datos por mes
• Se ejecuta en PHP y MySQL
• tener 10 millones de registros en la base de datos mySQL, para cada registro hay 5-10 campos, alrededor de 100 bytes cada uno

Realmente no sé qué tipo de servidor necesito para manejar estos requisitos, mi pregunta es:

1. ¿Qué CPU / RAM necesito para un servidor dedicado o VPS?
2. ¿Qué empresas de hosting pueden ofrecer este tipo de servidor dedicado o VPS?
3. ¿Qué pasa con la computación en la nube? He investigado Amazon EC2 pero me parece complicado. Y me puse en contacto con Rackspace, pero extrañamente me dijeron que Cloudsites no es adecuado para mis requisitos. Me pregunto si hay otra empresa de alojamiento en la nube.
4. ¿Algún otro método alternativo?

¿Un escritorio barato?

Entremos en las matemáticas.

• 10 millones de solicitudes.
• Eso se desglosa en 416667 solicitudes por hora.
• Eso se descompone en 6944 solicitudes por minuto.
• Eso se desglosa en 116 solicitudes por segundo.

Duplique eso (carga máxima) y hablamos de una carga que un escritorio de cuatro núcleos barato puede manejar SI las consultas son lo suficientemente simples, y realmente no dice cuán complejas son.

• 5000 GB por mes es trivial; en serio, se aplica la misma matemática.
• Eso se descompone en 208 GB / día
• Eso se descompone en 8 GB / hora
• Eso se descompone en 148 MB / minuto

• Eso se descompone en 2,5MB / segundo, 25Mbit. Doble para el pico: 50Mbit, trivial para cualquier centro de alojamiento. Sin embargo, te costará.

• Almacene 2000 GB en el disco duro. ¿Eso es discos duros de 2x2000 GB en un RAID? A menos que sea para la base de datos, tiene una gran cantidad de E / S complejas, entonces es cualquier cosa entre una docena de discos y MUCHOS discos SAS de 73GB a 15,000 RPM en un RAID 10 (alrededor de 60 discos) para obtener la E / S necesaria. la pregunta no puede responderse sin MUCHA más información sobre los patrones de acceso a datos.

• Ejecuta PHP y MySQL: mi teléfono móvil puede hacer eso;) La pregunta es qué tan compleja es la aplicación. MySQL PUEDE o NO PUEDE ser una solución aceptable aquí, por cierto l. - eso requeriría más pruebas. Hay una razón por la que algunas personas todavía usan otras bases de datos comerciales más grandes.

• ¿Qué CPU / RAM necesito para un servidor dedicado o VPS?

Uno diría que eso depende de la lógica (cuántos cálculos en la parte de PHP, inteligencia o falta de programadores y muchas otras preguntas.

En serio, esta es una configuración no trivial. Haz que algunos especialistas lo analicen.

Básicamente necesitas bajar y hacer tu tarea. Muchas de las preguntas no tienen respuesta de esta forma. Especialmente porque parece que no te importan tus datos ...

• Copias de seguridad?
• ¿Sin plan de contingencia? Quiero decir, los servidores mueren, ¿estás de acuerdo con que el sitio esté inactivo durante días mientras se configura el reemplazo?

Para agregar algo de mi experiencia que puede ser útil:

• Como TomTom mencionó, es difícil / imposible dar especificaciones exactas, ya que muchas de ellas dependen del diseño y la implementación de su aplicación. El hardware que me da a mí u otra persona X solicitudes / segundo puede no funcionar bien para usted.
• Tengo un servidor MySQL dedicado de gama baja (Intel Core2 Duo E4600 2.40 GHz, 4 GB de RAM) que atiende un promedio de 100 solicitudes / segundo (cerca de 10 millones / día) con una tasa de inactividad de la CPU del 90%. Además de algunos ajustes básicos a la configuración, funciona bien debido a que se lee mucho (+ 95% de lecturas) y el conjunto de registros activo se contiene fácilmente en la memoria. Tenga en cuenta el tamaño de su conjunto activo al elegir la cantidad de RAM del servidor, ya que puede hacer una gran diferencia. Asegúrese de comprender la diferencia entre el tamaño de su base de datos y el tamaño del conjunto de registros activo. Por ejemplo, mis bases de datos suman un total de ~ 7 GB, pero el conjunto activo probablemente solo sea de unos 100 MB.
• Del mismo modo, tengo un servidor Apache de especificaciones similares que atiende ~ 1 millón de solicitudes por día que tiene una tasa de inactividad de CPU promedio de ~ 95%. Las solicitudes son una mezcla de consultas AJAX de datos de mapas muy simples y páginas de MediaWiki más complejas.
• La evaluación comparativa de su aplicación específica es un buen comienzo para tratar de determinar exactamente lo que necesita. No desea subestimar, pero sobreestimar puede ser tan malo debido a la posible pérdida de dinero y esfuerzo.
• Considere no solo la tasa de solicitud promedio sino también la tasa máxima. No desea un servidor que apenas pueda manejar la tasa promedio ya que las tasas de solicitud pueden variar significativamente durante el día, la semana y el mes. Por ejemplo, puedo obtener 3-4 veces el tráfico durante las horas pico los fines de semana como lo hago en las horas mínimas durante la semana. Cuánto varía dependerá de su aplicación y base de usuarios.
• ¿Puede almacenar en caché cualquiera de sus solicitudes de base de datos / HTTP? Esto puede aumentar drásticamente su tasa de solicitud con hardware más barato / menos dependiendo de cuánto pueda almacenar en caché.
• Considere sus opciones de escala para el crecimiento futuro ahora en lugar de más adelante. Una buena opción puede ser usar una escala horizontal que le permita comenzar con un hardware mínimo y crecer fácilmente según sea necesario.
• El diseño adecuado de su capa de aplicación puede tener un gran efecto en su rendimiento final. Una consulta SQL incorrecta en una tabla sin índices puede ser de orden de magnitud más lenta que una diseñada correctamente. Del mismo modo, los servidores Apache / MySQL mal configurados pueden ser muchas veces más lentos que cuando se configuran correctamente.