Lo memorable de infra.conf 2024 / Sudo Null IT News
El 4 de junio tuvo lugar infra.conf 2024, una conferencia sobre la creación de infraestructura y el funcionamiento de sistemas de alta carga del equipo de Yandex Infrastructure. En el evento, pedimos a ingenieros no solo de Yandex, sino también de Ozon.Tech, T1, MTS Web Services, T-Bank, SberDevices, Alfa-Bank, Kaspersky Lab, Selectel, Postgres Pro, SberMarket y Avito que compartieran su infraestructura. cuentos. Como resultado, según los comentarios de los participantes, “la concentración extrema de hardware y DevOps se salió de escala y voló por los aires”.
En este artículo, hemos recopilado los puntos más interesantes de aquellos informes que provocaron la mayor reacción y deleite de utilidad en el banquillo y en los chats, para que le resulte más fácil descubrir qué vale la pena revisar.
Temas YDB: historia de las relaciones con Kafka
Ya hemos escrito sobre Habré sobre la historia de la formación del bus de datos YDB Topics, por ejemplo, Aquí. En su informe, el jefe del grupo de desarrollo de YDB, Alexander Zevaikin, recordó las tareas de las plataformas de procesamiento de colas y habló de los desafíos que surgen cuando los volúmenes de datos alcanzan los 20 millones de EPS.
¿Qué hacer si las plataformas de código abierto existentes para trabajar con mensajes en streaming limitan significativamente sus capacidades, por ejemplo, cuando se trabaja con clústeres y reservas geográficas? En infra.conf puedes hablar sobre esto en formato de diálogo y hacer tus propias preguntas, incluso provocativas.
Marco aleatorio del informe:
La pregunta más provocativa del reportaje (según el presentador):
El equipo de YDB nos dice que el “grande” Yandex ha estado usando YDB para sus tareas de alta carga durante mucho tiempo. Pero, como entendemos, Yandex Infrastructure no es Yandex Cloud, hay una diferencia. ¿Puedes decir qué?
Una pregunta muy amplia, permítanme responderla dentro del alcance del informe: ¿YDB es diferente en la nube y en la infraestructura interna? YDB funciona con una única base de código, independientemente de si es de código abierto, instalación interna o instalación externa. Dentro de Yandex hay una pequeña pieza relacionada con el sistema de autorización interna y funciones dentro de la nube, por ejemplo, multiinquilino. Estas son las únicas pequeñas diferencias que existen.
Cómo vivir cómodamente con hardware en la infraestructura básica 2K24
Gestionar una flota de redes férreas se convierte en una tarea muy interesante cuando se trata de una escala seria:
cientos de servidores de hierro,
200 gigabits por host.
Boris Litvinenko, del grupo de desarrollo y monitoreo de infraestructura de red de Yandex Infrastructure, habló sobre cómo el equipo abordó la tarea de orquestar los servicios de red y la gestión automatizada de recursos. Para facilitar la gestión, los servicios se transfirieron a la infraestructura de la nube a través de contenedores Kubernetes. Y para ello, se desarrolló un sistema de automatización de la red y los componentes de la red YANET, que permitió unificar los servicios con el resto de la infraestructura de Yandex, y del que definitivamente hablaremos en un artículo aparte.
Marco aleatorio del informe:
La pregunta que más me gustó para el informe del chat.:
Como especialista con experiencia trabajando con kubeadm, puedes responder: “Si puedo configurar un clúster usando kube-adm la primera vez, ¿es magia o simplemente suerte?”
De hecho, esto no es magia y ahora todo avanza hacia la simplificación. Probablemente sea más difícil entender los matices y cómo funciona internamente. Yo diría que el problema con Kubernetes ahora es que hay mucha información, muchas soluciones similares y uno necesita elegir algo propio.
Nuestra propia implementación de S3 sobre Ceph-Lusca: cómo aprendimos a trabajar de forma predecible con el índice y ahorrar espacio con las mismas garantías
A medida que aumenta la carga en S3, el equipo de ingeniería puede encontrar dificultades al utilizar soluciones de código abierto: por ejemplo, problemas con la escalabilidad del almacenamiento y la distribución de la carga.
Victor Koreysha, jefe de Servicios Gestionados de Ozon Tech, mostró en detalle cómo surgen estos problemas a escala empresarial. Algunos números y detalles sobre el uso de S3:
unos 1.000 servicios de Ozon Tech;
20.000 cubos;
5.000.000.000 de objetos;
60 petabytes de datos;
cientos de miles de RPS.
En la conferencia, Víctor mostró cómo su equipo logró identificar los cuellos de botella que surgieron durante el funcionamiento del almacenamiento de objetos, seleccionar la solución más adecuada e implementarla teniendo en cuenta todos los requisitos internos.
Marco aleatorio del informe:
La pregunta que más me gustó para el informe del chat:
Imaginemos que todos vivimos en un gran almacén de datos distribuido, donde cada persona es un objeto con atributos diferentes. ¿Quién crees que ocuparía el lugar de BlueStore y cómo gestionaríamos los objetos “personales” en un sistema de este tipo? ¿Actuará RadosGW como un porteador benevolente que intenta agilizar el flujo de datos, o acabaremos todos en un ciclo continuo de compactación de RocksDB intentando hacer espacio para nuevos 'objetos'?
DNS sobre YTsaurus: cómo funciona todo el almacenamiento de datos DNS de Yandex
El volumen de datos DNS para todo Yandex no supera los 10 GB, pero son diez gigabytes muy importantes. De ellos depende el rendimiento de casi todos los servicios de Yandex. Aquí es exactamente donde Sergey Fomin, jefe del grupo YP y Discovery en Yandex Infrastructure, comenzó su informe.
La historia de Sergei sobre el almacenamiento DNS detalla cómo crear un almacenamiento consistente, tolerante a fallas y de alta carga.
Marco aleatorio del informe:
La pregunta y respuesta más inesperada al informe del chat:
Si los registros DNS fueran secundarios, ¿con qué frecuencia cree que preguntarían “¿Por qué?” antes de actualizar?
…lo principal es no hacer demasiadas preguntas a los padres autorizados.
Sistema de autotest propio Hive
Kaspersky Lab ejecuta más de un millón de tareas diariamente en cientos de plataformas diferentes para probar productos. Al principio, los requisitos de la empresa para la infraestructura de autotest parecían bastante estándar y se eligieron soluciones ya preparadas para crearla. Pero con el tiempo, las necesidades empezaron a crecer.
Alexander Krymov, desarrollador senior de infraestructura Hive en Kaspersky Lab, explicó cómo y por qué se decidió crear nuestro propio sistema de prueba automática y qué escenarios no estándar ayudó a resolver.
Marco aleatorio del informe:
DevEnv como servicio
Cuando creamos un entorno único y repetible para desarrolladores, la mayoría de las veces decimos que tenemos Pruebas, Puesta en escena, Preestable y Producción, que se administran a través de soluciones IaC. Pero al mismo tiempo, los entornos de desarrollo a menudo se olvidan y hay muchos más que entornos de prueba. Las dificultades para configurarlos pueden provocar cambios no programados y otros problemas.
Vitaly Dmitriev, director técnico de proyectos de Yandex Infrastructure, mostró cómo estas ideas llevaron a la creación del servicio gestionado Codenv, del cual es responsable un equipo independiente.
Marco aleatorio del informe:
La pregunta más persistente para el informe del chat (y su respuesta):
¿Los desarrolladores tienen cuotas/límites en el uso de entornos? ¿Alguien puede abusar de él y crear más ambientes de los necesarios? ¿Existe algún tipo de acuerdo?
Más bien, aquí todo es igual que con cualquier servicio: hay seguimiento, hay información sobre quién consume cuánto. Todo ello está monitorizado en tiempo real, y si es necesario, podemos dar respuesta a cualquier anomalía.
Mejorar la calidad de las pruebas de carga reforzando la infraestructura.
Mikhail Zhilin, jefe del grupo de rendimiento del departamento de implementación y soporte técnico de PostgreSQL, compartió su amplia experiencia en pruebas de carga en infra.conf. Antes de unirse a la empresa, también trabajó en cuestiones de rendimiento, pero los últimos 3 años en PostgreSQL le han brindado nuevas oportunidades: acceso completo al bare metal mientras gestiona la carga de la base de datos.
En el informe, Mikhail habló sobre cómo el equipo se vio afectado por las características de Linux, modificó el ahorro de energía del procesador, escribió su propio demonio de enlace central y mucho más.
Marco aleatorio del informe:
El mundo moderno de Cloud Native y enfoques para su recuperación ante desastres
Dmitry Rybalka, TechLead del departamento de infraestructura básica de TI de SberMarket, comparte estadísticas: en los últimos seis meses, la mayoría de los operadores de la nube han experimentado accidentes. Esta dura realidad lleva inevitablemente a los equipos de ingeniería a crear planes de recuperación ante desastres. Pero esos planes serán ligeramente diferentes para las soluciones nativas de la nube.
En su informe, Dmitry pasa gradualmente del concepto de recuperación de desastres al concepto de prevención de desastres, muestra muchas estrategias de recuperación y explica cómo el enfoque agnóstico de la nube puede ayudar en este caso.
Marco aleatorio del informe:
Trucos de bases de datos en memoria en DBMS tradicionales
Introducir un destornillador en una base de datos que se encuentra cerca puede resultar útil para comprender mejor las diferentes formas de optimizar el rendimiento. Andrey Borodin, jefe del departamento de desarrollo RDBMS de código abierto de Yandex Cloud, comparte la experiencia de muchos años de observar y analizar el trabajo de bases de datos y muestra varios trucos a la vez:
El puntero chisporrotea. La búsqueda de clave principal es muy útil al realizar búsquedas binarias en las páginas del árbol B, descomprimir IndexTuple, TID, mover las páginas a búferes compartidos y, finalmente, los datos HEAP. En esta ruta no tan directa, hay un par de lugares donde puedes tomar atajos.
Estructuras de páginas más adecuadas para el almacenamiento en caché. Una búsqueda binaria puede afectar a menos líneas de caché y la página en sí puede tener una estructura de columnas (atributos de partición en todo el diseño).
Un enfoque más optimista para bloquear buffers compartidos: leer sin bloquear, restablecer el resultado en caso de cualquier cambio.
Marco aleatorio del informe:
Respaldo estático
Pavel Lakosnikov, jefe de la unidad ArchGovernance en Avito, se ha centrado en cuestiones de fiabilidad durante más de cuatro años y durante este tiempo ha visto muchos accidentes y varias liberaciones que fueron “quemadas por el despliegue”. Todo esto llevó a su equipo a crear un sistema alternativo que le permite cubrir a Avito con “todo en caché”.
En su informe, Pavel comparte el diseño de dicho sistema, los enfoques para escalarlo y garantizar la calidad del almacenamiento en caché.
Marco aleatorio del informe:
Pregunta provocativa para el informe del chat (y respuesta):
¿Existen sanciones por accidentes? Después de todo, a menudo no se encuentra a los culpables.
El peor castigo por una caída es un informe del incidente. Es necesario elaborar un mapa de riesgo para los componentes que se han caído y, de hecho, esta es la solución más eficaz en esta situación.
Esto es sólo una pequeña parte de todo lo que pasó en infra.conf. Ver completa grabación de transmisión en nuestro canal, comparta sus impresiones si estuvo en el sitio sin conexión y asista a los próximos eventos.
