Windows AzureArchitecture d’une application Facebook

Thomas Conté, tconte@microsoft.comtwitter.com/tomconte Architecte Windows Azure

Les frameworks Facebook

• Le Facebook C# SDK sur CodePlex est régulièrement mis à jour

• Le Windows Azure Toolkit for Social Games est spécifiquement dédié aux développeur de jeux sociaux, très populaires bien sûr sur Facebook

• Le concours “Pitch Your Social App” a permis à 5 startup françaises de pitcher leurs Social Apps lors du « Facebook Start Up Day »

Le cas d’usage

• Une application Facebook est généralement constituée de deux grandes parties:– une interface Web intégrée au sein d’une Fan Page– une partie applicative fournissant effectivement un

service ou un traitement.

• L’application va identifier l’utilisateur, puis effectuer un traitement long à l’aide de l’Open Graph (i.e. récupérer une liste des Likes ou autres informations, et produire quelque chose d’intéressant comme une animation, une visualisation, etc.)

• Typiquement le principe d’applications comme Museum of Me, par exemple.

L’architecture• L’on va séparer le rôle “Web” et le rôle “applicatif” (appelé

“Worker” dans Windows Azure). Cela permettra de les faire évoluer indépendamment par ajout d’instances lors de la montée en charge.

• L’on va orchestrer les traitements de façon asynchrone à l’aide d’une file d’attente (les Queues, fournies par Windows Azure).

• Le navigateur va lui aussi adopter ce même modèle asynchrone: il ne va pas attendre du serveur Web une réponse immédiate, il va aller chercher son résultat (typiquement par polling) dans un stockage lui aussi fourni par Windows Azure.

• L’on pourrait bien entendu utiliser des Tables pour ce dernier point, mais étant donné que la partie asynchrone côté navigateur sera implémentée en JavaScript, il paraît encore plus naturel d’utiliser le Blob Storage, dans lequel la réponse prendra la forme d’un bloc JSON directement utilisable.

Web Role

Worker Role

Web Role

Worker Role

queue

BlobStorage

①

②

③

④

⑤

⑥

Polling & Blob Storage• Une remarque qui revient souvent est que les “transactions”,

autrement dit les accès au Blob Storage sont payants, et qu’il conviendrait donc d’éviter une stratégie à base de polling qui risque de coûter cher…

• Exemple sur un traitement de 3 minutes:– intervalle de polling de 1 seconde– Donc 180 accès au Blob Storage.

• En mode “pay-as-you-go”, les transactions de Storage sont facturées 0,01 dollars pour 10.000 transactions.

• Nos 180 accès vont donc nous coûter 0.00018 dollars, ce qui ne paraît pas onéreux.

• Si l’on multiplie par 1 million d’utilisateurs par jour, le coût total arrive à 180 dollars par jour.

• L’expérience montre que ce coût est et restera proportionnellement très inférieur aux autres coûts liés au succès de l’application, typiquement la bande passante.

Merci!