Ivan Kruglov, desarrollador principal de Booking.com, habló en SlOmer DevOps con el tema SRE y, después de la charla, acordó hablar sobre Kubernetes, Service Mesh, código abierto y soluciones no estándar en Booking.com con una taza de café.
Dado que el tema de SRE resultó ser mucho más amplio, Ivan y su colega Ben Tyler, desarrollador principal de Booking.com, acordaron convertirse en oradores de Slurm SRE, que se realizará del 3 al 5 de febrero de 2020 . Allí discutirán la teoría y la práctica de aplicar el presupuesto de SLI / SLO / error, realizar análisis post-mortem, eliminación efectiva de incidentes de TI, construir sistemas confiables (monitoreo y alerta, degradación elegante, inyección de fallas, planificación de capacidad, prevención de fallas en cascada )
Y ahora una palabra para Ivan.
¿Cuál ha sido un desafío profesional interesante para ti últimamente?
En los últimos dos años he estado haciendo dos cosas. Primero: haciendo la nube interna de Booking.com. Está construido sobre Kubernetes. En esta ocasión, tuve un informe largo y completo sobre Highload.
Tuvimos una forma larga e interesante de cómo construimos nuestra nube. Este es mi proyecto anterior, que le dejé a un colega.
Ahora estoy tratando un tema llamado Service Mesh. Este es, de hecho, un tema candente, como lo fueron Big Data y Kubernetes a la vez.
La idea es, por un lado, simple, por otro lado, compleja: en una arquitectura de microservicio, toda la interacción pasa por la red, bueno, es como si fuera una parte integral de los microservicios. Y la interacción en sí es una operación compleja, muchas cosas pueden salir mal allí. Todo esto necesita ser controlado. En particular, se imponen restricciones: si tenemos un monolito y funcionan dos funciones, y estas dos funciones podrían confiar entre sí, porque son parte del mismo proceso, entonces, en teoría, los microservicios no pueden confiar entre sí.
¿Cómo sabes de dónde viene la solicitud? Aquí hay un microservicio, llega una solicitud HTTP. ¿Realmente vino del servicio desde el que pienso? Y de la misma manera, el servicio que otro servicio requiere. Necesito estar seguro de que el servicio al que llamo es el que necesito, y no algún tipo de servicio falso. En organizaciones pequeñas, esto probablemente no sea tan cierto. Y en los grandes, cuando tiene miles y decenas de miles de automóviles, no hará un seguimiento de cada máquina. Y para las grandes empresas este es un problema bastante serio. Es decir, digamos, todo está construido con cero confianza. Siempre que realice algún tipo de comunicación, debe realizar una verificación. Resulta que a nivel de interacción de red es necesario autenticar y autorizar la operación. Todos estos son procesos bastante difíciles en términos de implementación. Y resulta que Service Mesh asume estas tareas para garantizar una interacción segura. Esta es solo una de las características que hace Service Mesh. Hay mucho más: confiabilidad, monitoreo, rastreo y otros.
¿Y crees que esta tecnología es el futuro?
Service Mesh es una tendencia que está creciendo. Esta es mi opinión personal. Ya es bastante común. Por ejemplo, hay Istio. Luego, en las nubes, en la misma Amazonía, apareció Service Mesh. Creo que todos los principales proveedores pronto tendrán o ya tendrán una malla de servicio completa.
Es decir, la misma tecnología innovadora que alguna vez fue, ¿y ahora hay Kubernetes?
Yo creo que si. Aunque es interesante notar aquí que, en mi opinión, ni Kubernetes ni Service Mesh inventan nada nuevo. Kubernetes tomó una pila de tecnología existente y la convirtió en automatización. Service Mesh hace aproximadamente lo mismo. Da nuevas herramientas sobre una base existente. Enviado ha aparecido en Service Mesh, que demostraré hoy. (Tenga en cuenta que Ivan abordó este tema en un discurso en el programa intensivo Slurm DevOps .) La idea es que Service Mesh es un instrumento de nivel superior que le permite organizar las comunicaciones de una gran flota de microservicios. Explicaré ... Para iniciar la arquitectura de microservicios, primero necesita el llamado tiempo de ejecución: este es el lugar donde se iniciará la aplicación. Esto es lo que hace Kubernetes. Service Mesh lo complementa, en el sentido de que proporciona la interacción entre estos microservicios que se ejecutarán en tiempo de ejecución.
¿Desarrollarás esta tecnología en el futuro cercano?
Puedo hablar por mi mismo. Estoy involucrado en infraestructura. Y en términos de infraestructura, en los próximos años, este será uno de los temas principales: Kubernetes y Service Mesh.
¿Se desarrollarán en paralelo?
Ciertamente, porque se complementan entre sí. Kubernetes hace tiempo de ejecución. Service Mesh proporciona interoperabilidad.
Más precisamente, Kubernetes tiene algunos componentes que parecen cubrir aspectos de Service Mesh. Pero en Kubernetes son demasiado básicos. Es decir, Kubernetes, en términos de redes, solo le ofrece redes de bajo nivel. Quiero decir, los paquetes IP pueden ir del punto A al punto B. Eso es todo. De acuerdo, hay controladores de Ingress, hay momentos de enrutamiento de nivel superior, es decir, no solo interacción de red. Sin embargo, en Kubernetes, por ejemplo, no hay mecanismos integrados para garantizar la fiabilidad de la ejecución de consultas. Un ejemplo tan simple. En Kubernetes, si el "bajo" (Pod) cae, Kubernetes lo recogerá por sí mismo. Por defecto Este es un mecanismo de reintento. Pero a nivel de interacción de red esto no sucede. Es decir, si el servicio de la página principal envía una solicitud al servicio de cesta, y por alguna razón esto no funcionó, la solicitud no se volverá a intentar.
Service Mesh en este sentido agrega funcionalidad. Permite, si la solicitud falla, repetirla nuevamente. Existen otros mecanismos, como la detección de valores atípicos. Si, por ejemplo, tenemos una flota de "hogares" que trabajan para el servicio de la "página principal", y una flota de "hogares" que son un servicio de la "canasta". Si están separados geográficamente, entonces pueden aparecer cosas en ellos que una parte de los "hogares" ve una parte de los "hogares" y la otra parte de los "hogares" ve la otra parte de los "hogares". En consecuencia, en Service Mesh hay mecanismos que le permiten construir dinámicamente una imagen de quién está disponible para cualquier persona y cambiar entre ellos, todo esto en tiempo real. Y si uno de los "hogares" tiene demasiada latencia, bótelo. Todos los que están "debajo" pueden decidir que con este "hogar" mi conversación es lenta, todos los demás son normales, y esto lento, porque lo echaré de mi piscina. Así es como funciona el mecanismo para detectar anomalías. Cuando tenemos diez "hogares", nueve "hogares" funcionan sin errores, y el décimo constantemente envía errores. O nueve "hogares" responden con una latencia de 15 ms, y uno responde con una latencia de 400 ms. Y Service Mesh decide tirarlo a la basura.
Service Mesh también es bueno para permitirle recopilar estadísticas del lado del cliente. Es decir, tenemos un cliente y tenemos un servidor. Por lo general, las estadísticas se recopilan en el lado del servidor. Bueno, porque es lo más fácil. Queremos utilizar métricas para comprender qué tan bien interactúa nuestro usuario con nuestro servicio. En consecuencia, en teoría, debe medir en el lado del cliente y no en el lado del servidor. Porque hay una gran brecha entre ellos, que está llena de interacciones de red.
Cada componente de toda esta variedad puede fallar.
Y Service Mesh es bueno porque pone al agente de un lado a otro y envía estadísticas desde dos extremos. Y pueden surgir situaciones cuando la latencia del lado del servicio es de 20 ms y del lado del cliente 2 segundos. Por ejemplo, en el lado del servidor, recopilamos estadísticas de un servidor web, pero tenemos el 5% de los paquetes perdidos por alguna razón. Como resultado, debido a la retransmisión en la pila TCP, resulta que nuestro cliente ve latencia en 2 segundos. Y en el lado del servidor, todavía vemos una latencia excelente: como todo se envió al búfer, ¡eso es todo! Estoy bien, tengo una latencia de 20 ms. ¿Y cómo es el cliente?
¿Y cómo resuelves esto?
Básicamente, esto se resuelve mediante la instrumentación del cliente. En el buen sentido, las estadísticas deben recopilarse lo más cerca posible del cliente. Pero las herramientas para el cliente no siempre son posibles y no siempre son convenientes.
¿Cuáles son las métricas de confiabilidad y disponibilidad de su empresa?
Todo es, en general, estándar. Hoy hablaré sobre eso. (Nota. Ivan Speech en el tercer día de Slurm DevOps ) Hay cinco o seis indicadores clave. Los llamados indicadores de nivel de servicio: latencia, durabilidad, frescura, corrección ... Cuando me estaba preparando para la presentación en el Slurm, traté de encontrar casos no estándar en Booking.com, ejemplos interesantes de SLI que no encajaban en este modelo. Porque, en teoría, la idea clave de SRE se basa en una declaración de alto nivel: debemos resaltar una métrica o métricas que reflejen la experiencia del usuario. Y para algunos servicios, la latencia, la durabilidad es adecuada, para otros no. Y cómo encontrar este punto de equilibrio que refleje la experiencia del usuario: esta es una tarea interesante.
¿Qué soluciones únicas vio en Booking.com cuando vino a trabajar allí? ¿O todo es estándar?
No Tenemos muchas cosas que son "no estándar". Expliquemos por qué no es estándar entre comillas. ¿De dónde viene lo no estándar? Lo no estándar a menudo proviene del hecho de que la compañía encontró un problema antes que el mercado, y por lo tanto no existe una solución "estándar". En este sentido, Booking.com, siendo una compañía que ha estado operando en el mercado desde 1997 y ha crecido a tal tamaño, en un momento se enfrentó a una serie de problemas que no se resolvieron.
Por ejemplo, Google. Según mis observaciones, se parece a esto. En su interior realizan importantes desarrollos, que se presentan en público en cinco o diez años. Por ejemplo, hablé con los chicos de Google que parchearon el kernel de Linux. Entonces tuve ciertos problemas en la pila TCP. Les digo: “Este es claramente el problema central. ¿Cómo luchas contra esto? Dicen: “Ah, entonces tenemos un núcleo parcheado. Aquí podemos ajustar la configuración. En 2013, lo reparamos. Y lo estamos implementando en código abierto en 2018 ”.
Casi lo mismo con Service Mesh. También está integrado en la imagen de la tecnología que Google usa internamente. Pero no lo suben directamente a código abierto. Istio es esencialmente una reimplementación de código abierto de su sistema interno. Con Kubernetes también. En mi opinión, esto se debe a que cuando una empresa es pionera, crea soluciones para sí misma. Porque es más rápido, más barato. El código abierto es caro. Y no importa quién diga que necesita difundirlo, realmente necesita construir una comunidad. Y para construir una comunidad, debe invertir un gran esfuerzo. Y solo entonces el regreso irá a ti. Me parece que detrás de cualquier "farmacia" seria hay una comercialización aún más seria, en la que el dinero se invierte naturalmente.
¿Por qué estoy ...? Como dije, al resolver un problema, la empresa hace mucho por sí misma. Y luego ponerlo en código abierto es bastante difícil. Necesita recortar la lógica de negocios y un montón de pequeños detalles. Tenemos nuestro propio servicio Service Mesh, nuestro propio sistema de monitoreo. Y para difundirlo en código abierto, necesita ser rehecho. La publicación de código abierto tiene sus ventajas ...
¿Cuál, por ejemplo?
Marca tecnológica, fidelización, fácil incorporación. Son importantes
No puedes contarlos directamente.
Si, eso es correcto. No cuentes directamente. Esta es una inversión estratégica a largo plazo. No estoy a favor o en contra del código abierto. Debe estar equilibrado, evaluando lo que la compañía le da a la publicación de una tecnología en particular. Balance de estrategia a largo y corto plazo.
Volviendo a la pregunta, ¿cuánto es estándar y no estándar en Booking.com? Diré esto, no la mayoría no es estándar, sino mucho. Debido a que estábamos resolviendo problemas que todavía eran desconocidos en el mercado, u otras compañías solo estaban al comienzo del viaje. Solo para la empresa es más fácil y rápido, y más barato resolver problemas por sí mismos.
PD : No es posible cubrir todo el tema de SRE en una presentación. No solo hay herramientas, también existe la filosofía del enfoque. Por lo tanto, destacamos un Slurm SRE intensivo para este tema , que se llevará a cabo del 3 al 5 de febrero de 2020 . Los oradores serán Ivan Kruglov, desarrollador principal en Booking.com, su colega Ben Tyler, desarrollador principal en Booking.com, Eduard Medvedev , CTO en Tungsten Labs, Eugene Varavva, desarrollador de perfil amplio de Google.