Nous avons économisé 38 % des coûts de traitement du trafic grâce au gateway natif du cloud, mais nous avons failli perturber la chaîne d'approvisionnement en produits frais en Europe pendant le Black Friday.

La réunion de révision de la grande promotion du Black Friday de la semaine dernière vient de se terminer, et notre équipe de trois personnes chargée du backend de la livraison de produits frais en Europe est encore sous le choc : le jour de la prévente, 17 % des demandes de livraison sous contrôle de chaîne de froid ont été directement rejetées (code 429), ce qui a entraîné une augmentation de trois fois du nombre de plaintes des utilisateurs, et nous avons failli gâcher la grande promotion annuelle pour laquelle nous nous préparions depuis trois mois.

Le problème vient de l'utilisation d'un gateway API traditionnel pendant deux ans : nous avons fixé une limite de trafic commune pour deux interfaces clés, l'analyse des adresses et la réservation de la chaîne de froid. Le jour du Black Friday, les demandes d'analyse des adresses ont explosé, occupant entièrement la capacité du gateway, empêchant les demandes de réservation d'arriver. Avant, nous pensions toujours que le changement de gateway était une tâche réservée aux grandes équipes. Ce n'est qu'après avoir rencontré ce problème que nous avons réalisé que les gateways natifs cloud pourraient représenter une meilleure option en termes de rapport qualité-prix pour les petites équipes.

Qu'est-ce qu'un gateway natif du cloud, après tout ?

En une phrase : c'est l'entrée du trafic qui fonctionne à l'intérieur d'un cluster K8s, et vous n'avez pas besoin de louer un serveur séparément pour le déployer.Vous vous occupez uniquement des règles de routage et des stratégies de limitation de trafic ; le reste, comme l'élasticité des ressources et les mises à niveau opérationnelles, est géré par le fournisseur de services cloud.Nous utilisons actuellement une version qui peut gérer 20 000 demandes par seconde avec un seul instance, ce qui nous évite de devoir planifier à l'avance la capacité de notre système.

Les trois bénéfices réels que nous avons obtenus après le changement

Après le problème survenu le jour de la prévente, nous avons passé trois jours à mettre en place le gateway natif cloud. Le jour de la compétition principale du Black Friday, il n’y a plus eu aucune erreur de limitation de trafic. De plus, il y a eu trois avantages inattendus :

• Le coût a été directement réduit : auparavant, nous louions deux serveurs 4 cœurs 8G pour exécuter la passerelle traditionnelle, plus un service d'exploitation et de maintenance a passé 8 heures par mois à faire la mise à niveau de la version, calculant le coût mensuel de 1200 euros. Maintenant, la passerelle native du cloud paie en fonction du volume d'appels, ne dépensant que 740 euros par mois.Réduction directe de 38 % des coûts de traitement du trafic
• J'ai enfin compris la stratégie de limitation de trafic : auparavant, le gateway ne pouvait imposer des seuils de limitation de trafic que pour toutes les interfaces de manière globale. Maintenant, nous pouvons définir des règles distinctes pour différents scénarios d'utilisation. Par exemple, nous pouvons limiter l'interface d'analyse d'adresses à 5000 demandes par seconde. Même si cette interface est sollicitée de manière intensive, cela n'affectera pas les processus de paiement ou de réservation qui suivent.
• La durée de l'échange de données lors de la négociation HTTPS a été réduite de moitié : auparavant, notre certificat SSL était stocké sur notre propre serveur de passerelle, ce qui entraînait des retards allant jusqu'à 200 ms pour les utilisateurs situés dans différentes régions d'Europe. Maintenant, les fournisseurs de services cloud ont mis en cache le certificat sur des nœuds de périphérie, permettant de réduire ces retards à moins de 80 ms pour la plupart des demandes.

Ne vous pressez pas pour monter dans la voiture, nous avons déjà rencontré ces deux problèmes.

Il n’est pas dit que tous les gateways natifs du cloud présentent des avantages ; pendant le processus de migration, nous avons également rencontré deux problèmes qui ont failli nous obliger à tout refaire :

Le premier problème concerne le retard de démarrage à froid. Lorsque nous avons effectué des tests de charge le premier jour, nous avons constaté que, après 10 minutes sans aucune demande, le temps de réponse pour la première série de demandes a soudainement augmenté à plus de 300 ms. Nous avons ensuite découvert que les instances élastiques fournies par le fournisseur de cloud étaient lancées sur demande, et il était nécessaire de définir un nombre minimal d'instances réservées pour les interfaces clés afin d'éviter les temps d'attente excessifs en cas d'arrivée soudaine de trafic.

Le deuxième point concerne les limitations des plugins personnalisés. Avant, nous avions écrit nous-mêmes un plugin pour la vérification des signatures des demandes et l'avions exécuté sur un gateway traditionnel. Ce n'est que lors du passage à un gateway cloud-native que nous avons découvert que celui-ci ne prenait en charge que les plugins au format WebAssembly. Il nous a fallu deux jours pour modifier le code afin de l'adapter. Si vous avez beaucoup de logiques personnalisées, il est préférable de vérifier au préalable la compatibilité des plugins proposés par le fournisseur.

Faut-il vraiment le changer ? Regardez simplement ces deux critères de décision.

La situation dans laquelle vous devriez vous changer :

• L'équipe compte moins de 5 développeurs backend et n'a pas de personnel dédié à l'opération et à la maintenance. Nous ne voulons pas consacrer du temps à l'entretien et à la mise à niveau des serveurs de passerelle.
• Les fluctuations de trafic sont importantes ; par exemple, pendant les périodes de promotion, le trafic peut atteindre de 3 à 10 fois la normale. Nous ne voulons pas louer un grand nombre de serveurs à l'avance, car cela entraînerait un gaspillage d'argent puisque ces serveurs resteraient inutilisés la plupart du temps.

Dans les situations où vous ne devriez pas changer :

• Les exigences en matière de conformité sont particulièrement strictes : tout le trafic doit passer par des serveurs que vous contrôlez vous-même, et il ne peut pas utiliser les nœuds publics des fournisseurs de services cloud.
• Votre passerelle intègre une logique personnalisée très complexe et spécifique, qui n’est pas supportée par les passerelles cloud natives disponibles sur le marché. Modifier cette logique vous-même coûterait plus cher que de maintenir votre propre passerelle.

Trois petits conseils pour ceux qui commencent pour la première fois

• Il n'est pas nécessaire de faire le transfert complet du trafic d'un coup. Commencez par diriger 10 % du trafic vers le gateway natif cloud pendant une semaine et surveillez la situation. Si aucun problème n'est détecté, vous pourrez ensuite progressivement transférer le reste du trafic. Au début, nous avons commencé par transférer l'interface d'analyse des adresses, et seulement après avoir constaté qu'il n'y avait aucun problème, nous avons migré tout le trafic.
• Les interfaces clés doivent absolument disposer d'un nombre minimum d'exemplaires en instance. Ne économisez pas sur cela ; nous avons maintenant réservé 2 exemplaires permanents pour chacune des deux interfaces clés, celle de réservation et celle de paiement dans le système de chaîne de froid, et nous n'avons plus jamais rencontré de problèmes de démarrage lent ou de temps d'attente excessif.
• Il n’est pas nécessaire d’acheter la version la plus évoluée ; pour la plupart des petites et moyennes entreprises, les fonctionnalités de la version de base sont amplement suffisantes. La version de base que nous utilisons actuellement ne nécessite pas d’ajout de frais pour un trafic inférieur à 20 000 requêtes par seconde (QPS).

Réponse à la question la plus fréquemment posée au sein de l'équipe : Serons-nous liés à un fournisseur de services cloud ?

Notre conclusion est la suivante : pour une équipe de développement backend composée de moins de 10 personnes,L'amélioration de l'efficacité apportée par la liaison avec les fournisseurs de services cloud est bien supérieure au coût de mettre en place soi-même tous les composants.Lorsque le moment viendra de changer de fournisseur de cloud, vous aurez suffisamment d'énergie pour effectuer la migration. Ne vous en préoccupez pas pour l'instant.