Comment rendre ce système VRAIMENT robuste ?

Hello,

Dans le cadre d’un projet, un serveur web reçoit une grosse quantité de requêtes HTTP chaque minute. Ces requêtes sont des commandes e-commerces que le serveur doit traiter impérativement (ces requêtes HTTP sont générées par des webhooks Shopify/Woocommerce/Prestashop/…).

Je cherche à rendre cette architecture la plus fiable possible, parce que si le serveur down quelques minutes ou heures, alors je perds toutes les commandes reçues pendant ce temps.

Actuellement, j’utilise un load-balancer qui dispatch les requêtes sur 2 instances. Mais il y a quelques semaines, le prestataire qui manage la base MongoDB derrière ces instances a fait une bêtise, et le système a down 12h sans que je m’en aperçoive (j’ai depuis amélioré ma gestion/notification des erreurs).

Auriez-vous des conseils et des suggestions pour rendre plus robuste ce type de système ?

Ce qui m’angoisse un peu, c’est que plus je rajoute de mécanisme du genre "ça va aider", plus je rajoute de cause de bugs possibles ahah.

Merci d’avance à ceux qui auront des idées bonne journée

Une solution efficace mais pas forcément simple à mettre en place est d’avoir une réplication sur plusieurs zones, comme du cloud voire du serverless permettrait de le faire.
Pourquoi ne pas passer sur une base de donnée managée (type DocumentDB ou Atlas chez AWS) ? Tu déporterais ainsi la responsabilité sur un service spécialisé tout en t’assurant une redondance au besoin (tu peux répartir ta DB sur plusieurs datacenters assez facilement).

Sinon il faut mettre en place des alertes et être capable d’y répondre rapidement mais ça demande de l’énergie humaine…

Hello @viki53,

Merci pour ton retour !

Pour la base managée : c’est déjà le cas, j’utilise une base managée chez ScaleGrid. Mais les gars de ScaleGrid ont changé un paramètre de connexion sans avertir personne (ou alors j’utilisais une méthode dépréciée sans le savoir), ce qui a causé le bug dont je parlais. Au final, ça m’a fait prendre conscience que managée ou pas, je peux avoir des soucis ici aussi.

Par contre, le serverless je ne connaissais pas, et ça semble être super pertinent dans mon cas ! Je pourrai remplacer mon load-balancer et mes 2 instances par du serverless si j’ai bien compris ; ou même utiliser du serverless pour faire une sorte de proxy avant mon architecture actuelle (et logger les requêtes HTTP qui arrivent, au cas où l’archi derrière déconne).

Le serverless va pas vraiment remplacer un load-balancer, mais le load-balancer peut être managé pour plus avoir à le gérer oui.

Par contre si un service managé est modifié sans te prévenir c’est que le prestataire fait pas son boulot correctement : à ta place je vérifierais ce qui leur permet de modifier ta configuration sans prévenir. Chez AWS par exemple (et c’est pareil chez beaucoup de fournisseurs compétents) tu restes maître des paramètres et des versions utilisées tant qu’ils les supportent, il n’y a pas de modification non prévue, sauf panne.

Je vois qu’en plus ScaleGrid utilise AWS, donc je vois pas ce qu’ils apportent par rapport à Atlas (qui est géré par MongoDB directement) voire DocumentDB (qui n’est pas du Mongo mais en grosse partie compatible pour un usage courant — attention tout de même à quelques subtilités, j’ai un client qui a du avoir son propre cluster MongoDB parce qu’il a besoin d’une fonctionnalité précise de MongoDB par exemple).

@viki53

Effectivement, je ne sais plus ce qui m’avait poussé à passer par Scalegrid, mais ce choix devient vraiment discutable. Je pense changer de crèmerie pour m’éviter ce genre de problème aberrant à l’avenir.

Et concernant le serverless : après m’être pas mal renseigné suite à ton message, je vois qu’il y a des choses à faire, mais je n’ai pas encore en tête la combinaison idéale.

Soit un simple système de proxy qui log les requêtes HTTP en amont, soit un truc plus intelligent que ça. Je vais y réfléchir et aussi voir si quelqu’un propose d’autres pistes ici

Merci beaucoup pour ton aide.