Lentitud de SSL en EC2

Question

Implementamos nuestra aplicación de rieles en EC2. En nuestra configuración, tenemos dos proxies en instancias pequeñas detrás del DNS round-robin. Estos ejecutan equilibradores de carga nginx para una granja de servidores web en crecimiento y contracción dinámica. Cada servidor web también ejecuta nginx con un grupo de mongrels. El nginx aquí se encarga del contenido estático y del equilibrio de carga de los mestizos.

De todos modos, nuestro tráfico en general es HTTPS. Tenemos los 2 proxies que se ocupan de SSL. Me di cuenta de que el rendimiento de nuestra red en esas instancias se limita a solo 60 Mbps aproximadamente. Para contrastar, en las pruebas puedo obtener 700+ Mbps en una instancia pequeña a través de HTTP regular. De hecho, esto es lo mismo que puedo obtener en una gran instancia. Similar a lo que obtuvieron los chicos de Right Scale en their testing. (Amazon dice que una pequeña obtiene E/S de red "moderada", mientras que una grande se "eleva". Si tuviera que especular, creo que esta es solo su forma de decir que hay más instancias pequeñas por caja física que comparten una tarjeta de red . No estoy seguro si esto significa que un gran tamaño tiene una interfaz de red dedicada, pero lo dudaría).

En las pruebas, pude obtener una instancia grande para obtener aproximadamente 250 Mbps SSL. Esto me dice que la CPU o algún otro recurso es el cuello de botella. Sin embargo, nuestros gráficos de supervisión no muestran que la CPU en nuestros servidores proxy esté particularmente ocupada.

Mis preguntas son:

1. ¿Es mi instinto sobre SSL siendo más lento debido a la CPU correcta y nuestros gráficos de monitoreo que están mal? ¿O podría algún otro recurso ser el factor limitante?
2. ¿Deberíamos tomar el costo adicional y poner los servidores proxy en instancias de CPU de alta? ¿O sería mejor simplemente agregar más instancias pequeñas?
3. ¿Deberíamos descargar la terminación SSL a los servidores web? Sin embargo, esto introduce un problema más: ¿cómo obtenemos la dirección IP del cliente en nuestra aplicación? En este momento nuestro proxy lo establece en el encabezado X-FORWARDED-FOR, pero obviamente esto no sería posible si no se está descifrando SSL.

Me encantaría saber acerca de cualquier configuración similar. Juzgamos un poco con su Elastic Load Balancer, pero creo que básicamente nos pone en la misma situación que el n. ° 3 anterior. ¿Alguien más ha hecho el cambio a ELB y ha encontrado que vale la pena?

Answer 1

¿Está utilizando la caché de sesión SSL que proporciona nginx? Eso puede ayudar a nginx a ahorrar en ciclos constantemente reacomodando el cifrado. Consulte http://wiki.nginx.org/NginxHttpSslModule#ssl_session_cache

¿Qué monitoreo está utilizando para determinar el uso de su CPU? SSL generalmente requiere mucha CPU.

Me quedaría con los proxies SSL como una capa designada, de esa manera usted puede escalar el costo de negociar SSL por separado de otras preocupaciones.

Answer 2

El SSL es más lento: verdadero, entonces cualquier solicitud HTTP normal HTTPSSL será más lenta.

Intente crear una configuración similar, en la LAN local, donde tiene 3 mongrel_clust y 2 servidor web. y verifique usando el cargador curl, enviando aproximadamente 5k solicitudes.

si todo está bien, eso es genial. puede ser que trabaje más duro con los chicos de EC2.

Answer 3

Estoy usando SSL en Apache, que maneja el acceso a nuestro repositorio de Subversion en una instancia de Small Windows EC2. En las pruebas, descubrí que el acceso HTTPS era un poco más lento que HTTP, pero esa es la razón obvia de que el cifrado/descifrado no es un proceso instantáneo, como era de esperar.

Si las métricas de su CPU son correctas y no está viendo una carga excesiva, la consecuencia es que el ancho de banda es el factor limitante; sin embargo, realmente no veo por qué podría obtener más de 700 Mbps en una instancia HTTP, en comparación con solo 60 Mbps en una instancia HTTPS. A menos que las condiciones de prueba no fueran realmente idénticas, por supuesto, y hay algo más que sucede dentro de la instancia de HTTPS que no has tenido en cuenta ...

Por supuesto, las instancias más grandes obtienen una mejor parte del ancho de banda del host que las Smalls: hay menos compitiendo por el recurso. Dado que la red EC2 interna es Gigabit Ethernet, es factible ver 700Mbps en una instancia Grande, suponiendo que ninguna otra instancia Grande en el mismo nodo estuviera haciendo demandas de ancho de banda similares. Para sacar eso de una instancia Small, tendrías que ser realmente afortunado de estar corriendo dentro de un host con poca carga. Y en ese caso, no hay garantía de que mantengas ese nivel de rendimiento: tan pronto como otros Smalls se conecten, tu parte del ancho de banda disponible comenzará a disminuir.

Creo que esto es esencialmente un pequeño problema de ancho de banda de instancia: agregar más Smalls no necesariamente ayudará mucho, porque no tiene control sobre qué host aceleran; Sin embargo, las instancias grandes obtienen una porción más grande del ancho de banda y, por lo tanto, es probable que tengan una disponibilidad de capacidad más consistente.