| |
 |
David Bordas
Responsable
technique
Jeuxvideo.com |
|
David
Bordas
"Avec des développements internes, nous sommes sûrs de connaître le fonctionnement de nos applications"
Avec 1,65 million de visiteurs uniques par mois, Jeuxvideo.com se classe parmis les premiers sites éditoriaux en ligne. Son responsable technique nous en dévoile les coulisses.
26/04/2005 |
| |
|
 |
JDN
Solutions. Quelle était la plate-forme technique de votre site lors
de sa création ?
David Bordas. L'entreprise a été créée en 1997
par trois personnes. Au lancement, l'hébergement se
faisait chez un petit hébergeur mutualisé qui nous fournissait
un espace disque d'un mega-octet. Internet n'était alors
pas aussi développé que maintenant. Lorsque nous avons
commencé à grossir, l'hébergement a été confié à Adarweb,
devenu VerioFrance après son rachat par Verio.
A-t-elle connue des changements
jusqu'à aujourd'hui ?
Dans les années 1999-2000, l'architecture est passée
sur un environnement multi-serveur sous Linux avec un
répartiteur de charge Alteon. Le support était encore
confié à VerioFrance mais l'hébergement proprement
dit s'effectuait dans un centre de données basé à Springfield,
aux Etats-Unis.
En
2002, ce centre de données a été rapatrié en France,
à Courbevoie, chez Téléglobe. Nous avions alors fait
le choix de Téléglobe car nous n'étions pas satisfait
de Verio et de ses prestations. Depuis le rachat par
Verio, les procédures d'hébergement d'Adarweb avaient
été changées en profondeur.
Fin 2001, une coupure de
courant est survenue dans notre centre de données et
a touché tous nos serveurs pendant une à deux heures.
Je considère que ce genre d'incident ne doit pas arriver. Une fois chez Téléglobe, nous y sommes restés un certain
temps mais ils ont fait faillite. Depuis, Agarik, ancien
sous-traitant de Téléglobe, se charge de notre hébergement.
Utilisez-vous une solution
de mise en cache des données pour gérer votre trafic
?
Non, j'ai eu des contacts avec Akamai. Leur solution
propose d'absorber le coût de la montée en charge par
leur propre infrastructure, au lieu de rajouter un serveur
chez nous. Mais, à l'époque, acheter un serveur supplémentaire
chez mon hébergeur me coûtait moins cher.
Un autre problème
se serait posé : nous n'aurions pas trop su où transitaient les données.
Or, ce que l'on connaît mal ou peu fait peur. Nous n'aurions
pas eu la maîtrise totale de la chaîne de publication.
Comment s'organise aujourd'hui
votre centre de données ?
|
|
 Nous totalisons 11 serveurs différents, dont 5 frontaux Web sous Apache" |
|
Nous totalisons 11 serveurs différents, dont 5 frontaux Web sous Apache, deux
serveurs de base de données sous MySQL, un serveur de
téléchargement sous Linux et BitTorrent, deux serveurs
de mail SendMail, dont un est utilisé comme anti-virus
avec la solution Kaspersky Server.
Nous disposons
d'un dernier serveur dédié à nos clients, fournissant
notamment des prestations d'hébergement. Enfin, deux
répartiteurs de charge Iron de Foundry Networks assurent
l'évolutivité et la stabilité du site.
Avec Linux, Apache et MySQL,
utilisez-vous le langage PHP ?
Il n'y a que très peu de PHP sur Jeuxvideo.com, cela
afin de supporter la montée en charge et réduire au
maximum les ressources serveurs. Par exemple, la partie
publication de données et mise en forme de contenu est
issue de développements internes en langage C.
Le système
fonctionne de la manière suivante : nous générons des
pages HTML qui sont ensuite réparties sur nos frontaux.
Les pages HTML exigent moins de ressources machines
- pour être affichées - que des pages dynamiques.
Pourquoi avoir généralisé
le développement en C sur un environnement Web ?
|
|
J'obtiens
une meilleure performance avec du développement
CGI" |
|
J'obtiens une meilleure performance avec du développement
CGI. Le C est un langage de bas niveau et permet donc
de faire les choses plus finement qu'avec PHP. Comme
module d'Apache, le PHP est un langage interprété et
non compilé comme le C.
Toutefois, l'inconvénient majeur
du C - puisqu'il n'a pas été prévu à l'origine pour Internet -
vient du fait qu'il faut décrire par soi-même des fonctions
comme la gestion des cookies ou des flux XML.
Le choix du langage C est-il
historique ?
Non, à l'époque de la création du site, une grande partie
des développements avaient été fait en Perl. Mais, au
fur et à mesure de la montée en charge, certains programmes
ont été réécrits en C. Désormais, les nouveaux programmes
sont automatiquement développés en C.
Pourquoi avoir opté pour
Linux comme système d'exploitation ?
D'abord, en raison de sa robustesse et de sa fiabilité,
puis de son prix. De plus, l'équipe connaissait déjà
bien Linux. Le principe de l'Open Source représente
un avantage certain pour nous. Si une faille vient à
être découverte, la taille de la communauté est telle
que la faille sera corrigée plus rapidement que sur
un système Microsoft. Nous sommes tellement contents
de Linux que nous ne souhaitons pas changer.
Du point de vue de la performance, il nous faudrait
plus de machines, sans compter le coût des licences pour
faire tourner le site. Apache était un choix logique
avec Linux. Enfin, concernant MySQL, nous en sommes
contents et comme notre structure de base de données
est relativement simple, cette solution nous permet
d'être performants sans avoir les coûts pharaoniques
d'une solution Oracle.
D'une manière générale,
comment arbitrez-vous entre développement interne et
externe ?
|
|
La
disponibilité du code source représente
davantage un gage de sécurité
qu'une menace" |
|
Historiquement, en 1997-1998, les solutions du marché
étaient moins développées qu'elles ne le sont aujourd'hui.
Notre moteur de recherche - mais aussi notre outil de
publication - ont alors été développés en interne. Depuis,
nous en sommes satisfaits.
Comme ce sont nos produits,
nous sommes sûrs de connaître tout ce que fait le programme
et comment il le fait. C'est un gage de sécurité. Cela
correspond également à notre choix de l'Open Source.
Je considère que la disponibilité du code source représente
davantage un gage de sécurité qu'une menace.
Avez-vous envisagé de consolider
votre parc de serveurs ?
Aujourd'hui, le site fonctionne à l'aide de machines
Bi-Xeon dotées de 2 Go de RAM. Typiquement, à l'heure
actuelle, je ne suis pas convaincu que nous puissions
faire tourner tout jeuxvideo.com sur une seule machine.
En revanche, une baie de disques a été envisagée. Tous
les serveurs seraient reliés à la baie de disques et
partageraient ainsi le même disque dur. Les serveurs blades
ne sont pas forcément quelque chose d'intéressant pour
nous.
Quels sont vos projets
pour 2005 ?
Le gros challenge cette année consiste à créer une architecture
multisite. Notre architecture redondante réunit toutes
les machines dans une seule et même salle. Cela comporte
un risque car si le centre de données tombe en panne,
toute la plate-forme du site est indisponible.
Différentes
options s'offrent à nous : soit nous créons un site
agissant comme une bouée de secours, c'est-à-dire qu'il
ne reçoit de trafic que si le site principal tombe,
soit nous partageons le trafic entre les deux sites.
La première solution sera moins coûteuse - car sans
frais d'administration courant - mais moins optimisée
en matière de ressources.
| La
DT de Jeuxvideo.com |
| La direction technique |
|
Effectif
|
3 personnes
|
|
Les solutions
technologiques |
|
Serveur
Web
|
Apache
|
|
Langage
de développement
|
C,
Perl
|
|
Bases
de données
|
MySQL
|
|
Systèmes
d'exploitation
|
Linux
(Red Hat)
|
|
Moteur
de recherche
|
Interne
|
|
Serveur
de messagerie
|
SendMail
|
|
Antivirus
|
Kaspersky
Server
|
|
Publication
de contenu
|
Interne
|
|
| |
Propos recueillis par Yves DROTHIER, JDN Solutions |
|
|
PARCOURS
|
|
|
| |
David Bordas, 25 ans, est responsable technique
du site Jeuxvideo.com. Il était anciennement
analyste programmeur lorsqu'il a rejoint le groupe,
5 ans plus tôt.
08/2000 : Analyste programmeur chez Jeuxvideo.com.
Et aussi titulaire d'un DUT informatique
(2000) |
|
|
|
Dossier 