insideIT.fr : le blog des architectes IT de SFEIR

Aller au contenu | Aller au menu | Aller à la recherche

lundi 30 janvier 2012

Noël dans les nuages !

Ou comment Google App Engine, permet de mettre en place un service supportant une très grosse charge dans un temps très court.



Le projet

L'Église Catholique propose depuis plus de 10 ans un site internet pour chercher les horaires de messes dans toute la France, qui souffrait historiquement d'un problème majeur : le trafic quotidien est raisonnable (environ 1 000 visites par jours, et des pointes à 5 000 visites le WE) mais le site doit faire face à d’importants pics de trafic à Noël et durant la semaine de Pâques.

Interface d'EgliseInfo

Or les années précédentes, l'ancien site (messesinfo.catholique.fr), développé en PHP/MySQL, ne tenait pas la charge lors de ces pics, s'écroulant sous les demandes des visiteurs. La technologie utilisée était tout à fait suffisante pour les besoins courants du site, cependant pour répondre à la forte charge sans changer de projet, il aurait fallu, soit disposer d’un serveur plus puissant, soit mettre en place du load balancing entre plusieurs serveurs. Dans les deux cas, ce n'aurait pas été très flexible, obligeant à s’équiper d’un serveur sur-dimensionné, pour seulement 6 jours dans l'année !



Nouveau projet

Nous avons donc fait le choix de migrer vers une technologie permettant de gérer cette surcharge ponctuelle, en ne payant que ce qui est réellement consommé. La refonte du site, permet également d’outrepasser les limitations imposées par l'ancien système (messes en semaine, autres types de célébrations) et d'ajouter de nouvelles fonctionnalités (événements, apis, widget, …).

Notre choix c'est porté sur Google App Engine, par la simplicité de développement que celui-ci apporte, le dimensionnement automatique des serveurs, les quotas gratuits et le paiement à la consommation.

Le projet a démarré en octobre 2010, avec la création d'une simple interface de recherche développé en GWT sur Google App Engine, mais laquelle se connectait ensuite à l'ancien site pour récupérer les résultats de la recherche. Cette première version à été mise en ligne pour Noël 2010, mais les deux sites n'ont pas tenu le coup car la base de donnée n'a pas accepté le nombre très élevé de requêtes simultanées ! Nous ne pouvions pas mettre les données de la base de donnée MySQL directement sur Google App Engine, car déjà l'interface d'administration n'est pas encore refaite, et la base de donnée chez App Engine, ne fonctionne pas exactement de la même manière.

Pour la période de Pâques 2011, Google venait de sortir en test la base de donnée Google Cloud SQL qui permet d'avoir des bases de données MySQL directement sur Google App Engine. Nous avons ainsi développé un service qui recopie la base de l'ancien site, sur le nouveau. Le système a fonctionné, mais du fait de la nouveauté du service et du manque d'optimisation de notre part, les bases de données SQL ont régulièrement planté.



Noël 2011

Visiteurs le jour de Noël 2011

EgliseInfo a relativement bien fonctionné pour Noël 2011, faisant face à une pointe de 1104 visiteurs simultané, et plus de 800 visiteurs en permanence durant toute l'après-midi, soit 100 000 visites en 3 jours.

Nous avons toutefois rencontré trois problèmes :

  • Vendredi soir vers 21h, nous avons dépassé le quota que nous avions fixé (25$), donc tous le site s’est retrouvé bloqué, le temps de changer et de mettre à 100$
  • Samedi matin, nous avons été limité par Google Cloud SQL a 100 requêtes simultanées. J'ai corrigé en faisait un balancing sur 2 bases SQL, et j'ai écrit un mail à Google : réponse dans la fin de l'après midi, ils ne peuvent pas modifier cette limite, et proposaient de passer à un serveur de plus grande capacité sans être vraiment sûr que cela résoudrait le problème : base de donnée plus grande, mais pas plus de connexion simultanées (cela changera plus tard), avec par ailleurs une interruption le temps de redémarrer le serveur. La double base de données a permis de réduire le nombre d'erreurs et de fournir une meilleure réactivité. Les responsables de Google SQL sont en train de tester avec notre jeu de données sur les requêtes les plus lentes.
  • Samedi 18h : EgliseInfo marchait toujours, mais les pubs ne s'affichait plus (un script PHP sur un serveur de la CEF) car le trop grand nombre de personnes sur tous les sites (le site de pub, messesinfo, les sites de paroisses et diocèses) à surchargé le firewall du datacenter où sont hébergés tout ces sites !

Analyse EgliseInfo

Record de visite : 1104MessesInfo (Ancienne version du site fait en PHP, qui est encore référencé) redirigeait presque tous le trafic vers EgliseInfo, redirection javascript depuis la page de résultat MessesInfo (pouvait venir d'une recherche Google) vers la recherche correspondante sur EgliseInfo. Donc pas de plantage du côté de MessesInfo, et une forte charge sur EgliseInfo qui a bien fonctionné avec des temps de réponse acceptables (forcément plus lent qu'habituellement).

Evolution des instances App EngineGoogle nous a mis en place automatiquement jusqu'à 400 serveurs disponibles (instances de l'application, qui sont virtualisées sur plusieurs serveurs réels).



Conclusion

En conclusion, Google App Engine a vraiment permis de gérer la très forte charge du site pour un coût tout à fait raisonnable. Pour les prochaines fois, il nous faudra mettre en place une répartition sur plusieurs bases de données, et dégrader les fonctionnalités pour accélérer les recherches.

dimanche 10 avril 2011

Du Jersey, du Guice et de l'App Engine 2/3

Dans le dernier article, nous disposions d'un service Hello World qui renvoyait du texte brut. Cette fois, nous allons lui ajouter la capacité à répondre du xml en sérialisant le message avec JAX-B.

Tout d'abord, notre nouvelle réponse sera faite par l'objet suivant :

XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class Hello {
 
 private String message;
 private String name;
 
 public Hello(){
 }
 
 public Hello(String message, String name) {
  super();
  this.message = message;
  this.name = name;
 }
 
 public String getMessage() {
  return message;
 }
 
 public void setMessage(String message) {
  this.message = message;
 }
 
 public String getName() {
  return name;
 }
 
 public void setName(String name) {
  this.name = name;
 }
 
 @Override
 public int hashCode() {
  return Objects.hashCode(message, name);
 }
 
 @Override
 public boolean equals(Object obj) {
     if(obj instanceof Hello){
         final Hello other = (Hello) obj;
         return Objects.equal(message, other.message)
             && Objects.equal(name, other.name);
     } else{
         return false;
     }
 }
}

La ressource exposée évolue peu :

Path("hello")
@Singleton
@Produces(MediaType.APPLICATION_XML)
public class HelloResource {
 
 @Context 
 UriInfo uriInfo; 
 
 @Inject
 private HelloService helloService;
 
 @GET
 @Path("/{name}")
 public Hello reply(@PathParam("name") String name){
  return helloService.saysHelloToSomeone(name);
 }

 @POST
 public Response send(String name){
  Hello hello = helloService.sendHello(name);
  URI uri = uriInfo.getAbsolutePathBuilder().build();
  return Response.created(uri).entity(hello).build();
 }  
 
 
 public void setHelloService(HelloService helloService) {
  this.helloService = helloService;
 }
 
}

Les opérations de marshall/unmarshall sont opérées directement par Jersey lui même.

De même, les tests vont peu évoluer, seul le type de données attendu va changer. Nous aurons par exemple :

@Test
 public void shoulReplyHello(){
  String name ="Nicolas";
  String hello = "Hello "+name;
  when(helloServiceMock.saysHelloToSomeone(name)).thenReturn(hello);
  
  ClientResponse response = resource().path("hello").path(name).get(ClientResponse.class);
  
  verify(helloServiceMock).saysHelloToSomeone(name);
  assertThat(response.getClientResponseStatus()).isEqualTo(Status.OK);
  assertThat(response.getType()).isEqualTo(MediaType.TEXT_PLAIN_TYPE);
  assertThat(response.getEntity(String.class)).isEqualTo("Hello Nicolas");
  
 }

Et c'est tout, pour aujourd'hui ...

Bon ok, je reconnais, c'est un peu l'arnaque cet article, il y a peu de choses à faire. Mais n'est ce pas justement ça qui est intéressant, non ?

La prochaine fois, nous terminerons cette ballade autour de Jersey en générant du JSon.

Le code est disponible ici.

lundi 10 mai 2010

En attendant Google I/O...

googleio_mark.jpg Nous sommes à 9 jours de la grande messe annuelle de Google : "Google I/O".
Pendant 2 jours, 3000 développeurs se retrouvent au Moscone Center à San Fransico pour suivre à un rythme effréné des conférences sur toutes les technologies Google.
Chez SFEIR nous travaillons beaucoup avec ces technologies, en particulier GWT, App Engine et Android, nous sommes donc particulièrement attentifs à ce qui va sortir de cet évènement.
C'est bien souvent l'occasion aussi pour google de faire une annonce fracassante. Pour rappel la session 2009 a levé le voile sur Google Wave qui a fait sensation par son coté avant-gardiste et innovateur.
Alors à quoi peut-on s'attendre cette année ?

Android


android-robot-io.png Tim Bray l'a dit sur le blog android : "I don’t think that I’m telling any secrets when I say that there will be Android-related announcements at that event"
Le petit monde d'Android évolue à toute vitesse : nouvelles versions, nouveaux téléphones, parts de marché à croissance exponentiel.
Des signes nous ont montré l'approche de Froyo, la version 2.2 d'Android qui pourrait être dévoilée lors de l'évenement. On connait déjà quelques nouveautés :

  • Gain de performance important via un compilateur Just In Time pour la machine virtuelle Dalvik
  • Un nouveau market avec mise à jour automatique des applications
  • Console améliorée pour les developpeurs avec les erreurs clientes consultables
  • Support de la radio FM pour les appareils le supportant
  • Support Flash 10.1
  • Des évolutions pour le développement de jeux (OpenGL ES ou autres), terrain sur lequel Google essaye de faire progresser Android qui fait encore pâle figure face à l'iphone.


On parle aussi de nouveaux types d'appareils : le robot s'inviterai sur des tablettes ainsi que sur les télévisions.


App Engine


google-app-engine.png Une roadmap des évolutions de app engine a été publiée il y a quelques temps. La nouveauté la plus attendue est l'arrivée des technologies push (Comet, Websockets, ...), technologie qui va assurément changer notre façon de consommer le web avec des usages plus "temps réels".



Maps & Geo


maps.gif Nous avons récemment eu droit à l'api V3 pour Maps qui va donc être un sujet de certaines sessions.
Concernant les produits "geo" chez google, on parle d'évolutions de Google Latitude pour suivre notamment la mode du "check-in" à la Foursquare.
Buzz qui a un succès mitigé pourrai aussi faire l'objet d'ajustement dans ce sens. La géolocalisation devenant omniprésente dans notre quotidien avec les smartphones, c'est le terrain le plus actif en terme de recherche de nouveaux usages dans les startups et google va aussi continuer à innover dans le domaine.

Chrome


logo-google-chrome-navigateur-web.jpg La version 5 est en cours de développement et apportera sont lot de nouveautés : plus de synchronisation des données avec le cloud, plus de performances, une barre d'adresse revue avec la disparition du "http://", flash player intégré...
Google continue de miser sur son navigateur en le faisant évoluer et en investissant massivement dans la publicité. Le travail semble porter ces fruits car sa part de marché ne cesse d'augmenter et a dépassé celle de safari.
Chrome OS attendu pour la fin de l'année sera peut être le sujet d'annonce, le système d'exploitation pour netbook qui boot en 5 secondes et réduit à l'essentiel : un navigateur chrome. Cela sera peut être un élément clé de la stratégie google dans le futur.
Chrome et Chrome OS intègrent déjà la technologie NaCL (native client) qui permet d'exécuter du code à 99% de la vitesse du code natif dans un environnement protégé mais elle est désactivée par défaut. A la vue du nombre de commiters google sur le projet googlecode et l'activité des commits sur le projet, on peut être certain que cela sera un élément important dans le futur de google, qui pourra faire entrer le domaine du jeu vidéo et des applications gourmandes en calculs couteux dans le navigateur et le cloud. Activation par défaut dans chrome annoncé à google i/o et premier produit annoncé ?


Entreprise


google_apps-300x284.jpg La plus grande attente des entreprises utilisant les google apps est d'avoir accès à plus de produits google en mode "for your domain" comme reader, voice ou google code.
On sait déjà que plusieurs produits vont faire leur apparition cet été : annoncé ici mais peut être des choses inédites vont être annoncées.


Suivez la conférence en live


google io Rares sont les français qui ont la chance d'aller à Google I/O, mais tout n'est pas perdu ! Cette année nous allons pouvoir suivre en direct la conférence via ce channel youtube : http://www.youtube.com/GoogleDevelopers.
Voici le programme : http://code.google.com/intl/fr-FR/events/io/2010/session-schedule.html
Tous les sujets n'ont pas été abordé dans ce billet, il y a encore le langage Go, wave, GWT, ... C'est peine perdu, malgré toutes les rumeurs, google a toujours réussi à créer la suprise, alors rendez vous la semaine prochaine !

Alexandre
@alexandre_t

jeudi 1 octobre 2009

GWT 2.0, App Engine, et WolfEngine

Depuis cet été, nous faisons régulièrement des builds de GWT, vous pouvez les retrouver sur le compte google code créé à cet effet :

http://code.google.com/p/sfeir/

Nous avons aussi écrit deux tutoriaux pour apprendre à utiliser les nouveautés de GWT :

Par contre, nous avions une erreur en utilisant Google App Engine :

@@failed com.google.apphosting.utils.jetty.DevAppEngineWebAppContext@3225c9{/,.} javax.xml.parsers.FactoryConfigurationError: Provider

org.apache.xerces.jaxp.SAXParserFactoryImpl not found@@

Pour résoudre ce problème, il faut ajouter une jar à son projet : xercesImpl.jar Nous avons donc testé WolfEngine avec GWT 2.0, celui-ci fonctionne parfaitement, malgré des Warnings à la compilation sur les classes et méthodes dépréciées qui risquent de disparaitre à la version finale de GWT. Il est bon de tester dès maintenant ses applications pour faire les corrections adéquates et passez ensuite facilement dans la version 2.0.

De plus, le mode debug directement dans le navigateur est vraiment très pratique, on peut ainsi tester dans les navigateurs et utiliser les outils comme firebug lors du développement. Pour utiliser ce mode, il faut ajouter la jar gwt-dev-oophm.jar avant la jar gwt-(window|mac|linux).jar. Ou encore utiliser la dernière version du plug-in google et définir ajouter GWT 2.0 en bibliothèque. Une case à cocher apparait alors en dessous de l'URL dans l'onglet GWT pour sélectionner ce mode.

oophm

Il suffit ensuite de copier coller l'URL donnée dans la barre d'adresse de votre navigateur préféré. L'installation des plug-ins dans les navigateurs est expliqué sur la page affiché. Pour chrome, il faut utiliser les dernières builds (chanel dev), firefox c'est le plus simple, une extension à télécharger et installer. Et pour IE, il faut installer une dll. Amusez-vous bien !