internet, desarrollo, diseño web, sysadmin

Encuentro sumamente interesante el artículo que escribe Randy Shoup sobre cuáles son las mejores prácticas de escalabilidad que aplican en eBay. Para ellos, escalar es realmente una necesidad, ya que sirven 2.000 millones de páginas diarias.

Particionar por funciones

Es decir, desacoplar funcionalidades. Separan las funcionalidades (venta, búsqueda, etc.) en pooles, de manera que cada pool puede escalar independientemente de los demás. Tienen 16.000 servidores de aplicaciones en 220 pooles. Asimismo, tienen 1.000 bases de datos en 400 máquinas.

Dividir horizontalmente

Los servidores de aplicaciones no guardan información del estado y utilizan balanceadores, con lo que el crecimiento horizontal es trivial. Si necesitan más recursos, simplemente añaden un nuevo servidor de aplicaciones.

En el caso de las bases de datos, lo que hacen es dividir según la clave por la que se accede al dato. Por ejemplo, los usuarios los tienen en 20 bases de datos. La base de datos en la que se almacena un usuario dependerá de su identificador. Para calcular dónde se almacenará un dato utilizan la función módulo, rangos de identificadores, tablas de consulta, etc.

Evitar las transacciones distribuidas

Al particionar, la operaciones habituales de actualización requerirán actualizar más de un tipo de recurso. La forma ortodoxa de implementar esto es mediante una transacción distribuida y un commit en dos fases para asegurar la integridad. Pues bien, el rendimiento y la latencia se ven seriamente afectados por este coste de coordinación. Según el teorema CAP, de las tres propiedades deseadas en un sistema distribuido, es decir, consistencia (C), disponibilidad (A) y particionado (P), hay que elegir sólo dos. En eBay, debido al alto tráfico, eligen P, para poder escalar, y A, ya que deben prestar su servicio 7×24. Para asegurar la integridad emplean técnicas de recuperación asíncronas.

Integrar asíncronamente los recursos

Si el recurso A llama al recurso B síncronamente, entonces si escalo A tengo que escalar B. Además, si B está caído, A fallará también. Por esto, es mejor que A y B se integren asíncronamente, por ejemplo, con una cola o con un proceso batch.

Procesar asíncronamente

Habrá parte del procesado de datos que pueda convertirse en procesado asíncrono. De esta manera, reduciremos la latencia del procesado que deba ser síncrono. Asimismo, podemos reducir los costes, ya que el dimensionado del procesado síncrono hay que hacerlo siempre para el pico de carga.

Virtualizar en todos los niveles

El sistema operativo realiza una abstracción del hardware, la correspondencia entre los objetos y las tablas realiza una abstracción de la base de datos, los balanceadores de carga y las IP virtuales realizan una abstracción de la infraestructura de red.

En eBay las aplicaciones interaccionan con una representación lógica de la base de datos En el momento de acceder a un dato se calcula cuál es la instancia física a la que hay que acceder según cierta configuración. Si fuera necesario, se podría cambiar dicha correspondencia entre el modelo lógico y la implementación física sin tener que cambiar el código.

Cachear apropiadamente

La estrategia de caching deberá ser planificada cuidadosamente y deberá tener en cuenta aspectos como el coste y la disponibilidad.

Leo en TechCruch que Google va a hacer públicas hoy mismo, en el evento Google I/O, las tarifas de Google App Engine. De confirmarse, estas tarifas van a ser muy competitivas:

Free quota to get started: 500MB storage and enough CPU and bandwidth for about 5 million pageviews per month.
$0.10 - $0.12 per CPU core-hour
$0.15 - $0.18 per GB-month of storage
$0.11 - $0.13 per GB outgoing bandwidth
$0.09 - $0.11 per GB incoming bandwidth

Leyendo esto me he preguntado, ¿cuanto me costaría en Amazon Web Services alojar la aplicación más grande que en Google App Engine va a ser gratis?, es decir, ¿cuánto costaría alojar una aplicación que almacene 500 MB y que sirva 5 millones de páginas en un mes? Pues bien, vamos a realizar un cálculo simple y sin ningún rigor científico, pero que tal vez nos dé una idea aproximada de cuándo nos costaría con AWS.

Para ello necesitaremos Amazon Elastic Computing Cloud y Amazon Simple Storage Service. Supondré que cada página se corresponde con la página media según este estudio, es decir, que tiene 60KB y 50 objetos.

5 millones de páginas de 60 KB son 286 GB de transferencia mensual. Vamos a suponer que la mitad va a S3 y la otra mitad a EC2 (realmente nos da igual ya que la transferencia de datos se cobra igual en ambos servicios). Esto sería data transfer-out, es decir, la transferencia entre AWS y el mundo exterior. Siendo muy benévolos, supongamos que la transferencia hacia AWS, es decir, la transferencia de datos de las peticiones de los usuarios son despreciables. Por último, supongamos que la mitad de estos 286 GB no sería necesario transferirlos gracias a las cachés de los navegadores. Con esto nos quedaría que tanto S3 como EC2 consumirían unos 70 GB de data transfer-out al mes.

Supongamos que de los 50 elementos de la página tenemos 40 en S3. Tendríamos que hacer 200 millones de peticiones. Una vez más, supongamos que sólo son necesarias 100 millones gracias a las cachés. Las peticiones que no sean GET las despreciamos.

También supondremos que utilizaremos una instancia pequeña en EC2.

Con todas estas suposiciones, si vamos a la calculadora que proporciona AWS, vemos que el coste de alojar dicha aplicación ascendería a unos $200 mensuales. Lo cual, está claro, no es nada competitivo con los $0 de Google.

Leyendo el blog O’Reilly radar llego a una interesante presentación de Jason Grigsby sobre la internet móvil. De ella me gustaría destacar los siguientes puntos:

• Existen realmente muchos teléfonos móviles. En concreto, unos 3.300 millones, es decir, más o menos la mitad de los habitantes del planeta tienen uno (aunque seguro que no están repartidos uniformemente). Aquí podemos apreciar el número de teléfonos móviles en perspectiva:



• La industria de la telefonía móvil genera unos ingresos enormes. Sólo los SMS generaron más ingresos que la industria del cine, de la música y de los videojuegos juntas.
• El iPhone manda ahora mismo en la internet móvil. El 65% de los usuarios que navegaron por Internet desde un dispositivo móvil en enero de 2008 lo hicieron desde un Iphone o un IPod. El 95% de los usuarios del IPhone navega regularmente por internet. Por ello, merece la pena desarrollar aplicaciones web pensando en el IPhone.

Hace unos días Sun presentó el data warehouse más grande del mundo. Tradicionalmente este tipo de anuncios se centraba sobre todo en la capacidad de proceso y en el retorno de la inversión. Es decir, en lo que me cuesta y lo que obtengo a cambio.

En este anuncio me llama la atención que se hace especial hincapié en la ventaja medioambiental que esta solución supone frente a la solución de la competencia. En concreto, se comparan las emisiones de CO₂ y la basura generada durante el periodo de amortización de los equipos.

Pienso que los parámetros medioambientales tendrán cada vez una mayor importancia a la hora de determinar las inversiones relacionadas con las tecnologías de la información. De hecho, hace unos días McKinsey y el Uptime Institute publicaban un interesante estudio sobre la eficiencia energética de los centros de datos, según el cual, uno de los principales retos que van a tener muchas empresas es gestionar la eficiencia energética de su infraestructura de TI, no sólo por el gasto que eso supone, sino por la gran emisión de gases de efecto invernadero que los centros de datos producen.

Leyendo el blog de Matt Cutts he llegado a las tiras cómicas y dibujos de Randall Munroe. No las conocía. La favorita de Matt Cutts me ha parecido muy buena. Eso sí, no es para todos los públicos:

Randall Munroe publica sus dibujos con licencia Creative Commons.