La semana pasada asistí a la conferencia de TI DUMP (https://dump-ekb.ru/) en Ekaterimburgo y quiero contarles sobre lo que se trató en las secciones de Backend y Devops, y si valen la pena las conferencias de TI regionales.
Nikolai Svertchkov de Evil Martians sobre Serverless
¿Qué pasó allí en realidad?
En total, la conferencia tuvo 8 secciones: Backend, Frontend, Mobile, Pruebas y QA, Devops, Diseño, Ciencia y Gestión.
Los espacios más grandes, por cierto, son los de Ciencia y Gestión, con capacidad para aproximadamente 350 personas cada uno. Backend y Frontend son un poco más pequeños. La sala de Devops fue la más pequeña, pero muy activa.
Asistí a las presentaciones en las secciones de Devops y Backend y hablé un poco con los ponentes. Quiero contarles sobre los temas que se trataron y hacer un resumen de estas secciones en la conferencia.
En las secciones de Devops y Backend participaron representantes de SKB Kontur, DataArt, Evil Martians, la agencia web local Flag y Miro (RealTimeBoard). Los temas incluyeron CI/CD, trabajo con servicios de colas, registro, se trataron bien los temas Serverless y el trabajo con PostgreSQL en Go.
También hubo presentaciones de Avito, Tinkoff, Yandex, Jetstyle, Megafon y el banco Ak Bars, pero no pude asistir a esas físicamente (los videos y diapositivas de las presentaciones aún no están disponibles, prometen publicarlos en un plazo de 2 semanas en dump-ekb.ru).
Sección de Devops
Lo sorprendente es que la sección se llevó a cabo en la sala más pequeña, con unas 50 plazas. La gente incluso estaba de pie en los pasillos 🙂 Les contaré sobre las presentaciones a las que pude asistir.
Elasticsearch de un petabyte
La sección comenzó con la presentación de Vladimir Lila (SKB Kontur) sobre Elasticsearch en Kontur. Tienen un Elasticsearch 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 en Kontur hay un ingeniero especializado en Elasticsearch (en realidad, el mismo Vladimir).
Vladimir también compartió sus pensamientos sobre los beneficios de Elasticsearch y los problemas que causa.
Beneficios:
- Todos los registros en un solo lugar, fácil acceso a ellos
- Almacenamiento de logs durante un año y su fácil análisis
- Alta velocidad de trabajo con logs
- Excelente visualización de datos 'listo para usar'
Problemas:
- un broker de mensajes es un must have (en Kontur, su función la cumple Kafka)
- particularidades del trabajo con Elasticsearch Curator (carga alta periódicamente causada por tareas regulares en Curator)
- no hay autorización incorporada (solo por un costo significativamente elevado, o como plugins de código abierto de diferentes grados de preparación para producción)
Sobre Open Distro for Elasticsearch, las opiniones han sido únicamente positivas 🙂 La misma cuestión de la autorización se ha resuelto allí.
¿De dónde proviene el petabyte?Sus nodos están compuestos por servidores con 12*8 Tb SATA + 2*2 Tb SSD. Almacenamiento en frío en SATA, SSD solo para caché caliente (hot storage).
7+9 servidores, (7 + 9) * 12 * 8 = 1536 Tb.
Parte del espacio está en reserva, destinado a redundancia, etc.
En Elasticsearch se envían registros de aproximadamente 90 aplicaciones, incluidos todos los servicios de informes de Kontur, Elba, etc.
Características del desarrollo en Serverless
A continuación, la presentación de Ruslan Serkin de DataArt sobre Serverless.
Ruslan habló sobre qué es el desarrollo con el enfoque Serverless 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 (Serverless dentro de Kubernetes), Google Cloud Functions.
La aplicación Serverless ideal es simplemente una función que envía una solicitud al proveedor Serverless a través de una puerta API especial. Un microservicio ideal, y en AWS Lambda se admiten muchos lenguajes de programación modernos. El costo de mantener y desplegar infraestructura se vuelve cero en el caso de proveedores en la nube, y el soporte de pequeñas aplicaciones también será muy económico (AWS Lambda — 0.2$ / 1 millón de solicitudes simples).
La escalabilidad de tal sistema es prácticamente ideal; el proveedor en la nube se encarga de ello, Kubeless se escala automáticamente dentro del clúster de Kubernetes.
Existen desventajas:
- el desarrollo de aplicaciones grandes se vuelve más complicado
- hay dificultades con la profilación de aplicaciones (solo tienes acceso a los registros, pero no a la perfilación en el sentido habitual)
- no hay versionado
Sinceramente, escuché sobre Serverless hace varios años, pero durante todos esos años no entendía cómo aplicarlo correctamente. Después de la presentación de Ruslan, adquirí comprensión, y después de la presentación de Nikolai Sverchkov (Evil Martians) en la sección de Backend, se consolidó. Ya no fui en vano a la conferencia 🙂
CI para pobres, o ¿vale la pena escribir su propio CI para una agencia web?
Mikhail Radionov, líder de la agencia web Flag de Ekaterimburgo, habló sobre su CI/CD personalizado.
Su estudio pasó de "CI/CD manual" (acceder al servidor por SSH, hacer git pull, repetir 100 veces al día) a Jenkins y a una herramienta personalizada que permite controlar el código y realizar lanzamientos, llamada Pullkins.
¿Por qué no convencía Jenkins? No ofrecía suficiente flexibilidad por defecto y era demasiado complicado de personalizar.
“Flag” está desarrollando en Laravel (un framework PHP). Al desarrollar un servidor CI/CD, Mikhail y sus colegas utilizaron los mecanismos integrados de Laravel llamados Telescope y Envoy. Como resultado, se creó un servidor en PHP (tenga en cuenta) que procesa solicitudes de webhook entrantes, puede realizar la construcción de frontend y backend, implementar en diferentes servidores y reportar en Slack.
Luego, para poder realizar implementaciones blue/green y tener configuraciones homogéneas en entornos dev-stage-prod, pasaron a Docker. Las ventajas permanecieron las mismas, se añadieron capacidades de homogeneización del entorno y despliegue continuo, además de la necesidad de aprender Docker para trabajar correctamente con él.
Cómo redujimos las retiradas de versiones del servidor en un 99%
La última presentación en la sección de DevOps fue de Viktor Yaremchenko, ingeniero devops líder en Miro.com (anteriormente RealTimeBoard).
El núcleo de RealTimeBoard, el producto principal del equipo de Miro, es una aplicación monolítica en Java. Compilar, probar e implementar sin tiempo de inactividad es una tarea complicada. Es importante implementar una versión del código que no requiera ser retirada (es un monolito pesado).
En el camino hacia la construcción de un sistema que permita hacer esto, Miro ha recorrido un camino que incluye trabajar en la arquitectura, las herramientas utilizadas (Atlassian Bamboo, Ansible, etc.) y en la formación de equipos (ahora tienen un equipo de DevOps dedicado más muchos Scrum independientes de desarrolladores de diferentes perfiles).
El camino fue difícil y lleno de espinas, y Viktor compartió el dolor acumulado y, al mismo tiempo, un optimismo inacabado.
Ganó un libro por las preguntas
Sección Backend
Llegué a 2 presentaciones: la de Nikolai Sverchkov (Evil Martians), también sobre Serverless, y la de Grigory Koshelev (compañía Kontur) sobre telemetría.
Serverless para mortales
Mientras Ruslan Sirkin hablaba sobre qué es Serverless, Nikolai mostró aplicaciones sencillas utilizando Serverless y habló sobre los detalles que influyen en el costo y la velocidad de las aplicaciones en AWS Lambda.
Un detalle interesante: el elemento mínimo facturable es de 128 Mb de memoria y 100 ms de CPU, y cuesta 0,000000208$. Además, 1 millón de solicitudes similares al mes es gratuito.
Algunas 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 resultó en un gran ahorro.
Vostok Hercules — ¡haz que la telemetría sea genial otra vez!
El último informe de la sección de Backend de Grigory Koshelev (empresa Kontur) sobre telemetría. La telemetría son registros, métricas, trazas de aplicaciones.
Kontur utiliza herramientas que han sido desarrolladas internamente y están disponibles en Github. La herramienta presentada en el informe es Hercules, , que se utiliza para la entrega de datos de telemetría.
En la presentación de Vladimir Lila en la sección de Devops se abordó el almacenamiento y procesamiento de registros en Elasticsearch, pero también existe el desafío de entregar registros desde miles de dispositivos y aplicaciones, y eso se soluciona con herramientas como Vostok Hercules.
Kontur ha recorrido un camino conocido por muchos — de RabbitMQ a Apache Kafka, pero no todo es tan simple. Tuvieron que añadir Zookeeper, Cassandra y Graphite al esquema. No revelar todos los detalles de este informe (no es mi perfil), pero si están interesados, pueden esperar las diapositivas y el video en el sitio de la conferencia.
¿Cómo se compara con otras conferencias?
No puedo compararlo con las conferencias en Moscú y San Petersburgo, pero puedo compararlo con otros eventos en los Urales y con el 404fest en Samara.
DUMP se lleva a cabo en 8 secciones, lo cual es un récord para las conferencias en los Urales. Las secciones de Ciencia y Gestión son bastante grandes, lo cual 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 también influye en las presentaciones.
Otro punto interesante es que muchas empresas tienen de 3 a 4 ponentes en la conferencia (así ocurrió con Kontur, Evil Martians, Tinkoff). Muchos de ellos eran patrocinadores, pero las presentaciones estaban a la par con las demás, no eran presentaciones publicitarias.
¿Ir o no ir? Si vives en los Urales o cerca, tienes la oportunidad y los temas te interesan — sí, por supuesto. Si piensas en un viaje más largo — yo revisaría los temas de las presentaciones y los videos de años anteriores. y tomaría una decisión.
Otro beneficio de las conferencias en regiones, como regla, es que es fácil hablar con los ponentes después de las presentaciones, simplemente hay menos candidatos para esa interacción.
¡Gracias a DUMP y Ekaterimburgo!
Fuente: habr.com
