En voilà un article Américain fort intéressant ! En effet, ce matin je suis tombé par hasard sur un article de High Scalability dans lequel l’auteur revenait sur l’achat d’Instagram par Facebook, et plus particulièrement une présentation de l’architecture d’Instagram ! Intitulé « canonical description of an early stage startup in this era », l’article met en avant les techniques, les ressources, les décisions prises par Instagram lors de son lancement.
D’ailleurs, l’équipe d’Instagram a publié en Décembre dernier un article présentant les technologies et les idées de la firme. Celle-ci avait glissé quelques principes de base sur le choix d’un système :
- Retenez toujours le plus simple
- Ne réinventez pas la roue
- Allez vers des technologies éprouvées et solides quand vous le pouvez
Instagram utilise de multiples technologies et des stratégies bien différentes. L’équipe qui était jusque là constituée de seulement treize personnes, a connu une croissance rapide surfant sur la vague du social et du mobile.
L’entreprise utilise un hybride de SQL et NoSQL, et intègre une tonne de projets Open Source.
Côté cloud, l’entreprise s’est tournée vers les services d’Amazon plutôt que de construire leur propre écosystème cloud, et ce afin d’avoir des serveurs en haute disponibilité.
Le système est composé autant que possible d’API permettant à des applications tierces de s’appuyer dessus, augmentant par la même occasion la notoriété du service, des données stockées sur le cloud mais également en mémoire, et la plupart du code est développé dans un langage dynamique, ce qui lui permet d’être rapidement modifié, amélioré !
En termes plus concis, il s’agit d’une construction très moderne !
Voici quelques points intéressants que l’on peut relever de l’article d’Instagram :
- 3 Engineers. (They now reportedly have 13 employees, remember this was awhile back)
- 100+ EC2 instances total for various purposes.
- Ubuntu Linux 11.04 (“Natty Narwhal”). Solid, other Ubuntu versions froze on them.
- 25+ Django application servers on High-CPU Extra-Large machines.
- Traffic is CPU-bound rather than memory-bound, so High-CPU Extra-Large machines are a good balance of memory and CPU.
- PostgreSQL (users, photo metadata, tags, etc) runs on 12 Quadruple Extra-Large memory instances.
- Twelve PostgreSQL replicas run in a different availability zone.
- All of their working set is stored memory. EBS doesn’t support enough disk seeks per second.
- Several terabytes of photos are stored on Amazon S3.
- Amazon CloudFront as the CDN.
- Redis runs on several Quadruple Extra-Large Memory instances. Occasionally shard across instances.
- Redis runs in a master-replica setup. Replicas constantly save to disk. EBS snapshots backup the DB dumps. Dumping on the DB on the master was too taxing.
- Apache Solr powers the geo-search API. Like the simple JSON interface.
- 6 memcached instances for caching. Connect using pylibmc & libmemcached. Amazon Elastic Cache service isn’t any cheaper.
- Gearman is used to: asynchronously share photos to Twitter, Facebook, etc; notifying real-time subscribers of a new photo posted; feed fan-out.
- 200 Python workers consume tasks off the Gearman task queue.
- Pyapns (Apple Push Notification Service) handles over a billion push notifications. Rock solid.
- Munin to graph metrics across the system and alert on problems. Write many custom plugins using Python-Munin to graph, signups per minute, photos posted per second, etc.
- Pingdom for external monitoring of the service.
- PagerDuty for handling notifications and incidents.
- Sentry for Python error reporting.
Alors que j’étais en train de rédiger cet article hier, Instagram, et plus particulièrement Mike Krieger co-fondateur de la société, a fait une présentation lors d’un événement Airbnb pour les employés et les membres du réseau, qui fait partie d’une conférence habituelle appelée le Tech Talk, dont le sujet était « Scaling Instagram » (La montée en charge d’Instagram).
Vous allez retrouver la bagatelle de 185 diapos… Bah oui il y a des choses à dire pour valoir 1 milliard de dollars ! Dans celles-ci, vous allez retrouver tous les aspects techniques de la mise en œuvre d’Instagram, et principalement sur les travaux d’ingénierie, mais également le travail sur le back-end. Comme vous pouvez le constater, la firme a rencontré quelques obstacles, mais elle a rapidement trouver des solutions afin de les contourner, ralliant ainsi des millions d’utilisateurs en peu de temps.
Certains points de ces travaux sont notables :
- Si le service n’a jamais affiché la baleine bleue, propre à Twitter, celui-ci a tout de même provoqué de nombreuses erreurs 404 à ses débuts, suite à des « tonnes d’erreurs », liées à …. l’oubli du favicon !
- Peut-être qu’un vrai test de scalabilité est : « remplacer tous les composants d’une voiture tout en la faisant rouler à 100 mph » (replacing all components of a car while driving it at 100mph) ! Plutôt que de réinventer la roue, se baser sur des outils performants et sûrs : Nginx, Redis, Postgres et Django
Voici le diaporama complet de la conférence :
La simplicité est l’une des choses qui rend si attrayant Instagram ! Il semblerait que cette philosophie soit reprise dans la plupart des développements de la firme, mais également pour ce qui est de la partie back-end du site.
Et maintenant, vous savez le secret pour vous faire acheter pour un milliard de dollars …
Que pensez-vous de tout ça ? Parmi les lecteurs du blog, des personnes ont-elles déjà été contraintes d’adopter de telles dispositions ?
