Escalabilidad: ¿Cómo funciona Heroku? La tecnología cambia la vida futura

Bueno, como nadie más respondió, decidí sacar Google y profundizar un poco más. Aquí está mi interpretación de alto nivel de cómo funciona Heroku. Se basa en información pública, pero no creo que haya visto todo reunido en un solo lugar antes.

Algunas partes pueden ser incorrectas o imprecisas, en cuyo caso, corríjame. Traté de anotar los lugares donde hice suposiciones / inferencias / conjeturas. Obviamente, Heroku tiene mucho más de lo que se conoce públicamente.

Solicitar ciclo de vida

Heroku ejecuta servidores DNS que apuntan los dominios “appname.heroku.com” a un subconjunto de sus proxies inversos frontales, o puede configurar un subdominio personalizado con un CNAME que apunta a proxy.heroku.com (que a su vez resuelve el IP proxy inverso), o un dominio raíz con registros A que apuntan directamente a los servidores proxy inversos de Heroku. Se devolverán varias IP (actualmente 3) para proporcionar conmutación por error en caso de que uno o más de los servidores proxy inversos estén inactivos.

Su navegador envía una solicitud HTTP a uno de los servidores proxy inversos (nginx) señalados por el DNS (si no se conecta, debe probar con otra de las IP). La solicitud se reenvía a la capa de caché HTTP. Cuando la respuesta finalmente regresa, la codificación gzip se puede aplicar según el encabezado Content-Type. Los servidores nginx también terminan las conexiones SSL (es decir, HTTPS) desde el navegador. Si desea que un dominio personalizado funcione con SSL (sin depender de SNI), Heroku debe ejecutar una de estas instancias de servidor nginx, con su propia IP, específicamente para su aplicación.
La capa de caché HTTP (Varnish) acepta solicitudes reenviadas desde los servidores proxy inversos. Devolverá una página en caché inmediatamente si está en la caché, o reenviará la solicitud a la “malla de enrutamiento” si no está en caché. Las respuestas devueltas de los servidores de malla / aplicación de enrutamiento se almacenan en caché si se establecen los encabezados HTTP apropiados.
[La información disponible en esta pieza es escasa, es parte de su salsa secreta] La malla de enrutamiento personalizada (escrita en Erlang) busca un servidor de aplicaciones (Heroku lo llama “dinamómetro”) con capacidad para atender su solicitud. Si ninguno se está ejecutando, genera uno. Si la carga es alta y la aplicación paga dinamómetros adicionales, puede generar otro dinamómetro. La solicitud se retiene hasta que se haya iniciado un banco de pruebas o esté inactivo, momento en el cual se reenvía al banco de pruebas nuevo / inactivo.
Los dinamómetros de cada aplicación se extienden a través de la “cuadrícula de dinamómetro”, que consta de muchos servidores (Heroku llama a estos servidores “railgun”) que ejecutan dinamómetros de muchas aplicaciones. Los Dynos se generan cuando es necesario, lo que generalmente solo toma un par de segundos. Los dinamómetros que no responden y de exceso de capacidad finalmente se matan / recogen basura, liberando capacidad para dinamómetros de otras aplicaciones. Parece que Heroku ejecuta al menos 60 dynos / trabajadores por instancia de cañón de riel, que parece ser una “instancia extra grande de alta memoria” EC2 con 17.1GB de RAM y dos núcleos de CPU de 2.67GHz (ver http: // aspen- versiones.heroku.com …)
Tras el despliegue (“git push” en el servidor git de Heroku), el código de aplicación y las dependencias se compilan en “babosas” (railgun dispara las babosas … ¿lo entiendes?), Un sistema de archivos comprimido de solo lectura (SquashFS) que se puede descargar rápidamente a un railgun, montado y ejecutado en un sandbox chroot con el conjunto de variables de entorno de configuración de la aplicación. Cada dinamómetro tiene su propio usuario de Unix, solo puede ver los archivos en su propia cárcel chroot y no puede escribir en el sistema de archivos. La seguridad no depende del sandboxing de VM.
El proceso del servidor de aplicaciones es MRI Ruby (o Node.js) y el servidor web Ruby utilizado es Thin (basado en Mongrel). La pila Ruby expone la interfaz web de Rack.

Despliegue

El servidor git de Heroku acepta los git push al repositorio de cada aplicación de los usuarios permitidos. Un gancho previo a la recepción inicia el resto del proceso de implementación.
Se realiza una comprobación git del HEAD of master.
Para las aplicaciones de Ruby, las dependencias enumeradas en el manifiesto de gemas (.gem) se descargan y las extensiones nativas se compilan si es necesario.
Se eliminan archivos adicionales como .git, .gem, tmp y registros.
La aplicación se compila en el “slug” de SquashFS mencionado anteriormente con sus dependencias y variables de entorno de configuración.
La babosa se prueba al iniciar la aplicación. Si la aplicación no puede iniciar la implementación (incluido el empuje git), se rechaza.
[Estoy haciendo suposiciones aquí.] La malla de enrutamiento deja de enviar solicitudes a dynos que ejecutan babosas viejas. Los dinamómetros antiguos terminan de responder a su solicitud actual y se eliminan mientras se inician nuevos dinamómetros con la nueva babosa, y la malla de enrutamiento comienza a enviar solicitudes a los dinamómetros nuevos.
Las aplicaciones también se reinician después de ciertas operaciones, como establecer variables de configuración y cambiar complementos para que la aplicación tenga los últimos datos de configuración.

DNS

Parece que Heroku ejecuta aproximadamente 6 proxies inversos nginx (más los clientes que pagan $ 100 / mes por una IP / proxy dedicada para que puedan usar SSL en un nombre de dominio personalizado).

De los dominios que verifiqué (algunos cientos encontrados a través de la herramienta “Buscar subdominios” aquí: http://www.magic-net.info/), appname.heroku.com (incluido proxy.heroku.com) devolverá 3 de estas:

50.16.215.196
50.16.232.130
50.16.233.102
75.101.145.87
174.129.212.2

Es posible que el DNS de Heroku esté devolviendo diferentes IP basadas en la carga de los servidores proxy inversos, pero al consultar los 4 servidores de nombres de heroku.com directamente, obtuve diferentes subconjuntos de esas 5 IP. Una distribución aleatoria de IP probablemente proporciona una distribución de carga suficientemente buena.

Y la documentación de Heroku dice señalar los registros A a estos tres:

75.101.163.44
75.101.145.87
174.129.212.2

También es interesante observar que las aplicaciones no están vinculadas a servidores proxy específicos. Si configura el encabezado “Host” en el subdominio de su aplicación, una solicitud a cualquiera de esas IP funcionará.

Base de datos SQL

Se aprovisiona automáticamente una base de datos PostgreSQL para cada aplicación.
Las bases de datos se ejecutan en instancias EC2 compartidas o dedicadas con persistencia EBS.
Los detalles de configuración de la conexión de la base de datos se pasan a dynos a través de variables de entorno.
Las copias de seguridad de bases de datos se realizaron previamente a intervalos periódicos para datos compartidos, pero pronto implementarán un esquema de copia de seguridad continua para todas las bases de datos.
TAPS se puede utilizar para importar / exportar sus bases de datos.

Memcached

Utiliza Membase proporcionado por Couchbase (anteriormente Membase anteriormente NorthScale) como complemento.

Trabajadores

Los trabajadores (anteriormente Trabajo retrasado) también se ejecutan en los servidores Railgun similares a los servidores de aplicaciones.
Casi la mitad de los dinamómetros de la red de dinamómetro de Heroku son trabajadores.

Explotación florestal

Los registros de stdout de servidores y trabajadores de aplicaciones, e incluso algunos de los componentes de infraestructura internos de Heroku (nginx, enrutador, api, slugc) y complementos se envían a un enrutador syslog que desarrollaron llamado Logplex.
Para las aplicaciones Rails, inyectan rails_log_stdout para iniciar sesión en stdout.
Los usuarios pueden acceder a los registros a través de la herramienta de línea de comandos e incluso configurar su propio punto final de syslog.

Complementos

Los complementos de terceros (y algunos de los servicios propios de Heroku) implementan una API REST para automatizar el aprovisionamiento
Cuando un cliente agrega un complemento, Heroku realiza solicitudes a la API del complemento.
El proveedor recibe la solicitud de API y proporciona el complemento para la aplicación.
El proveedor devuelve una respuesta que contiene datos de configuración (ubicaciones y credenciales) que la aplicación puede usar para conectarse a los servicios del complemento.
El slug de la aplicación se vuelve a compilar y se reinicia. Estos datos se exponen a la aplicación a través de variables de entorno como otros datos de configuración.

Tecnología variada

Doozer, “un almacén de datos nuevo, consistente y de alta disponibilidad escrito en Go” para la coordinación distribuida entre sus servicios internos. Doozer es similar a Apache ZooKeeper.
Redis para “una memoria caché redundante de datos de estado compartido, un medio para rastrear grupos dinámicos de instancias en ejecución, un contenedor para datos estadísticos en tiempo real y un almacén de datos transitorios para grandes volúmenes de mensajes de registro”.
RabbitMQ más un DSL Ruby llamado Minion.
Splunk (producto) (http://www.splunk.com/view/SP-CA…) para administrar, monitorear y solucionar problemas de su infraestructura.
Silverline / Load Manager de Librato (https://silverline.librato.com/p…) para la gestión de carga de grano fino.

Referencias

(Lo siento, estos no se citan en línea, pero creo que todos están allí)

http://www.heroku.com/how/archit…
http://devcenter.heroku.com/arti…
http://devcenter.heroku.com/arti…
http://devcenter.heroku.com/arti…
http://devcenter.heroku.com/arti…
http://blog.heroku.com/archives/…
http://blog.heroku.com/archives/…
http://status.heroku.com/inciden…
http://adam.heroku.com/
http://adam.heroku.com/past/2009…
http://adam.heroku.com/past/2011…
http://orion.heroku.com/past/200…
http://groups.google.com/group/h…
https://addons.heroku.com/provid…
http://blog.golang.org/2011/04/g…
https://github.com/heroku y https://github.com/ha
http: //aspen-versions.heroku.com… (inspeccionar procesos y otra información del sistema en un servidor railgun)
http://highscalability.com/herok…
http://pivotallabs.com/talks/30

Actualización 31/05/2011

Heroku lanzó una importante actualización de la plataforma con la pila “Celadon Cedar”: http://news.heroku.com/news_rele…

Heroku.com también recibió una actualización ingeniosa: http://www.heroku.com/how
Lista de nuevos documentos de devcenter: https://gist.github.com/1000964
Procfile (http://adam.heroku.com/past/2011…) se utiliza para definir y gestionar procesos. “web” y “trabajador” se asignan a los dynos y al trabajador existentes, y puede definir tipos de procesos personalizados. La “escala heroku” se utiliza para ajustar el número de cada tipo de proceso que se ejecuta en la plataforma.
Cedar tiene Node.js y Ruby 1.9 de primera clase. Parece haber soporte no oficial para otros idiomas, incluyendo Python (https://gist.github.com/866c7903…), Go y Erlang, y potencialmente la capacidad de usar procesos / idiomas personalizados.
Todos los procesos (web y trabajadores) ahora se consideran “dynos” y se tratan de forma idéntica. (http://devcenter.heroku.com/arti…)
LXC (http://lxc.sourceforge.net/) se utiliza para un mejor aislamiento del proceso además de chroot para el aislamiento del sistema de archivos. http://devcenter.heroku.com/arti…
La nueva pila HTTP herokuapp.com tiene soporte para HTTP / 1.1, sondeo largo, respuestas fragmentadas (http://devcenter.heroku.com/arti…). También admite múltiples solicitudes simultáneas por dyno. La malla de enrutamiento enviará solicitudes al banco de pruebas de inmediato, o si tiene varios bancos de pruebas, seleccionará un banco de pruebas aleatorio. Esto es necesario para aprovechar los servidores web asincrónicos o multiproceso como Node.js, EventMachine, etc.
La pila herokuapp.com no incluye la capa de memoria caché de Varnish porque es incompatible con las respuestas de sondeo largo / fragmentado (se recomienda la memoria caché en rack o memcache). Tampoco tiene el tiempo de espera de 30 segundos presente en la pila heroku.com, pero tiene un tiempo de espera de inactividad de 60 segundos.
Aparentemente, el “banco de datos” es el nuevo nombre de la “red de datos” (http://devcenter.heroku.com/arti…). Cedar le brinda una mayor visibilidad de la plataforma a través del sistema de registro Logplex discutido anteriormente (¡ahora con registros de colores bonitos!), Listados de procesos (“heroku ps”: http://devcenter.heroku.com/arti…), formas más fáciles de ejecutar programas arbitrarios (por ejemplo, “heroku run bash”)
Los procesos están inactivos (cerrados) después de una hora de inactividad.
Los procesos finalizan si se unen a puertos incorrectos (por ejemplo, excepto $ PORT en 0.0.0.0).
Las aplicaciones de cedro se detectan en función de la presencia de “Gemfile” para Ruby o “package.json” para Node.