AWS Free tier -off && t3a -swapon
Índice
Adiós a la capa gratuita de AWS
¡Llegó el día! El día en que finalizó la capa gratuita de mi cuenta de AWS, donde está alojada esta web/blog, y algún que otro bot de Telegram u otro experimento.
Mi presupuesto máximo estaría rondando los 4,5€ o menos, aproximadamente lo que pagaría por un plan churretoso básico de hosting compartido, sin acceso a la máquina, y con un limitado cpanel/plesk para administrar. Evidentemente eso es imposible manteniendo la “t2.micro” que sale a 9.20 USD (Solo la máquina, sin contar demás gastos) con la que disfrutaba gratis de 1 vCPUs y 1 GiB de memoria.
Hace tiempo que realicé pequeñas mejoras en la configuración de mariaDB y de PHP (pm=ondemand, pm.max_children, etc…) que redujeron el consumo de memoria en un 50% y que sobre todo, dieron fin a los “OOM” que experimentaba al principio de los días en la t2.micro. Se puede observar en la siguiente captura, el momento en el que apliqué dichos cambios. Estoy seguro en que no habrá problema alguno en mudarnos a la instancia más buena, bonita y barata que ofrezca AWS.
Migrando de t2.micro a t3a.nano
La instancia que más me seduce en estos momentos es la “t3a.nano” con 2vCPUs y 0,5 GiB de memoria. De la familia de las T3 pero más baratas aún al usar los AMD EPYC 7000 2.5 GHz en vez de la solución Intel. Vendría a costar 3.72 USD mensualmente bajo demanda, pero podríamos llegar a pagar 2.34 USD realizando una reserva de instancia de un año, o 1.61 USD ampliando esta reserva a tres años. No está nada mal, por lo que, ¡A la t3a del tirón!
La migración de la t2 a la t3a no tiene mayor dificultad, tras comprobar que tenemos ENA (Adaptador de red mejorado) y /etc/fstab configurado con UUIDs en vez de con rutas /dev/…
Al momento de comprobar si el entorno es estable o no, los tiempos de respuestas son similares a los de antes, y todo está cargando según lo esperado. Se está consumiendo la mitad de la memoria disponible y no hay errores aparentes.
OOM
Pero lamentablemente, en cuanto iniciamos un proceso pesado, como pueda ser un análisis de seguridad de “wordfence” o un análisis “Yoast SEO” la cosa termina mal; un “OOM” que nos deja “frita” la máquina.
¿Por qué un pico de memoria tiene que ser tan dramático? No me importaría notar un poco de lentitud en la web mientras se ejecute un proceso pesado, normal, soy un tieso , estoy utilizando la instancia más barata… pero de ahí a un “Time Out..” ¡No es justo! Esto con swap no pasaba…
SWAP en AWS
Las AMIs de AWS vienen por defecto con swap (Área de intercambio) desactivado, y en alguna ocasión he leído que “swap no es una buena idea en entornos cloud”; “si necesitas más memoria, ve a por una instancia más grande” Hay varios hilos en reddit donde se discute sobre los problemas que podrías tener con los IOPS de disco, es decir con el número de operaciones de lectura y escritura realizadas en el disco por segundo.
Pero no he visto en ningún documento de AWS, que se desaconseje directamente utilizar swap bajo ningún concepto. Además encuentro este procedimiento oficial: https://aws.amazon.com/es/premiumsupport/knowledge-center/ec2-memory-partition-hard-drive/ el cual no indica que sea “una mala idea”. Solo hay una nota, con una recomendación:
“Se recomienda crear espacio de intercambio solo en volúmenes de almacenamiento de instancias de almacenamiento efímero.”
Claro, en algunas instancias se entrega un espacio efímero del Almacén de instancias. Un lugar ideal donde podríamos alojar nuestro SWAP en partición.
“El almacén de instancias ofrece un almacenamiento de nivel de bloques temporal para la instancia. Este almacenamiento se encuentra en discos que están conectados físicamente al equipo host. El almacén de instancias es perfecto para el almacenamiento temporal de información que cambia con frecuencia”
Pero estamos en una t3a, y no disponemos de este almacén. Por lo que ¿Por qué no utilizamos un EBS gp2 (SSD de uso general) de 1GiB como SWAP?
El coste un 1GiB EBS gp2 es de 0,11 USD. Y como se indica en https://aws.amazon.com/es/ebs/pricing/
Las operaciones de E/S están incluidas en el precio de los volúmenes, por lo que solo deberá pagar cada GB de almacenamiento que aprovisione.
Es decir, que lo peor que podría pasar, es que el rendimiento no fuera óptimo, pero en ningún caso se cobraría más de 0,11 USD por mucho que aumentaran las operaciones E/S.
Me parece mucho peor no tener SWAP y que por un pico de memoria la fiesta se termine por un OOM, por lo que … ¡Vamos allá!
Aprovisiono 1 GiB gp2:
Tras crearlo y enchufarlo a la máquina, compruebo que es visible:
lsblk
Le doy formato y configuro el disco como SWAP con:
mkswap /dev/nvme3n1
Habilito SWAP:
swapon /dev/nvme3n1
Compruebo que está activo con:
sudo swapon --show
Para hacer esto persistente, lo añado al /etc/fstab pero antes, averiguo el UUID con lsblk -f
Añadiéndolo al /etc/fstab
Ahora probamos a lanzar procesos pesados en WordPress y observamos que los tiempos de respuesta son normales, y sobre todo, la t3a se recupera de cualquier pico de memoria.
¿Y los IOPS?
He monitorizado la métrica “Burst Balance” del EBS utilizado para SWAP y se mantiene estable en 100 al igual que los otros discos destinados para «/»,“mariaDB” o “/var/www” por lo que parece que no hay ningún impacto en los IOPS por ahora.
Seguramente esto no entre dentro de las mejores prácticas para WordPress en AWS, no entraré ahí, pero en mi caso ha solucionado los OOM que estaba experimentando en la t3a cuando realizaba ciertas tareas.
¿Lo más recomendable hubiera sido saltar al siguiente tamaño de t3a, donde tendríamos 1 GiB, por 7.45USD (Bajo demanda) solo la máquina, sin EBS?
En mi caso, solo me ha costado 0,11USD + el precio de la t3a, con reserva de un año: 2,34USD. Si le sumamos los demás 11GiB en EBS que ya tenía, nos da un total de 3.55 USD. Justo lo que cuesta el plan básico de Amazon Lightsail, pero éste tiene 1 vCPUs menos (seguramente esté basado en t2.micro) y eso sí, 20GB de SSD, y 1TB de transferencia.
En cualquier caso, si estuviera usando Lightsail, todo lo comentado en este post seguiría siendo igual de válido. Aunque prefiero mantenerme en ec2, que es más divertido.
¿Qué opinas tú? ¿Es una buena, o una mala idea activar SWAP en entornos Cloud? ¿Me acabas de perder definitivamente el respeto por usar un EBS como SWAP? ¡Déjalo en los comentarios por favor!
ACTUALIZO: ¡Bitnami ya lo hizo!
Tras publicar esta entrada descubro que las instancias (micro) que vienen con Ubuntu + WordPress pre-instalado por bitnami ya utilizan esta técnica.
No me percaté antes antes porque siempre he utilizado «Amazon Linux 2», pero si observamos unas de estas AMIs veremos lo siguiente:
(Que por cierto, no están tan optimizadas, pues están utilizando bastante memoria)
Tiene swap configurado en fichero. Este es el script que utiliza bitnami para generarlo:
Ese fichero SWAP, estará en el disco raíz, que generalmente será un EBS gp2, al igual que el que yo aprovisioné para el SWAP en partición.
Viendo que el balance de IOPs permanece estable, y que es la práctica habitual en instancias micro WordPress bitnami, creo que me siento menos mal de utilizar SWAP en AWS.