5 cosas que perjudican la Escalabilidad
septiembre 29, 2011 Publicado en Admin-tips, Escalabilidad, InfraEstructura con 23 Comentarios
Mapeadores de Objetos Relacionales (ORM)
Los ORM permiten a los desarrolladores ser más productivos, evitando las dificultades de la interacción con la Base de Datos, y permitiendoles concentrarse en las funcionalidades y las caracteristicas de las aplicaciones.
Desde el lado de Rendimiento la imagen es bien diferente, al permitir que un ORM sea quien construya las consultas que se ejecutan, tendremos consultas bien complejas que la Base de Datos no podra optimizar de la mejor manera.
Procesos sincronos, seriales, acoplados o bloqueantes
Se deben evitar al maximo posible los procesos que generan bloqueos a nivel de Base de Datos, si definitivamente lo necesitamos lo mejor es usar tablas de tipo InnoDB, las cuales generan bloqueos a nivel de registro, y no bloqueos a nivel de tabla como trabaja MyIsam.
Evite procesos sincronos o semi-sincronos, los cuales esperan la respuesta de otro servicio para continuar y detienen la ejecución de codigo. En una aplicacion altamente transaccional estas esperas pueden resultar en miles de sesiones simultaneas o concurrentes.
Unica copia de la Base de Datos
Sin replicación, dependemos de una unica Base de Datos. Con esta configuración limitamos a nuestros WebServers a usar una unica Base de Datos, lo cual obviamente resultara en un cuello de Botella para nuestra aplicación.
Lo mejor es tener varias Bases de Datos, y dar la opcion a nuestros WebServers de utilizar la que ellos consideren adecuada, o mejor la que nuestro algoritmo dictamina debemos usar.
No tener Metricas
Sin metricas no podremos tener un panorama de lo que sucede en nuestra infraestructura cada vez que tenemos una nueva funcionalidad al aire, o cuando estamos teniendo problemas en nuestra aplicacion, sin este tipo de informacion nuestro equipo de Ingenieros no podran estar sensibilizados sobre lo que esto supone y sera mas dificil que trabajemos en pos de mejorar.
Existen muchas soluciones que trabajan con SNMP y que no son invasivas, para citar algunas Cacti, Munin, OpenNMS, Ganglia y Zabbix.
Las metricas deben incluir metricas de negocio como Cantidad de usuarios registrados, Numero de comentarios por hora, Numero de articulos vendidos; asi como las metricas tecnicas de infraestructura como Espacio en disco, Memoria disponible, Numero de procesos ejecutandose, consultas por segundo.
Banderas de funcionalidades
En las aplicaciones que son construidas sin banderas de funcionalidades es mucho mas dificil degradar correctamente.
Cuando un sitio esta teniendo un pico de trafico o de request y no es posible escalar o expander la capacidad, las banderas permitiran bajar funcionalidades mientras la carga baja en los servidores sin tener que bajar el sitio por completo. Esto le dara tiempo para poder realizar los ajustes necesarios.
Sin estas recomendaciones limitara la Escalabilidad y la Disponibilidad de las aplicaciones.
Tags: bases de datos, bloqueo, disponibilidad, escalabilidad, metricas, MySql, ORM, procesos, sincrono
Los 4 secretos de escalabilidad en Facebook
junio 24, 2010 Publicado en Escalabilidad, InfraEstructura con 55 Comentarios
Aditya Agarwal, Director de Ingenieía de Facebook, dio una excelente conferencia acerca del escalamiento en Facebook que cubrio su arquitectura, pero la charla realmente fue más sobre como escalar una organizacion preservando lo mejor de su cultura. La clave de la conferencia es:
You can get the code right, you can get the products right, but you need to get the culture right first. If you don’t get the culture right then your company won’t scale.
Puedes tener el codigo bien, puedes tener los productos bien, pero necesitas tener bien la cultura primero. Si no tienes bien la cultura entonces la compañia no podrá escalar
Esto nos lleva a los 4 secretos de escalabilidad en Facebook:
- Escalamiento necesita Iteración
- No sobredimensione
- Escoja la mejor herramienta, pero tenga en cuenta que traerá consigo otras consideraciones
- Ajuste la cultura. Muevase rápido – rompa paradigmas. Alto Impacto – equipos pequeños. Sea valiente – innove.
Estas son algunas consideraciones antes de hablar sobre cada uno de los cuatro secretos en Facebook:
Facebook es muy grande
400 millones de usuarios actuvos; los usuarios utilizan facebook 20 minutos al dia en promedio; 5 billones de piezas de contenido (actualizaciones de estado, comentarios, gustos, carga de fotos, carga de videos, mensajes de chat, mensajes de correo, eventos, paginas de fans, conexiones de amigos) son compartidas en facebook cada semana; 3 billones de fotos cargadas cada mes; 250 aplicaciones que tienen mas de 1 millon de usuarios al mes; 80.000 conexiones de aplicacion, 500.000 aplicaciones; 2 millones de desarrolladores; 150 millones de operaciones por segundo en memcache; miles de servidores de memcache con decenas de Terabytes en memoria.
Facebook es dificil de escalar
Cada tipo de contenido tiene su propio patrón de acceso lo cual hace dificil el escalamiento. Todos usan Facebook de una manera diferente. Cada experiencia de usuario es unica. La mayoria de sitios web escalan de manera horizontal, porque su data puede ser particionada. En Facebook los usuarios no pueden ser particionados porque pueden unirse a cualquier red, Facebook es una red global que trata de cautivar a todo el mundo, permite a cualquiera ser amigo de cualquiera, y puede representar cualquier relación entre usuarios. cada usuario nuevo puede acceder los datos de cualquier otro usuario por lo tanto no se puede particionar geograficamente o por otra tipo de criterio. En promedio, cada usuario de Facebook tiene 130 amigos.
La arquitectura tiene 4 componentes principales
- Balanceador de Carga
- Servidores Web (PHP)
- Servicios (Buscador, publicidad, memcache,etc)
- Bases de Datos
Los 4 secretos de escalabilidad en Facebook
1. Escalamiento necesita Iteración. Las soluciones por lo general funcionan al principio, pero deben ser modificadas a medida que pasa el tiempo. Lo que funciona en el primer año, podria no funcionar despues. PHP, por ejemplo, es simple usarlo al principio, pero no es una buena elección cuando se tienen miles de webservers.
Otro ejemplo son las fotos, actualmente sirven 1.2 millones de fotos por segundo. La primera versión se creo de la manera facil, sin preocuparse ucho por como escalaba, simplemente enfocandose en que funcionara bien. El cargador almacenaba el archivo en un NFS y la meta-data en MySql, funciono bien los 3 primeros meses y causo muchas noches sin poder dormir, aun lo hace. El Time to market, o tiempo para salir al mercado fue la ventaja más competitiva que se tenia, tener la funcionalidad era más importante que si esta escalaba bien o no.
La segunda fase fue la optimización, se evidencio que las imagenes pequeñas son mas accesadas por lo cual se empezaron a almacenar en cache, además empezaron a usar un CDN, el servicio NFS no fue diseñado para almacenar 80 billones de pequeños archivos, asi que toda la meta-data no se ajustaba a la memoria, por lo cual eran necesarios 2 o 3 IOs a disco, lo cual era lento.
La tercera fase es un sistema que crea un archivo que es un BLOB almacenado en el sistema de archivos. Las imagenes son almacenadas en un BLOB y se conoce el offset de la foto en el BLOB para su recuperacion, esto se traduce en 1 IO por cada foto.
2. No sobredimensione. Unicamente utilice lo necesario a medida que va escalando. Descubra donde debe iterar en una solución, optimice o construya la solución usted mismo. Ellos dedicaron mucho tiempo tratando de optimizar PHP, terminaron escribiendo HipHop, un transformador de código que convierte PHP en C++, lo cual genero una cantidad masiva de ahorro en CPU y memoria. Esto no debe ser realizado en el dia 1, pero deberia, enfoquese primero en el producto antes de escribir un lengueaje nuevo por completo.
3. Escoja la mejor herramienta, pero tenga en cuenta que traerá consigo otras consideraciones. Si usted realmente necesita usar Python adelante, pero tenga en cuenta que tendrá su costo, usualmente en instalación, monitoreo, operación. Si usted decide usar una arquitectura basada en servicios, tendrá que construir la mayoria del backend usted mismo y eso toma tiempo, con LAMP por ejemplo tiene todo esto gratis. A medida que incursiona en el alcance por servicios, tendrá que reinventar la rueda.
4. Ajuste la cultura. Muevase rapido – rompa paradigmas. Alto Impacto – equipos pequeños. Sea valiente – innove. Construya un ambiente interno que promueva la construcción correcta de las funcionalidades y despues se optimicen segun sea necesario, sin preocuparse por la innovación, sin preocuparse por romper paradigmas, pensando en grande, pensando en que será lo siguiente en construir despues de este primer paso. Usted puede tener el codigo correcto, los productos correctos, pero si la cultura no es la apropiada no podrá escalar de manera eficiente.
- Muevase rápido. Sea el primero en el mercado, esta bien si rompe paradigmas. Por ejemplo, Facebook corre en una capa web compuesta en su totalidad por HipHop, el cual fue desarrollado por 3 personas. Muy arriesgado, esto llevo a que el sitio se cayera regularmente (Sin memoria, cilcos infinitos), pero al final la recompensa es que encontraron como hacer que funcionará. La alternativa era que se realizaran pruebas durante 3 meses, lo cual retrasaba todo el desarrollo. Este es un ejemplo puntual, pero lo más importante es la cultura, que la gente crea que lo más importante es que tan rápido se pueden mover en el mercado.
- Alto Impacto. Los equipos pequeños pueden hacer grandes cosas. Buscador, fotos, chat, HipHop, fueron desarrollados por pequeños equipos. Arme los equipos con la gente adecuada, empoderelos y dejelos trabajar.
- Sea Valiente. No le tema al fracaso, esta bien intentar cosas nuevas y fallar, puede ser descabellado decir “Vamos a hacer una nueva JVM”, pero la recompensa puede ser grandiosa cuando funciona.
En Facebook no hay dueños del producto, todos son dueños del producto. Dele a la gente apropiación de lo que hacen, si solo una persona obtiene el crédito, entonces nadie contribuira para llevar el producto al siguiente nivel. Las ideas vienen internamente de los usuarios y las personas, si la responsabilidad no esta distribuida y solo un número de personas siente que son parte del producto, entonces solo ellos serán suceptibles de ser motivados. Moverse rápido no es solo un deseable, las compañias deben encontrar maneras para que la gente sienta que es una realidad.
A continuación les dejo el link donde pueden ver el video completo de la conferencia :
http://www.infoq.com/presentations/Scale-at-Facebook
Tags: arquitectura, blob, C++, cdn, escalabilidad, Facebook, hackatons, HipHop, IO, LAMP, MySql, NFS, php, Python, scale, server, web, webserver
