💱 👥 🍆 Cómo ayudamos a las escuelas a cambiar al aprendizaje a distancia y a enfrentar la carga 👵🏽 🏝️ 👩‍👦

Hola Habr! Mi nombre es Alexey Vakhov, soy el director técnico de Uchi.ru. A mediados de marzo, cuando las escuelas comenzaron a cambiar a educación a distancia, brindamos a los maestros y estudiantes varios servicios para clases en línea. Según nuestros cálculos, teníamos un margen de seguridad para soportar un máximo de 1.5-2 veces la carga. A mediados de abril, nuestro tráfico creció 8 veces. Tenía que hacer mucho para mantenerme a flote. Quizás alguien necesite nuestra experiencia para sobrevivir a esta o una crisis futura.

No esperábamos tales sorpresas y no estábamos preparados para ellas, probablemente ni una sola compañía en Rusia, ni en el mundo, estaba lista para esto. Por lo general, en marzo, la actividad en Uchi.ru es menor en relación con el otoño debido a la primavera y las próximas vacaciones de verano, momento en el que ya nos estamos preparando para septiembre: estamos aserrando características, refactorizando, realizando cambios arquitectónicos a gran escala y haciendo otra rutina agradable. Sin embargo, esta vez fue diferente.

El número máximo de usuarios únicos en el sitio en un momento llegó a 240 mil, registramos el máximo anterior del año escolar actual en 30 mil personas. En este punto, la carga creció todos los días, y trabajamos las 24 horas para estabilizar el sitio.

Cuando dicha carga cae en el sitio, como regla, se forman aplicaciones, servicios, equilibradores, bases, web, canales. Todos los "cuellos de botella" de la infraestructura están expuestos. En tales condiciones, es difícil diagnosticar problemas: sintomáticamente, todo tiene errores. Es fácil de reparar cuando el tráfico crece sin problemas y una cosa se descompone. Cuando la carga se agita, uno de los grandes problemas es comprender las causas de las fallas.

La estrategia para trabajar en tales condiciones es eliminar lo que más golpea el sitio, luego encontrar el siguiente punto más doloroso, al mismo tiempo buscar posibles problemas y solucionarlos, y así sucesivamente. Estas son algunas de las cosas más notables que hicimos para estabilizar la plataforma.

Confiar en ellos mismos

Durante una crisis antes del tráfico, usted como equipo se convierte en uno. Dependerá de sus empleados si encontrará soluciones, enfrentará la crisis o no.

No hay personas en la industria que vengan, investiguen su complejo sistema, hagan algo de inmediato y todo estaría bien. Por supuesto, en el mundo hay suficientes especialistas que se encargarán de la tarea si hay tiempo. Pero cuando se necesita una solución fundamental en este momento, solo puede confiar en su equipo, que conoce el sistema y sus detalles. El resultado y la responsabilidad del negocio recae en el equipo. Se recomienda un examen externo para conectar puntiagudos.

La coordinación operativa del equipo contra la crisis en un chat especial en Slack nos ayudó a navegar rápidamente y construir nuestro trabajo, todo lo cual se resolvió aquí y ahora. Dividimos las áreas de responsabilidad entre los empleados para que no hubiera intersecciones y los muchachos no hicieran doble trabajo. En los días más difíciles, tenía que estar en contacto literalmente durante todo el día.

Nube expandida

No se puede asegurar contra todas las crisis, pero es importante ser flexible. La acumulación de nubes nos dio tanta plasticidad y la oportunidad de mantenernos a flote incluso con un aumento tan dramático de la carga.

Inicialmente, aumentamos los recursos bajo el aumento de la carga, pero en algún momento nos encontramos con las cuotas de la región de nuestro proveedor de la nube. Surgieron problemas a su nivel: nuestros servidores virtuales se vieron afectados por vecinos, en los cuales también creció el tráfico, lo que causó fallas en el funcionamiento de nuestras aplicaciones. Esto era de esperar: dependemos del proveedor y su infraestructura, que a su vez también experimentó una gran carga. Hemos lanzado algunos recursos de máquinas virtuales no prioritarias para el sitio principal. Con el proveedor, acordamos un recurso dedicado.

Herramientas de monitoreo actualizadas

Durante la crisis, la alerta no cumplió su función. Todos los miembros del equipo ya monitorearon todos los sistemas durante todo el día, y la gestión de incidentes se redujo al trabajo constante en todos los frentes. Para diagnosticar completamente los problemas que encontramos, teníamos muy pocos datos. Por ejemplo, para monitorear máquinas virtuales, utilizamos el Nodo Exportador estándar para Prometheus. Es bueno ver el panorama general, para una mirada más cercana a una sola máquina virtual comenzó a usar NetData.

Almacenamiento optimizado en caché

También surgió un problema con las tiendas de valores clave. En una de las aplicaciones, Redis no pudo hacer frente: en una sola copia puede funcionar en un solo núcleo. Por lo tanto, utilizaron una bifurcación de Redis llamada KeyDB, que puede funcionar en varios subprocesos.

Para aumentar el ancho de banda en otra aplicación, hemos planteado 10 Redis'ov independientes. Están representados por nuestro Service Mesh, que también fragmenta las claves. Incluso si uno o dos Redis se bloquean, esto no causará problemas debido al hashing constante. Además, prácticamente no necesitan ser administrados.

Expandido la red

Como saben, 640 Kb es suficiente para todos. Siempre utilizamos subredes privadas / 24, pero en el contexto de la cuarentena tuvimos que expandirnos urgentemente a / 22. Ahora que la red admite cuatro veces más servidores, esperamos que sea suficiente.

PgBouncer realizado por separado

Como base de datos relacional, utilizamos PostgreSQL en todas partes, en algunas instancias virtuales pequeñas y en algún lugar: la instalación de varios servidores dedicados grandes para el maestro y las réplicas. El cuello de botella obvio de esta arquitectura es el maestro, que en el caso ideal se usa solo para grabar y no se escala horizontalmente. Con el crecimiento del tráfico, comenzamos a descansar en la CPU.

Al mismo tiempo, utilizamos PgBouncer, que se instaló en el asistente y en cada réplica, para administrar las conexiones. En un puerto, no puede usar más de un núcleo de procesador, por lo que en cada servidor teníamos varios rebotadores. En algún momento, quedó claro que el propio PgBouncer quitó la parte tangible de la CPU de la base, y con la carga máxima experimentamos un rápido aumento en el promedio de carga y una caída en el rendimiento del sistema.

Movimos a los gorilas a un servidor separado, lo que nos ayudó a ahorrar 20-25% de la CPU en cada servidor de base de datos.

Ante sorpresas

Solo se puede confiar en una herramienta, especialmente en tiempos de crisis. Por el contrario, la redundancia de herramientas ayuda, porque permite ver una imagen más objetiva. Las herramientas familiares comienzan a fallar por una variedad de razones. Por ejemplo, generalmente para estimar la cantidad de personas en un sitio, usamos un informe de Google Analytics en tiempo real, que es una métrica sensible y precisa. Pero a veces es defectuoso y esta vez tuvimos que mirar métricas internas como la cantidad de eventos de páginas vistas y la cantidad de solicitudes por segundo.

Para el registro centralizado usamos ELK. Nuestro canal de entrega de registros se basa en Apache Kafka y Elastic Filebeat. Bajo una carga alta, el transportador de entrega de registros dejó de funcionar, los registros comenzaron a perderse o retrasarse. Aumentamos la velocidad de la transferencia de registros y la indexación de almacenamiento manipulando los índices de Elasticsearch, aumentando el número de particiones en Kafka y Filebeat, y ajustando la compresión en todas las etapas. Debido al hecho de que la tubería para recopilar registros es independiente de la producción, los problemas con el aumento del tráfico de los registros no tuvieron ningún efecto en el funcionamiento del sitio.

Aceptó las reglas del juego.

Es imposible prepararse para cada crisis por adelantado, pero inicialmente puede intentar construir un sistema flexible. Las startups o empresas que gradualmente dejan de ser startups, en un momento de silencio, no siempre es racional prepararse para un crecimiento anormal del tráfico: los recursos del equipo son limitados. Si dejamos de lado su preparación para algo que nunca puede suceder, no quedará fuerza para el producto principal. Es mucho más importante reaccionar correctamente en el momento y no tener miedo a las decisiones audaces. Como regla general, la salida de su crisis es una salida a un nivel cualitativamente nuevo.

Aquí hay una primavera muy divertida este año. Cuando parece que se ha hecho todo lo posible, a veces resulta que esto es solo el comienzo.

Cómo ayudamos a las escuelas a cambiar al aprendizaje a distancia y a enfrentar la carga