Engineering: Redesign Elasticsearch/Redis health checks to improve performance of all M2X requests
Engineering: Design & Implement robust & reliable messaging solution between data centers using RabbitMQ
Engineering: Redesign workers messaging and queuing (possibly migrating them from Ost-based queues to RabbitMQ queues)
Engineering: Unify datapoint writer and trigger evaluator queues (avoid queueing each datapoint twice).
Engineering: Optimize datapoint writer worker
Engineering: Adjust number of workers and background processes based on load testing results.
Engineering: Bootstrap logging management system
Engineering: Review logging needs for all app and system components
Engineering: Review & improve logging generation and management
Engineering: Add metrics generation & management for all application & system components (find new alternative to NewRelic)
Engineering: Synchronize developer portal sessions across datacenters
Engineering: Multi-stream data modelling
Engineering: Jobs API
Engineering: Background jobs monitoring interface
Engineering: Refactor all datapoint writing methods to avoid hitting ES (it requires that users, keys and device IDs are all cached in Redis, and therefore it requires RabbitMQ to be able to invalidate caches stored in a different DC). This prioritizes access to writing time series data over any other API methods (performance-wise).
Engineering: Refactor all datapoint writing methods to give the option to the user of checking the status of this operation (i.e. return a Location header along with the 202 response pointing to a url which users can ping to check the status of this transaction).
Engineering: Continue improving deployment workflow
Engineering: Improve device's last activity storage
Engineering: Redesign app settings configuration
Engineering: Automate Elasticsearch templates configuration
Engineering: Cache frequent responses in Redis to improve performance
Engineering: Automate Elasticsearch mappings configuration
Engineering: Extract datapoint writing routes into its own router/microservice
Esto es esencial para la mayor parte de las cosas que queremos
hacer. Ya sea los workers o el cache, necesitamos comunicar los tres
DC entre ellos. Para mí es lo primero de todo lo que hay que hacer.
Esto me parece que necesita mejorar desde la parte de monitoring y
alerting. Monitoring en tanto y cuanto el ver si los servicios
funcionan. Alerting para avisarnos que algo no anda y para avisarle a
la app para que entre en modo mantenimiento.
Relacionado con lo de arriba. Estos checks deberían ser un background
job.
Con la comunicación entre DCs podemos empezar a migrar algunos workers
a RabbitMQ en vez de Ost. Para empezar, dejaría los actuales como
están, y solamente pasaría los nuevos (session sync, cache sync, etc)
con RabbitMQ.
Unificar en esta instancia no tiene sentido. Se puede hacer muy fácil
moviendo una llamada de DatapointWriter a routes/streams.rb y obtener
el mismo resultado. Luego se puede mejorar libremente.
Sería un caso especial de cache sync. No lo agrupo ahí porque hoy ya
está funcionando, pero es ideal para hacer con redis sincronizado
entre DC.
Necesitamos hablar con Chris y Cuervo para ver qué ideas tienen y cómo
mejorar esto, en cuanto a infraestrutura.
En cuando a código necesitamos todos estar en sincronía acerca de cómo
tomar las métricas y de qué vale la pena hacerlo.
Este punto es importante para algunas de las cosas que vienen luego.
Ejemplo de lo anterior: sin métricas acá no podemos hacer nada.
Me gustaría definamos un poco más claramente qué es cada cosa de esta
lista, para que la podamos estimar mejor.
En parte relacionada con lo anterior: hoy día podríamos empezar
volcando las métricas en un log antes de pasarla a algo centralizado.
No le encuentro sentido separarla de las otras tareas de cache sync.
Entiendo que no necesariamente las dos se refieren a exactamente lo mismo, pero medio que la estimación de una implica en parte la otra.
No entiendo qué sería esto.
No necesariamente como las de menor prioridad, pero me parece son dos
tareas que van a tomar mucho tiempo, tienen base en todas las cosas
anteriores (monitoring, alerting, logging)
Como dije en slack: me encantaría hacerlo, pero hoy día no me parece
prioritario en cuanto a la mejora, teórica, que puede traer. Todo lo
otro que nombramos antes va a mejorar la performance de estas rutas
que el sacarlo a un router propio.