¡Sorpresa! Esta es una publicación de blog adicional para la serie AI for Web Devs que terminé recientemente. Si aún no has leído esa serie, te animo a que lo hagas. . Échale un vistazo Esta publicación analizará la arquitectura del proyecto existente y las formas en que podemos mejorarla tanto para los desarrolladores de aplicaciones como para el usuario final. Analizaré algunos conceptos generales y utilizaré productos Akamai específicos en mis ejemplos. https://www.youtube.com/watch?v=dvXJmiQY2Xk&embedable=true Arquitectura de aplicación básica La aplicación existente es bastante básica. Un usuario envía dos oponentes y luego la aplicación transmite una respuesta generada por IA sobre quién ganaría en una pelea. La arquitectura también es simple: El cliente envía una solicitud a un servidor. El servidor construye un mensaje y lo reenvía a OpenAI. OpenAI devuelve una respuesta de transmisión al servidor. El servidor realiza los ajustes necesarios y envía la respuesta de transmisión al cliente. Utilicé los servicios de computación en la nube de Akamai (anteriormente ), pero esto sería lo mismo para cualquier servicio de hosting, en realidad. Linodo 🤵 parece un camarero en un restaurante elegante y 👁️🗨️ es “un ojo” o IA. jajaja Técnicamente esto funciona bien, pero hay un par de problemas, particularmente cuando los usuarios realizan solicitudes duplicadas. Podría ser más rápido y rentable almacenar las respuestas en nuestro servidor y acudir solo a OpenAI para solicitudes únicas. Esto supone que no necesitamos que cada solicitud sea no determinista (la misma entrada produce una salida diferente). Supongamos que está bien que la misma entrada produzca la misma salida. Después de todo, una predicción sobre quién ganaría en una pelea probablemente no cambiaría. Agregar arquitectura de base de datos Si queremos almacenar respuestas de OpenAI, un lugar práctico para colocarlas es algún tipo de base de datos que permita una búsqueda rápida y sencilla utilizando a los dos oponentes. De esta manera, cuando se realiza una solicitud, podemos verificar primero la base de datos: El cliente envía una solicitud a un servidor. El servidor busca una entrada existente en la base de datos que coincida con la entrada del usuario. Si existe un registro anterior, el servidor responde con esos datos y la solicitud se completa. Omita los siguientes pasos. De lo contrario, el servidor sigue desde el paso tres del flujo anterior. Antes de cerrar la respuesta, el servidor almacena los resultados de OpenAI en la base de datos. Las líneas de puntos representan solicitudes opcionales y el tipo 💽 parece un disco duro. Con esta configuración, la base de datos manejará cualquier solicitud duplicada. Al hacer que algunas de las solicitudes de OpenAI sean opcionales, podemos reducir potencialmente la cantidad de latencia que experimentan los usuarios, además de ahorrar dinero al reducir la cantidad de solicitudes de API. Este es un buen comienzo, especialmente si el servidor y la base de datos existen en la misma región. Se lograrían tiempos de respuesta mucho más rápidos que ir a los servidores de OpenAI. Sin embargo, a medida que nuestra aplicación se vuelva más popular, es posible que comencemos a recibir usuarios de todo el mundo. Las búsquedas más rápidas en bases de datos son excelentes, pero ¿qué sucede si el cuello de botella es la latencia del tiempo transcurrido en vuelo? Podemos abordar esa preocupación acercando las cosas al usuario. Incorporación de Edge Compute Si aún no está familiarizado con el término "borde", esta parte puede resultar confusa, pero intentaré explicarla de forma sencilla. Edge se refiere a que el contenido esté lo más cerca posible del usuario. Para algunas personas, eso podría significar dispositivos IoT o torres de telefonía celular, pero en el caso de la web, el ejemplo canónico es un . Red de entrega de contenido (CDN) Te ahorraré los detalles, pero una CDN es una red de computadoras distribuidas globalmente que pueden responder a las solicitudes de los usuarios desde el nodo más cercano de la red ( ). Si bien tradicionalmente estaban diseñados para activos estáticos, en los últimos años comenzaron a admitir computación de borde ( ). algo sobre lo que he escrito en el pasado También algo sobre lo que he escrito en el pasado. Con la computación perimetral, podemos acercar gran parte de nuestra lógica de backend al usuario, y no se limita a la computación. La mayoría de los proveedores de computación perimetral también ofrecen algún tipo de almacén de valores clave eventualmente consistente en los mismos nodos perimetrales. ¿Cómo podría eso afectar nuestra aplicación? El cliente envía una solicitud a nuestro backend. La red informática de borde enruta la solicitud al nodo de borde más cercano. El nodo perimetral busca una entrada existente en el almacén clave-valor que coincida con la entrada del usuario. Si existe un registro anterior, el nodo perimetral responde con esos datos y la solicitud se completa. Omita los siguientes pasos. De lo contrario, el nodo perimetral reenvía la solicitud al servidor de origen, que la pasa a OpenAI y yadda yadda yadda. Antes de cerrar la respuesta, el servidor almacena los resultados de OpenAI en el almacén de valores clave del borde. El nodo de borde es el cuadro azul y está representado por 🔪 porque tiene un borde, EdgeWorker es el producto informático de borde de Akamai representado por 🧑🏭 y EdgeKV es el almacén de valores clave de Akamai representado por 🔑🤑🏪. El cuadro de borde está más cerca del cliente que el servidor de origen en la nube para representar la distancia física. Puede que el servidor de origen no sea estrictamente necesario aquí, pero creo que es más probable que esté allí. Por el bien del flujo de datos, computación y lógica, esta es prácticamente la misma que la arquitectura anterior. La principal diferencia es que los resultados almacenados anteriormente ahora están muy cerca de los usuarios y se pueden devolver casi de inmediato. (Nota: aunque los datos se almacenan en caché en el borde, la respuesta aún se construye dinámicamente. Si no necesita respuestas dinámicas, puede ser más sencillo usar una CDN frente al servidor de origen y configurar los encabezados HTTP correctos en caché la respuesta. Hay muchos matices aquí, y podría decir más, pero... bueno, estoy cansado y realmente no quiero hacerlo. No dudes en comunicarte con nosotros si tienes alguna pregunta). ¡Ahora estamos cocinando! Cualquier solicitud duplicada será respondida casi de inmediato, al mismo tiempo que nos ahorrará solicitudes API innecesarias. Esto ordena la arquitectura de las respuestas de texto, pero también tenemos imágenes generadas por IA. Almacenar en caché esas imágenes Lo último que consideraremos hoy son las imágenes. Cuando trabajamos con imágenes, debemos pensar en la entrega y el almacenamiento. Estoy seguro de que la gente de OpenAI tiene sus propias soluciones, pero algunas organizaciones quieren poseer toda la infraestructura por razones de seguridad, cumplimiento o confiabilidad. Algunos incluso pueden ejecutar sus propios servicios de generación de imágenes en lugar de utilizar OpenAI. En el flujo de trabajo actual, el usuario realiza una solicitud que finalmente llega a OpenAI. OpenAI genera la imagen pero no la devuelve. En cambio, devuelven una respuesta JSON con la URL de la imagen, alojada en la infraestructura de OpenAI. Con esta respuesta, se puede agregar una etiqueta a la página usando la URL, lo que inicia otra solicitud para la imagen real. <img> Si queremos alojar la imagen en nuestra propia infraestructura, necesitamos un lugar donde almacenarla. Podríamos escribir las imágenes en el disco del servidor de origen, pero eso podría consumir rápidamente el espacio en el disco y tendríamos que actualizar nuestros servidores, lo que puede resultar costoso. es una solución mucho más barata ( ). En lugar de usar la URL de OpenAI para la imagen, podríamos cargarla en nuestra propia instancia de almacenamiento de objetos y usar esa URL en su lugar. Almacenamiento de objetos También he escrito sobre esto. Eso resuelve la cuestión del almacenamiento, pero los depósitos de almacenamiento de objetos generalmente se implementan en una sola región. Esto se hace eco del problema que tuvimos al almacenar texto en una base de datos. Una sola región puede estar alejada de los usuarios, lo que podría provocar mucha latencia. Habiendo introducido ya la ventaja, sería bastante trivial agregar funciones CDN solo para los activos estáticos (francamente, cada sitio debería tener una CDN). Una vez configurada, la CDN extraerá imágenes del almacenamiento de objetos en la solicitud inicial y las almacenará en caché para futuras solicitudes de visitantes en la misma región. Así es como se vería nuestro flujo de imágenes: Un cliente envía una solicitud para generar una imagen basada en sus oponentes. Edge Compute comprueba si los datos de imagen para esa solicitud ya existen. Si es así, devuelve la URL. La imagen se agrega a la página con la URL y el navegador solicita la imagen. Si la imagen se almacenó previamente en caché en la CDN, el navegador la carga casi de inmediato. Este es el final del flujo. Si la imagen no se ha almacenado en caché previamente, la CDN extraerá la imagen de la ubicación de almacenamiento del objeto, almacenará en caché una copia para futuras solicitudes y devolverá la imagen al cliente. Este es otro extremo del flujo. Si los datos de la imagen no están en el almacén de valores-clave de borde, la solicitud para generar la imagen va al servidor y luego a OpenAI, que genera la imagen y devuelve la información de la URL. El servidor inicia una tarea para guardar la imagen en el depósito de almacenamiento de objetos, almacena los datos de la imagen en el almacén de valores-clave de borde y devuelve los datos de la imagen al cálculo de borde. Con los nuevos datos de la imagen, el cliente crea la imagen que crea una nueva solicitud y continúa desde el paso cinco anterior. La red de entrega de contenido se indica mediante un camión (🚚) y una señal (📶), y el almacenamiento de objetos se indica mediante calcetines en una caja (🧦📦) u objetos almacenados. Este título probablemente no sea necesario, ya que creo que está claro, pero estoy demasiado orgulloso de mi juego de emojis y necesito validación. Gracias por consentirme. Continuar. de reparto de red Es cierto que esta última arquitectura es un poco más compleja, pero si su aplicación va a manejar un tráfico importante, vale la pena considerarla. Voilá ¡Tocar el asunto exacto! Con todos esos cambios implementados, hemos creado texto e imágenes generados por IA para solicitudes únicas y proporcionamos contenido almacenado en caché desde el borde para solicitudes duplicadas. El resultado son tiempos de respuesta más rápidos y una experiencia de usuario mucho mejor (además de menos llamadas API). Mantuve estos diagramas de arquitectura aplicables en varias bases de datos, computación perimetral, almacenamiento de objetos y proveedores de CDN a propósito. Me gusta que mi contenido sea ampliamente aplicable. Pero vale la pena mencionar que integrar la ventaja es algo más que solo rendimiento. También hay muchas funciones de seguridad realmente interesantes que puedes habilitar. Por ejemplo, en la red de Akamai, puede tener acceso a cosas como , , , y más. Sin embargo, todo eso está más allá del alcance de la publicación de hoy. cortafuegos de aplicaciones web (WAF) Protección de denegación de servicio distribuida (DDoS) detección inteligente de robots Entonces, por ahora, los dejo con un gran “gracias” por leer. Espero que hayas aprendido algo. Y, como siempre, no dude en comunicarse en cualquier momento si tiene comentarios, preguntas o inquietudes. Muchas Gracias Por Leer. Si te gustó este artículo y quieres apoyarme, la mejor manera de hacerlo es , , y . Compártelo Inscríbete a mi boletín de noticias Sigueme en Twitter Publicado originalmente en austingil.com .
