Inside Google Labs

Publié le 15 novembre 2006 et mis à jour le 28 avril 2007 - 9 commentaires -

J’ai assisté récem­ment à une pré­sen­ta­tion d’Alice Bonhomme-Biais, une ingé­nieur fran­çaise en déve­lop­pe­ment logi­ciel chez Google. Elle était des­ti­née à des élèves de l’option tech­no­lo­gies de l’information de l’Ecole Cen­trale Paris où j’enseigne sur les Stra­té­gies de l’Innovation.

En une heure, Alice a dressé un por­trait fort inté­res­sant de la manière dont le déve­lop­pe­ment et les opé­ra­tions fonc­tionnent chez Google.

En voici un apperçu, com­plété par un peu de lec­ture personnelle, avec tout d’abord quelques remarques générales:

• Tout d’abord, Google a des labos de déve­lop­pe­ment bien répar­tis dans le monde. Rien qu’en Europe, ils en ont un à Dublin où se trouve égale­ment un data cen­ter euro­péen, un à Londres, un à Zurich et un autre à Trond­heim, en Suède. Alice est elle-même basée à New York dans un autre labo. Donc, Google a beau être un clas­sique suc­cès de la Sili­con Val­ley, basé à Moun­tain View, ils ont rapi­de­ment éclaté géo­gra­phi­que­ment leurs déve­lop­pe­ments. C’est per­mis par une orga­ni­sa­tion du déve­lop­pe­ment logi­ciel en petites équipes : de 2 à 10 per­sonnes, et 5 en moyenne. Il y a d’un côté des ser­vices qui requièrent effec­ti­ve­ment des équipes de cette taille, comme le Calen­drier sur lequel tra­vaille Alice Bonhomme-Biais. Et de l’autre, le gros du déve­lop­pe­ment qui est orienté sur le search est lui-même découpé en autant de modules néces­si­tant des équipes de cette taille. L’éclatement géo­gra­phique du déve­lop­pe­ment répond à une logique de recru­te­ment assez simple consis­tant à cher­cher les talents là où ils sont au lieu de leur pro­po­ser tous de démé­na­ger à Moun­tain View. Au pas­sage, cela per­met de contour­ner les limi­ta­tions du nombre de visas pour l’entrée de tra­vailleurs aux USA. C’est donc bien vu! Et cer­tains éditeurs de logi­ciels pour­raient s’en ins­pi­rer! Donc, Google conti­nue de recru­ter à tour de bras et les ingé­nieurs fran­çais les inté­ressent, même s’il n’y a pas encore de labo de R&D en France même.
• Le déve­lop­pe­ment de nou­veaux ser­vices est (serait?) piloté par les équipes pro­duits, indé­pen­dam­ment de toute démarche mar­ke­ting ou de modèle écono­mique. Le point clé est de créer des ser­vices qui ont une grande valeur d’usage pour les uti­li­sa­teurs et de géné­rer du tra­fic. Une fois seule­ment usage et tra­fic géné­rés se pose la ques­tion de la moné­ti­sa­tion. Sachant qu’en plus, Google fait très peu de mar­ke­ting de ses offres. Elles se dif­fusent en mode viral et grâce au tra­fic généré par le moteur lui-même. Ce décou­plage pro­duit / mar­ke­ting est sommes toutes encore plus fort que ce que j’ai constaté chez Micro­soft Corp. Il est contre-intuitif pour ceux - comme moi - qui pensent que le mar­ke­ting doit être impli­qué le plus en amont pos­sible de la créa­tion d’un pro­duit pour assu­rer son ali­gne­ment avec un besoin mar­ché et avec un busi­ness qui tienne la route. Google peut éviter cette démarche pour un cer­tain nombre de fac­teurs dont peu d’entreprises béné­fi­cient: une marge énorme géné­rée par le coeur de métier qui per­met de finan­cer (sou­vent à perte) de nom­breux tests de nou­veaux pro­duits, le tra­fic généré par le site Google qui per­met d’aspirer de nou­veaux clients pour ces ser­vices, et un modèle de revenu indi­rect basé sur la publi­cité et la vente de mots clés qui per­met de four­nir des ser­vices gra­tuits au plus grand nombre.
• Cer­tains pro­jets comme Gmail sont bien nés du fameux “20% de temps libre” pour des pro­jets de son choix. Mais la part rela­tive des nou­veau­tés de Google qui en pro­viennent et celle qui est issue d’acquisitions n’est pas claire! La der­nière étant assez consé­quente en nombre de ser­vices mais pas for­cé­ment en effec­tifs de déve­lop­pe­ment puisqu’il semble qu’une grosse part de la R&D de Google soit encore foca­li­sée sur le coeur du métier: la recherche (voir “Inno­va­tion ou mar­ke­ting?” un de mes posts du prin­temps dernier).

Nous avons dans cette confé­rence sur­tout fait le tour du coeur de métier de Google, le search. Qui est découpé en tranches:

• Le craw­ler qui scanne les sites Web pour y détec­ter tous les mots clés uti­li­sés. Il s’appuie sur des mil­liers de ser­veur qui scannent de façon récur­sive tous les liens de toutes les pages de tous les sites Web détec­tés. Toutes les URL d’Internet ne peuvent être récu­pé­rées. Google s’aide de dif­fé­rents arti­fices, notam­ment des Site­maps qui per­mettent aux sites d’informer Google de leur struc­ture et de leur mise à jour.
• L’index qui pour chaque mot liste les pages et les posi­tions dans les pages où on les trouve. Il fonc­tionne en mode mul­ti­lingue et stocke égale­ment les infor­ma­tions de lieu et de temps sur les pages indexées. Le lieu s’identifie pro­ba­ble­ment via l’adresse IP des sites. Il y plu­sieurs copies de l’index répar­ties géo­gra­phi­que­ment et elles tiennent toutes en RAM sur les ser­veurs. En 2006, Google indexe­rait envi­ron trois fois plus de pages que ses prin­ci­paux concur­rents (donc: Yahoo et Micro­soft). Ils indexent aussi 2 mil­liards d’image, 35 mil­lions de docu­ments non HTML et un mil­liard de mes­sages Use­Net. L’ensemble fait des Tera­oc­tets, bien évidem­ment. L’indexation d’une nou­velle page qui appa­rait sur Inter­net prend entre 15 minutes et quelques heures selon l’importance et le tra­fic du site.
• Le ran­king des mots, Page­Rank, qui évalue la per­ti­nence des pages liées à la com­bi­nai­son de mots clés d’une recherche en fonc­tion de dif­fé­rents cri­tères, notam­ment le nombre des liens qui abou­tissent à cette page, et la posi­tion des mots dans les pages. Pour­quoi les sites de com­merce arrivent-ils presque tou­jours au début des résul­tats lorsque l’on recherche un pro­duit? Ce ne serait pas lié à de la vente de pla­ce­ment, mais à une bonne opti­mi­sa­tion de ces sites qui connaissent bien le fonc­tion­ne­ment de Page­Rank. La force de Page­Rank, c’est d’exploiter la mine d’or géné­rée par l’index et par l’usage. Tout repose sur des ana­lyses statistiques.
• L’affi­chage, tout ce qui relève de la pré­sen­ta­tion des résul­tats dans un navi­ga­teur Web, et l’intégration des autres com­po­sants de nature publi­ci­taire dans les pages. Pour tes­ter les évolu­tions de son inter­face, Google dis­pose d’un “usa­bi­lity lab” à l’échelle pla­né­taire. Ils “servent” les nou­veau­tés à tes­ter à un faible pour­cen­tage de leurs uti­li­sa­teurs (genre 1%), mais qui suf­fit à en avoir des mil­lions, et ils com­parent les résul­tats: temps passé dans la recherche, taux de clic, etc. Sou­vent, une modi­fi­ca­tion mineure ne serait-ce que d’un seul pixel d’interlignage peut avoir des réper­cus­sions signi­fi­ca­tives. La force du nombre leur apporte des don­nées sta­tis­tiques extra­or­di­naires. Quant au “spell check” de Google qui pro­pose une ortho­graphe dif­fé­rente aux termes recher­ché, il s’appuie lui-aussi sur des sta­tis­tiques et non pas sur un dic­tion­naire tra­vaillant sur la dis­tance des mots, approche trop limi­tée pour la ges­tion des noms propres. Ils s’appuient donc sur des algo­rithmes de pro­ba­bi­lité de conco­mit­tance (pro­ba­bi­lis­tic co-occurrence)! Une simple recherche sur Google génère côté ser­veurs la lec­ture de plu­sieurs cen­taines de Mo de don­nées et le site en reçoit des mil­liers par seconde!

L’archi­tec­ture ser­veur s’appuie sur quelques carac­té­ris­tiques ori­gi­nales et mai­son qui font des labos de Google une sorte de véri­table labo­ra­toire de R&D de sys­tème d’exploitation et de midd­le­ware réseau et de ges­tion de don­nées distribués:

• Les racks de ser­veur sont bâtis sur une archi­tec­ture phy­sique opti­mi­sant leur rem­pla­ce­ment ainsi que celui des disques durs: au lieu de vis pour les fixa­tions, ils uti­lisent du Vel­cro ! En effet, sur 5000 machines envi­ron par data cen­ter, il y a régu­liè­re­ment une dizaine de pannes par jour. Donc, cela fait gagner du temps. Ces ser­veurs sont des lames stan­dard de type PC tour­nant sous Linux. Ce sont des machines “peu fiables” aux dires de Google, mais peu importe, c’est l’architecture logi­cielle qui apporte la fia­bi­lité à l’ensemble. Ce ne sont pas les machines les plus puis­santes du moment, mais celles qui apportent le meilleur rap­port puissance/prix du moment. Les racks ont 40 à 80 ser­veurs cha­cun, connec­tés entre eux en 100 mbits/s, le rack étant lui-même en liai­son Giga­bit avec les autres. Chaque ser­veur a une durée de vie de 2 à 3 ans. L’alimentation élec­trique et le refroi­dis­se­ment de ces racks sont des défis de taille à eux seuls qui entrainent moutle cal­culs tech­niques et écono­miques pour opti­mi­ser l’ensemble, la fac­ture d’électricité de Google étant l’une de ses plus grosses charges d’exploitation!
• Il y a plu­sieurs clus­ters d’environ 5000 ser­veurs répar­tis dans le monde entier, ce qui apporte une forte tolé­rance aux pannes de réseau sur Inter­net. La répar­ti­tion de charge s’effectue au niveau DNS pour iden­ti­fier le clus­ter le plus proche de l’utilisateur au niveau temps de latence réseau.
• Google s’est créé son propre sys­tème de ges­tion de fichiers dis­tri­bué, qui tourne sous Linux: le Google File Sys­tem. Il dis­tri­bue les recherches de fichiers sur plu­sieurs ser­veurs de façon extrê­me­ment effi­cace. C’est un peu grâce à lui que le résul­tat d’une recherche abou­tit dans notre navi­ga­teur en quelques mil­li­se­condes de traitement.
• GFS est com­plété par Big­Table, une sorte de base de don­nées hié­rar­chique (donc non rela­tion­nelle) sca­lable pour la ges­tion de gros volumes de don­nées qui doivent être accé­dés très rapi­de­ment. Cela sert notam­ment à Google Ana­ly­tics (l’outil d’analyse du tra­fic sur son propre site Web où l’on a placé de la publi­cité Google AdSense, 200 tera­oc­tets de don­nées rien que pour le sto­ckage des clicks sur les sites abon­nés au ser­vice), Google Earth et à Per­son­na­lize Search, une fonc­tion mécon­nue qui per­son­na­lise les résul­tats de la recherche pour les uti­li­sa­teurs qui sont iden­ti­fiés sur le moteur de recherche par un logon, le logon com­mun à Gmail et autres ser­vices per­son­nels de Google.
• Ils ont défini leur propre archi­tec­ture de paral­lé­li­sa­tion des trai­te­ments avec le Glo­bal Work Queue et MapRe­duce qui per­met de décou­per un trai­te­ment en mor­ceaux. MapRe­duce est uti­lisé au tra­vers d’un lan­gage de pro­gram­ma­tion mai­son Saw­zall. Au pas­sage, l’architecture de Google béné­fi­cie donc à plein des nou­veaux pro­ces­seurs à hyper­threa­ding et multi-coeurs qui per­mettent de paral­lé­li­ser les trai­te­ments sur une même machine.

Nombre de ces aspects sont docu­men­tés dans des publi­ca­tions scien­ti­fiques des Google Labs dis­po­nibles sur leur site : http://labs.google.com/papers/. Ce domaine est pas­sion­nant et on pour­rait y pas­ser des heures pour décor­ti­quer son fonc­tion­ne­ment. Cer­taines socié­tés de ser­vice en ont d’ailleurs fait leur métier pour aider les sites Web à bien se faire réfé­ren­cer sur Inter­net! Il sera aussi inté­res­sant de voir docu­men­ter la ges­tion des vidéos main­te­nant qu’il ne s’agit plus que de les indexer avec Google Video, mais égale­ment de les sto­cker et de les dif­fu­ser, via YouTube!

Com­pa­rai­son inévi­table avec Micro­soft. L’éditeur a égale­ment une grande tra­di­tion de publi­ca­tion de tra­vaux scien­ti­fiques, notam­ment par le tru­che­ment du site de Micro­soft Research. Mais la par­tie du site qui relève du search évoque la créa­tion d’un labo­ra­toire com­mun sur le search avec MSN en Chine, mais rien de plus. Et cela ne concerne pas ce qui est en exploi­ta­tion comme Google. La par­tie est dif­fi­cile pour Micro­soft car rat­tra­per le savoir faire de Google, quand on se plonge dedans, est loin d’être évident. Micro­soft parie sur­tout sur des évolu­tions d’interface comme pour la recherche de pho­tos pré­sen­tée de façon sym­pa­thique avec la pos­si­bi­lité de choi­sir la taille des “thumb­nails”. Mais c’est loin d’être suf­fi­sant pour faire la dif­fé­rence. C’est un sujet à creu­ser car le manque d’informations de la part de Micro­soft ne veut pas dire qu’ils sont inac­tifs en R&D sur le search, loin s’en faut!

J’évoquais au début cette marge énorme de Google lui per­met­tant de finan­cer des tests de ser­vices sans se sou­cier trop de logique écono­mique au départ. Google “crache” en effet aujourd’hui une pro­fi­ta­bi­lité nette de 27%, soit celle la moyenne de celle de Micro­soft ces der­nières années. Soient presque $3B pour 2006, extra­po­lés des $2046m sur les 9 der­niers mois. Leur bilan en octobre 2006 com­pre­nait envi­ron $10B de cash dis­po­nible. Mais tout ceci, c’est le pro­fit et le cash géné­rés après les dépenses en R&D, en infra­struc­ture et en acqui­si­tions évoquées dans cet article! Ils ont donc un sacré mou pour prendre des risques. C’est le grand pri­vi­lège des numéro un dont la taille cri­tique leur per­met d’absorber la valeur de leur secteur!

Alice Bon­homme fai­sait cette confé­rence aux élèves cen­tra­liens dans le cadre de ses 20% de temps consa­cré à des pro­jets libres de son choix. Car Google recrute à tour de bras pour sup­por­ter sa crois­sance qui n’en finit pas. Mais elle a oublié de citer le béné­fice du “free lunch” à ces recrues poten­tielles. Car chez Google, c’est bois­son et repas gra­tuits, en plus du plai­sir de pou­voir venir tra­vailler accou­tré comme bon vous semble! Tout du moins dans les labs… .

Ce post fai­sait lui aussi par­tie de mon “20% de temps libre”… pour de la veille technlologique!

Publié le 15 novembre 2006 Post de Olivier Ezratty | Google, Internet, Microsoft, Technologie | 9 commentaires