Escalando sin atajos

Desafíos y lecciones aprendidas intentando escalar CartoDB sin limitando lo menos posible al usuario en una plataforma de mapas dinámicos

Transcript

1. Escalando sin atajos @luisico
2. ¿Qué es CartoDB? CartoDB is a Software as a Service (SaaS) cloud computing platform that provides GIS and web mapping tools for display in a web browser
3. ¿Qué puede hacer CartoDB?
4. ¿Qué puede hacer CartoDB?
5. ¿Qué puede hacer CartoDB?
6. ¿Qué puede hacer CartoDB?
7. ¿Qué puede hacer CartoDB?
8. ¿Qué puede hacer CartoDB?
9. CartoDB is about.. ..big geospatial datasets ..analyzing data with SQL ..building map visualizations
10. empower the user to do anything he wants
11. El stack Web routing Editor Application Data Cache SQL API Tiler User Data Async jobs
12. Cada petición de un tile Entra a un servidor web Es procesada por una API de tiles Lanza la SQL del usuario a su base de datos Renderiza un png con datos de la DB
13. Números Varios miles de peticiones de tiles por segundo Respuestas medias por tile de 300 miliseconds Peticiones totalmente dinámicas
14. Números Varios miles de peticiones de tiles por segundo Respuestas medias por tile de 300 miliseconds Peticiones totalmente dinámicas
15. Servidores calentitos
16. Caché Caché del sistema en DB Cachés internas de las aplicaciones Varnish CDN Pregunta de entrevista :)
17. CDN La mayor parte de las peticiones a tiles se cachean de forma transparente en el CDN Mayor velocidad por región geográfica Menos carga para la plataforma
18. Mapas dinámicos El CDN es solo un componente más El usuario sigue pudiendo lanzar sus queries contra sus datos y renderizar en base a sus estilos El usuario puede modificar sus datos o estilos en cualquier momento sin preocuparse del mapa
19. Bottlenecks Es difícil medir los recursos de una plataforma cuando permitimos al usuario que haga lo que quiera con ella Aparecen bottlenecks que no pensabas que tendrías nunca Varias formas de solucionarlos Límites, control de recursos, quotas, escalado, tunning, sharding, ...
20. Escalado
21. ¿Cómo escala CartoDB? Escalado horizontal vs vertical vs sharding El escalado horizontal se usa principalmente para las capas de procesamiento sin persistencia Escalado vertical y sharding se usa principalmente para las base de datos
22. Web routing DB Server 1 (n users shard) Tiler Web routing Web routing Tiler Tiler DB Server 2 (n users shard) DB Server 3 (n users shard) DB Server 4 (n users shard) DB Server 5 (n users shard) DB Server n (n users shard)
23. Cuando el escalado no es bastante En partes como la base de datos se pueden dar luchas por recursos de la máquina Una query particularmente pesada puede usar mucha CPU o memoria Limitación de recursos Re-ajustes dinámicos de configuraciones Redistribución dinámica de bases de datos
24. Límites
25. ¿Donde no aplicar límites? En todo aquello que favorezca el éxito de un mapa Renderizados rápidos Queries rápidas No aplicamos límites en el número de mapas vistos
26. ¿Donde aplicar límites? En todo aquello que haga que un mapa no tenga éxito Queries largas = Timeouts en DB Renderizados largos = Límites de renders simultáneos
27. Limitación de recursos: timeouts Es importante tener timeouts coherentes en todas las capas del stack Timeouts en las capas de aplicación Statement timeouts en base de datos
28. Limitación de recursos: cgroups
29. Limitación de recursos: cgroups
30. Reajustes de configuración PostgreSQL tiene decenas de configuraciones para tunning del cluster Monitorización de los logs Reajustes de configuración en base a comportamientos del cluster Ejemplo: work_mem
31. Redistribución dinámica de bases de datos Origin DB Server Target DB Server Origin DB Server DB Dump DB Restore DB Trigger (Writes Sync)
32. Quotas Como casi cualquier servicio tenemos quotas Quotas de uso en disco Quotas de uso de la plataforma en tiempo real
33. Ayuda y feedback al usuario Queremos que las visualizaciones de nuestros usuarios tengan éxito Análisis constante de la plataforma (procesamiento de logs, métricas, ..) Detectamos casos anormales y le damos feedback al usuario Ayudamos a nuestros usuarios a realizar sus integraciones de forma más eficiente y mejorar sus queries SQL
34. Cuando lo tradicional no es suficiente Una vez más: Queremos que las visualizaciones del usuario lo peten PostgreSQL FDW Hadoop Renderizado en cliente Write only tables (Elections)
35. Lecciones aprendidas
36. Lección: Analiza bien las crisis Nunca presupongas los motivos de un fuego Métricas, métricas, métricas
37. Lección: Conoce bien tu stack
38. Lección: Conoce bien tu stack Es esencial conocer bien tu stack, incluso si no lo desarrollas tú Varnish, NodeJS, Express, Rails, ORMs, PgBouncer, … Todo software se comporta de formas inesperadas cuando lo llevas al límite Al final vas a necesitar hacer cambios Benchmarks
39. Gracias ¿Preguntas?