Diapositiva 1

Page 1. 1 lacoctelera.com y The Shaker. Conferencia Rails Hispana. Fernando García y Álvaro Ortiz noviembre 2006. Page 2
2MB Größe 6 Downloads 59 Ansichten
lacoctelera.com y The Shaker Conferencia Rails Hispana

Fernando García y Álvaro Ortiz noviembre 2006

1

2

php mysql xhtml css estándares web rdf sindicación … 

3

4

¿qué es lacoctelera.com?  servidor de blogs para personas normales

que se ha convertido en una gran comunidad 5

páginas vistas

situación actual

Fuente: Nielsen Net­ratings

lacoctelera.com 45.000 cuentas creadas 350.000 posts  900.000 comentarios 35.000 amigos 6

the shaker  aplicación extraida del desarrollo de lacoctelera.com herramienta de gestión de comunidad y gestión de contenidos blogs, fotologs, medialogs, portadas temáticas, directorio, grupos, tags… 7

+ …

+ 1.000.000 de peticiones Rails al día 175GB de transferencia diaria 8 servidores

8

internet peticiones  dinámicas

servidores web

lighttpd

• • • •

2 servidores web Balanceo de carga de servidor web con Pound  Redundancia mediante VRRP Escalabilidad horizontal

Balanceo de carga a servidores de aplicaciones con Lighttpd

servidores  aplicaciones

ruby on rails

• 4 servidores de aplicaciones • FastCGIs • Antivirus: Kaspersky

Balanceo de carga a servidores de BBDD con Rails

BBDD

mysql

batch

9

• • • •

MyISAM 2 servidores de BBDD Replicación de BDs Maestro­Esclavo La carga de las lecturas se balancea entre múltiples esclavos

• 1 servidor • Conversión de videos • Generación estadísticas

• Copias de seguridad • Correo • Memcache

peticiones estáticas (ficheros y caché) 

ficheros (imágenes, documentos, caché) • compartidos por NFS • replicados

the shaker

sistemas  Debian Sarge

 Rails 1.1.6

 Servidores Dell 1850/1950  Dual Xeon / Dual Core   App/Web: 2GB RAM  BD: 10GB / 4GB RAM  HD: RAID1

 Lighttpd 1.4.10

 Red privada 1GB

 Ruby 1.8.4

 MySQL 5.0.18    Memcache   FastCGI  Pound  NTP, NFS, SNMP, VRRP, Ffmpeg … 10

the shaker

caché  comenzamos construyendo la nuestra cuando la de Rails apenas estaba  desarrollada, estamos cambiando a la de Rails 

 rutas, ajax cuando todavía no se llamaba ajax…), analisis de logs, RAILS_ROOT, tareas en 

background, internacionalización, etc…

 en lacoctelera.com muchas páginas tienen algo no cacheable  si el usuario está loggeado:  el lighttpd sirve la página estática, y con Ajax rellenamos el contenido no  cacheable (petición mucho más ligera que un dispatch sirviendo una  página entera, aunque sea de caché)  si no está loggeado:  el lighttpd sirve la página, no interviene Rails en absoluto  cachear también en el back – una de las páginas más vistas de  lacoctelera.com es la página de publicar historia, y no la teníamos cacheada 11

the shaker

internacionalización  varios niveles de internacionalización:  soporte unicode

 ruby y el soporte de unicode: no hasta el año que viene  se va a incluir soporte unicode en rails 1.2 (anunciado ayer) 

 cadenas de la aplicación – resuelto! (lang.yml, no  necesitamos más)  contenido:

 depende de la aplicación que necesites desarrollar – lógica de  negocio 100%  en nuestro caso, no tiene sentido que un usuario tenga un blog  multilenguaje (aunque puede escribir en el idioma que quiera – gracias UTF­8 y los estándares web)  gestor de contenido multilenguaje: AI, workflow de traducción…  (sería como pedir un gestor de encuestas en el core de rails)

 la internacionalización la tiene que trabajar quien la  comunidad que la necesite

12

the shaker

redundancia y replicación  servidores web: 2; balanceo con Pound; VRRP para redundancia  instancias específicas del servidor web según tarea: estáticos, dinámicos

 servidores de aplicación: balanceo con Lighttpd  añadir nuevos web y app es trivial

 hemos hecho nuestros propios paquetes con todo lo necesario para montar un web o app

 ficheros de usuario: compartidos por NFS (y replicados)  BBDD

 lacoctelera.com  1 maestro (R/W) y 1 esclavo (R)  balanceo de lecturas entre ambos  resto de sites  1 maestro (R/W) y 1 esclavo (R)  balanceo de lecturas entre ambos  siguientes pasos:  mysql cluster  separar tablas en hosts  segmentar usuarios por hosts

13

maestro

esclavo 1

esclavo 2

esclavo … n

the shaker

monitorización  scripts caseros: check_tolai, kill_gumias  errores de rails ­> email  daemon tools (monitorización interna)  nagios (monitorización externa)  monitorización de site:  DB_read  DB_write  dinamic  index  static  monitorización de host:  CPU  Carga  DISK  PING  SMTP  warning ­> email  critical ­> sms

 guardias 24/7

 kit B12: portatil + movil 3G

14

the shaker

logs 23/11/2006

 servidor web + pound > awstats   logs de aplicación > awk  MySQL:

 desarrollo: análisis de consultas pesadas  de MySQL    producción: SHOW FULL PROCESSLIST

 lastmin: peticiones/carga CPU   huellas de Nielsen y Google  Analytics

15

the shaker

control de versiones y entregas  repositorio SVN 

 en el servidor de desarrollo de la oficina  mirror de SVN en producción  deploy: oficina ­> mirror producción ­> despligue a todos los servidores 

 capistrano

 roles primarios:  web  app  db (maestro, esclavo)  roles secundarios:  mirror  shared  batch  tareas:  setup  deploy  web_deploy  destroy_cache…

16

 migrations

 control de versiones de la estructura de la BD  integradas en los deploys

 tests / baterias de pruebas

 ejecutados en el deploy; rollbacks  por servidor

 configuración de máquinas en el repositorio  despliegue con el capistrano de la configuración 

the shaker

problemas y dificultades  no estamos cómodos con los FastCGIs – son inestables, consumen mucho  valorando alternativas: mongrels, nginx  ataques de spam: usuarios y comentarios  medidas progresivas: javascript en cliente  solución definitiva: webservice antispam – filtro bayesiano   +30% de comentarios son spam  no hay mal que por bien no venga  el servicio se puede acoplar de forma muy sencilla a otros servicios

 SPF – puntos de fallo únicos

 los hemos ido superando todos (web, ficheros, app, bbdd)  nos queda uno: múltiples centros de datos

  Testing – no tiene sentido desarrollar sin tests  una plataforma tan grande hay que estar manteniéndola de forma regular;  gastas mucho tiempo, y eso es un problema si lo que te gusta es programar 17

the shaker

hasta dónde hemos llegado  empezamos desde el día 0 con un producto nuevo, desconocido para  nosotros (¡y para cualquiera!)  hemos sabido crecer  disfrutamos con Ruby, Rails y con nuestro producto   estamos convencidos de nuestra apuesta (… y esto no ha hecho más que empezar)

18

19

20

c/ Salamanca, 17 Madrid – 28020 España tel. +34 91 567 0605 www.the­cocktail.com

21