1. Building Geo-Distributed Web
Applications
Jason Rexilius
Founder, CEO - hostedlabs
UTPL
May 28 2009

2. Quien es Jason?
•Arquitecto, hacker, problemático, fundador de
compañías
•Sistemas de intercambio financiero,
telecomunicación wireless, seguridad nacional
•PHP, perl, C, SAS, cualquier cosa con filos
peligrosos

3. Que significa Geo-Distributed?
Una sola aplicación ejecutándose
simultáneamente en muchas localidades
en el mundo.
ES: es un cluster de clusters, comportándose como la imagen de
una sola computadora. (grid, cloud, etc.)
NO ES:
• Clustering alojado sobre dispositivos compartidos como NFS
en un centro de datos. (ej. MediaTemple)
• Sitio de respaldos con replicación de datos (ej. SunGard)
• Creación instantánea de sistemas virtuales (ej. Amazon EC2)

4. Objetivos
• Escalamiento - Escalar arbitrariamente. Entrar a Digg,
Slashdot y CNN al mismo tiempo y todavía dar un buen
servicio.
• Rendimiento - reducir el tiempo de espera entre el
usuario y la aplicación, esto incluye alcanzar mercados
globales.
• Disponibilidad - Cero tiempo de inactividad. Operación
continua, sin importar los problemas ambientales. Puede con
todo, desde perdida de nodos a perdida del backbone
regional.
• Intensidad - Permitir procesamiento intensivo en recursos
sin impactar las operaciones. Computación distribuida,
búsqueda, almacenamiento etc.

5. Por que quiero hacer esto otra vez?
• Capturar el éxito - ame a Digg, deje al equipo de marketing ser libre, sirva a sus
usuarios apenas le descubran.
• Donde están sus usuarios? - son el WORLD WIDE web..

6. • Tiempo es Dinero - “33% de los consumidores comprando
con una conexión de banda ancha no esperan mas de 4
segundos para que una pagina Web se muestre.” -
JupiterResearch via Akamai
Cada segundo mas lento es una baja en clicks en
publicidad (ganancias)
• Proveedores Descarrilados
– “ISPs fallan en enrutamiento” (Level3 vs Cogent)
– “FBI Shutters Web Host” (su vecino aloja warez)
– “Akamai Outage Raises Questions” (falla jerarquica)
– Incendio en estación de energía apaga Equinix
– Falla de generador de 365Main (mal mantenimiento)
– Apagon en Rackspace (borracho en un camion)

7. Prepararse para la inundación
Optimización prematura es mala. Ignorar sus objetivos
también es malo
Que puede hacer hoy para posicionarse mejor mañana?
1. Piense mas allá de la base de datos
2. Permita la especialización
3. Mejore ese viejo SO
4. Disciplina estricta con las interfaces de datos
5. No reinvente la rueda

8. Donde quiere terminar
• Alcance los mercados mayores - suficientes ubicaciones para servir al mundo,
pero no demasiadas

9. Como se ve esto?
• Arquitectura nTier típica de una vista física

10. Como funciona?
Aduéñese del proceso completo - desde bloques IP a DNS a servir el contenido,
procesamiento de aplicación y persistencia de datos. (ver http://stevesouders.com/hpws/rules.php)
1) Optimice BGP/DNS para encaminar el trafico las localidades, distribuir el trafico por los
nodos y encaminarlo fuera de los problemas.
2) Usar nodos Sub-Dominios/CDN para mejorar el rendimiento, sacar el trafico de los
servidores de aplicación y particiones de trabajo.
3) Sesiones auto describibles y compartidas, nivel de cache distribuido permite a los
usuarios moverse. No crea en los proveedores, niveladores de carga no siempre funcionan.
4) Usar diferentes capas de persistencia para necesidades diferentes. Volátil corto-plazo
vs. largo plazo, etc. Se necesita un ambiente global pero administración de datos simple.
5) Usar el modelo de implementación de BD mas simple que se pueda (maestro/esclavo,
two-phase commit, particionamiento de datos, etc. NDB es difícil, casi imposible en WAN).
6) Modelo “control workstation” para coordinar, revisar y administrar todos los niveles.

11. Administración de Trafico Global
BGP/anycast DNS Geo-weighting Load Distribution
• Optimización de primer nivel de enrutamiento Anycast, DNS es el
primer punto
• Geo-weighting basado en quien lo requiere, siguiente nivel
• 8 respuestas para todo, póngalo dentro de un paquete UDP
•Tablas actualizadas en tiempo real de registros A (no use CNAMEs)
• Migre bloques ip en tiempos de inactividad (/24 tamaño mínimo)
• IP assumption dentro del centro de datos
• Use un sistema wing-man para simplicidad
• Use grandes pilas de direcciones IP antes que niveladores de
contenido

12. Nivel de Contenido Web
• Use un directorio separado para el contenido estático
– /var/www/webapp (direcciona a www.you.com, contiene PHP)
– /var/www/static (direcciona a static.you.com, contiene JPG, JS, etc.)
• Establezca EnvVars en httpd.conf para varios ambientes
–SetEnv STATICURL http://devstatic.you.com
– SetEnv STATICURL http://qastatic.you.com
– SetEnv STATICURL http://static.you.com
• Llame a las EnvVars en sus plantillas HTML para contenido estático
<html>
<img src=“<?php print $_SERVER[‘STATICURL’]; ?>/you_logo.gif”>
</html>
• Use replicación simple de datos para transferir de SVN o el sistema de
archivos a CDN
– crontab -e
– svn deploy script

13. Nivel de Aplicación Web
• Sesiones auto describibles - combinación de cookie/servidores cache
Pseudo code:
if ( $Compressed_Encrypted_Session_Data < 4000 bytes ) {
Store_Session_In_Cookie( $Compressed_Encrypted_Session_Data
}else{
Store_Session_In_Two_Nodes( $Node1, $Node2, $Compressed_Encrypted_Session_Data )
Store_Location_Of_Session_In_Cookie ( $Node1, $Node2 )
}
• Uso estricto de interfaces de datos
Function SQLRead($accessstring,$type,$constraints);
Function SQLWrite($dataobject,$type,$constraints);
Function FileRead($file,$method,$constraints);
• No use AUTOINCREMENT, genere llaves
• Use fork/exec para procesos largos/pesados antes que hilos de ejecución,
use wrappers, IPC definido

14. Caching
• MemcacheD es su amigo (o los parecidos)
• “pre compile” paginas que son semi-dinámicas como noticias, etc. Piense
cronológicamente
• Obtenga listas y otros datos semi-dinámicas de la BD, genere includes
locales
• APC u otros opcode compile caches help
• Overlay cache manager con modelo pub/sub para actualizaciones en
background
• Use locator keys para apuntar al cache “system of records”

15. Persistencia
• Guarde los datos correctos en el lugar correcto
– filesystem
– berkleyDB
– MySQL
– REST interface to
– MogileFS
• Sistemas de archivos Global Namespace (Coda, Andrew, Lustre, et al.)
– Use procesos en background para forzar caching y replicacion
– Use nombres de directorios para implicar niveles de servicio o patrones de
comportamiento
• Escoja una arquitectura de BD apropiada “patrón de diseño”, use interfaces
– Primary master, multi-slave, default read from slave
– Primary master, two-phase commit, multi-slave
– Partitioned, distributed multi-master, slave failover
– distributed “hash-map” master, overlay query model

16. Principios
• HTTP NO TIENE ESTADOS, use esta ventaja
•Conozca y optimice toda la pila del sistema, no solo el
lenguaje de programación
• 3i’s - Interfaces, Indirección e Independencia como
características de diseño de sistemas
• Service Oriented Architecture != Webservices solamente,
utilice múltiples modelos y métodos

17. Gracias MorphoDev
Morpho, LLC New York | Chicago | Quito
www.morphodev.com
Morpho Development provides web application outsourcing services to
small and medium sized companies in the United States. Morpho skillsets
include:
•PHP5/MySQL
–PEAR libraries, smarty, Zend and CakePHP framework
–Content Management Systems like Drupal and WordPress
•HTML/CSS coding and Javascript development
–Web standards and semantic markup, Ajax techniques and popular frameworks like
prototype.js and Jquery
We're growing, and we're looking for developers. So if you are interested, please
contact us. Info@morphodev.com