Commentaire à propos de l’article TripAdvisor Architecture – 40M Visitors, 200M Dynamic Page Views, 30TB Data paru sur highscalability.com.
Chiffres
- 40 millions de visiteurs uniques par mois
- 20 millions de membres
- 45 millions de commentaires / contributions
- 200 millions de pages dynamiques servies par jour
- 102 GB de logs (compressés !) générés chaque jours
- 30 TB de data stocké dans Hadoop
Points intéressants
- architecture orientée service avec découpage par domaine fonctionnel: membres = un service, commentaires = un service etc…
- utilisation de pool / groupes de serveurs avec rooting par cookie: en gros, une session navigateur/client et donc par cookie va se voir assigner un ensemble de serveurs. Cet ensemble est un groupe de serveurs qui assure le service dans sa totalité et de manière autonome. Par contre il correspond à un déploiement d’une version spécifique de l’application: version de test, pre-release etc.. Cela permet d’éprouver une nouvelle version seulement sur un panel de clients / sessions.
- pages construite par le front en agrégeant les données provenants de divers appels au “services” : chaque appel prends en moyenne entre 2 et 15 ms
- 64 serveurs web “stateless”: les éventuels “états” liés à un utilisateur sont stockés en DB.
- Postgres: plus 700 millions de requêtes par jour.
- 2 data centers: un en mode lecture/ecriture l’autre en mode read only fail over. swap régulier entre les deux modes.
- logs à fond: beaucoup de logs produits dans la démarche de monitorer un maximum d’éléments
- les développeurs intervienent sur toutes la chaine: de la DB jusqu’au CSS !! et si vous n’avez pas une compétence.. vous apprenez !
- emplois de ingénieurs motivés par tout type de taches et pret à apprendre, toujours.
- scaling vertical des DBs autant que possible: éviter les joins, mettre le maximum en RAM et donc upgrader au maximum les serveurs avant de partitionner horizontalement.
- pas de join dans le meme esprit que les services: pas de join entre domaines fonctionnels différents.
- keep it simple: code simples, machines standards, par d’usine à gaz, pas trop de process, déploiement simple. je pense que la simplicité au niveau soft donne plus de liberté au niveau système pour le scaling, disponibilité etc… AMHA
- monitoring: utilisation de scripts custom qui parsent les logs et génèrent des graphs. d’ou l’utilité de cette masse de logs
- design for failure: ne pas faire totalement confiance meme a ce que est censé ne pas tomber en panne. partir du principe qu’a un moment ou un autre quelques chose va tomber en panne..
