Okta fait constamment évoluer son infrastructure cloud pour répondre aux besoins de ses clients. Nous plaçons la fiabilité et l'évolutivité au cœur de nos décisions de conception pour les services qui traitent des milliards d'authentifications par mois. Cet article explique en détail comment un projet récent visant à supprimer l'un de nos services les plus fréquentés a permis d'améliorer considérablement les opérations et la fiabilité.
Un aperçu de l'avantage d'Okta
Auparavant, trois services principaux recevaient et facilitaient la majorité du trafic client vers Workforce Identity Cloud d'Okta à la périphérie : un Application Load Balancer pour protéger contre les inondations de requêtes, un service basé sur Apache pour l'arrêt SSL et un service basé sur Nginx pour le routage et la logique métier.
Ces services sont déployés à l'échelle mondiale et mis à l'échelle pour gérer les volumes importants de trafic qu'Okta traite quotidiennement. Bien que performant, le couplage étroit de ces services est devenu progressivement un défi opérationnel. Toujours désireuse d'améliorer notre infrastructure, une équipe interfonctionnelle s'est attachée à réévaluer ces services.
Un de trop ?
Les clients d'Okta s'attendent à un service performant et disponible, et il est impératif que nous répondions à ces attentes. Tout en traitant régulièrement d'innombrables flux de connexion, le fait d'être sur l'Internet public invite à l'inattendu. Qu'elles soient initiées par le client ou non, Okta reçoit parfois d'importants afflux de trafic sur une courte période.
En examinant attentivement les services que nous exploitons, nous avons déterminé que le goulot d'étranglement par thread d'Apache limitait notre capacité à gérer d'importants afflux de trafic sans impact et avons décidé de supprimer entièrement ce service de notre edge. Cela ferait avancer l'architecture événementielle de Nginx dans notre stack comme un meilleur moyen de gérer les schémas de trafic imprévisibles.
Avec une fiabilité accrue comme principal facteur de motivation, la possibilité d'arrêter plusieurs centaines de serveurs Apache entraînerait une réduction significative des tâches opérationnelles. Entre l'amélioration de la fiabilité du service, la réduction de notre volume d'agrégation des journaux système, l'élimination des tâches opérationnelles et les économies de coûts, nous bénéficierions grandement de la mise hors service de notre service Apache.
Notre équipe a mis au point une chorégraphie robuste pour détourner le trafic du service Apache et l'envoyer directement vers Nginx, ce qui nous a permis d'itérer rapidement sur les problèmes découverts dans les environnements de test avant d'appliquer progressivement cette modification à nos environnements de production mondiaux.
En cours de test
Le service Apache d'Okta exécute une application Java légère avec des configurations personnalisées pour traiter les requêtes entrantes avant de les transmettre à notre service Nginx. En supprimant Apache, nous devions nous assurer que toutes les fonctionnalités fournies par le service étaient recréées dans Nginx. Grâce à des tests synthétiques, notre équipe a rapidement identifié plusieurs schémas de requêtes entrantes qui n'étaient plus correctement traitées après la suppression du service Apache.
Le problème de la « double barre oblique »
Parce que Apache servait autrefois d'application initiale pour recevoir le trafic client, il contenait une logique développée au fil des ans pour identifier et répondre correctement aux demandes mal formées. À mesure que l'infrastructure de périphérie d'Okta a mûri au fil des ans, cette fonctionnalité a été largement déplacée plus tôt dans la pile. Pourtant, un problème lié à la suppression d'Apache a été rapidement identifié : nous n'étions plus en mesure de gérer correctement les requêtes contenant //.
Dans les environnements de test sans le service Apache, Nginx a renvoyé des codes d'état incorrects pour toute requête contenant //. À titre d'exemple artificiel, les appels d'API pour /api/v1/users ont continué à se comporter comme prévu, mais les appels à //api/v1/users ont été observés pour renvoyer des réponses HTTP d'erreur du client.
Notre service Apache traitait ces requêtes avec une simple règle de réécriture, mais Nginx renvoyait des codes d'erreur pour les requêtes sans la réécriture, nous avons donc dû introduire une nouvelle règle de réécriture pour restaurer cette fonctionnalité.
En observant RFC 3986, ce serait notre premier contact avec la loi de Hyrum.
Le problème de la « chaîne de requête »
Avec une suite robuste de tests synthétiques pour valider la résolution du problème de « double barre oblique », nous avons commencé un déploiement progressif de la suppression du service Apache dans nos environnements de staging. À mesure que la quantité de trafic traitée sans Apache augmentait progressivement, nous avons de nouveau observé que Nginx renvoyait des codes de réponse incorrects pour certaines requêtes précédemment traitées par Apache sans problème.
Comme précédemment, nous avons découvert un cas où Apache réécrivait auparavant des requêtes mal formées dans un format que Nginx pouvait traiter. Contrairement à RFC 1738, Apache avait réécrit les chaînes de requête encodées en valeurs décodées. Par exemple, les requêtes à /api/v1/users%3Flimit=1 étaient décodées et transmises à Nginx comme /api/v1/users?limit=1. Sans Apache dans le chemin de requête, Nginx n'était pas en mesure de traiter les chaînes de requête encodées et renvoyait une erreur au client à l'origine de la requête. Pour résoudre ce problème, une règle de réécriture supplémentaire a été introduite dans notre configuration Nginx, et nous avons pu poursuivre le déploiement.
Plusieurs itérations plus tard
La suppression d'un service aussi important n'a pas été une mince affaire, mais elle a finalement été réalisée sans impact durable sur les clients. Cet effort a connu plusieurs itérations au fil du temps, mais l'accent mis sur le résultat est resté le même :
- Supprimer un goulot d'étranglement des performances
- Améliorer la fiabilité du service
- Réduire la fatigue opérationnelle
Après avoir terminé cet effort dans tous les environnements, les avantages sont rapidement devenus apparents et l'équipe prévoit déjà nos prochaines améliorations.
Vous avez des questions sur cet article de blog ? Contactez-nous à l'adresse eng_blogs@okta.com.
Consultez d’autres Blogs sur l’ingénierie d’Okta pour approfondir vos connaissances.
Prêt à rejoindre notre équipe d’ingénieurs aussi passionnés qu’exceptionnels ? Consultez notre page Carrières.
Libérez le potentiel d’une gestion des identités moderne et sophistiquée pour votre entreprise. Contactez notre équipe commerciale pour plus d’informations.
