L’arrivée de Free sur le marché du mobile français a été…fracassante. Son site web d’inscription aussi. Il a été, pour ainsi dire, indisponible le premier jour. Les premières inscriptions ont pu être réalisées que le lendemain.

Bon, l’objectif n’est pas de dire si le prix de ces nouveaux forfaits est bien ou pas, si le service est bien, si on capte au fin fond du Gers (mais le front de libération du Gers m’oblige à dire que le Gers c’est bien). En tant que développeur, je me suis posé la question suivante : Si on vient me voir demain, et on me demande de concevoir un site qui permet de tenir la charge avec 1 million de demandes par minute, je réponds quoi ?”

Et voilà, vous avez compris de quoi va parler ce post :).

Ce post est simplement un extract d’une réflexion que j’ai eu lors d’un voyage en voiture de 4h le lendemain (Mercredi) de l’annonce de Free Mobile. C’est un mélange de banalités, de points qui peuvent être évidents pour nombre de développeurs. Les théories du “Free a fait exprès de limiter son service”, ou du « il n’avaient pas pensés à tout cela/ils ont bien pensés à tous ces points », ne m’intéressent pas dans le cadre de cet article. Ce que je trouve intéressant, c’est de partager cette réflexion et un certain nombre de points qui sont certainement non connus de beaucoup (trop) de développeurs web.

Lors de l’écriture de ce post, il s’est avéré rapidement que celui-ci allait être très long. J’ai donc décidé d’en faire une série de posts.
Si vous avez des remarques sur celle-ci, n’hésitez pas à remplir la zone de commentaires :).

Les faits / les besoins

On va lancer un site à très fort trafic sur une période plus ou moins importante (on peut dire que l’on va avoir 72h de folie, et 2/3 semaines de très forte affluence). Ce site va permettre :

• d’avoir une page de présentation des offres
• de pouvoir télécharger quelques fichiers (grille tarifaire, CGV, CGA, …)
• de “se connecter” si on est déjà abonné
• de souscrire à un abonnement, en 4 étapes (choix du forfait, coordonnées personnelles, données bancaires, choix du N° ou portabilité du numéro).

Maintenant, question essentielle : à quelle volumétrie doit-on s’attendre ? Et bien 1 million de demande par minute (dixit Xavier Niel au Grand Journal, le 11/01/2012). Ya plus qu’à !

On s’arrête deux secondes sur ce chiffre : 1 million de hits par minute…60 millions de hits par heure, 1,8 milliard de hits par mois. Si on prend le site le plus consulté de France – leboncoin.fr- il est à 5,8 milliards/mois (si on prend “demande” = “hit” = “page vue”). Le second site français est à 0.6 Milliards. En l’espace de quelques heures, on se retrouve donc avec un site qui a une fréquentation de 0 (on oublie la période buzz, qui n’avait qu’un fichier html basique) au second site le plus visité de France, après l’équipe, le monde, le figaro, seloger.com … Pas mal, non ? :)

Ping me if you can

Avec une telle volumétrie, le moindre composant devient primordial. Il faut reprendre tout ce qui se passe lorsque le visiteur vient sur le site, étape par étape, et optimiser chacune de ces opérations.

On commence donc par ouvrir son navigateur, taper http://mobile.free.fr, et appuyer sur entrée. En tant qu’éditeur du site, il y a toute une partie de la chaîne sur laquelle on n’a aucun contrôle : le wifi du visiteur, la qualité de sa ligne ADSL, etc… . Le premier maillon sur lequel on peut agir ce sont les serveurs DNS. Mais bon, les DNS…on s’en fout non ? On les a avec notre registrar, ou carrément sur notre serveur web et cela suffit ?

En réalité, Les DNS sont l’un des éléments les plus sous-estimés de l’hébergement de sites internet. Et pourtant, entre l’hébergement et le réglage des DNS, vous avez déjà de quoi faire.

Ils sont où mes DNS ?

Les serveurs DNS pour vos sites sont généralement chez la société chez qui vous avez enregistré votre nom de domaine. Mais ce n’est pas une obligation. Il existe de nombreuses sociétés qui se proposent de gérer vos DNS pour vous. Vous pouvez également les héberger sur vos propres serveurs (cette dernière option est, pour la plupart des situations, déconseillée).

Comment choisir entre son registrar et un service tiers ? Cela dépend déjà du service DNS de ce dernier. Certains vous limitent dans le nombre d’enregistrement, d’autres dans le type d’enregistrements (vous n’avez pas accès aux enregistrements du type SRV, TXT ou AAAA pour l’IPv6). Mais l’un des critères qui peut vous faire changer pour un service dédié, c’est le SLA. Quelle garantie vous apporte votre registrar à ce niveau ? La solution d’installer des serveurs DNS sur son infrastructure cloud n’est pas non plus la meilleure réponse. Les services DNS sont souvent l’un des points les plus fragiles de l’architecture des services internet (et donc, également cloud).

A part associer free.fr à l’ip x.x.x.x, je peux faire quoi avec le DNS?

Si on se concentre uniquement sur du traffic web, qui nécessite de traduire un nom de domaine en adresse IP, votre DNS est l’un des systèmes de load-balancing le moins cher du marché. En effet, un utilisant la technique du Round-Robin DNS, votre serveur DNS va répondre différemment à chacune des requêtes qu’il reçoit. Cela vous permet d’associer une liste d’adresses IP à un seul enregistrement DNS. Attention, cela vous oblige à avoir des serveurs qui sont TOUS capables de répondre aux requêtes, et ceci de la même manière (ie. même version de l’application, ils se connectent tous aux mêmes données, etc…nous reviendrons sur ce point plus loin). Une variante, appelée Weighted round robin vous permet d’affecter un “poids” aux différentes réponses possibles. Vous pouvez ainsi faire en sorte que ce soit les adresses IPs des serveurs les plus costauds qui soient retournées le plus fréquemment.

DNS et mise à jour des applicatifs : Dans les infrastructures cloud, il est fréquent d’avoir plusieurs fois tout ou partie de son infrastructure dupliquée (c’est du moins plus simple – hormis le coût). Le DNS vous permet aisément de promouvoir un environnement de staging ou de préproduction en environnement de production. Il suffit de changer l’adresse IP dans le DNS. Le retour en arrière est tout aussi simple. Les instances Windows Azure sont d’ailleurs un bon exemple de simplicité dans ce domaine (bien que Azure soit un niveau en dessous, car ils changent les adresse IP virtuelles, et non pas l’enregistrement DNS). Le swap de VIPs dan Azure est une solution encore plus efficace pour la haute disponibilité et la gestion de la charge que la répartition via DNS.

On a donc ici un premier point pour assurer cette charge : la répartition de charge via le DNS.

Tu me caches quelque chose ?

Moi ? Non, mais vos DNS eux en ont l’habitude. Il y a de nombreux niveaux de caches pour les enregistrements DNS : le TTL (Time-to-live) du serveur DNS, les serveurs DNS de votre fournisseur d’accès, les serveurs DNS de votre box/routeur, les serveurs DNS de l’entreprise, le cache DNS de votre OS, le cache de votre navigateur (1min pour Firefox 3, 15 minutes pour IE 7).

Ce cache est plutôt une bonne chose pour notre problème actuel, car il permet de réduire le trafic vers nos serveurs DNS. Mais si vous avez à changer les adresses IPs de vos serveurs en plein milieu du coup de feu, cela peut vous poser des problèmes.

On en arrive à parler de l’un des réglages les moins pris en considération des DNS : Le TTL. Ce chiffre indique aux différents composants qui se permettraient de cacher le résultat d’une requête DNS “Hey, tu as le droit de le stocker, mais dans (remplacer par la valeur du ttl), redemande moi, car je risque d’avoir changé de réponse”. Si vous indiquez 1 jour, une très grande partie de votre trafic (= tous ceux qui ont déjà visités votre site avant le changement et dont le temps de cache est valide) sera toujours effectué sur votre ancien serveur. Si celui-ci est tombé, cela veut dire 0 trafic pour vous…pendant 1 jour.

Si on regarde les TTL de quelques grands site, on obtient les résultats suivants :

On voit donc que le temps est relativement court. Ce temps court va, certes, générer un peu plus de trafic DNS, mais il permet également de pouvoir effectuer des modifications sans avoir de délai de propagation trop important. Si vous devez changer en catastrophe d’hébergeur, un TTL d’une journée (ce qui est assez courant) rendra indisponible votre site jusqu’à une journée pour certains de vos visiteurs.

Une solution DNS efficace ?

Avoir une solution DNS efficace, abordable, sûre et qui peut accepter une charge importante n’est pas quelque chose d’aisé. Dans ce domaine, pour moi, l’une des solutions les plus intéressantes est Route 53 D’amazon Web Services. Pour un prix tout à fait abordable (0.5$/mois/nom de domaine + 0.5$ / million de requêtes), vous avez tous les services cités ci-dessus, avec un SLA de 100% (+ compensation en cas d’indisponibilité).

 

Que mettre derrière son DNS ?

Nous n’avons que très peu d’éléments sur ce qu’il y a derrière mobile.free.fr en terme de technologie : un proxy nginx, du Java Server Faces, et un usage de jquery. On n’a également aucune idée de toute l’infrastructure qu’il y a derrière. Cette partie va donc, premièrement, se baser sur un certain nombre d’hypothèses, secondement, sur un choix de technologies Microsoft (ca vous étonne ? :)).

Les défis

Le site d’inscription a, visible d’un point de vue utilisateur, les fonctionnalités suivantes :

• Afficher des pages d’informations,
• Permettre de télécharger certains documents (pdf des CGV, etc…),
• Se connecter avec ces identifiants Free,
• Remplir un formulaire d’inscription,
• Utiliser la portabilité ou choisir un numéro de téléphone
• Recevoir par email l’accès à son espace client

Les plus gros points de contention sont en gras : la connexion avec les identifiants Free nécessite un accès à un service d’authentification (on va considérer que la copie de l’ensemble des utilisateurs/mot de passe n’est pas la solution retenue), et le choix du numéro de téléphone ne doit pas être réalisé en simultané par deux personnes.

L’une des premières choses que l’on va pouvoir faire, c’est la création d’un CDN. De nombreux fournisseurs existent, à commencer par Windows Azure. Le CDN va nous permettre de répliquer le contenu sur de nombreux serveurs, spécifiquement configurés pour délivrer du contenu statique, à travers toute la planète. Le seul point ici –et pour l’ensemble des solutions “cloud” globales – c’est qu’elles ne disposent pas forcément d’un noeud en France, et certainement pas de plusieurs noeuds en France. Le CDN reste pertinent car il sera à même de délivrer le contenu statique du site (PDF, CSS, images) beaucoup plus rapidement que le serveur web. Si on devait ne servir qu’un pays et pour une durée plus longue que ce pic d’affluence (par exemple le site de rediffusion d’une chaîne nationale), la stratégie pourrait être légèrement différente.

L’affichage des informations n’est pas la partie la plus compliquée. On peut penser que de simples pages HTML sont la meilleure réponse que l’on puisse apporter. Mais cela ne suffit pas, il y a de nombreux éléments de performance à prendre en compte, y compris pour une simple page HTML : Taille du code HTML, nombre de liens (CSS, JS) référencés et minification, …), etc… Si on regarde de plus près le site de Free Mobile, certaines de ces règles ne sont pas respectées. Pour voir cela, j’utilise l’indispensable plugin Y!slow de Yahoo. Il permet de valider si un site répond aux « grands critères de performance » déterminés par les équipes de Yahoo.

 

 

Une migration vers Windows Azure

Windows Azure est là, pourquoi ne pas prévoir de déployer notre infrastructure dessus ?

En fait, on a déjà commencé à le faire, avec notre CDN. En plus, c’est dans le cloud, donc pas de problèmes de charge ? Non ? Non, avoir tout ou partie de votre infrastructure dans le cloud ne vous prive pas magiquement de réfléchir aux impactrs d’une charge importante, y compris pour un service tel que le CDN !

On va considérer que le blob storage d’Azure ne perdra pas nos fichiers dans l’espace de temps où notre site d’inscription sera en ligne. Il a cependant des limites dans la capacité de l’infrastructure Azure à répondre à vos requêtes. D’un point de vue global, il y a de quoi répondre, pas de soucis :). Cependant, si on prend un compte, ou un fichier, il faut s’intéresser aux Scalibility targets. On apprend ainsi qu’une limite existe à différents niveaux, notamment qu’un seul compte de storage ne peut assurer “que” 5,000 téléchargements par seconde. Si on remet cela avec notre target à nous (1M/s) et que nous avons 3 blobs par page (1 JS, 1 CSS et 1 image utilisée en sprite-css), un compte de stockage azure ne peut assurer que 1666 “utilisateurs” par seconde, et il nous faudra 600 comptes de stockage pour assurer cette charge (chaque compte azure a une limite de 5 comptes de stockage, qui peuvent être débloqués via un appel au support). Cette estimation est grossière (tous les clients ne demandant pas à chaque chargement les fichiers grâce au cache, ni durant la même seconde).

Alors, tous ces chiffres sont pour les comptes de stockage, et non pas pour le CDN. En effet, les CDNs sont entre l’utilisateur et le compte de stockage. Ils stockent en local les données du blob storage (pendant une durée qui peut être personnalisée). On aura donc une scalability target différente. Celle-ci peut s’évaluer avec le nombre de points du CDN (à voir s’il n’est récupéré qu’une fois par edge location ou une fois par serveur de l’edge location), le nombre de fichiers et la durée du cache.

Je n’ai pas trouvé de métriques sur les capacités du CDN, mais elles sont bien évidemment supérieures. Un détail est également important dans notre cas : la géographie de nos visiteurs. Le CDN est très intéressant quand vous avez des utilisateurs aux 4 coins du globe, moins quand l’ensemble de vos utilisateurs sont sur le même pays. Cependant, Si le point de Paris venait à être surchargé, une partie du trafic est automatiquement redistribué sur d’autres points (Zurich, Londres ou Amsterdam).

 

Fly me to the cloud

Nous avons fait une bonne partie du travail. Il nous faut maintenant nous occuper d’une partie centrale : le site d’inscription à proprement parler. Pour les besoins de cet article, notre choix technologique se portera sur ASP.net MVC. Nous devons désormais créer notre site pour qu’il supporte cette charge. Nous savons qu’il sera hébergé dans Windows Azure. Nous développons notre site rapidement, et nous le testons sur notre machine de développement.

Une fois le site déployé dans Azure, une simple modification d’un fichier de configuration nous permettra de grossir l’infrastructure qui l’héberge. En ce sens, deux leviers s’offrent à nous :

• Le Scale-up : ou le fait d’augmenter la puissance de chaque serveur qui héberge notre site. On augmente le nombre de processeurs, la mémoire vive, etc… Avec Windows Azure, c’est la « taille » de notre instance que l’on augmente,
• Le Scale-out ou le fait d’augmenter le nombre de serveurs qui hébergement notre site, ou le nombre d’instances sous Azure.

On pourrait penser que l’on a ici terminé notre travail. On a réfléchi au DNS, à minimiser notre volumétrie, à héberger nos fichiers statiques sur un CDN, et nous avons pleins de serveurs surpuissants pour répondre aux requêtes.

Cela n’est malheureusement pas suffisant. Nous verrons dans le prochain épisode que, même pour un site « simple » comme celui-ci, il n’est pas possible de se contenter d’héberger son site dans Azure pour immédiatement pouvoir absorber une telle charge.

Le prochain épisode s’intéressera à l’architecture qui permettra, avec un ensemble de services Windows Azure, de supporter un site à fort trafic de ce type. Stay tunned.