Cómo hice para que una pequeña instancia de T2.Nano EC2 maneje miles de visitantes mensuales usando CloudFront

Advertencia! – La razón por la que escribí este post es porque tenía curiosidad. También quería demostrar cómo CloudFront reduce los tiempos de respuesta de un sitio web y cómo el resultado de una modesta instancia podría mejorarse utilizando CloudFront. Si está ejecutando un sitio importante de alto tráfico, le recomiendo implementar las mejores prácticas para el rendimiento y la disponibilidad, como el uso de tipos de instancia más grandes, ELB, Autoscaling, un RDSinstance dedicado y réplicas de lectura (y también un poco de ayuda de CloudFront).

Ahora vamos a empezar….

En diciembre de 2015, AWS anunció la disponibilidad de un nuevo tipo de instancia EC2: thet2.nano. Con 512MB de memoria, 1vCPU y un costo de menos de $5/mes, este tipo de instancia es el más pequeño y barato de la familia EC2 – incluso más barato si se observan las tarifas reservadas en la región este de los Estados Unidos ($3/mes por 1 año y $2/mes por 3 años).

Menos de 5 dólares al mes es fantástico, pero… ¿puede ejecutar una carga de trabajo decente utilizando el tipo de instancia EC2 más pequeño? Gracias a AWS CloudFront, la respuesta es sí!

AWS CloudFront es una red de entrega de contenido que almacena el contenido de su sitio en múltiples ubicaciones alrededor del mundo. Si utiliza CloudFront, los visitantes de su sitio acceden al contenido que está almacenado en caché en una ubicación cercana a ellos, en lugar de llegar a su propio servidor web. Esto resulta en tiempos de carga más rápidos para sus clientes y una menor carga en su servidor. Como la mayoría de los AWServices, CloudFront está diseñado para manejar un tráfico enorme, por lo que no tiene que preocuparse por la escala.

Configuración

WordPress

Para este ejemplo, configuré un blog de WordPress en una instancia t2.nano con un volumen EBS (SSD) de 8GB. Para hacer la prueba más realista, también cargué 700 entradas de blog en mi instalación de WordPress usando el pluginDemo Data Creator. También tengo instalado un agente New Relic, que utilizo para visualizar métricas que no están disponibles en CloudWatch, como el consumo de memoria o el consumo de recursos a nivel de proceso.

CloudFront

CloudFront soporta dos tipos de distribuciones: 1) Web (archivos estáticos o dinámicos que utilizan HTTP y HTTPS) y 2) RTMP (para la transmisión de archivos de audio o vídeo). Como voy a crear un blog de WordPress, he creado una distribución Web.

Configuré el valor mínimo de TTL (tiempo de vida) en 900 segundos, lo que significa que CloudFront guardará en caché las páginas del sitio durante al menos 15 minutos antes de que CloudFront busque nuevo contenido en la instancia de thet2.nano. Puede jugar con este valor, sólo recuerde que las actualizaciones frecuentes producen más visitas al servidor. Valores más grandes dan como resultado un contenido menos “fresco”. También puse “Compress Objects Automatically” a “Yes”, para aprovechar esta característica que reduce el uso de ancho de banda entre clientes y distribuciones CloudFront. Configuré theOrigin al DNS público de mi instancia t2.nano.

JMeter

Hice pruebas de rendimiento usando Apache JMeter. JMeter es una herramienta de prueba de rendimiento de código abierto que simula usuarios concurrentes, envía solicitudes a un punto finalHTTP predefinido (su sitio) y registra los resultados. Para este post, ejecuté dos pruebas de rendimiento: una enviando peticiones a la instancia t2.nano directamente y otra enviando peticiones a la distribución CloudFront. Utilicé como entrada un archivo.csv con las URLs de los 700 posts de blog que había cargado anteriormente en mi instalación de WordPress ejecutándose en el archivo t2.nano.

La mejor práctica en las pruebas de rendimiento es generar siempre carga de tráfico en un servidor separado del que se está probando. Esto asegura que los resultados de la prueba no se vean afectados por el consumo esperado de recursos en el servidor del generador de carga. Por lo tanto, configuré JMeter en una instancia EC2 separada que funcionaba en la región de AWS Este de los Estados Unidos. Y como no me gusta gastar $$ a menos que tenga que hacerlo, ¡instalé JMeter en un t2.nano!

Utilicé el agente de AWS Logs en mi servidor JMeter y configuré los filtros métricos de AWS CloudWatch Logs para medir los resultados de mis pruebas de carga.

Pruebas

1) Pulse el botón t2.nano (prueba de referencia)

La intención de esta prueba es ver qué tipo de tráfico puede manejar una instancia de t2.nano de forma fiable sin usar CloudFront. Para esta prueba, corrí 10 usuarios concurrentes (JMeterthreads) contra el blog de WordPress alojado en el t2.nano. Configuré un tiempo de reflexión aleatorio de 30 a 45 segundos entre peticiones. En la vida real, el tiempo de pensar sería el tiempo que austeridad pasa leyendo una entrada de blog antes de navegar a una entrada diferente. Esto solo es un tráfico bastante decente que nuestro amigo el T2.nano puede manejar. Dependiendo de cuánto tiempo se queden sus usuarios y cuántos regresen, una constante de 10 usuarios simultáneos puede convertirse en miles de visitantes únicos en un solo mes.

Una cosa que me gusta de la t2.nano es que su modesta memoria RAM de 512MB es suficiente para mantener un blog de aWordPress con poco tráfico. Antes de empezar la prueba, el consumo de memoria era de alrededor del 50%, una vez que empecé la prueba con 10 usuarios simultáneos, el consumo de memoria alcanzó entre el 57% y el 60%, lo que considero un rango seguro que permitiría algunos picos intermitentes.

La CPU no superó el 6% durante esta prueba:

Una cosa a tener en cuenta son los créditos de CPU, supongamos que empezamos con el saldo inicial de 30 créditos de CPU (el saldo de crédito que obtienen los nanos t2 en el momento del lanzamiento). Con un consumo constante de CPU del 6%, cada minuto consumiríamos 0,06 créditos de CPU y ganaríamos 0,05 créditos de CPU. A este ritmo, se necesitarían 3000 minutos, o 50 horas, para agotar 30 créditos de CPU. cuando esto ocurra, el uso de la CPU t2.nano se limitará al 5%, lo que probablemente será suficiente para manejar a 10 usuarios. Sin créditos de CPU, el rendimiento de la CPU no aumentará para manejar picos en el uso, lo que resultaría en tiempos de respuesta más largos y posiblemente en fallas si el tráfico va más allá de los 10 usuarios simultáneos durante un período de tiempo prolongado.

Para más información sobre los créditos de CPU, también puede leer este artículo.

New Relic me da una visión útil del consumo de recursos por proceso. En este ejemplo podemos ver que la mayor parte del consumo de recursos tiene lugar en el servidor web Apache:

10 usuarios concurrentes con un tiempo de pensamiento aleatorio de 30-45 segundos resultaron en ~0.3 peticiones por segundo, o ~18 peticiones por minuto.

Y ahora mi sección favorita, los tiempos de respuesta:

El tiempo medio de respuesta es de

Como usé CloudWatch para agregar mis resultados de JMeter, no tengo P90 o P99metrics en esta prueba (las matemáticas métricas son definitivamente una característica que falta en CloudWatch). Para este ejemplo, los valores medios son suficientemente buenos.

2) Haga clic en la distribución CloudFront

Para mi segunda prueba, corrí 100 usuarios concurrentes (hilos JMeter) con un tiempo de reflexión aleatorio de 30-45 segundos entre peticiones y apunté a la distribución de CloudFront en su lugar. cuando CloudFront recibe una petición entrante de un usuario web, primero intenta encontrar la página web en su caché; si no puede encontrarla, entonces obtiene el contenido desde el servidor de origen (en este caso el t2.nano). De esta manera, la carga en mi servidor WordPress se reduce significativamente. Además, CloudFront almacena copias de estas páginas en caché en múltiples ubicaciones de todo el mundo. Esto significa que los visitantes de América del Sur tendrán acceso a una copia de mi contenido almacenado cerca de América del Sur (¡y tendrán mejores tiempos de carga en sus navegadores!) en lugar de ir a mi servidor WordPress, que está alojado en Virginia del Norte.

Al principio de la prueba, no habrá páginas en caché en CloudFront. Durante este período de ~15 minutos, la mayoría de las peticiones fueron enviadas a la instancia t2.nano. El consumo de memoria en thet2.nano comenzó en un 20% y se estabilizó en un 50%. Esto supone una mejora con respecto al consumo del 57%-60% que experimentó la instancia en la prueba de los 10 usuarios concurrentes.

Ahora echemos un vistazo al uso de la CPU en el t2.nano. Hay un aumento en la CPU durante el calentamiento de la caché de CloudFront, seguido de una disminución, cuando las peticiones eran servidas principalmente por CloudFront. La parte importante aquí es que los créditos de CPU no se agotarán con el tiempo, ya que el uso está por debajo de la línea de base del 5% que está disponible para la instancia t2.nano. De la misma manera que los créditos de CPU funcionan, el uso por encima del 5% resulta en un agotamiento del crédito; el uso por debajo del 5% resulta en una acumulación increíble. En otras palabras, se trata de un uso sostenible de la CPU.

Y ahora las peticiones por minuto, que aumentaron proporcionalmente en comparación con la prueba de 10 usuarios.

Finalmente, los tiempos de respuesta. Excepto el período de rampa, los tiempos de respuesta no excedieron los 50 ms y permanecieron en ~20ms:

Al introducir CloudFront, aumenté el número de usuarios concurrentes de 10x a 100 con un consumo de CPU sostenible de menos del 5% (lo que no agotará los créditos de CPU de mi instancia) y también ofrece una experiencia mucho mejor a los visitantes al reducir significativamente los tiempos de respuesta (en este experimento, de ~160ms a ~20ms).

4. Conclusiones

  • El t2.nano es una instancia muy útil capaz de ejecutar cargas de trabajo como un blog de bajo tráficoWordPress o un generador de carga JMeter. Son buenos ejemplos para hacer entrenamiento y algo de desarrollo y pruebas (dependiendo de las aplicaciones que estés desarrollando o probando).
  • No recomendaría un t2.nano para ejecutar un blog importante que sirve a cientos de usuarios concurrentes, pero consideraría usar uno para impulsar un sitio interno de bajo tráfico o no crítico. En esta prueba, el t2.nano alonecould puede manejar de forma fiable 10 usuarios simultáneos con un tiempo de reflexión de 30-45 segundos entre peticiones.
  • Continuaré usando instancias t2.nano para ejecutar pruebas, ejecutar scripts operativos o como generadores de carga JMeter (o Locust).
  • Es posible servir a miles de visitantes al mes usando una instancia t2.nano EC2 y una distribución aCloudFront. Tenga en cuenta que debido a la configuración de TTL, habrá períodos de tiempo en los que CloudFront solicitará el contenido desde el origen. El origen debe ser capaz de manejar el volumen de peticiones entrantes de CloudFront durante estas ventanas.
  • Para una prueba de rendimiento que utiliza CloudFront, alto volumen y un tipo de instancia pequeño, asigne tiempo suficiente de arranque antes de alcanzar el número completo de usuarios concurrentes. De lo contrario CloudFront no tendrá todo el contenido en su caché durante un período inicial de alto tráfico y la instancia de prueba se verá desbordada. Para esta prueba, configuré el tiempo de rampa a 15 minutos.
  • No recomiendo usar un t2.nano para alimentar un sitio WordPress crítico y de alto tráfico. En tal caso, Ireecomendamos usar una combinación de tipos de instancia grandes, ELB, Autoscaling y RDS con réplicas leídas.
  • Es genial tener un tipo de instancia útil a $5/mes (bajo demanda), $3/mes(1 año reservado) o $2/mes(3 años reservados)!

Leave a Comment