Bon, l'un des gros problèmes du service de fichiers statiques, c'est qu'il exige un amorçage (bootstrap) complet de Drupal, ce qui gruge beaucoup de ressources système. Nous avons du travail à faire dans Drupal et l'API File pour prendre en charge des options d'évolutivité intéressantes, les fichiers distants, etc. Mais je pense qu'il existe des modèles intéressants pour servir des fichiers statiques de façon très évolutive en dehors de Drupal (et S3 d'Amazon est génial). Pour la première architecture, considérez ce qui suit, pour le domaine example.com :
- 3 serveurs Web frontaux (ou plus) avec Drupal installé (extractions identiques de la base de code; appelons-les www1 - N)
- une base de données en arrière-plan (une grappe ou simplement une grosse machine haute performance; appelons-la db1 - N)
- les répertoires files et tmp de Drupal montés par NFS à partir d'une machine distincte (soit un NAS, soit le serveur de fichiers statiques lui-même)
- une machine servant les fichiers statiques (appelons-la static1 - N)
Pour Drupal, toutes les opérations sur les fichiers sont locales : le système NFS monté est configuré selon les réglages locaux files et tmp, et Drupal croit écrire sur un système de fichiers local. Aucune modification du code de Drupal n'est donc nécessaire. Ensuite, pour servir réellement les fichiers, les serveurs frontaux www* ont un mod_rewrite d'Apache configuré pour rediriger toutes les requêtes de fichiers (p. ex. *.jpg, *.doc, etc.) vers static.example.com. Celui-ci n'a pas du tout besoin d'exécuter PHP (ni même Apache) : il est entièrement optimisé pour servir des fichiers statiques. C'est tout. Je n'ai pas (encore) d'exemple de règles mod_rewrite pour cela, mais je pense que ce serait une « recette » intéressante pour servir beaucoup de fichiers statiques sans pénaliser la performance de Drupal.
Aussi : il n'est PAS OBLIGATOIRE d'utiliser cela avec une grappe; on peut même le faire sur une seule machine : un hôte virtuel exécute Drupal, et un autre exécute le serveur Web de fichiers statiques. Mais un minimum de deux machines procurerait déjà un bon gain de performance.
Ce que je pense d'Amazon S3? D'abord, pour ceux qui ne connaissent pas, voici la citation de la page qui le décrit :
Amazon S3 est un espace de stockage pour Internet. Il est conçu pour faciliter l'informatique à l'échelle du Web pour les développeurs. Amazon S3 offre une interface de services Web simple qui permet de stocker et de récupérer n'importe quelle quantité de données, n'importe quand, de n'importe où sur le Web. Il donne à tout développeur accès à la même infrastructure de stockage de données hautement évolutive, fiable, rapide et peu coûteuse qu'Amazon utilise pour exploiter son propre réseau mondial de sites Web. Le service vise à maximiser les avantages de l'échelle et à en faire profiter les développeurs.
Vous obtenez donc un stockage de fichiers dédié chez Amazon, avec une interface de services Web et de bons tarifs de bande passante. Il y a aussi quelques petits extras très sympas : par exemple, vous pouvez demander n'importe quel fichier en ajoutant ?torrent à la fin pour obtenir automatiquement un fichier d'amorce BitTorrent. Un vrai module Drupal qui ferait des choses plus intéressantes serait emballant, mais ce n'est pas le propos de ce billet...
Imaginez donc un script côté serveur qui synchroniserait ces mêmes répertoires files et tmp avec le service S3 d'Amazon, et le script mod_rewrite pointant vers l'espace Amazon S3. Vous n'utilisez même plus votre propre bande passante ni votre propre stockage, et vos coûts de bande passante et de stockage sont prévisibles.
Il y a toutefois un piège qui demande du travail. En gros, un script prendra un temps X pour transférer les nouveaux fichiers vers le service S3. Pendant ce temps, mod_rewrite ne doit PAS rediriger les requêtes visant uniquement les fichiers qui n'ont pas encore été synchronisés. Le script de synchronisation devra donc probablement mettre à jour mod_rewrite dynamiquement (insérez ici de grands gestes vagues) en attendant la synchronisation des fichiers.
Note : je ne suis vraiment pas « le gars des serveurs »; je me débrouille assez bien en architecture de systèmes, mais il se peut fort bien que je déraille sur certains points. Ces idées me trottent dans la tête depuis un moment, alors je me suis dit qu'il était temps de les publier. Commentaires et rétroaction bienvenus.