Product
Novedades de producto semanales: consejos para configurar la terminación SSL en Cloud Load Balancers
Nos gusta mantenerte al día de lo que pasa en Mailgun cada semana, pero, a veces, los proyectos en los que trabajamos se encuentran en fase de investigación y desarrollo, y no tenemos mucho que compartir. Es lo que ha ocurrido esta semana, así que no hay mucho que destacar. Pero eso no significa que hayamos estado de brazos cruzados. Dado que la clientela de Mailgun está compuesta por profesionales del desarrollo como nuestro equipo, hemos pensado en compartir lo que hemos aprendido al realizar una tarea de mantenimiento común: añadir la terminación SSL a nuestros Cloud Load Balancers, que gestionan el tráfico del panel de control y del sitio web. Hemos descubierto cosas interesantes, sobre todo en torno al rendimiento, que te pueden resultar útiles en tu propia aplicación. Si no te interesa, no te preocupes: vuelve la semana que viene para descubrir nuevas funciones y mejoras.
Añadir terminación SSL a Rackspace Cloud Load Balancers
Un requisito habitual para los proveedores de SaaS (como Mailgun y gran parte de nuestra clientela) es llevar un registro de las sesiones por dirección IP. Al pasar tráfico por un balanceador de carga, existen diferentes formas de asegurarse de que se conserve la dirección IP original. Antes, usábamos un balanceador de carga F5 que pasa una variable $remoteaddr que utilizábamos en nuestra configuración de nginx. Esta variable era una dirección de cliente extraída de las opciones del socket. Cuando hace poco nos pasamos a Rackspace Cloud Load Balancers para servir el tráfico de nuestro sitio web y panel de control, nos dimos cuenta de que Cloud Load Balancers proporciona la IP del balanceador de carga para $remoteaddr, en lugar de la dirección IP del cliente. Por lo tanto, necesitábamos otra forma de conservar esta información.
Cloud Load Balancers puede añadir un encabezado X-Forwarded-For con el valor IP del cliente; sin embargo, esta opción no funciona para SSL, que es lo que utilizamos en nuestro panel de control. ¿Por qué no funcionaría? Sencilla. Para añadir un encabezado al archivo enviado a través de SSL, el balanceador de carga primero debe descifrar el archivo. Por defecto, un balanceador de carga no está equipado para esto, por lo que no se añade el encabezado. Por suerte, Cloud Load Balancers ofrece una opción de terminación SSL que te permite descifrar el tráfico SSL antes de pasarlo a los servidores de destino. Tiene ciertas ventajas en torno a la reducción de la carga en los servidores de la aplicación. Para que funcione, solo tienes que habilitar la terminación SSL en tu balanceador de carga y proporcionarle un certificado y una clave privada SSL.
En realidad, se trata de un excelente ejemplo de separación de responsabilidades. En lugar de tener todo lo relacionado con SSL en los archivos de configuración del servidor, lo pones en el balanceador de carga y, simplemente, funciona.
Un aspecto importante a tener en cuenta es que, una vez habilitada la terminación SSL, todo el tráfico HTTPS que pase por el balanceador de carga pasará a ser HTTP. Parece obvio, pero es muy común olvidarse de este pequeño detalle. De hecho, nos topamos con este mismo problema al realizar pruebas en nuestro entorno de ensayo. La solución consiste en usar el encabezado X-Forwarded-Proto que el balanceador de carga configura como “https” para el tráfico HTTPS. Aquí tienes un buen ejemplo de cómo hacerlo en nginx.
Un sorprendente resultado de rendimiento usando terminación SSL
Antes de implementar el cambio, queríamos asegurarnos de que el rendimiento no se viera afectado al usar la terminación SSL. Para comprobarlo, hicimos algunas pruebas de rendimiento en nuestro entorno de ensayo y obtuvimos resultados inesperados: los balanceadores de carga con terminación SSL, de media, tuvieron un mejor rendimiento que los que no la tenían.
Para realizar las pruebas, hicimos un GET en tres URL diferentes:
GET /cpGET /cp/logGET /cp/domains[/list]
Cada GET recuperó páginas HTML con y sin todos los recursos incrustados, es decir, analizó el archivo HTML y envió solicitudes HTTP/HTTPS para todas las imágenes, los applets de Java, los archivos JavaScript, los CSS, etc., a los que se hacía referencia en el archivo.
Aunque hubo un caso en el que el rendimiento con SSL fue más lento, de media fue sorprendentemente mejor: el tiempo de carga promedio se redujo de 3957 a 3811 milisegundos, un descenso del 3,7 %. No está nada mal teniendo en cuenta que la terminación SSL añade pasos al proceso de transferir un archivo de la parte cliente al servidor y viceversa.
Eso es todo por esta semana. Esperamos que esta información te resulte útil la próxima vez que necesites añadir la terminación SSL a tus balanceadores de carga. Hasta la semana que viene.
Felices envíos,
El equipo de Mailgun
