Lo bueno de que las empresas tecnológicas tengan un blog técnico es que nos cuentan lo que hay detrás de sus productos. Es decir, cómo desarrollan, la infraestructura y cómo tienen todo montado. Un valioso conocimiento compartido que no todo el mundo está dispuesto a compartir.

En este caso, Instagram, que por si alguien no la conoce es la startup que ha revolucionado la forma de compartir fotos por medio de una aplicación para el iPhone, cuenta en su blog la tecnología que hay detrás. Os puedo asegurar que es muy interesante y que más de alguna que otra empresa debería aprender como optimizar recursos.

En Instagram dicen que tienen un pequeño equipo de ingenieros pero que han sabido aprovechar al máximo cada recurso para llegar a escalar su infraestructura a más de 14 millones de usuarios en apenas un año.

Sus reglas básicas son:

• Mantenerse simples
  
• No reinventar la rueda
  
• Usar tecnologías ya probadas siempre que eso sea posible
  

Alojamiento

Instagram usa Ubuntu Linux 11.04 en sus instancias en Amazon EC2, las cuales manejan según las necesidades de demanda. De momento, no se plantean utilizar servidores en sus propias instalaciones aunque no lo descartan si el crecimiento se mantiene constante.

Servidores de aplicaciones

Usan Django en Amazon High-CPU Extra Large pasando de tan sólo unas maquinas a alcanzar ya más de 25. Aunque ese no es ningún problema ya que son capaces de escalar horizontalmente al poder trabajar independientemente unas de otras.

Usan como servidor WSGI a Gunicorn, en lugar de mod_wsgi y Apache, al ser Gunicorn más fácil de configurar, y menos intensivo con la CPU. Y para la ejecución de comandos en varias instancias en paralelo se usan Fabric que es capaz de desplegar en cuestión de segundos cual ejecución.

Almacenamiento de datos

Uno de los pilares de Instagram son los datos de las fotografias y los usuarios. La base de datos que se usa es PostgreSQL. Afirman que tiene 12 cluster de instancias de memoria Quadruple Extra-Large y sus 12 replicas en distintos lugares.

Nos aconsejan el uso de vmtouch para la gestión de datos de memoria, sobre todo cuando se produce un error en la conmutación de una máquina a otra. Todas las maquinas que se usan están configurada en maestro-replica. Para la gestión de la replicación se usa repmgr.

Para realizar las conexiones a la base de datos con PostgreSQL, principalmente desde Django se usa Pgbouncer.

Como no podía ser de otra forma, para todo los que es contenido principal del feed de actividad y las notificaciones de Instagram se usa Redis. Aunque como todo tiene que caber en memoria se usa de nuevo otras instancias Quadruple Extra-Large en configuración maestro-replica.

Para el uso de la API de geo-búsqueda se usa Apache Solr que permite el consumo de datos por medio de JSON, lo que facilita el acceso a los datos cuando las aplicaciones lo necesitan. Tampoco se olvidan del uso de memcached para la caché utilizando pylibmc y ibmemcached.

Tareas de notificación y push

Para estos casos en los que se tiene que notificar a un usuario en tempo real de una nueva foto publicada se usa Gearman, un sistema de cola de tareas escrita originalmente en Danga. Colas asíncronas para distribuir el trabajo pesado en segundo plano y que las tareas más ligeras se realicen rápido.

Para realizar las notificaciones push usan pyapns y aseguran que les ha ido bastante bien manejando más de mil millones de notificaciones. Habrá que echarle un vistazo.

Monitorización

Con más de cien instancias distribuidas en los distintos procesos que hemos descrito, en Instragram usan Munin para revisar todos los parámetros gráficos de los sistemas. Además de haber escrito varios plugin basado en Python. También se usa Pingdom para la supervisión externa del servicio y PagerDuty para las incidencias y las notificaciones.

Y para el informe de errores usan Sentry, escrita usando Django por la gente de Disquis.

Conclusiones

Muy interesante la configuración de Instagram y comprobar el uso intensivo que hacen de Python y las instancias de Amazon. Un conjunto de herramientas que habrá que echar un vistazo más en detalle pero que ha logrado que esta Startup pueda escalar un tremendo tráfico en poco más de un año. Como ellos dicen: reutilizando al máximo y, como hemos comprobado, sin reinventar la rueda ni embarcarse en complejas infraestructuras.

Más información | Instagram Developer
Vía | Instagram engineering

Al desarrollar una aplicación Android es tan importante la implementación de la aplicación como la de la parte servidor que usaremos para diferentes tareas como la autenticación de usuarios, servir contenido como imágenes o datos, usar una base de datos centralizada, etc.. Para ello, seguramente, si usamos algún servicio en la nube como Amazon quizás nos interese usar el SDK de Amazon Web Service para Android.

El SDK de Amazon Web Service para Android provee un conjunto de librerías, ejemplos y documentación para que los desarrolladores puedan construir aplicaciones móviles que usen los servicios en la nube de Amazon como Amazon S3, Amazon EC2, Amazon SimpleDB, CloudFront, Amazon RDS, Amazon SQS o Amazon SNS.

Normalmente, cuando queremos usar servicios en la nube debemos implementar nuestras propias librerías que manejen las peticiones HTTP, abran y cierren las conexiones y empaquetar cada uno de los parámetros necesarios. AWS SDK nos permite utilizar distintos servicios en la nube desde la misma aplicación cuando lo necesitemos

• Almacenamiento: usando Amazon S3 para los datos, tanto para servir contenido o almacenar datos enviados desde la aplicación móvil.
• Bases de datos: con SimpleDB disponemos de una base de datos clave-valor escalable para almacenar todos los datos que queramos desde la aplicación.
• Computación en la nube: podemos lanzar y manejar instancias de Amazon EC2.
• Mensajería: podemos usar Amazon SQS y Amazon SNS para integrar un sistema de comunicación móvil para nuestra aplicación y enviar mensajes broadcast.

Así, ya estemos desarrollando una aplicación multimedia que necesite fotos usando Amazon S3, un juego online que interactue con distintas bases de datos escalable o un sistema de mensajería entre aplicaciones podemos usar el Amazon Webservices SDK para Android para interactuar con los servicios en la nube fácilmente.

Descarga y documentación | SDK Amazon Web Services para Android
Más información | Develop Android Apps with Amazon Web Services

Los servicios de Amazon en la nube son fiables, es posible asegurar un 99% de uptime (aunque asumimos casi tres días de caída). Muchas veces esas caídas son algún fallo ocasional que no dura más de unos minutos seguidos, pero ayer Amazon EC2 experimentó la mayor caída del servicio al producirse graves problemas en los servidores basados en el Norte de Virginia. No se cayó el servicio a nivel mundial, pero la repercusión fue importante al afectar a numerosos proyectos de empresas de internet, desde startup a algunas que ya no lo son tanto como Foursquare, Quora, Reddit o Hootsuite, incluso servicios como Heroku que actúan de servidores en la nube a otros. El listado completo se puede ver en una web creada a tal efecto, #ec2disabled.

El compromiso del contrato a nivel de servicio de Amazon EC2 es de una disponibilidad del 99,95% en cada Región de Amazon EC2.

Cuando cedemos nuestra infraestructura de servidores a una empresa externa, sea la nube, un hosting o lo que sea, asumimos este tipo de fallos. Los críticos a los servicios a la nube pueden aprovechar este incidente para reclamar que aunque ahorremos dinero, tiempo, esfuerzo y ganemos escalabilidad no estamos a salvo de fallos inesperados. Ni mucho menos evitar preguntarnos cuando se restablecerá el servicio. Empresas que tienen miles de maquinas alojadas en EC2 pueden experimentar momentos de pánico al no saber que pasa con sus servicios. Si normalmente al detectar un pico de tráfico somos capaces de enviar con rapidez y anticipación nuevas instancia, aquí es complicado responder a tiempo.

Desde hace un tiempo Amazon EC2 está experimentando fallos en sus servidores como podemos contemplar en los paneles de status, el dashboard de Amazon Web Services. Errores sobre todo en Elastic Beanstalk, y la base de datos relacional, Cloudwatch entre otros. Problemas de conectividad entre instancias que no gustan nada a los desarrolladores, menos cuando nos estamos acostumbrando a desplegar y punto, olvidándonos de configurar maquinas.

Cuando hay nubes, a veces llueve. Por eso a raíz de las recientes interrupciones de servicio estaría bien seguir una serie de ideas para mantener los servicios hospedados disponibles durante las caídas masivas de los servidores alojados en la nube.

¿Tenéis alguna alternativa más en caso de caída masiva de nuestros servicios en la nube?

Vía | All Things Digital
Más información | Status Dashboard Amazon Web Services, EC2Disabled