La synchronisation
Par Damien Séguy le 1 février 2012La synchronisation est un problème typique pour les sites web e-commerce. La boutique en ligne doit être synchronisée avec un d’autres applications plus adaptées qui gèrent des tâches différentes: CRM, ERP, stocks, comptabilité, call center, entrepôts, catalogue et j’en passe.
La synchronisation est un problème difficile, et bien qu’il semble facile pour celui qui a inventé le terme, il est en fait un défi permanent pour les développeurs, quand on prend en considération la performance et la cohérence.
Cohérence
La cohérence est le fait que le système de contrôle et le site e-commerce sont toujours au même niveau d’information. Ce qui est dans le CRM est dans le site Web, et ce qui est dans le site Web est également dans le CRM.
Ou pas. Parfois, volontairement, la synchronisation est unidirectionnelle: l’information descend de l’un des serveurs, et est utilisée par le second. Le second système doit utiliser l’information qui est déjà prête : le second système ne peut pas faire de modification, comme le premier, aussi appelé le maître. Ceci est caractéristique de deux types de situations: quand le site web e-commerce est une évolution ou un complément d’un système plus vaste en interne. Cela arrive souvent lorsque les détaillants se tournent vers le Web. Ils ont déjà un système existant, tel un ERP ou une gestion de stock. Ainsi, le e-commerce prend les informations du système d’origine, et les publie sur le web. L’autre situation est lorsque le système interne est considéré comme stratégique, et que la compagnie ne veut pas l’ouvrir, pour des raisons de performances, de sécurité ou encore d’organisation. Afin de découpler les deux, la synchronisation est donc mise en place.
Cette synchronisation est l’approche la plus simple, et une fois qu’elle est bien assimilée, la « synchronisation bidirectionnelle » débarque. Évidemment, il y aura tôt ou tard, les informations du site web qui devront être mis à la disposition du système original : le CRM a besoin de voir les informations mises à jour des profils (contact), tout comme le site Web a besoin d’avoir les informations de contact mises à jour. Ou encore, le site web produit de nouvelles données, comme le nombre de vues pour chaque article, que les ERP souhaiteront utiliser afin de planifier le processus d’achat suivant.
Ces deux types de synchronisations sont les deux principales. Des solutions hybrides existent, et comprennent: une synchronisation à double voie (chaque serveur est maître pour un ensemble distinct de données), la synchronisation avec modération (l’un des serveurs sera le maître, et recueillera des données pour la résolution des conflits, avant de le pousser vers le second serveur), et d’autres variantes.
Une seule règle: garder cela simple, car le second volet de la synchronisation va être difficile.
Synchrone ou asynchrone
Les différents types de synchronisation doivent tenir compte de la vitesse de l’information. Le transfert est synchrone lorsque les deux serveurs mettent à jour leurs informations au même moment. C’est typiquement le cas pour les virements: les deux banquent valident le virement bancaire simultanément, ou pas du tout. Il ne peut pas y avoir de temps «transitoire», au cours de duquel une banque a envoyé l’argent, et l’autre ne l’a pas encore reçu.
Asynchrone introduit un concept simple: le retard. Un des serveurs dispose de l’information, et il la relaie plus tard à l’autre. Il y aura donc une différence de temps entre ces deux opérations.
Le principal avantage de cette approche est d’éviter de transférer la charge du trafic à la ressource distante. Fondamentalement, lorsque les deux serveurs sont synchrones, toute sollicitation sur le premier se traduit par une sollicitation sur le deuxième serveur. Ainsi, le trafic du premier serveur sera transféré au second. Et, quand il s’agit de l’application Web, ce n’est pas une bonne idée.
Par ailleurs, le transfert synchrone signifie généralement qu’il se fait unité par unité. Chaque fois qu’un client met à jour ses informations de contact, l’information est envoyée au CRM. AU contraire, les systèmes asynchrones sont capables de travailler par lots. Au lieu d’envoyer les demandes unes par unes, le serveur d’origine accumule plusieurs demandes dans un lot: cela fait moins de sollicitations, et des traitements souvent plus rapides.
Des retards dans mon application!
Habituellement, lorsque le transfert asynchrone est présenté aux clients, il y a un peu d’incompréhension. Le concept est habituellement rencontré avec rejet: écoutez, j’ai besoin de ces données tout de suite! Toutefois, le cycle métier permet le plus souvent un léger retard. En fait, c’est acceptable la grande majorité du temps. Passons en revue quelques exemples.
La mise à jour de la description du catalogue est habituellement une routine quotidienne. Il est assez rare qu’elle doive être mise à jour plusieurs fois par jour. Les erreurs bénignes, telles que les fautes d’orthographe peuvent être corrigées manuellement, en ligne ; toute mise à jour d’importance, avec plusieurs modifications, ajouts et suppression peut attendre le prochain jour ouvrable. Traditionnellement, il est préférable de faire cette synchronisation la nuit, à faible trafic, afin de réinitialiser tous les caches sans pression. Solution: asynchrone, une fois par jour.
Les informations de contact ne peuvent pas souffrir d’attendre un jour. Une fois l’information a été modifiée, il est souvent important de la relayer rapidement au CRM. Toutefois, une différence de 5 minutes à 1 heure est toujours acceptable. D’une part, cela permet à l’utilisateur de changer d’idée en ligne, et changer de nouveau le contact, évitant un double envoi. Deuxièmement, il est rare d’avoir besoin des informations à la seconde dans le CRM. Même si le CRM est sur le point d’une diffusion importante, 5 minutes de retard n’auront pas un impact majeur : au pire, on omettra les quelques dernières informations, a mettre en rapport avec les milliers de contacts déjà transférés. Et si les contacts sont traitées manuellement dans le CRM, 1 heure est même délai normal de traitement: pas besoin de se précipiter. Solution: asynchrone, 5 à 60 minutes.
Les factures et de leur acheminement sont plus compliqués. L’expédition le jour même aura besoin des informations à flux tendu, et cela va nous empêcher d’utiliser un long délai de synchronisation. Un retard de 5 minutes sera acceptable, permettant à la fois le traitement par lots, et celui d’une commande de dernière minute. Pourquoi pas adapter la cadence pour être plus fréquent juste avant l’échéance, et plus espacé en matinée : la cadence peut être une fonction variable. Solution: asynchrone à fréquence variable, de 5 a 120 minutes.
L’inventaire est probablement l’une des seules situations qui nécessiteront une vérification synchrone. Vous ne souhaitez pas vendre un produit qui est en rupture de stock. Non seulement sa disponibilité doit être vérifiée, mais sa réservation doit également être confirmée. L’entrepôt gérera la situation, en envoyant un ordre d’achat automatique en dessous de certains niveaux de stock, empêchant la vente de quelques articles avant qu’ils soient en rupture de stock, etc. Solution : synchrone.
La planification des capacités
La planification est plus simple pour les moteurs asynchrones que pour les synchrones. Fondamentalement, puisque le trafic est découplé de la synchronisation, vous pouvez dimensionner la taille de chaque opération. Idéalement, le traitement portera sur tous les objets en attente, et fera usage de toutes les commandes par lots disponibles sur le système distant. Pensez à la différence entre LOAD DATA INTO TABLE et INSERT INTO TABLE. Chaque fois que la charge est trop lourde pour le système distant, vous pouvez réduire la taille de chaque lot, ou, curieusement, les paralléliser (plusieurs mises à jour plus petites simultanément).
Quant au système synchrone, il n’existe qu’un seul espoir: rendre le système distant assez rapide. Pour cela, on doit estimer la quantité de trafic sur le Web qui sera reportée sur lui. En pratique, on peut utiliser une équation comme celle-ci:
Trafic * conversion * moyenne_hits * securite
Le trafic est ce que vous voulez: la circulation moyenne, les pics de trafic, etc. Idéalement, vous disposerez de tout à la fois, et ca sera le luxe.
La conversion est la partie de votre trafic qui va faire un appel à distance. Par exemple, votre e-boutique peut avoir 1000 utilisateurs par jour, mais fera 10 ventes par jour. Votre conversion est ici de 1 / 100.
Moyenne_hits est le nombre de hit que chaque session fera sur les serveurs distants. Par exemple, chaque vente contient habituellement deux produits. Il faudra alors 2 contrôles sur les serveurs distants. 2 est en fait une bonne évaluation ici.
La sécurité, facteur souvent négligé, couvre tous les problèmes imprévus. Ici, on peut s’attendre à des ventes soudaines. Cela fera 10 fois plus de commandes. Nous pouvons utiliser 10 comme sécurité.
Finalement, voici l’application de l’équation pour un trafic de 1000 visiteurs par jour, il faudra 1000 * 1 / 100 * 2 * 10 = 200 visites par jour sur le serveur distant. Si des pics de trafic 1000 visites par seconde sont attendus, nous aurons besoin de 200 requêtes par seconde sur le serveur distant.
Une fois que vous avez le trafic de cible pour le système distant, vous aurez besoin que ce système distant soit capable de répondre suffisamment vite. C’est un point extrêmement important, et, traditionnellement, il n’y a pas de contrôle fait. Avec le trafic de cible, vous pouvez exécuter un test de performances, et s’assurer que le serveur distant est convenable pour votre trafic et que les retards ne sont pas trop longs. La performance du système distant se reflétera directement sur votre site web e-commerce.
Conclusion
En conclusion, ne sous-estimez pas la synchronisation. Comme d’habitude avec l’informatique, de tels systèmes sont sujets à changement : il est évident qu’au début une réplication unidirectionnelle suffit, mais un hybride est rapidement mis en place, puis une synchro bidirectionnelle est demandée, et finalement, les performances se dégradent. Chaque phase a ses propres défis.
