¿Qué especificaciones de AWS serían adecuadas para un sitio web de 4 mil + hit / día?

Bueno, hagamos un poco de matemática. Voy a hacer algunas suposiciones basadas en soluciones que he diseñado. YMMV.

Si tenemos solicitudes de página de 4M, supongo que estas son solicitudes de página y no activos estáticos, distribuidas uniformemente a lo largo del día resulta ser ~ 166K / hora o ~ 2800 / minuto. Ahora, por supuesto, no es así como funciona el tráfico real. La regla general que uso es que el pico es entre 5 y 7 veces la media, por lo que queremos poder manejar en el extremo superior ~ 19,500 solicitudes / minuto. Barnizar en un hardware básico como un m4.large puede manejar fácilmente ~ 2,000 solicitudes concurrentes a ~ 300ms / solicitud con un rendimiento total de ~ 6,000 solicitudes / segundo. Entonces, suponiendo una tasa de aciertos de caché del 100%, estás viendo un solo servidor.

Pero, por supuesto, no es probable que obtenga una tasa de aciertos de caché del 100%. En un sistema típico, nuestro promedio tiende a estar en los 90 bajos, así que digamos 90%. Eso nos tiene manejando apenas 2.000 solicitudes / segundo con nuestro backend. La última vez que hice pruebas de carga en profundidad fue una generación más o menos en el hardware EC2, por lo que estos números no reflejan necesariamente la capacidad actual. Pero en una gran instalación de Drupal en una gran instancia, estaba manejando ráfagas de hasta 100 solicitudes / segundo. Carga compuesta durante esto, así que eventualmente se volvió insostenible. El tráfico sostenido de alrededor de 25 solicitudes por segundo podría manejarse indefinidamente. Por supuesto, eso probablemente se escala de forma lineal con el tamaño de la instancia, al menos hasta cierto punto.

Pero en el extremo superior con una gran plataforma CMS, estás viendo 40 servidores de aplicaciones. Agregue un par de servidores para manejar Varnish (ya sabe, por redundancia) y luego otro par para Redis. Por lo tanto, redondee hasta 45 m4.grandes que está buscando a solo $ 5 / hora de los costos de EC2 en el pico. Para mantenerse al día con esa cantidad de servidores de aplicaciones, está buscando una cantidad de servidores de bases de datos. Digamos que cada r3.2xlarge puede manejar 5 servidores de aplicaciones que está buscando a $ 9.28 en costos de RDS. Agregue ELB, S3 y EBS y el tráfico y está buscando en algún lugar, estadio, alrededor de $ 16 – $ 17 / hora en el pico. Sin ningún tipo de escalado automático que le coloque alrededor de $ 13k / mes de costos de alojamiento.

Esto contiene muchos supuestos. Los grandes son:

• La mayor parte del tráfico es anónimo.
• Puede mantener sus tasas de caché al 90% +
• La relación entre el servidor de aplicaciones y el servidor de bases de datos es de 5 a 1, básicamente lectura pesada con buenos índices y almacenamiento en caché
• La relación pico a media es de 7 o menos

Sin saber más sobre el diseño del sitio, es difícil ofrecer algo más que sugerencias muy generalizadas sobre las especificaciones de infraestructura.

¿Es el sitio simple, con contenido principalmente estático y pequeñas cantidades de medios? Si ese es el caso, probablemente podría salirse con un par de nodos que alojan Nginx, ejecutándose detrás de un ELB.

Sin embargo, si su sitio es más dinámico, sirve muchos medios, retiene cualquier tipo de datos de usuario o depende de API externas, las cosas se vuelven mucho más complicadas. Cada pieza de la infraestructura de back-end es un posible cuello de botella. No importará si tiene 50 de las instancias de cómputo más grandes si su única base de datos RDS se está ahogando. ¿Sirviendo muchas imágenes? Es posible que desee considerar el uso de Cloudfront. ¿Se extienden esos 4 millones de visitas al día de manera uniforme durante 24 horas, o va a obtener el 50% de eso en picos durante las horas pico? Si es así, deberá utilizar el escalado automático.

Honestamente, solo estoy cubriendo una pequeña parte de las muchas consideraciones diferentes que tendrían en cuenta al diseñar la infraestructura para un sitio de tráfico relativamente alto.

Saber un poco más sobre sus planes permitiría una respuesta mucho más directa y específica.

Un golpe puede significar muchas cosas.

Puede ser una solicitud de recursos (solicitando una hoja de estilo, JavaScript, imagen, página, fuente, etc.).

Puede ser una vista de página (solicitando una página que luego puede iniciar solicitudes de recursos).

Puede ser una sesión (un visitante que solicita varias páginas que luego pueden iniciar solicitudes de recursos).

Por lo tanto, comprender su definición de éxito nos ayudaría bastante. Una vez que establezca su definición de éxito, vea la respuesta de Bill.

Dirijo un sitio que recibe alrededor de 1 millón de visitas por mes. Estoy usando 8 CPU en una instancia de C4 con aproximadamente 100 gb de espacio. Estoy usando nginx en lugar de apache para la velocidad, y nunca he tenido ningún problema.

Te recomendaría que busques en una instancia de C4 con 8 CPU ejecutándose en nginx.