La semana pasada asistí a la conferencia DUMP IT (https://dump-ekb.ru/) en Ekaterimburgo y quiero contarles lo que se discutió en las secciones Backend y Devops, y si las conferencias regionales de TI merecen atención.
Nikolay Sverchkov de Evil Martians sobre Serverless
¿Qué había allí de todos modos?
En total, la conferencia contó con 8 secciones: Backend, Frontend, Móvil, Testing y QA, Devops, Diseño, Ciencia y Gestión.
Las salas más grandes, por cierto, están en Ciencias y Gestión)) Para ~350 personas cada una. Backend y Frontend no son mucho más pequeños. La sala Devops era la más pequeña, pero activa.
Escuché los informes de las secciones Devops y Backend y hablé un poco con los ponentes. Me gustaría hablar sobre los temas tratados y revisar estas secciones en la conferencia.
En las secciones Devops y Backend hablaron representantes de SKB-Kontur, DataArt, Evil Martians, el estudio web Flag de Ekaterimburgo y Miro (RealTimeBoard). Los temas cubrieron CI/CD, trabajo con servicios de cola, registro; temas sin servidor y trabajo con PostgreSQL en Go estuvieron bien cubiertos.
También hubo informes de Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, pero no tuve tiempo de asistir físicamente a ellos (las grabaciones de video y diapositivas de los informes aún no están disponibles, prometen publicarlos dentro de 2 semanas). en dump-ekb.ru).
Sección de desarrollo
Lo sorprendente fue que la sección se celebró en la sala más pequeña, con unas 50 plazas. Incluso había gente parada en los pasillos :) Les contaré sobre los informes que logré escuchar.
Elástico que pesa un petabyte
La sección comenzó con un informe de Vladimir Lil (SKB-Kontur) sobre Elasticsearch en Kontur. Tienen un Elastic bastante grande y cargado (~800 TB de datos, ~1.3 petabytes teniendo en cuenta la redundancia). Elasticsearch para todos los servicios de Kontur es único, consta de 2 clústeres (de 7 y 9 servidores) y es tan importante que Kontur tiene un ingeniero especial de Elasticsearch (de hecho, el propio Vladimir).
Vladimir también compartió su opinión sobre los beneficios de Elasticsearch y los problemas que trae.
Beneficio
- Todos los registros están en un solo lugar, fácil acceso a ellos.
- Almacenar registros durante un año y analizarlos fácilmente
- Alta velocidad de trabajo con registros.
- Visualización de datos genial lista para usar
Problemas
- El intermediario de mensajes es imprescindible (para Kontur su papel lo desempeña Kafka)
- características de trabajar con Elasticsearch Curator (alta carga creada periódicamente a partir de tareas regulares en Curator)
- sin autorización incorporada (solo por separado, bastante dinero, o como complementos de código abierto con distintos grados de preparación para la producción)
Solo hubo críticas positivas sobre Open Distro para Elasticsearch :) El mismo problema de autorización se resolvió allí.
¿De dónde viene el petabyte?Sus nodos constan de servidores con 12*8 Tb SATA + 2*2 Tb SSD. Almacenamiento en frío en SATA, SSD solo para caché activa (almacenamiento en caliente).
7+9 servidores, (7 + 9) * 12 * 8 = 1536 Tb.
Parte del espacio está en reserva, reservado para redundancia, etc.
Se envían registros de unas 90 aplicaciones a Elasticsearch, incluidos todos los servicios de informes de Kontur, Elba, etc.
Características del desarrollo en Serverless.
El siguiente es un informe de Ruslan Serkin de DataArt sobre Serverless.
Ruslan habló sobre qué es el desarrollo con el enfoque Serverless en general y cuáles son sus características.
Serverless es un enfoque de desarrollo en el que los desarrolladores no tocan la infraestructura de ninguna manera. Ejemplo: AWS Lambda Serverless, Kubeless.io (sin servidor dentro de Kubernetes), Google Cloud Functions.
Una aplicación sin servidor ideal es simplemente una función que envía una solicitud a un proveedor sin servidor a través de una puerta de enlace API especial. Un microservicio ideal, aunque AWS Lambda también admite una gran cantidad de lenguajes de programación modernos. El coste de mantenimiento e implementación de la infraestructura se vuelve cero en el caso de los proveedores de la nube, el soporte de aplicaciones pequeñas también será muy barato (AWS Lambda - 0.2 dólares / 1 millón de solicitudes simples).
La escalabilidad de un sistema de este tipo es casi ideal: el proveedor de la nube se encarga de ello él mismo, Kubeless escala automáticamente dentro del clúster de Kubernetes.
Hay desventajas:
- desarrollar aplicaciones de gran tamaño es cada vez más difícil
- hay dificultades con las aplicaciones de creación de perfiles (sólo están disponibles los registros, pero no la creación de perfiles en el sentido habitual)
- sin versiones
Para ser honesto, escuché sobre Serverless hace unos años, pero todos estos años no tenía claro cómo usarlo correctamente. Después del informe de Ruslan, apareció la comprensión, y después del informe de Nikolai Sverchkov (Evil Martians) de la sección Backend, se consolidó. No en vano fui a la conferencia :)
La CI es para los pobres, ¿o vale la pena escribir tu propia CI para un estudio web?
Mikhail Radionov, director del estudio web Flag de Ekaterimburgo, habló sobre el CI/CD escrito por él mismo.
Su estudio ha pasado de “CI/CD manual” (iniciar sesión en el servidor a través de SSH, hacer un git pull, repetir 100 veces al día) a Jenkins y a una herramienta escrita por él mismo que le permite monitorear el código y realizar lanzamientos llamada Pullkins. .
¿Por qué Jenkins no funcionó? No proporcionaba suficiente flexibilidad de forma predeterminada y era demasiado difícil de personalizar.
“Flag” se desarrolla en Laravel (marco PHP). Al desarrollar un servidor CI/CD, Mikhail y sus colegas utilizaron los mecanismos integrados de Laravel llamados Telescope y Envoy. El resultado es un servidor en PHP (tenga en cuenta) que procesa las solicitudes entrantes de webhook, puede crear el frontend y el backend, implementarlo en diferentes servidores e informar a Slack.
Luego, para poder realizar una implementación azul/verde y tener configuraciones uniformes en entornos de etapa de desarrollo y producción, cambiaron a Docker. Las ventajas siguieron siendo las mismas, se agregaron posibilidades de homogeneización del entorno y despliegue fluido, y se agregó la necesidad de aprender Docker para trabajar con él correctamente.
Cómo redujimos la cantidad de reversiones de versiones de servidores en un 99 %
El último informe en la sección Devops fue de Viktor Eremchenko, ingeniero jefe de Devops en Miro.com (anteriormente RealTimeBoard).
RealTimeBoard, el producto estrella del equipo de Miro, se basa en una aplicación Java monolítica. Recopilarlo, probarlo e implementarlo sin tiempo de inactividad es una tarea difícil. En este caso, es importante implementar dicha versión del código para que no sea necesario revertirlo (es un monolito pesado).
En el camino hacia la construcción de un sistema que le permita hacer esto, Miro recorrió un camino que incluyó trabajar en la arquitectura, las herramientas utilizadas (Atlassian Bamboo, Ansible, etc.) y trabajar en la estructura de los equipos (ahora tienen un equipo Devops dedicado + muchos equipos Scrum separados de desarrolladores de diferentes perfiles).
El camino resultó difícil y espinoso, y Víctor compartió el dolor acumulado y el optimismo que no terminó ahí.
Ganó un libro por hacer preguntas.
Sección de fondo
Logré asistir a 2 informes: de Nikolay Sverchkov (Evil Martians), también sobre Serverless, y de Grigory Koshelev (compañía Kontur) sobre telemetría.
Sin servidor para simples mortales
Si Ruslan Sirkin habló sobre qué es Serverless, Nikolay mostró aplicaciones simples que usan Serverless y habló sobre los detalles que afectan el costo y la velocidad de las aplicaciones en AWS Lambda.
Un detalle interesante: el elemento mínimo pagado es de 128 Mb de memoria y 100 ms de CPU, cuesta $0,000000208. Además, 1 millón de solicitudes de este tipo al mes son gratuitas.
Algunas de las funciones de Nikolai a menudo excedían el límite de 100 ms (la aplicación principal estaba escrita en Ruby), por lo que reescribirlas en Go proporcionó excelentes ahorros.
Vostok Hercules: ¡haga que la telemetría vuelva a ser grandiosa!
El último informe de la sección Backend de Grigory Koshelev (empresa Kontur) sobre telemetría. Telemetría significa registros, métricas, seguimientos de aplicaciones.
Para ello, Contour utiliza herramientas escritas por él mismo y publicadas en Github. Herramienta del informe - Hércules, , se utiliza para entregar datos de telemetría.
El informe de Vladimir Lila en la sección Devops analiza el almacenamiento y procesamiento de registros en Elasticsearch, pero aún queda la tarea de entregar registros de miles de dispositivos y aplicaciones, y herramientas como Vostok Hercules las resuelven.
El circuito siguió un camino conocido por muchos: desde RabbitMQ hasta Apache Kafka, pero no todo es tan simple)) Tuvieron que agregar Zookeeper, Cassandra y Graphite al circuito. No revelaré completamente la información de este informe (no mi perfil). Si está interesado, puede esperar las diapositivas y los videos en el sitio web de la conferencia.
¿Cómo se compara con otras conferencias?
No puedo compararlo con conferencias en Moscú y San Petersburgo, puedo compararlo con otros eventos en los Urales y con el 404fest en Samara.
DAMP se lleva a cabo en 8 secciones, este es un récord para las conferencias de los Urales. Secciones muy grandes de Ciencia y Gestión, esto también es inusual. La audiencia en Ekaterimburgo está bastante estructurada: en la ciudad hay grandes departamentos de desarrollo de Yandex, Kontur, Tinkoff, lo que deja su huella en los informes.
Otro punto interesante es que muchas empresas tienen entre 3 y 4 oradores a la vez en la conferencia (este fue el caso de Kontur, Evil Martians, Tinkoff). Muchos de ellos fueron patrocinadores, pero los informes están bastante a la par de otros, no son informes publicitarios.
¿Ir o no ir? Si vives en los Urales o en sus alrededores, tienes la oportunidad y te interesan los temas, sí, por supuesto. Si estás pensando en un viaje largo, miraría los temas de reportajes y reportajes en vídeo de años anteriores. y tomó una decisión.
Otra ventaja de las conferencias en las regiones, por regla general, es que es fácil comunicarse con el orador después de los informes, simplemente hay menos solicitantes para dicha comunicación.
¡Gracias a Dump y Ekaterinburg! )
Fuente: habr.com