Creación de un acortador de URL totalmente sin servidor basado en AWS
En este artículo, queremos presentarle una solución completamente sin servidor para crear un acortador de URL. En los siguientes párrafos, mostraremos un caso de uso del mundo real: desde los requisitos hasta el diseño de una solución basada en los servicios sin servidor y totalmente administrados de AWS.
Hoy en día es fundamental explotar al máximo el potencial de la nube para llevar a cabo proyectos eficientes y exitosos. El paradigma serverless es uno de los más disruptivos, aún revolucionando el sector.
Al explotar los principios de la computación sin servidor, es posible crear aplicaciones en las que el componente de infraestructura escala automáticamente, siguiendo perfectamente la curva de demanda. Una excelente infraestructura serverless le permite reducir los costos de infraestructura y mantenimiento al reducir el área de responsabilidad del cliente. Toda la infraestructura es altamente disponible, escalable y elástica por diseño.
Los requisitos
El acortador de URL proporciona una API que se puede utilizar para la creación de enlaces.
La API debería responder a una solicitud GET como esta https://example.com/api/v1/action/shorten?url=[URI]
La respuesta debe ser texto sin formato y el cuerpo debe contener la URL abreviada https://example.com/f/7427
Al visitar la URL corta, el acortador de URL redirigirá al visitante a la URL completa.
No se necesita autorización ni autenticación para esta versión del acortador de URL.
El acortador de URL debe redirigir y aplicar HTTPS.
Una solución
Intentaremos no usar la solución obvia de simplemente exponer una API RESTFul pública usando API Gateway, Lamba y DynamoDB porque no sería divertido 🙂 y, lo que es más importante, no es la solución más rentable.
Aprovecharemos los siguientes servicios de AWS
- Amazon S3 como almacenamiento de objetos para metadatos de enlaces y como motor de redirección.
- Amazon CloudFront como CDN y punto de entrada único para todas las solicitudes.
- AWS Lambda@Edge para la informática de back-end requerida para generar el enlace acortado.
- Amazon Route53 para administrar las entradas de DNS.
- AWS Amazon Certificate Manager para generar y renovar automáticamente certificados HTTPS.
La idea es crear una API sencilla que aproveche Lambda@Edge.
Lambda@Edge es una forma de utilizar Amazon CloudFront como punto de entrada de su código y ejecutar Lambda más cerca de los usuarios de su aplicación. Esto mejora el rendimiento y reduce la latencia; también tiene capacidades de almacenamiento en caché incorporadas. Lambda@Edge le permite crear una aplicación realmente global sin proporcionar ni administrar infraestructura en múltiples ubicaciones en todo el mundo.
Cuando el usuario invoca la API del acortador de enlaces, la solicitud llega al mejor nodo de CloudFront para el usuario. CloudFront luego iniciará una lambda en la ubicación más cercana.
La lógica Lambda debería ser muy simple; básicamente calcula k, una cadena única de 8 caracteres compuesta de letras mayúsculas, letras minúsculas y números. El número total de enlaces que pueden estar activos simultáneamente es, por lo tanto, 218.340.105.584.896 (218+ enlaces Tera).
Ahora necesitamos un lugar para almacenar nuestra clave única y la URL correspondiente, y DynamoDB es la opción más obvia.
Sin embargo, hay una característica de Amazon S3 que es casi desconocida, que se puede utilizar para reducir aún más el costo de la solución, manteniendo un excelente rendimiento y escalabilidad.
Solicitudes de redirección para un objeto S3
Puede redirigir las solicitudes de un objeto a otro objeto o a una URL arbitraria configurando la ubicación de redirección del sitio web en los metadatos del objeto. Agregar la propiedad x-amz-website-redirect-location a los metadatos del objeto S3 es todo lo que necesita para obtener una redirección 301 cada vez que solicita la clave del objeto. Además, el objeto puede estar vacío (0 bytes).
Podemos aprovechar esta característica usando S3 como un almacén de datos habilitado para CloudFront para nuestra base de datos de valores clave, creando objetos de 0 bytes nombrados usando k como un nombre único y configurando la ubicación de redirección del sitio web de x-amz en el URL original.
Volvamos a nuestro escenario: Lambda@edge almacena un objeto vacío en un depósito de Amazon S3. La clave de objeto se establece en k, y los metadatos x-amz-website-redirect-location se establecen en la URL original.
Los objetos contenidos en el S3 Bucket se utilizan para provocar la redirección HTTP cuando el usuario sigue el enlace a través de CloudFront CDN.
Necesitamos configurar nuestra distribución de CloudFront para usar el S3 Bucket como origen.
Esta solución es económica y rápida, gracias a la distribución CloudFront. Utiliza solo servicios sin servidor y puede escalar de manera rápida y confiable a millones de impresiones.
También es posible configurar un mecanismo para eliminar enlaces antiguos mediante políticas de ciclo de vida de S3.
Infraestructura de AWS
El siguiente es el diagrama de infraestructura de la solución.
Acá el punto de entrada del sistema siempre es CloudFront CDN; integra Lambda@Edge para la API y Amazon S3 para los redireccionamientos de enlaces. El enrutamiento se basa en la ruta.
La CDN puede o no almacenar en caché los resultados de la API; por lo tanto, puede configurar CloudFront para almacenar en caché las respuestas de la API, lo que reduce el costo de cómputo de la solución.
Si habilita el almacenamiento en caché, las llamadas posteriores para acortar la misma URL obtendrán la misma versión abreviada y no ejecutarán una función de Lambda. De lo contrario, cada solicitud activará Lambda y producirá enlaces acortados diferentes y únicos.
Tenga en cuenta que para esta solución, la VPC no se usa en absoluto; aprovecha los servicios completamente administrados en el espacio de redes de AWS.
Motor de redirección
El motor de redirección se realiza utilizando Amazon S3.
El depósito está configurado como alojamiento web estático público, que requiere el motor de redirección. Cada objeto tiene metadatos para indicar al alojamiento web estático que redirija al usuario con un código de estado HTTP 301.
Este depósito se usa como uno de los orígenes de la CDN, por lo que el contenido real se sirve a través de la CDN, no directamente desde S3. Podemos configurar S3 para que el contenido solo se pueda solicitar a través de CloudFront, lo que reduce el riesgo de acceso no deseado a S3 y los costos relacionados.
La redirección para cada clave única se almacena en caché en la CDN para ahorrar costos y mejorar el rendimiento.
Registro y depuración
Lambda está configurado para transmitir registros a AWS CloudWatch y es posible establecer el período de retención para cada grupo de registros.
Debido a que los registros de replicación de Lambda (Lambda@Edge) se transmiten a la región de AWS más cercana, los registros se almacenan en la misma región donde se crea el enlace.
Terminando…
Entonces, para concluir, esta es una solución multirregional, de alta disponibilidad y totalmente sin servidor para crear un acortador de URL simple. ¡Este es un punto de partida perfecto para refinar y discutir más!
¿Alguna vez has implementado algo similar? ¡Cuéntanos en los comentarios!
Si le interesa, puede echar un vistazo a algunos de los otros artículos que he escrito recientemente sobre Laravel:
Diego Pacheco
Ingeniero en Sitemas, MBA (Babson College). Desarrollador PHP/Java/JavaScript. Fundador & CEO de EpicStudio. Entusiasta de las tecnologías web (JavaScript, Vue, Laravel, AWS, Docker) Viajes, Negocios, Surf y Growth.
Recent Post
Class: Comprensión de las declaraciones
Flutter: ¿Cómo conectarlo a Node.js?
