Accueil/Blog/Optimisation de la Progressive Web App pour PrestaShop/

Optimisation de la Progressive Web App pour PrestaShop

Publié Mis à jour Par

C’est officiel, nous proposons désormais les PWA pour PrestaShop avec la solution PrestApp ! Après quelques mois de travail, nous sommes en mesure de vous proposer un site mobile first compatible Progressive Web App. Si vous souhaitez voir le rendu : https://pwa.prestapp.eu

L’infrastructure de nos PWA PrestaShop

Afin de garantir la « scalabilité » et la haute disponibilité de notre service, nous avons effectué des tests de performance et de résilience sur notre infrastructure. Voici un schéma « succinct » de cette dernière :

Petit tour d’horizon de notre infrastructure :

  • Par serveur physique :
    • 1 instance Traefik
      • Gère l’ensemble du trafic réseau entre Internet et les containers (reverse-proxy) et les certificats SSL
    • 1 instance Web API
      • Permet à l’interface d’administration de PrestApp de fonctionner
    • 1 instance Mobile API
      • Permet de fournir l’ensemble des informations nécessaires au lancement des PWA PrestaShop et donc de les impacter en temps réel :
        • Les couleurs
        • Les images (Logo & Bannière)
        • La disposition du menu
        • Les widgets de la page d’accueil
        • Les moyens de paiement
        • Les moyens de transport
        • Les pages personnalisées
        • L’enregistrement des tokens utilisateurs pour les Notifications Push
    • 2 instances MongoDB
      • Stockage de l’ensemble des configurations effectuées sur la Web et Mobile API
    • 1 instance Web de l’interface d’administration
      • Front-end de l’interface d’administration

Notre infrastructure est donc basée sur 3 serveurs physiques Docker permettant une tolérance de panne d’1 serveur. Libre à nous dans le futur d’ajouter 2 autres serveurs à notre cluster Swarm, nous aurions alors 5 nœuds « Manager » et une tolérance de panne à 2 serveurs.

Petite parenthèse sur la provenance des informations essentielles aux applications (images des produits, descriptions, déclinaisons, stocks, etc…), ces dernières proviennent de la boutique du e-commerçant PrestaShop directement via notre Module PrestApp. Cela décharge donc notre infrastructure d’une grosse partie du trafic. A noter que la « consommation » en ressource côté boutique PrestaShop est la même que celle effectuée par un visiteur web classique.

Résultat de recherche d'images pour "docker swarm"

Les problèmes « majeurs » identifiés ?

Traefik et les IPV6…

Problématique 1 :
Après quelques tests nous nous sommes aperçus que Traefik c’est très bien ! Certes ! Mais pas lorsque le trafic s’effectue via IPV6… En effet Traefik n’est pas encore compatible avec cette technologie. La problématique est donc de taille, les utilisateurs de nos PWA PrestaShop ne pouvaient lancer ces dernières s’ils étaient sous une IPV6 !

Solution 1 :
Après quelques heures de recherche pour premièrement se rendre compte que Traefik n’était pas compatible IPV6, nous avons décidé de mettre en place un service HAProxy pour pallier à ce problème.

L’idée est simple, réceptionner l’ensemble du trafic IPV6 sur HAProxy et le rediriger en IPV4 vers Traefik 🙂 Nous avons donc configuré notre service HAProxy sur notre DNS en ajoutant une entrée AAAA de sorte que l’ensemble du trafic IPV6 arrive sur HAProxy et soit redirigé ensuite en IPV4 vers nos serveurs Docker selon la méthode « Round-Robin ».

Problématique 2 :
Nous avons fait des tests en coupant nos serveurs un par un afin de voir si notre infrastructure était « haute dispo ». Problème : certaines requêtes étaient redirigées par le service HAProxy sur le serveur que nous venions de couper ce qui est logique… et tombaient en « timeout »…

Solution 2 :
Pour éviter qu’HAProxy prenne dans le pool des 3 serveurs, celui que nous venions de couper, nous avons mis en place une vérification sur un Webservice de la Mobile API. Nous avons pour ce faire modifié la configuration de notre HAProxy et ajouté « option httpchk GET » sur notre Webservice ainsi qu’un intervalle de vérification toutes les 5 secondes. De cette marnière le serveur « down » est écarté du pool HAProxy et les requêtes ne sont plus redirigées vers celui-ci.

DNS sans IP Failover

Problématique :
Même problématique que pour notre service HAProxy cependant à un niveau plus élevé : nos DNS. Hébergés sur un des serveurs de PrestApp, un problème était présent, nos DNS n’étaient pas « haute dispo » et ne possédaient pas d’IP Failover. Si notre serveur DNS tombait, l’ensemble de l’architecture tombait, problème identique si un serveur Docker ne répondait plus, certaines requêtes pouvaient être redirigées sur ce dernier et tomber en « timeout » : nous étions en présence d’un Single Point of Failure…

Solution :
Nous avons transféré l’ensemble de nos DNS sur le service proposé par Amazon « Route 53 ». Une petite coupure est donc survenue la semaine dernière, le temps que les modifications se propagent. Une vérification est effectuée sur chacun de nos 3 serveurs Docker, plus précisément sur le Webservice de la mobile api de PrestApp. Si la Mobile API ne répond plus sur un serveur Docker ou que ce dernier est coupé, les requêtes ne sont plus redirigées vers ce dernier.

Résultat de recherche d'images pour "amazon route 53"

Limité à « seulement » 580 ouvertures par seconde de nos PWA PrestaShop

Problématique :
Après quelques benchmark, sur notre Mobile API (sollicitée à chaque lancement d’une application), nous avons constaté une capacité de 49 766 400 requêtes journalières possibles. Ce chiffre n’est que théorique puisque les lancements des applications ne sont pas effectués de manière linéaire mais plutôt avec des pics à des heures précises. Nous étions à 580 RPS (requêtes par seconde) possibles en théorie, cependant si nous souhaitons être « scalable » nous nous devons de pouvoir accepter plus de RPS.

Solution :
Afin de ne plus être dépendant des performances de notre infrastructure en cas de « burst », nous avons décidé d’externaliser ce service qui permet à nos applications de se lancer : un fichier JSON.

Pour ce faire, nous avons utilisé Google Cloud Storage en y stockant le fichier JSON correspondant à l’application. Nous avons donc fait en sorte que l’alimentation de ce fichier sous Google Cloud Storage soit effectué dès lors qu’un changement est réalisé par un ecommerçant sur l’interface d’administration de PrestApp.

In fine, nous passons de 580 RPS à 5 000 RPS, soit 432 000 000 de requêtes sur 24 heures grâce à Google Cloud Storage.
Source : https://cloud.google.com/storage/docs/request-rate

Résultat de recherche d'images pour "google storage"

Conclusion

Notre infrastructure est plus robuste et performante qu’hier car nous avons identifié 2 SPOF mais surtout nous les avons corrigé ! Nous n’avons pas hésité à nous appuyer sur des services externes comme Amazon ou Google pour fournir résistance et vigueur à notre service PrestApp. En effet, pourquoi vouloir absolument « internaliser » certains services alors que les mastodontes les fournissent avec fonctionnalités et technologies très avancées ?

Pour conclure, prendre du recule sur l’architecture dans son ensemble et cette étape de « testing » était nécessaire car plusieurs points faibles ont été mis en lumière alors qu’ils étaient pourtant très clairement identifiables, comme par exemple les DNS.