¿Sin código? ¡Sin problema! Cómo los servidores GraphQL fallan y cómo fortalecer tus resolvers

♪♪ Gracias por unirse a nosotros. Estamos aquí para hablar sobre GraphQL, sin código, sin problema, cómo se rompen los servidores de GraphQL y cómo fortalecer tus resolvers. Así que, primeras presentaciones, mi nombre es Kevin. He estado aquí en solo.io durante varios años, trabajando en una amplia variedad de proyectos pero relevante para lo que estamos hablando hoy, un gran defensor de nuestro Envoy en GraphQL y Envoy Filter y proyectos relacionados. Y hoy nos acompaña amablemente Sai.

Sí, hola, soy Sai. Soy un ingeniero de software en solo.io. Junto con Envoy, Istio y Flagger, he contribuido a varios proyectos de open-source, incluyendo Glue, y también estoy aquí hablando sobre GraphQL. Soy uno de los ingenieros líderes del esfuerzo de GraphQL y service mesh aquí en solo.io. Y hablando de solo.io, ¿quiénes somos exactamente? Somos una startup en Cambridge, Massachusetts, y nos consideramos líderes de la industria en networking de aplicaciones, service mesh, y tecnologías modernas de API gateway. Y más recientemente, GraphQL, pero continuemos.

Entonces, sí, los objetivos para hoy. Queremos hablar sobre el estado actual de los servidores de GraphQL, específicamente los resolvers. ¿Cómo fallan los resolvers programáticos? ¿Cómo los solucionamos? Luego queremos echar un vistazo concreto a los resolvers declarativos, cómo podrían funcionar y demostrarlo. Solo vamos a verlo en acción.

Así que vamos directo al grano. El estado actual de las cosas. Quiero decir, esto es una conferencia de GraphQL. Todos deberíamos estar familiarizados con esto, pero solo para recapitular. Aquí a la izquierda, tenemos un cliente móvil simple que realiza una solicitud GraphQL a un servidor GraphQL. Este servidor aquí resuelve la solicitud para un servicio de pagos y planes, como un servicio telefónico, por ejemplo. Tenemos tres réplicas del servicio de pagos y tres réplicas del servicio de planes como se indica en las líneas punteadas. Este servidor GraphQL resuelve algunos campos en el servicio de pagos y otros en el servicio de planes, los reconcilia a través del esquema y devuelve todos los data aquí a la derecha en esa única respuesta GraphQL.

Así que vamos a sumergirnos en ello, tenemos un único resolvedor aquí. Así que solo quería centrarme en el servicio de planes. Puedes ver aquí que devuelve como una respuesta JSON estándar a nuestro servidor GraphQL. Y el servidor sabrá en el motor de ejecución cómo poner eso de nuevo en tu esquema y enviar la respuesta de vuelta.

En particular, me gustaría centrarme en cómo esto está funcionando un poco por debajo. Como mencioné antes, tenemos tres réplicas del servicio de planes aquí. Ahora, cuando tenemos tres réplicas, simplemente elegimos una al azar para equilibrar la carga. Para ser concretos, usaré Kubernetes como ejemplo aquí, pero tu infraestructura tiene algún tipo de lógica equivalente en algún lugar si estás, ya sabes, eligiendo entre tres servicios de una réplica para satisfacer las demandas de escalado de tu infraestructura.

En el ejemplo de Kubernetes aquí, el código del resolvedor podría verse así. Tienes un cliente HTTP que intenta hacer una solicitud, una solicitud GET con parámetros de consulta a esa entrada DNS. En el ejemplo de Kubernetes, resolviste eso a través de DNS para obtener ese servicio de IP de clúster correcto, en el servicio de Kubernetes, y esa IP de clúster es una IP virtual que se resuelve a través del equilibrio de carga a una de estas tres IP para los pods. La clave aquí es que estamos eligiendo al azar uno de estos tres pods para golpear realmente una de estas tres réplicas del servicio.

Ahora, si pensamos en las interrupciones del servidor, supongamos que una de esas tres réplicas se cae por cualquier motivo. Podríamos decir falla de hardware, error en el código que es una fuga de memoria, bloqueo, lo que sea. Lo que esto significará en la práctica es que cuando el servidor GraphQL resuelva esa solicitud, una de esas tres réplicas volverá con un tiempo de espera de solicitud, y luego el cliente verá errores. La interfaz de usuario obtendrá datos incompletos. Esto obviamente es malo y algo que queremos evitar. Entonces sí, como mencioné, queremos minimizar el problema. ¿Cómo podemos hacer esto? Así que mirando un ejemplo, sé que me apoyé en Kubernetes antes, esto es solo para hacer las cosas concretas. Pero nuevamente, esto es algo que probablemente tu infraestructura tenga de alguna forma u otra, y es posible que simplemente no estés al tanto. Aquí, vamos a ver qué hacen las sondas de preparación y supervivencia. Nuevamente, los escenarios que esto intenta resolver son principalmente cosas como una fuga de memoria, bloqueo de tu código, o incluso simplemente una falla de hardware, volver a programar las cosas. La esencia de esto es que en Kubernetes, al menos tienes un pod, tienes un proceso aquí. En este ejemplo, tenemos una sonda de supervivencia, y lo que hace es hacer una solicitud HTTP GET a tu servicio en /health. Espera tres segundos antes de hacer la primera solicitud, y lo más importante, hace una solicitud cada tres segundos. Y así está simplemente haciendo una encuesta todo el tiempo. Y si comienza a ver fallas, sabe que tu servicio no está saludable. Realmente no le importa la razón, solo sabe que no está saludable y probablemente sea mejor reiniciar reiniciar el proceso, moverlo a otro hardware. Y nuevamente, esta es la forma de Kubernetes, pero esto se puede hacer de varias formas diferentes, un vigilante, algún tipo de monitor de procesos, infiltrado por puppet. Y gran parte de esto está fuera del ámbito de la conferencia de GraphQL, pero esto probablemente exista de alguna forma. Entonces nuestro objetivo es minimizar el problema.

¿Podemos hacer más? Ya sabes, tenemos este mecanismo de sondeo cada tres segundos, pero pensemos en el escenario donde tenemos una API muy ocupada. Por eso tenemos réplicas. Estábamos recibiendo miles de solicitudes. Eso es bastante lento. Nos llevará un tiempo, ya sabes, inyectar esos puntos finales y realmente servir respuestas saludables a nuestro cliente.

Entonces, ese mecanismo de sondeo activo es como una verificación de salud activa. Estoy seguro de que hemos oído hablar de circuit breaking antes, pero otra forma de resolver esto es mediante una verificación de salud pasiva. Y así, un seudocódigo muy simple a la izquierda sobre cómo podría funcionar esto, solo para repasarlo juntos, es decir, supongamos que nuestro código de resolutor está instrumentado con algún conocimiento de las IPs y DNS. Y lo que podríamos hacer es, ya sabes, cuando el servidor GraphQL se inicia, obtenemos todas las IPs detrás de nuestro servicio, tenemos todas nuestras réplicas. Luego, cuando resolvemos, simplemente elegimos una IP saludable al azar y la enrutamos. Y si resulta que recibimos una respuesta que no está bien, entonces la expulsamos, la marcamos como no saludable, y la próxima vez no lo intentaremos. Luego, podemos, ya sabes, volver a marcarla como saludable después de un tiempo de espera, pero la clave de esto es que, si estamos recibiendo miles de solicitudes por segundo, podemos instruir a nuestro servidor para que diga, `oye, si tienes cinco errores seguidos, como deja de intentarlo, ¿sabes? Como que este punto final probablemente no está bien, nuestro resolutor puede hacerlo mucho mejor, ser más inteligente y no enviar solicitudes a esta réplica que sabe que probablemente no funcionará. Ahora, obviamente, este código no está listo para producción, definitivamente no quieres instrumentar tus resolutores con este tipo de lógica, pero esta lógica debe estar en algún lugar. Si queremos incorporar esto en nuestro servidor GraphQL, ¿dónde lo colocamos? Podría estar en algún tipo de middleware del servidor GraphQL detrás de tu servidor GraphQL, podríamos intentar mover partes de él a un servidor DNS, malo por otras razones, podríamos usar un proxy local de nodo, otro balanceador de carga, hay muchas opciones aquí, podemos profundizar.

Simplemente retrocediendo un poco, así que hemos visto el circuit breaking aquí como ejemplo, pero el problema aquí es que GraphQL es un único punto final, es un único servidor que vive en un nodo que tiene que ser responsable de muchas responsabilidades antes de enviar solicitudes a servicios secundarios. Entonces, si estoy operando un servidor GraphQL e implementando resolutores, a veces tengo que instrumentarlos con cosas como preocupaciones de failover, circuit breaking, como acabamos de hablar, una política de reintento, autorización, autenticación, límites de velocidad. Puedes ver aquí a la izquierda nuestro resolutor ideal. Queremos que los resolutores sean livianos, muy simples de leer y comprender. Pero a menudo vemos resolutores instrumentados con cosas como las de la derecha, aquí tenemos comprobaciones de autenticación, para asegurarnos de que tienes permiso para acceder al backend. Pero esto no es ideal. Además, algunas de estas preocupaciones que estamos hablando y que deben ser manejadas en el nodo, como el hardware mismo en el que reside el servidor GraphQL. Por ejemplo, como el circuit breaking. Si quisiéramos mover esto a otro hardware, estaríamos introduciendo otro punto de falla. Más puntos de falla en la red, eso es más difícil de comprender. Son sistemas distribuidos, es mucho mejor si lo mantenemos local. Entonces, mencionamos algunas de esas opciones, podríamos considerar agregar otro proxy que tenga este tipo de conocimiento contextual en el mismo hardware. Así que puedes tener un servidor GraphQL que luego enrutará a un proxy local y ese proxy tendrá ese conocimiento de circuit breaking y autenticación y enrutará a los servicios secundarios. O podríamos juntarlos. ¿Y si fueran una sola cosa? ¿Y si pensamos en nuestro servidor GraphQL como algo menos de un servidor y más como un protocolo o una capa que existe en nuestro proxy preexistente o infraestructura? Esto se adentra un poco en las ideas que tengo sobre API Gateway y Service Mesh. Esto es un poco de lo que hace Solo y tal vez sea nuevo para muchos de ustedes que asisten a una charla sobre GraphQL.

Pero la idea real aquí a la izquierda, por ejemplo, es que si piensas en las solicitudes que entran y salen de tu empresa, tu red, generalmente tienes algo en el borde, esta cosa en el borde se llama una API Gateway o a veces detrás de un balanceador de carga. Es responsable de cosas como un firewall y prevenir fugas de datos personales. Ese tipo de lógica se implementa en un montón de proxies inversos. Por ejemplo, NGINX, Envoy proxy, HAProxy, y luego maneja enrutamiento complejo, failover, circuit breaking a tus servicios backend, ya sean microservicios monolíticos o funciones en la nube o clústeres de Kubernetes. Realmente, el único punto que quería mencionar es que tienes proxies inversos y es probable que ya existan en tu infraestructura, ya sea que estés consciente de ellos o no.

Del mismo modo, eso maneja lo que llamaríamos norte-sur, sabes, dentro o fuera de tu tráfico de red. A la derecha, también tenemos la idea de service mesh. Esto es aún más incipiente o nuevo, pero esto utiliza conjuntos similares de proxies, como Envoy, NGINX, HAProxy, para manejar el enrutamiento entre servicios dentro de tu red. Así que piensa en la observabilidad estandarizada, métricas, trazabilidad, así como, ya sabes, casos de uso comunes, encriptación en todas partes, redes de confianza cero, y tu infraestructura puede tener esto ya y es posible que ya tengas un proxy Anhui, ya sabes, junto a todos tus servicios sin siquiera saberlo.

Así que hablamos un poco sobre los problemas que estamos viendo actualmente con los resolutores y nuestro modelo de implementación actual y muchos servidores GraphQL donde es posible que necesites tener un proxy frente a él o un proxy inverso frente a tu servidor GraphQL actual y hablamos sobre cómo podemos fusionar el servidor GraphQL y el proxy juntos. Y hablemos un poco sobre cómo funciona esto y cuáles son los beneficios de hacerlo realmente. Ahora que tenemos nuestro servidor GraphQL como parte de nuestro proxy, obtenemos muchos beneficios que antes venían solo de tener proxies, como el almacenamiento en caché, la autorización, la autenticación, la limitación de velocidad, el firewall de aplicaciones web, así como el enrutamiento del tráfico, el tráfico de GraphQL de los usuarios a los servicios backend. Y también puedes enrutar el tráfico de forma segura a través de TLS a tus servicios backend y tener comunicación segura dentro de tu clúster desde tu proxy, tu API gateway a tus servicios backend. Y hablamos un poco sobre el hecho de que podríamos hacer esto en código, o también podemos hacerlo como configuración. Elegimos hacerlo más como configuración. Y aquí tienes un ejemplo de cómo se ven los resolutores declarativos. Así que en el lado izquierdo, tenemos un resolutor que resuelve una solicitud de GraphQL enrutando, creando una solicitud a un upstream REST. Y a la derecha, tenemos una solicitud gRPC que se está creando. Así que vemos gran parte del esqueleto de cómo se ve exactamente esta configuración declarativa, donde estamos construyendo una solicitud upstream. A la izquierda, vemos un campo de ruta para establecer la ruta hacia el upstream REST, el método HTTP, así como algunos encabezados adicionales que podríamos querer establecer en la solicitud upstream REST. Y a la derecha, vemos, para la solicitud gRPC, tenemos el nombre del servicio, el nombre del método, otros parámetros gRPC que se necesitan para crear una solicitud upstream, así como la referencia real al upstream. En este caso, esto podría ser un servicio Kubernetes, un destino, un servicio externo o algo así. Y luego tenemos este campo JQ. Vamos a profundizar un poco en qué es exactamente JQ, pero esencialmente es un lenguaje de plantillas que nos permite construir datos durante el tiempo de ejecución a partir de nuestra solicitud GraphQL en el protocolo específico que requiere el upstream. En este caso, estamos construyendo la ruta dinámicamente a partir de los argumentos y la consulta de GraphQL. Así que profundicemos un poco en qué es JQ realmente, y podemos enmarcar mejor lo que JQ resuelve al describir un problema. Y en este caso, tenemos un esquema que devuelve una matriz de objetos de revisión, y los objetos de revisión tienen un campo de revisor y calificaciones. Pero luego nuestro upstream responde con datos que se ven así, donde tenemos un montón de pares clave-valor, y básicamente un diccionario que tiene el nombre del revisor y las calificaciones. Ahora, esto no es algo que GraphQL sepa cómo trabajar nativamente. La especificación de GraphQL no incluye este tipo de forma de datos.

Entonces tenemos el problema de tener que transformar los datos de upstream en datos que los servidores GraphQL realmente puedan reconocer. Y para hacer eso, utilizamos JQ, que es un lenguaje de transformación expresivo. Aquí, mostramos que a través de una serie de filtros, podemos transformar los datos de solicitud o respuesta de upstream en datos que realmente son reconocidos por nuestro esquema y filtro de GraphQL. Recomiendo encarecidamente investigar más sobre JQ, ya que es un lenguaje extremadamente poderoso para transformar JSON. Gracias Sai por brindar un ejemplo concreto aquí.

Mirando desde una perspectiva más amplia, lo que estamos tratando de hacer aquí es simplemente reutilizar la infraestructura existente. Muchas empresas ya tienen API gateways o service mesh y ya tienen implementados estos proxies inversos. Obviamente, aprovechamos nuestra CDN para las consultas en caché y los servicios de respaldo de larga duración, pasándolos a través de suscripciones GRPC de GraphQL. Pero realmente, el sentimiento es que menos es más. Si podemos aprovechar nuestra infraestructura y tratar GraphQL como un protocolo en lugar de un servidor separado, podemos mejorar la experiencia del desarrollador y la confiabilidad.

Sí, veamos esto en la práctica. Veamos una demostración real de cómo funciona en el clúster. Este es nuestro entorno de clúster de Kubernetes. En el lado izquierdo, podemos ver una interfaz de usuario para interactuar con nuestro clúster, y en nuestro clúster tenemos un servicio en ejecución llamado página de producto. Ahora tenemos la versión uno y la versión dos de la página de producto en ejecución. Ahora queremos interactuar y obtener una respuesta de estos servicios a través de una consulta GraphQL, y podemos hacerlo a través del gateway de ingreso, que se está ejecutando aquí. Puedes ver que es el gateway de ingreso de Istio, y eso se ejecuta en Envoy. Si revisamos la imagen en el manifiesto, verás que se está ejecutando nuestro proxy Envoy, y dentro del proxy Envoy hay un filtro de GraphQL. Si envío una solicitud GraphQL, que debería ser familiar para el proxy Envoy, verás que recibimos una respuesta con los datos que queremos. Ahora agreguemos un poco más de detalles a esta solicitud, y obtendremos una respuesta como esta. Es posible que hayas notado que algunas de nuestras solicitudes están fallando. Y están fallando con el mensaje 'rest resolver got response status 503 from the upstream'. Esto significa que nuestro filtro de GraphQL no puede comunicarse con uno de nuestros servicios de upstream, y esto es esperado. Si observamos las imágenes utilizadas en estas dos implementaciones diferentes del servicio de página de producto, una de las imágenes es en realidad una imagen de curl no receptiva, lo que significa que si enviamos cualquier tipo de tráfico a ella, no responderá con ningún dato. Pero la otra imagen es un servicio real, nuestro servicio de reserva para una página de producto proporcionado por Istio. Entonces, lo que realmente está sucediendo aquí es que nuestro tráfico está siendo balanceado implícitamente por Kubernetes entre los dos servicios backend para nuestro servicio de página de producto. ¿Cómo mitigamos este comportamiento? Bueno, podemos usar una política de detección de valores atípicos, que nos permite eliminar los servicios no saludables del grupo de puntos finales a los que se dirigen las solicitudes de GraphQL en el upstream. ¿Cómo se ve esta política de detección de valores atípicos? Se ve algo así. Dice que podemos aplicar esta política de detección de valores atípicos a nuestros servicios y decir que si nuestros servicios reciben al menos un error consecutivo, queremos eliminar esa instancia particular del servicio del grupo de nodos saludables o del grupo de puntos finales saludables. Así que vamos a aplicar esta política de detección de valores atípicos.

Podemos continuar y echar un vistazo a la política, esperar a que se actualice el campo de estado, lo que significa que sabemos que nuestro sistema lo ha procesado. Ahí vamos, y podemos ver el campo de estado se actualiza aquí mismo. Eso dice estado aceptado. Entonces, ahora lo que deberíamos ver es que podemos seguir haciendo curl a nuestro servicio, y en el momento en que reciba un 503, el servicio defectuoso, la página de producto V2, se eliminará del grupo de puntos finales saludables. Entonces, ahora el resto de nuestras solicitudes deberían estar completamente saludables, y verás que estamos recibiendo los data que esperamos.

Ahora hay una cosa más, y eso es el tiempo de inyección base. Eso significa cuánto tiempo el punto final estará expulsado del grupo de puntos finales saludables. Todo esto dice es que después de 60 segundos, el punto final se volverá a agregar para ver si es necesario volver a interrumpir el circuito, o si el punto final está saludable nuevamente. Y así es como hemos hecho que nuestros resolvers sean muy resilientes contra los servicios en el backend que se caen. No lo demostré en esta demostración, pero podemos agregar cosas como conmutación por error, reintentos, y otras políticas que hacen que nuestros resolvers sean súper resilientes.

Y esa fue nuestra demostración. Así que en nombre de solo.io y Kevin y yo, solo queríamos decir gracias por recibirnos aquí en GraphQL Galaxy. Únete a nosotros en nuestro Slack público y síguenos en Twitter. Estamos muy contentos de continuar la discusión allí y participar con ustedes en la community. ♪ Hey, hey, hey, hey, hey, hey, hey, hey, hey, hey ♪