De un 13% de errores en las solicitudes durante el Black Friday a cero interrupciones en el servicio: Ahorramos un 60% en costos de servidores gracias a la implementación basada en contenedores.

El año pasado, durante el Black Friday, nuestra interfaz de resolución de direcciones colapsó completamente: el 13% de las solicitudes recibió el código de error 429, y el equipo de atención al cliente recibió más de 300 quejas de los comerciantes. Tres servidores backend trabajaron sin parar durante 24 horas para superar el pico de carga. En ese momento, nuestro servicio funcionaba en dos servidores en la nube con configuraciones fijas, y cualquier ajuste de escala se hacía de forma manual. Solo cuando se pusieron en marcha nuevos instancias, el pico de tráfico había pasado.

Primero, vamos a aclarar qué es exactamente el despliegue en contenedores.

En resumen, se trata de empacar todo tu código, bibliotecas dependientes y archivos de configuración en un “contenedor” estandarizado que puede tener entre varios MB y varios cientos de MB. Esto asegura que el entorno de ejecución sea 100% consistente, sin importar en qué servidor se esté ejecutando el programa. El tamaño del primer ícono del servicio de resolución de direcciones que empacamos fue...187MBLa carga y el inicio completo no toman más de 10 segundos.

Los 3 beneficios principales que realmente hemos obtenido

• La autoescala realmente fue de gran ayuda: durante el Black Friday de este año, el tráfico aumentó tres veces, y el sistema activó automáticamente 27 instancias de contenedores. Después de que el pico de tráfico pasó, se redujeron a 3 instancias, todo sin intervención humana, lo que llevó a que la tasa de errores cayera directamente por debajo del 0.1%.
• El bug relacionado con la incompatibilidad del entorno ha desaparecido por completo: los problemas misteriosos que no ocurrían localmente, pero que se presentaban en cuanto el sistema se ponía en línea, representaban el 40% del total de nuestros errores. Desde que migramos a los contenedores, no hemos vuelto a tener ningún caso de este tipo.
• El costo de los servidores se ha reducido a la mitad: Antes, para soportar los picos de carga, teníamos que alquilar 8 servidores de alta configuración todo el año, pero su tasa de utilización promedio era solo del 15%. Ahora pagamos según el uso real, lo que nos ha ahorrado un 60% en gastos de servidores para todo el año.

No solo hay ventajas; también hemos tropezado con varios problemas de manera bastante seria.

Cuando comenzamos a usar el contenedor, para ahorrar trabajo, almacenamos todos los registros de actividad y los archivos temporales dentro de él. Como resultado, cuando una instancia se destruyó automáticamente, los registros de solicitudes de los últimos 3 días desaparecieron por completo, y nos llevó dos días enteros recuperar la información. Otra vez, incluimos demasiadas dependencias innecesarias en la imagen, lo que aumentó el tiempo de inicio de 10 segundos a 2 minutos. Cuando hubo un aumento repentino en el tráfico, no tuvimos tiempo de escalar el sistema, y casi volvimos a tener un problema.

Lo que más fácil es pasar por alto son los problemas de permisos: al principio le otorgamos al contenedor los permisos de root, y más tarde los programas de minería aprovecharon esta vulnerabilidad para consumir el 30% de los recursos del CPU. No nos dimos cuenta hasta una semana después, cuando lo detectamos a través de los sistemas de monitoreo.

Primero piensa bien si realmente deberías usarlo o no.

Si eres parte de un pequeño equipo de personas que desarrolla herramientas internas con fluctuaciones de tráfico muy bajas, y solo tienes de 1 a 2 servicios, realmente no hay necesidad de complicarse la vida; simplemente alquila un servidor, eso es lo más sencillo y conveniente.

Pero si el tráfico de tu servicio tiene grandes fluctuaciones, necesitas lanzar actualizaciones con frecuencia, los diferentes miembros del equipo desarrollan en entornos que a menudo causan problemas, o ya estás preocupado por el costo de los recursos de servidores que no están siendo utilizados, entonces la implementación en contenedores definitivamente merece que inviertas una semana para probarla.

3 consejos concretos para quienes empiezan por primera vez

• No comiences directamente con clústeres K8S; primero utiliza Docker Compose para realizar implementaciones en máquinas individuales. Aprende bien la lógica de empaquetamiento, ejecución y montaje de logs. Así fue como procedimos durante los primeros 3 meses, y fue más que suficiente.
• Al crear la imagen por primera vez, se sigue el “principio de mínimismo”, instalando solo las dependencias necesarias para el funcionamiento. Utilizando una imagen base Alpine, se puede reducir el tamaño de la imagen en más de la mitad.
• Todos los datos y registros generados deben ser almacenados en volúmenes de almacenamiento externos al contenedor, bajo ninguna circunstancia deben permanecer dentro del propio contenedor. Este punto se encuentra al principio de las normas de operación de tu equipo.

Preguntas y respuestas sobre problemas comunes

Pregunta: Si nadie en nuestro equipo entiende sobre contenedores, ¿será muy alto el costo de aprendizaje?
Para un uso básico, basta pasar 2 días leyendo los documentos de inicio oficiales para poder poner en marcha el primer servicio. Si necesitas configuraciones de clústeres más avanzadas, puedes aprender sobre ellas cuando las necesites; no hay problema en hacerlo más adelante.

Pregunta: ¿Será muy complicado migrar los servicios existentes a contenedores?
Nuestros 3 servicios de backend se migraron completamente en una semana, y la mayor parte del tiempo se dedicó a organizar las dependencias; el tiempo real que se invirtió en escribir los archivos Dockerfile fue de menos de 1 día.