La cuisine de Gandi

Accueil > Hébergement > Penser architecture web - Aller plus loin avec plusieurs centres de données

Penser architecture web - Aller plus loin avec plusieurs centres de données


1. Vérifier d'abord votre code source, puis les configurations des services

Bien entendu, avant de se lancer dans les optimisations du serveur ou plus loin dans une architecture spécifique, il convient d'identifier les problèmes inhérents aux code source.

Puis il est nécessaire de vérifier si les services (serveur web, de bases de données, ...) sont bien configurés par rapport au serveur d'hébergement (ses ressources, notamment RAM et processeur).

2. Augmenter la puissance du serveur en adaptant les configurations des services

Une fois que vous avez optimisé le code source et que les configurations sont optimales, si le service manque toujours de réactivité, si le serveur ne parvient pas à honorer les requêtes de vos visiteurs (syndromes de la page blanche, de pages incomplètes ou encore expiration de la connexion), vous pourrez augmenter la puissance et reconfigurer les services en accord avec ces nouveaux paramètres.

Sur un serveur physique, il sera difficile d'augmenter les ressources sans changer d'offre.
Sur un serveur cloud Gandi, il vous suffit d'ajouter du processeur et de la mémoire vive, à chaud, sans redémarrage (dans une certaine limite)

Si vous avez déjà poussé tous les paramètres à fond, il va falloir aller plus loin...

3. Optimiser les services

Il y a plusieurs services qui peuvent être optimisés, prenons l'exemple d'un blog qui connaît un nombre important de connexions qui fonctionne sous PHP/MySQL, soit une grande partie des sites web aujourd'hui.

Serveur web (Apache, Nginx, Cherokee, ...)

Pour chacun d'entre eux, les gestionnaires de connexions diffèrent, il est préférable de vérifier les bonnes pratiques pour les configurer par rapport à la puissance du serveur, la consommation de ressources maximum par visite, ... Leurs documentations restent le bon point de départ pour les appréhender au mieux.

Module/interpréteur PHP


Apache est connu pour faire fonctionner l'interpréteur PHP à la volée, soit le démarrer lorsqu'il y a du code PHP à exécuter. Démarrer l'interpréteur peut etre long à s'instancier, cela peut paraître infime, cependant, c'est une source majeure de ralentissements. Pour éviter cela, on peux sortir PHP du serveur web en passant du mode module (mod_php) en FastCGI. L'interpréteur démarre donc au meme moment que le serveur web, reste en arriere plan et est disponible immédiatement. Il est donc recommandé de passer PHP en mode FastCGI. Notez que Cherokee ou Nginx sont paramétrés comme cela nativement.

Serveur de bases de données MySQL

Il existe sur MySQL plusieurs optimisations comme sur cet article (qui date un peu).
La documentation à jour est disponible sur cette page.

Comme vous le verrez dans cet article provenant de MySQL, ils demandent bien de trouver les  goulots d'étranglement inhérents au code source, au serveur, aux liaisons entre les services, ... avant de se lancer dans les optimisations qui peuvent être :
  • matérielles : comme adapter la version du système selon la taille des bases et de la mémoire vive (32/64bits), les disques (lire plusieurs blocs à la fois) ou le système d'exploitation (nombre de fichiers ouverts avec ulimit)
  • la réplication pour avoir plus de serveurs permettant d'augmenter le nombre de requêtes possibles en simultané
  • augmenter le nombre de threads et/ou de connexions sur chaque serveur
  • optimiser les requêtes SQL et utiliser un moteur convenant à l'utilisation faite
  • utiliser les caches (query, key myisam ou buffer innodb)
  • ...

Systèmes de caches

Vous pouvez installer des systèmes de cache à plusieurs niveaux : nous l'avons vu pour MySQL rapidement, sachez qu'il existe des caches à placer devant le serveur web (cache HTTP tel que Varnish) qui garde une copie de la page web complète en mémoire. D'autres systèmes de cache pour les interpréteurs comme Xcache pour PHP. Ils consomment un peu de ressources mais évitent une charge supplémentaire sur les services principaux en limitant les appels que pour le recalcul de la page web et le remplaçement dans le cache.

Pour le cache Web/HTTP, il permet aussi d'éviter que le serveur web ne soit directement accessible depuis l'extérieur, offrant un protection légère mais non négligeable.

4. Opter pour une architecture répartie

Si, au terme de ces optimisations, le serveur ne supporte toujours pas la charge, il faudra donc penser architecture web

Cela implique de multiplier les serveurs où sont installés les services pour répartir la charge sur chacun d'eux, il est possible de dupliquer tout ou partie de l'infrastructure : web, caches, bases de données, ... La répartition peut se faire au niveau du cache HTTP (Varnish), des DNS (Round Robin) ou d'un proxy (tel qu'Haproxy) selon les souhaits et la taille de la plateforme.

Avec des systèmes de vérification (de type "healthcheck" sur Haproxy, Heartbeat ou encore Varnish par exemple), nous pouvons éviter d'envoyer un visiteur sur un serveur dont les services ne fonctionnent pas.


La géolocalisation des visiteurs ou l'exploitation de plusieurs centres de données pour le même service
Avec l'architecture répartie, nous avons trouvé une solution qui permet d'honorer la charge en terme de visites simultanées en masse. Cependant, certains visiteurs éloignés du pays de localisation des serveurs peuvent avoir une latence importante (depuis la Nouvelle Zélande ou le Chili vers la France par exemple). Une solution est de mettre à disposition des serveurs plus proches d'eux, en géolocalisant par pays par exemple, le serveur DNS Bind avec le système de "vues" (views) allié à la base MaxMind qui contient les plages d'adresses IP par pays effectue bien cette opération.

Un exemple concret avec un blog Wordpress sur 2 centres de données

Vous pourrez voir un exemple de cette solution réalisé par Emerick du support hébergement sur le site suivant. Le site est ouvert aux commentaires, sera agrémenté avec plus de solutions et d'explications dans les prochaines semaines. Vous aurez une vue plus détaillée de l'utilisation de chaque service, voir des configurations (basiques) utilisées pour mettre en place cette petite plate-forme.

A titre d'information, nous avons pris des serveurs d'une part chacun :
  • un DNS,
  • deux serveurs Web,
  • deux serveurs de bases de données.
Nous n'avons pas mis en place toutes les optimisations décrites, les serveurs web sont différents en France et aux USA, les caches Varnish sont situés sur les serveurs web directement.