¿Cuál es la configuración correcta de Cloudwatch/Autoscale para picos de tráfico extremadamente cortos en Amazon Web Services?

Question

Tengo un sitio que se ejecuta en Amazon planta de frijoles elástica con el siguiente patrón de tráfico:

• ~ 50 usuarios simultáneos con normalidad.
• ~ 2000 usuarios simultáneos durante 1/2 minuto cuando se realiza una publicación en la página de Facebook.

Los servicios web de Amazon dicen ser capaces de escalar rápidamente a desafíos como este, pero la configuración "Mayor que x durante más de 1 minuto" de cloudwatch no parece ser lo suficientemente rápida para este patrón de tráfico.

Por lo general, en cuestión de segundos todas las instancias de ec2 se bloquean, lo que elimina todas las métricas del reloj en la nube y todo el sitio está inactivo durante 4/6 minutos. Hasta ahora, aún no he encontrado una configuración que funcione para este senario.

Aquí está la gráfica de un evento más pequeño que también mató el sitio:

Answer 1

La sugerencia de AWS fue la siguiente:

Siempre estamos trabajando para hacer que nuestros sistemas de mayor capacidad de respuesta, pero es desafiando a la provisión de servidores virtuales de forma automática con un tiempo de respuesta de unos pocos segundos como su el caso de uso parece requerir. Tal vez hay una solución que responde más rápidamente o que es más resistente cuando las solicitudes comienzan a aumentar.

¿Ha observado si el sitio funciona mejor si utiliza un tipo de instancia más grande o un número mayor de instancias en estado estable? Ese puede ser un método para ser resistente a los rápidos incrementos en las solicitudes entrantes . Aunque reconozco que puede no ser el más rentable, , puede encontrar que se trata de una solución rápida.

Otro enfoque puede ser ajustar su alarma para usar un umbral o una métrica que refleje (o prediga) el aumento de su demanda antes. Por ejemplo, es posible que vea un mejor rendimiento si establece su alarma en agregue instancias después de superar los 75 o 100 usuarios. Puede que ya sea haciendo esto.Aparte de eso, su caso de uso puede tener otro indicador que predice un aumento de la demanda, por ejemplo, una publicación en su página de Facebook puede preceder a un aumento de solicitud significativo en varios segundos o incluso un minuto. El uso de métricas personalizadas de CloudWatch para monitorear ese valor y luego establecer una alarma en Autoescala en él también puede ser una solución potencial de .

Así que creo que la mejor respuesta es ejecutar más instancias con menos tráfico y usar métricas personalizadas para predecir el tráfico desde una fuente externa. Voy a intentar, por ejemplo, monitorear las publicaciones de Facebook y Twitter con enlaces al sitio y escalar de inmediato.

Answer 2

Son estos enlaces publicados predecible? Si es así, puede usar Scaling by Schedule o como alternativa puede cambiar el valor de CAPACIDAD DESEADA del Grupo de escalamiento automático o incluso activar as-execute-policy para escalar horizontalmente antes de que se publique su enlace.

¿Sabe que puede tener múltiples políticas de escala en un grupo? Por lo tanto, es posible que tenga una política especial de escalamiento automático para su caso, algo así como SCALE_OUT_HIGH que agrega, por ejemplo, 10 instancias más a la vez. Eche un vistazo al comando as-put-scaling-policy.

Además, debe verificar su código y encontrar cuellos de botella.

¿Qué HTTPD usas? Considere la posibilidad de cambiar a Nginx ya que es mucho más rápido y consume menos software que Apache. Trate de usar Memcache ... NoSQL como Redis para leer y escribir bien también es una buena opción.