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 bots 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 le pouvait pas.

Le goulot d'étranglement architectural du jour du lancement

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

La plateforme eCommerce de Nike a été élaborée pour être fiable, mais pas 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é conçu 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 défini un objectif. La plateforme devait gérer 500 connexions et enregistrements par seconde, soutenus jusqu'à 4 heures pendant les événements de lancement. 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. Des sneaker bots, agents logiciels conçus pour coordonner les achats à grande échelle automatiquement. Nike avait identifié les achats de produits via bots comme un défi commercial persistant. Toute refonte de l'infrastructure devait également résoudre ce problème.

Architecture CQRS événementielle sur microservices AWS

Un système de profil monolithique a un goulot d'étranglement inhérent. À mesure que vous ajoutez des utilisateurs et des requêtes, chaque opération doit emprunter le même chemin 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 élaborée sur les microservices AWS. CQRS signifie Command Query Responsibility Segregation. Séparez complètement 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 s'échelonne là où les monolithes se cassent parce que les services sont faiblement couplés. Chaque service s'échelonne 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 sélectionné 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é ajouté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 tolèrent une cohérence finale brève. Ils ne peuvent pas tolérer un système qui est indisponible.

Magasins de données spécialisés et scalabilité linéaire

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 spécifique.

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 chronologique. Cassandra est conçu 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 d'événements distribués.

Elasticsearch alimente les capacités de recherche full-text. Les clients ont besoin de rechercher des profils et des paramètres. Elasticsearch excelle à cette tâche. Mais vous ne voudriez pas stocker tout dans Elasticsearch ou l'utiliser pour la cohérence transactionnelle. C'est hautement spécialisé.

Couchbase fournit le cache des profils. Lorsqu'un utilisateur se connecte, ses données de profil doivent être lues ultra-rapidement. Couchbase est un cache distribué conçu pour ce cas d'utilisation exact. C'est rapide et s'échelonne horizontalement sans limite.

Redis stocke toutes les autres données clé-valeur généralistes. 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 s'échelonne 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 full-text va à Elasticsearch. 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 critique. TechSparq a utilisé la virtualisation des services Web. Chaque microservice pouvait être testé isolément contre des versions simulées de ses dépendances. Les développeurs travaillant sur le service de profil n'avaient pas besoin de la plateforme entière en cours d'exécution. Ils travaillaient contre des versions simulées des autres services. Cela a permis aux équipes de livrer 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, donc elles ne peuvent pas se déplacer vite, donc elles attendent des environnements de test partagés, donc tout ralentit. Les microservices avec l'isolation des tests appropriée empêchent cela complètement.

Résultats de test et mitigation des bots intégrée

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é mis en charge jusqu'à 1 200 connexions par seconde. Zéro dégradation. 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 entièrement différente.

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

Le problème des bots a été résolu via 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 demande une vérification du téléphone mobile. C'est un facteur secondaire que les bots ne peuvent pas facilement automatiser. Les achats via bots ont diminué dramatiquement.

Le même système fondamental alimente maintenant les applications mobiles iOS, les applications mobiles Android et les applications Web HTML traditionnelles. Une seule plateforme gère les 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.

Implications pour les plateformes eCommerce de haut débit

Les lancements de produits ne sont pas uniques à Nike. Chaque marque de mode les exécute. 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 architectural.

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 gravé dans la roche.

Les microservices avec des magasins de données spécialisés éliminent ce plafond. Chaque service s'échelonne indépendamment. Chaque magasin de données est optimisé pour son modèle d'accès spécifique. CQRS sépare les chemins de lecture et d'écriture afin qu'ils s'échelonnent 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 des bots devient structurelle plutôt qu'ajoutée. Lorsque l'infrastructure de profil est conçue à partir de zéro autour de l'authentification et de la vérification, vous pouvez intégrer le combat contre les bots 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 alimente é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 et capable de pivoter rapidement.

• ✓ CQRS basée sur les événements s'échelonne là 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 compromise pour elle.
• ✓ Les tests en isolement permettent aux équipes de livrer sans déploiement stack complet. La vélocité augmente quand les développeurs n'ont pas à attendre des environnements de test partagés.
• ✓ La mitigation des bots intégrée à la couche auth, non ajoutée après. Les solutions structurelles sont plus fortes que celles ajoutées a posteriori.