Nike Cloud Microservices
pour les profils.
1 200 connexions par seconde.
Zéro dégradation.

Le jour du lancement des produits est tout pour Nike. C'est le jour où les nouveaux designs se mettent en vente. C'est le jour où la demande est la plus forte, lorsque les campagnes marketing convergent, lorsque les clients mondiaux font la queue à la fois. C'est aussi le jour où le trafic des robots atteint un pic. Coordonné, malveillant, conçu pour drainer l'inventaire limité avec une vitesse automatisée. Le système de profil utilisateur de Nike devait gérer à la fois le volume et l'intention adversaire, et il ne pouvait pas.

Le problème du jour du lancement des produits

Les lancements de produits sont conçus pour l'impact commercial. Les campagnes marketing sont chronométrées pour attirer l'attention. Les influenceurs coordonnent les chutes. L'ensemble de l'appareil marketing mondial pointe vers un moment unique. Tout le monde est censé se présenter à la fois et acheter la nouvelle chose.

La plateforme eCommerce de Nike a été construite pour être fiable, mais elle n'a pas été construite pour être submergée. L'infrastructure du profil utilisateur, qui gère l'enregistrement et la connexion, a atteint un plafond à 100 à 200 requêtes par seconde. Ce n'était pas exactement une défaillance technique. C'était une limitation structurelle. Le système avait été construit pour une charge moyenne et on lui demandait de gérer un pic.

Lorsque la connexion échoue le jour du lancement des produits, Nike ne perd pas une transaction. Nike perd des clients. Ils s'en vont. Ils vont ailleurs. Le jour du lancement est un événement sans pardon.

Nike a fixé un objectif. La plateforme devait gérer 500 connexions et enregistrements par seconde, soutenus jusqu'à 4 heures pendant les événements de lancement de pointe. L'état actuel était 100 à 200. Une amélioration de 250% était requise.

Mais il y avait un autre problème caché dans le problème. BYE sneaker bots, des agents logiciels conçus pour coordonner les achats à grande échelle automatiquement. Nike avait identifié les achats de produits BOT comme un défi commercial persistant. Toute refonte de l'infrastructure devait également résoudre ce problème.

Pourquoi les microservices sur AWS était la bonne architecture

Un système de profil monolithique a un goulot d'étranglement inhérent. À mesure que vous ajoutez des utilisateurs, à mesure que vous ajoutez des requêtes, chaque opération doit passer par le même chemin de code. La mise en cache aide. Le regroupement de connexions aide. Mais il y a un plafond. Les monolithes se heurtent à des murs.

TechSparq a choisi une approche différente. Une architecture CQRS basée sur les événements construite sur les microservices AWS. CQRS signifie Command Query Responsibility Segregation. Séparez les chemins qui écrivent les données des chemins qui lisent les données. Les opérations d'écriture vont dans un canal de commande. Les opérations de lecture interrogent des répliques cohérentes à terme optimisées pour chaque modèle d'accès. Le système ne frappe plus un seul goulot d'étranglement parce qu'il n'y a plus de goulots d'étranglement uniques.

Basé sur les événements signifie que les changements d'état sont enregistrés comme des événements dans le temps. Ces événements circulent dans le système de manière asynchrone. Les services les consomment, mettent à jour leurs propres magasins de données et répondent aux changements. Ce modèle se développe là où les monolithes se cassent parce que les services sont faiblement couplés. Chaque service peut se développer indépendamment. Le système peut gérer la charge coordonnée parce que la charge est distribuée sur plusieurs systèmes plutôt que concentrée en un seul.

Nike a choisi la pile Netflix OSS pour les outils de gestion. Sept clusters de microservices, chacun traitant une partie différente du cycle de vie du profil utilisateur. La haute disponibilité a été intégrée dès le départ. La tolérance aux pannes n'a pas été boulonnée. Le système a été conçu pour être finalement cohérent, ce qui signifie que les modifications de données se propagent dans le système au fil du temps plutôt qu'instantanément. Ce compromis est approprié pour les profils utilisateur. Les utilisateurs peuvent tolérer une cohérence finale brève. Ils ne peuvent pas tolérer un système qui est en baisse.

La stratégie de magasin de données derrière la dégradation zéro

La décision la plus puissante a été de refuser d'utiliser un magasin de données pour tout. Les modèles d'accès différents ont besoin d'infrastructures différentes. Nike a déployé plusieurs bases de données spécialisées, chacune optimisée pour son cas d'utilisation.

Cassandra stocke les événements basés sur le temps. Au fur et à mesure que les événements arrivent, ils sont enregistrés dans l'ordre où ils sont arrivés. Cassandra est construit pour les charges de travail lourdes en écriture avec des données de séries chronologiques. Ce n'est pas le meilleur choix pour chaque requête, mais c'est idéal pour les journaux des événements.

Elastic Search supporte les capacités de recherche en texte intégral. Les clients ont besoin de rechercher des profils et des paramètres. Elastic Search excelle à cela. Mais vous ne voudriez pas stocker tout dans Elastic Search ou l'utiliser pour la cohérence transactionnelle. C'est spécialisé.

Couchbase fournit la mise en cache des profils. Lorsqu'un utilisateur se connecte, ses données de profil doivent être lues rapidement. Couchbase est un cache distribué conçu pour ce cas d'utilisation exact. C'est rapide et ça se développe horizontalement.

Redis stocke toutes les autres données de référence clé générale. Paramètres, préférences, mappages de relations. Redis est optimisé pour les modèles d'accès clé-valeur et les types de données simples. C'est rapide et ça se développe bien.

Cette stratégie élimine les goulots d'étranglement parce que chaque modèle d'accès est servi par une infrastructure conçue pour ce modèle. Les événements lourds en écriture vont à Cassandra. La recherche en texte intégral va à Elastic Search. Les lectures de profil vont à Couchbase. Tout le reste va à Redis. Aucun magasin de données unique ne devient un goulot d'étranglement.

La stratégie de test était tout aussi importante. TechSparq a utilisé la virtualisation du service Web. Chaque microservice pourrait être testé isolément contre des versions simulées de ses dépendances. Les développeurs travaillant sur le service de profil n'ont pas besoin de la plateforme entière en cours d'exécution. Ils travaillent contre des versions simulées des autres services. Cela a permis aux équipes de construire des solutions contre la plateforme sans avoir un déploiement stack complet en cours d'exécution dans plusieurs VPC AWS.

Cette approche élimine un problème courant dans les systèmes distribués. Les équipes ne peuvent pas tester isolément, elles ne peuvent donc pas se déplacer vite, elles attendent donc des environnements de test partagés, tout ralentit. Les microservices avec l'isolation des tests appropriée empêchent cela.

Le résultat et le problème BOT résolu

Le nouveau système a été testé progressivement. Les tests alpha ont montré 600 connexions et enregistrements par seconde sans dégradation du système. Cela a dépassé l'objectif initial de 500. Ce n'était pas le dernier mot.

Les tests ont continué. Le système a été stressé à 1 200 connexions par seconde. Zéro dégradation du système. Aucun délai d'attente. Aucun échec. Six fois l'objectif d'origine. Ce n'était pas une amélioration marginale. C'était une classe d'infrastructure différente.

Les taux de charge de données initiale ont atteint un million de transactions par minute. Le système pourrait ingérer et traiter les données à une échelle qui aurait causé l'effondrement instantané de l'ancienne infrastructure monolithique.

Le problème BOT a été résolu par un nouveau processus commercial. Vérification du téléphone mobile. Lorsqu'un utilisateur s'enregistre ou se connecte lors d'événements à fort trafic, le système invite à la vérification du téléphone mobile. C'est un deuxième facteur que les robots ne peuvent pas facilement automatiser. Les achats BOT ont diminué dramatiquement.

Le même système fondamental serve maintenant les applications mobiles iOS, les applications mobiles Android et les applications Web HTML traditionnelles. Une seule plateforme alimente la gestion des profils dans l'écosystème numérique entier de Nike. L'expérience utilisateur s'est améliorée parce que le système est devenu fiable. Les taux de succès des connexions ont augmenté. Les délais d'enregistrement ont diminué. La clientèle mondiale de Nike a connu moins de points de friction lors des moments les plus importants de leur parcours d'achat.

Ce que cette architecture signifie pour les marques de commerce à fort trafic

Les lancements de produits ne sont pas uniques à Nike. Chaque marque de mode les a. Chaque entreprise d'électronique a des jours de lancement. Les pics de vente saisonniers se produisent pour les articles de sport, la maison et le jardin, les achats des fêtes. Les ventes éclair et les gouttes à quantité limitée sont partout dans le commerce moderne. Chaque marque avec des pics de trafic basés sur les événements fait face au même plafond.

Le système de profil monolithique crée un piège structurel. Vous avez des opérations de lecture et d'écriture qui circulent toutes dans la même infrastructure. À mesure que la charge augmente, le chemin partagé devient saturé. La mise en cache aide. L'optimisation de la base de données aide. Mais vous travaillez dans les contraintes architecturales qui ne peuvent pas être supprimées. Le plafond est en pierre.

Les microservices avec des magasins de données spécialisés éliminent ce plafond. Chaque service se développe indépendamment. Chaque magasin de données est optimisé pour son modèle d'accès. CQRS sépare les chemins de lecture et d'écriture afin qu'ils se développent de manière asynchrone. Le traitement basé sur les événements signifie que le système peut absorber la charge coordonnée parce que la charge est distribuée.

La mitigation BOT devient structurelle plutôt que boulonnée. Lorsque l'infrastructure du profil est conçue à partir de zéro autour de l'authentification et de la vérification, vous pouvez intégrer le combat BOT dans la plateforme elle-même. Vérification du téléphone mobile, empreinte digitale de l'appareil, analyse comportementale. Tout cela devient partie du flux normal plutôt qu'un cas particulier ajouté plus tard.

L'architecture supporte également l'expérimentation rapide. Les équipes peuvent tester de nouvelles fonctionnalités contre des services simulés sans nécessiter le déploiement de la plateforme complète. La vélocité de développement augmente. Le taux de livraison des fonctionnalités augmente. L'entreprise devient plus agile.

• ✓ L'événement CQRS se développe où les monolithes se cassent. Séparer les lectures et les écritures signifie qu'aucune n'a besoin de frapper le même goulot d'étranglement.
• ✓ Les magasins de données spécialisés éliminent les goulots d'étranglement. Chaque modèle d'accès obtient une infrastructure conçue pour lui, pas compromis pour elle.
• ✓ Les tests en isolement permettent aux équipes de construire sans déploiement complet de la pile. La vélocité augmente quand les développeurs n'ont pas à attendre des environnements de test partagés.
• ✓ La mitigation BOT intégrée dans la couche auth, non ajoutée après. Les solutions structurelles sont plus fortes que les solutions boulonnées.