AWS – cómo servir más rápido a los usuarios de ulttwigr

Tenemos nuestra infraestructura dependiendo de AWS en la región de us-east-1. (EC2, CloudFront, RDS, ElastiCache)

Ahora tenemos más y más usuarios de la APAC. Los usuarios comienzan a quejarse de la velocidad de la networking a nuestro website. (tenga en count que ya utilizamos CloudFront para servir activos estáticos)

Algunas pistas después de la investigación:

  1. Clonar un set de infraes a una región APAC (por ejemplo, JP)
    • preocupación
    • Un hecho encontrado por una testing rápida: La latencia entre us-east-1 <—> ap-norteast-1 es alnetworkingedor de 160-180ms.
    • No es realmente factible en nuestro caso. Aunque podemos crear una réplica de lectura de DB en JP, los serveres web deben enviar operaciones de escritura a los Estados Unidos.
    • ElastiCache no admite regiones cruzadas. es decir. US ElastiCache sólo es accesible por instancias de ec2 de EE. UU.
  2. Un VPC en cada región, interconecta ambos VPC con túnel IPSec / VPN. JP contiene sólo serveres web, todos los demás services permanecen en EE.UU.
    • Sin embargo, hay latencia entre EE.UU. y JP
  3. Uso del optimizador WAN para el túnel VPN en # 2
    • ¿Alguien tiene experiencias en esto? No pude encontrar mucho en google para la optimization VPC-a-VPC …
  4. Uso del Railgun de CloudFlare
    • Sólo necesitamos instalar el oyente Railgun en los serveres web de EE. UU.
    • Mucho mucho más simple, incluso no necesitamos nada funcionando en JP

Mis preguntas:

  • ¿Cuál es la mejor manera / mejor práctica de la industria? ¿Hacer escala en otra región? Sé que algunas compañías tienen sus infraes en una sola región solamente, pero cómo aseguran la velocidad para los usuarios ulttwigrinos?
  • Para # 2, ¿ayuda el túnel persistente?
  • Para # 2 / # 3, asumiendo que la latencia y la velocidad de la networking entre regiones pueden ser optimizadas, ¿es realmente necesario tener serveres web en JP? ¿Qué hay de tener sólo serveres proxy en JP que el proxy solicita a los serveres web de EE.UU.?

Cualquier ayuda será apreciada, gracias: D

El mundo es un lugar bastante grande y aunque el ancho de banda de la networking está aumentando de manera constante la latencia de la networking entre una parte del mundo y el extremo opuesto del globo no desaparece en el corto ploop.

La optimization y la optimization en varios niveles pueden mejorar la experiencia del usuario, pero en última instancia alcanzará el nivel en el que la única forma factible de mejorar el performance es networkingucir la latencia al acercar físicamente los datos al usuario final.

http://chimera.labs.oreilly.com/books/1230000000545/ch10.html#MORE_BANDWIDTH_DOESNT_MATTER_MUCH

Un buen libro con muchas ideas y la fuente de la gráfica anterior es High Performance Browser Networking por el ingeniero de performance web Ilya Grigorik.

Lo más económico / óptimo depende de su escenario específico, su base de código y requiere testings cuidadosas. No existe una solución de infraestructura mágica.

La mayoría de las aplicaciones que necesitan escalar masivamente pasan por uno o varios re-layouts para lidiar con eso. Las opciones de layout, la tecnología y las suposiciones que parecían válidas para la cantidad de X de usuarios demostrarían haber estado equivocadas para 100 o 1000 veces más.

Las interesantes lecciones aprendidas se encuentran en el blog High Scalability

Rediseñar el código de su aplicación para que el contenido dynamic se pueda almacenar mejor en caching es un enfoque, por ejemplo, eche un vistazo al model de barniz que permite que su aplicación web invalide el contenido dynamic en caching a petición que funciona realmente bien cuando no se necesita realmente mucho contenido dynamic. regenerado completamente para cada request. Eso le permitirá hacer un mejor uso de un CDN y significa que puede permanecer dentro de una única región de disponibilidad.

Rediseñar su aplicación para que funcione en múltiples zonas de disponibilidad también mejorará la recuperación de diaster y no sólo mejorará el performance para los usuarios internacionales.

Tienes que cambiar entre la experiencia del usuario y dólares. En primer lugar, me gustaría saber cuántos usuarios sobre una base de porcentaje están viniendo de APAC. Si es less de decir 10%, su mejor curso de acción es probablemente esperar para ver qué pasa.

Usted también no dice qué tipo de aplicación está apoyando y cómo es sensible a la latencia. Usted tomaría una decisión si se trataba de una aplicación de chat de video en time real y otra si era una aplicación de medios sociales consistente.

Todo lo dicho, has encontrado el set correcto de opciones.

Me gusta su opción 2 el mejor. Pondría como mucho de la porción del proxy / de la tela tan posible como cerca a la mayoría de usuarios como sea posible. A pesar de que algún tráfico siempre tendrá que volver a su location de us-east-1, tener la primera connection terminará en la región conducirá a una experiencia de usuario mucho mejor. Piense los viajes de ida y vuelta de SSL.

También miraría a SPDY .

También pensaría en pasar de nosotros-east-1 a nosotros-west-2 para su presencia en Estados Unidos.

Los túneles VPN son una buena idea y no tan difícil de configurar.

Establecería túneles networkingundantes usando OpenVPN .