ruby on rails 3 - perform - Gemas/Servicios para el autoescalamiento de las dinámicas y trabajadores de Heroku.

rails delayed_job_active_record (5)

Quiero saber si hay alguna buena solución para autoescalado y trabajadores en Heroku en un entorno de producción (probablemente una solución diferente para cada uno de ellos, ya que no están relacionados). ¿Qué están usando ustedes / empresas con respecto a esto?

Encontré muchas opciones, pero ninguna de ellas parece realmente madura para un entorno de producción. Hay Heroscale, que parece introducir algo de latencia ya que no se ejecuta localmente, y también escuché sobre algunos tiempos de inactividad. Hay modificaciones de delayed_jobs, que no se han actualizado durante mucho tiempo, y hay algunos problemas con los paquetes actuales. También hay algunas alternativas relacionadas con el reque, que parecen no manejar muy bien algunas excepciones de HTTP, lo que resulta en un bloqueo de la aplicación, y otras que parecen necesitar un trabajador siempre en ejecución para programar a otros trabajadores, y también pueden sufrir algunas excepciones de HTTP problemas.

Bien. En el final. ¿Qué se está utilizando, hoy en día, para realizar una autoescala de los dinámicos y trabajadores de Heroku en un entorno de producción con Rails3?

Gracias por adelantado.

Heroku está ofreciendo un nuevo complemento llamado AdeptScale que ahora está fuera de Beta.

Aquí está la página del complemento para AdeptScale

Aquí está la documentación más detallada para AdeptScale

Aquí está el formulario para inscribirse en el Programa Beta de Heroku

Esperamos que esta sea una solución robusta para la autoescala de Heroku Dynos, ya que todavía no estoy satisfecho con las opciones actuales.

Actualización (2/4/13): Me inscribí en el programa Beta de Heroku para probar este complemento, y me funcionó muy bien. Ocasionalmente, aumenta la escala de tráfico, pero en su mayoría depende del número mínimo de días que he programado 2. Ha reducido considerablemente mi factura y ha eliminado la preocupación de que pueda ser lento durante las horas pico de uso.

Actualización (3/6/13): Se agregó un enlace a la página de registro de Heroku para su programa beta.

Actualización (4/14/13): Parece que la escala automática está fuera de Beta. Todavía funciona muy bien para mí.

HireFire.io (El servicio, no el proyecto de código abierto) ahora le permite usar sus métricas de New Relic para escalar automáticamente sus dinámicas web. New Relic es una herramienta de supervisión del rendimiento que se proporciona como complemento a través de Heroku. Tienen un nivel gratuito y es suficiente para usar con HireFire.

Puede auto-escalar basado en:

Tiempo de respuesta
- Este es el tiempo de respuesta que se encuentra en el Panel de control de la nueva reliquia. Es una combinación de varios factores, incluyendo la cola de solicitud, el rendimiento de la base de datos, la capa de aplicación, el enrutador, etc.
Puntaje de Apdex
- Esto le permite escalar en función de su puntuación de New Relic Apdex, lo que le permite escalar en función de la experiencia / satisfacción del usuario, que está determinada por esta puntuación.

Aparte de esto, nos hemos convertido en lenguaje / marco agnóstico. Para los proyectos de trabajo, todo lo que tiene que hacer para que el escalado automático funcione es configurar un punto final JSON en una ruta determinada en su aplicación que devuelva una cadena JSON muy simple que contenga el tamaño de la cola (proporcionamos macros convenientes, pero no obligatorias) para el lenguaje Ruby y un poco de compatibilidad inmediata con las aplicaciones de Django, pero como dije antes, funciona de forma manual en cualquier lenguaje / marco configurando manualmente un punto final JSON (es muy fácil). Para web dynos, puede utilizar la Fuente de Métricas de HireFire con prácticamente cualquier lenguaje / marco, y la Fuente de Métrica de New Relic mencionada anteriormente para lenguajes / marcos de trabajo admitidos por New Relic (estos son lenguajes comunes como Ruby, Python, Java, etc.) ).

Descargo de responsabilidad: construí HireFire.

Nos topamos con esto hace un tiempo y pasé bastante tiempo en esto para mi gran frustración. Intentaré atenerme al punto saliente. Hay varias soluciones de autoescalamiento de Heroku que parecen decentes a primera vista.

El ejemplo que ya se ha dado heroku-autoscaler es en realidad para autoescalado y es prácticamente la única solución que dice hacer esto (y ciertamente no lo hace bien). La mayoría de los demás solo reclamarán a los trabajadores de autoescala para usted. Entonces, concentrémonos en eso primero. Los escaladores automáticos que buscará para los trabajadores dependerán de lo que realmente esté usando para sus trabajadores de fondo, por ejemplo, trabajo delayed_job , resque . Esas son las bibliotecas de procesamiento en segundo plano más comunes que utilizan las personas, por lo que los autoescaladores intentarán conectarse a uno de ellos. Puedes usar cosas como:

Algunos de estos trabajos en la pila de Cedros podrían necesitar algunos ajustes. El problema con todos ellos es que es como intentar sacarte del pantano con tu propio cabello. Tomemos como ejemplo elfire de fuego (probablemente sea el mejor del lote). Modifica delayed_job para que los propios trabajadores puedan mirar la cola y dar vuelta a más trabajadores si es necesario, si no hay más trabajos en la cola, los trabajadores se cerrarán mutuamente. Hay varios problemas:

Si desea poner un trabajo en la cola para ser ejecutado en el futuro en lugar de ahora, está de suerte. Un trabajador se inicia cuando los trabajos entran en la cola, pero como el trabajo se ejecutará en el futuro, el trabajador se cerrará y no se iniciará a menos que otro trabajo ingrese en la cola (eso es lo único que hace que los trabajadores se inicien)
pierde la capacidad de reintentar trabajos fallidos, esto es posible por defecto en delayed_job, pero toma un poco de tiempo antes de que un trabajo fallido sea reintentado (y progresivamente más largo) si falla varias veces, pero los trabajadores se apagarán durante este tiempo de espera y no hay nada que les pida que comiencen de nuevo (en esencia, este es el mismo problema que en el primer escenario)

Lo que resuelve este problema es tener un trabajador ejecutándose continuamente, por lo que puede monitorear la cola periódicamente y puede ejecutar trabajos cuando sea necesario o incluso generar más trabajadores. Pero si lo hace, no está ahorrando dinero (tiene un trabajador que trabaja continuamente las 24 horas del día, los 7 días de la semana y tiene que pagar por eso) y esa es toda la premisa detrás de los autocualizadores en Heroku. En esencia, si solo tiene que realizar un procesamiento en segundo plano ocasional, o si tiene trabajos en segundo plano que probablemente fracasen pero se reintenten, o si tiene trabajos en segundo plano que no es necesario ejecutar al instante, no hay una biblioteca de autoescalamiento que pueda uso que funcionará para usted.

Aquí hay una alternativa. El tipo que escribió Hirefire, más tarde lo convirtió en una aplicación web (la aplicación Hirefire ), cuya esencia es monitorear externamente a tus trabajadores / dínas de Heroku para ti y hacer girar / cerrar los días de trabajo según sea necesario. Esto era gratuito en la versión beta, pero ahora cuesta dinero, menos de lo que pagaría por dirigir a un trabajador las 24 horas del día, los 7 días de la semana, pero aún así no es insignificante si solo necesita unos pocos trabajos de fondo de vez en cuando. De cualquier manera, esta es la única manera viable de asegurarse de que su infraestructura de trabajo en segundo plano haga lo que usted quiere (bueno, eso significa que tener una máquina como una instancia de EC2 donde puede poner algunos scripts que harán ping a su aplicación de heroku y giren. subir / cerrar trabajadores según sea necesario (una cantidad de esfuerzo no trivial).

Ahora, la aplicación Hirefire también ofrece la autoescala de sus dinámicos para usted, lo hace en función de la latencia de la cola de solicitud de su heroku. Sin embargo, descubrí que esto no funcionó bien, tal vez si estás cerca del centro de datos de Amazon donde realmente vive tu aplicación heroku (no estábamos), es posible que tengas una experiencia diferente. Pero, para nosotros, innecesariamente hizo girar un montón de dinosaurios y nunca los redondearía por mucho que modificara la configuración. Puede atribuirse al hecho de que era una versión beta que puede haber mejorado desde entonces, pero esa es la experiencia que tuve.

En pocas palabras, si quiere autoescala a sus trabajadores, use la aplicación Hirefire, estará ahorrando mucho menos dinero de lo que pensaba, pero sigue siendo la opción más barata. Si quieres autoescala dinásticamente estás básicamente sin suerte. Esta es solo una de esas limitaciones con las que convive para tener la comodidad de una plataforma como Heroku.

Recientemente he escrito un sistema de escalado automático de Heroku llamado Heroku Vector:

https://github.com/wpeterson/heroku-vector

Le permite escalar múltiples tipos de dinámicas basadas en diferentes fuentes de tráfico. Actualmente admite NewRelic en todo y Sidekiq número de subprocesos ocupados. A medida que el tráfico sube o baja, aumentará o disminuirá el número de días. Es un proceso de daemon que se puede ejecutar en su propio dinamómetro en Heroku o en cualquier otro lugar.

También estoy tratando de encontrar una buena forma de autoescalar los dinamómetros.

heroku-autoscaler hace esto pero tiene un descargo de responsabilidad sobre su inmadurez.