¿Cómo configurar el equilibrio de carga global utilizando Digital Ocean DNS y Nginx?

Una Solución De Trabajo

He tenido un viaje salvaje en los últimos meses averiguando toda la configuración Global-HA. Toneladas de diversión y finalmente me he establecido con un equipo que funciona muy bien, y no es nada como el descrito en la pregunta anterior.

Todavía planeo escribir esto en forma de tutorial, pero el tiempo es escaso mientras me dirijo al sprint final para lanzar mi aplicación a principios del próximo año, así que aquí hay un breve resumen de la plataforma de trabajo que terminé con.

Descripción general

Terminé trasladando toda mi implementación a AWS. Me encanta Digital Ocean, pero la realidad es que AWS está a años luz de ellos (y de todos, en realidad) cuando se trata de los servicios ofrecidos bajo un mismo techo. Mis gastos mensuales subieron ligeramente, pero una vez que terminé de retocar y simplificar terminé con una solución que cuesta alrededor de 7 75/mes por región para la implementación más básica (2 instancias detrás de un ELB). Y un nuevo la región se puede girar y desplegar en aproximadamente 30 minutos.

Equilibrio global

Rápidamente descubrí (gracias a la respuesta de @Brad anterior) que tratar de girar mi propia capa de DNS de equilibrio global es una locura. Fue un infierno de un montón de diversión averiguar cómo funciona una capa como esta, pero a falta de conseguir en un avión y raspar mis nudillos instalar millones de dólares en equipos en todo el mundo, no iba a ser posible rodar mi propio.

Cuando finalmente descubrí lo que estaba buscando, encontré a mi nuevo mejor amigo: AWS Route 53. Ofrece una red DNS robusta con alrededor de 50 nodos a nivel mundial y la capacidad de hacer algunos trucos de enrutamiento realmente geniales, como enrutamiento basado en la ubicación, enrutamiento basado en latencia (que es un poco impresionante) y registros de AWS Alias que enrutan 'automáticamente' el tráfico a otros servicios de AWS que usará (como ELB para el equilibrio de carga).

Terminé usando basado en latencia enrutamiento que dirige el tráfico global al Equilibrador de carga Elástico regional más cercano, que tiene un Grupo de Escalado automático conectado en cualquier región determinada.

Dejaré que usted haga su tarea sobre los otros proveedores: www.f5.com, www.dyn.com, www.akamai.com, www.dnsmadeeasy.com . Dependiendo de sus necesidades, puede haber una mejor solución para usted, pero esto funciona muy bien para mí.

Entrega De Contenido Red

Route 53 se integra muy bien con AWS Cloudfront. Configuro un bucket S3 que estoy usando para almacenar todos los archivos multimedia estáticos que mis usuarios subirán, y he configurado una distribución de Cloudfront a la fuente desde mi bucket S3 media.myapp.com. Hay otros proveedores de CDN, así que haga sus compras. Pero Cloudfront recibe muy buenas críticas y es muy fácil de configurar.

Equilibrio de carga y terminación SSL

Actualmente estoy usando AWS Elastic Load Balancer para equilibrar la carga entre las instancias de mi aplicación, que viven en un Grupo de escalado automático . La solicitud es recibida por primera vez por ELB, momento en el que se termina SSL y la solicitud se pasa a través de una instancia en el Grupo Auto-Scaling.

NOTA: Una advertencia gigante para ELB es que, irónicamente, no maneja muy bien los picos masivos. Un ELB puede tardar hasta 15 minutos en desencadenar un evento de ampliación por sí mismo, creando 500 / timeouts mientras tanto. Un aumento constante y constante en el tráfico supuestamente se maneja bastante bien, pero si te golpean con un pico, puede fallarte. Si sabes que vas a ser golpeado, puedes 'llamar con anticipación' y AWS calentará tu ELB para ti, lo cual es bastante ridículo y anti-patrón a la esencia de AWS, pero me imaginando que están trabajando en ello, o ignorándolo porque no es realmente un gran problema. Siempre puede girar su propio HAProxy o Nginx capa de equilibrio de carga si ELB no funciona para usted.

Grupo de autoescalado

Cada región tiene un ASG que está programado para escalar cuando la carga pasa una métrica determinada:

IF CPU > 90% FOR 5 MINUTES: SCALEUP
IF CPU < 70% FOR 5 MINUTES: SCALEDN

Todavía no he puesto a prueba el combo ELB/ASG. Eso es un poco por debajo de mi lista de tareas pendientes, pero sé que hay muchos otros que utilizan esta configuración y no parece tener ningún problema de rendimiento importante.

La configuración para un Auto-Scaling Group es un poco complicado en mi opinión. En realidad es un proceso de tres pasos:

1. Cree una AMI configurada a su gusto.
2. Cree una configuración de lanzamiento que use la AMI que ha creado.
3. Cree un Grupo de Escalado automático que utilice la Configuración de lanzamiento que ha creado para determinar qué tipo de AMI y de instancia lanzar para cualquier evento de ESCALADO dado.

Para gestionar la configuración y la implementación de aplicaciones cuando se inicia una instancia, se utiliza el campo"Datos de usuario" para introducir un script que se ejecutará una vez que se inicie una instancia determinada. Esta es posiblemente la peor nomenclatura en la historia del tiempo. Cómo" Datos de usuario " describe un script de inicio que solo conoce el autor. De todos modos, ahí es donde pegas el script que maneja todos tus apt-gets, mkdirs, clones de git, etc.

Instancias y Equilibrio interno

También he agregado una 'capa de equilibrio interno' adicional usando Nginx que me permite 'flat-pack" todo mi Nodo.aplicaciones js (app.myapp.com, api.myapp.com, mobile.myapp.com, www.myapp.com, etc.myapp.com) en todos los casos. Cuando una instancia recibe una solicitud que se le pasa de ELB, Nginx gestiona el enrutamiento de la solicitud al nodo correcto.puerto js para cualquier aplicación dada. Algo así como una contenedorización de pobres. Esto tiene el beneficio adicional de que cada vez que una de mis aplicaciones necesita hablar con la otra (como cuando app. necesita enviar una solicitud a api.) se hace a través de localhost:XXXX en lugar de tener que salga a través de la red de AWS o del propio Internet.

Esta configuración también maximiza el uso de mis recursos al eliminar cualquier infraestructura inactiva si la capa de aplicación que aloja recibe tráfico ligero. También elimina la necesidad de tener y ELB / ASG combo para cada aplicación, ahorrando más dinero.

No hay trampas o advertencias que me he encontrado usando este tipo de configuración, pero hay una solución que debe estar en su lugar con respecto a la comprobación de salud (ver debajo).

También hay una buena ventaja en que todas las instancias tienen un rol de IAM, lo que significa que sus credenciales de AWS se 'cuecen' en cada instancia al nacer y son accesibles a través de sus ENV vars. Y AWS rota automáticamente sus credenciales por usted. Muy seguro, muy genial.

Controles de salud

Si vas por la ruta de la configuración anterior, empaquetando todas tus aplicaciones en una caja y ejecutando un equilibrador de carga interno, entonces necesitas crear un poca utilidad para manejar las comprobaciones de salud de ELB. Lo que hice fue crear una aplicación adicional llamada ping.myapp.com. Y luego configuré mis comprobaciones de estado de ELB para enviar cualquier comprobación de estado al puerto en el que se está ejecutando mi aplicación ping, así:

Ping Protocol: HTTP
Ping Port:     XXXX
Ping Path:     /ping

Esto envía todas las comprobaciones de estado a mi pequeño ayudante ping, que a su vez golpea localhost:XXXX/ping en todas las aplicaciones que residen en la instancia. Si todos devuelven una respuesta de 200, mi aplicación ping devuelve una respuesta de 200 a la comprobación de estado del ELB y instances puede vivir otros 30 segundos.

NOTA: No utilice Comprobaciones de estado de Escalado automático si está utilizando un ELB. Utilice los controles de salud del ELB. Es un poco confuso, pensé que eran lo mismo, no lo son. Tiene la opción de habilitar uno u otro. Ve con ELB.

La Capa De Datos

Una cosa que está claramente ausente de mi configuración es la capa de datos. Yo uso Compose.io como mi proveedor de capa de datos administrada y me despliego en AWS, por lo que obtengo una latencia muy baja entre mis capas de aplicaciones y mi capa de datos. He hecho una investigación preliminar sobre cómo desplegaría mi capa de datos a nivel mundial y descubrí que es muy compleja y muy costosa, por lo que la he eliminado de mi lista como un problema que aún no necesita resolverse. El peor de los casos es que voy a ejecutar mi capa de datos en US-East solamente y reforzar el hardware. Esto no es lo peor del mundo ya que mi API es estrictamente datos JSON en el cable por lo que el la respuesta promedio es relativamente pequeña. Pero puedo ver que esto se convierte en un cuello de botella a gran escala, a escala global - si alguna vez llego allí. Si alguien tiene alguna entrada en esta capa me encantaría escuchar lo que tienes que decir.

Ta-Da!

Alta Disponibilidad Global Con Un Presupuesto De Cerveza. Sólo me llevó 6 meses averiguarlo.

Me encanta escuchar cualquier comentario o idea de cualquiera que le lea esto.

Puede utilizar Anycast para su servicio web de forma gratuita si utiliza el plan gratuito de Cloudflare.

Digital Ocean ahora admite el equilibrio de carga de los propios servidores. Es extremadamente fácil de configurar y funciona muy bien! Le ahorra tener que agregar componentes innecesarios como nginx (si solo desea usar para el equilibrio de carga).

Estábamos teniendo problemas al usar cargas de archivos SSL con nginx en un servidor digital Ocean, sin embargo, desde la actualización Digital Ocean, hemos eliminado nginx y ahora usamos la función de equilibrio de carga de Digital Ocean y funciona como lo necesitamos.