Vous le savez sûrement, les applications sociales au sens large, et notamment celles tournant dans Facebook, sont un excellent cas d’usage pour Windows Azure. Nous avons donc plusieurs initiatives sur ce sujet:

Je voulais dans ce billet essayer d’illustrer concrètement l’apport de Windows Azure pour l’architecture d’une application Facebook, principalement du point de vue de sa montée en charge.

Une application Facebook est généralement constituée de deux grandes parties: une interface Web souvent intégrée au sein d’une Fan Page Facebook, possiblement sur plusieurs onglets, puis une partie applicative fournissant effectivement un service ou un traitement. Nous allons partir sur le principe général d’une application qui va identifier l’utilisateur, puis effectuer un traitement long à l’aide de l’Open Graph (i.e. récupérer une liste des amis, 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’idée de montée en charge dans Windows Azure va reposer sur les principes de séparation des rôles, de ���scalabilité horizontale” et de traitements asynchrones:

  1. 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.
  2. L’on va orchestrer les traitements de façon asynchrone à l’aide d’une file d’attente (les Queues, fournies par Windows Azure).
  3. 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.
  4. 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.

Voici donc un schéma qui illustre cette architecture, ainsi que le détail des différentes étapes:

image

1 – Le navigateur demande la page.

Le Web Rôle va typiquement pouvoir délivrer plusieurs pages de pur contenu, et va utiliser par exemple le Facebook C# SDK pour demander l’autorisation à l’utilisateur d’accéder à ses informations de profil.

2 – Le Web Role écrit la requête dans une file d’attente, puis retourne immédiatement une page d’attente au navigateur.

Lorsque le navigateur requête l’action ou la page nécessitant un traitement, le Web Rôle se contente d’écrire cette requête (par exemple accompagnée de l’ID de l’utilisateur ainsi que son token permettant d’accéder à la Graph API) dans une file d’attente, fournie par Windows Azure sous la forme de Queue.

A partir de ce moment, le Web Role est complètement déchargé de toute responsabilité, et peut donc continuer à servir le reste de l’expérience Facebook (les autres pages, les contenus, etc.)

3 – Le navigateur polle le Blob Storage en attente d'un résultat (typiquement un bloc JSON).

Le Web Rôle envoie au navigateur une page d’attente avec une jolie animation et un petit bout de JavaScript qui va régulièrement essayer d’aller chercher le résultat du traitement directement dans le Blob Storage, à l’aide du clef commune (par exemple l’ID de l’utilisateur).

4 – C’est maintenant les Worker Roles qui prennent la main; ils pollent la file d’attente et trouvent une unité de travail à effectuer.

Le message doit contenir toutes les informations dont a besoin le Worker Role (dans notre cas, le token OAuth provenant de l’authentification).

5 – Un Worker Role prend possession du message et effectue un traitement long (utilisation de la Graph API, etc.)

Dans notre exemple, les Workers accèdent à la Graph API de Facebook au nom de l’utilisateur, récupèrent les données dont ils ont besoin, puis effectuent un traitement, si nécessaire en utilisant du stockage comme les Tables ou SQL Azure.

6 – Une fois le traitement terminé, le Worker Role écrit un résultat final sous la forme d’un fichier JSON directement dans le Blob Storage.

Cet objet JavaScript peut soit contenir l’ensemble des informations nécessaires à l’affichage, soit un pointeur vers d’autres ressources (images, etc.)

7 – Le navigateur récupère le traitement et peut afficher le résultat final.

Pendant ce temps, notre brave navigateur a continué d’accéder au Blob Storage en attendant sa réponse; dès qu’il a récupéré le Blob JSON, il peut lancer l’affichage.

Note concernant l’utilisation du polling et du 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… Chiffrons donc ce coût, en partant par exemple sur un traitement de 3 minutes, avec un intervalle de polling de 1 seconde, qui provoquera 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.