KeyBank utilise la Suite Elastic pour mettre en place une solution de monitoring d'entreprise
Cet article résume une conférence donnée à l'événement ElasticON 2019. Vous souhaitez voir d'autres présentations comme celle-ci ? Consultez les archives ou renseignez-vous sur les prochaines dates de l'événement Elastic.
KeyBank est l'une des plus grandes banques des États-Unis, dont le système de monitoring a évolué en parallèle de sa croissance. Comptant plus de 1 100 filiales et de 1 400 GAB répartis sur 15 états, l'infrastructure de KeyBank s'est transformée en une "sorte d'Arche de Noé", indique Mick Miller, Senior Product Manager, Cloud Native chez KeyBank. En d'autres termes, la banque disposait de chaque élément en double, ce qui a entraîné la génération de 21 îlots de données différents. "Nous avons constaté que notre temps moyen de résolution était particulièrement lent, contrairement à notre temps moyen pour se rejeter la faute."
À la recherche de la cause première
Avec un tel nombre de systèmes, et n'ayant aucun moyen de corréler les données cloisonnées, l'équipe n'avait aucune visibilité sur la cause première des problèmes. Mauvaises performances des postes de travail des filiales, chute des évaluations de l'application bancaire mobile... Sans données d'observabilité corrélées, la banque avait les mains liées. Et, cerise sur le gâteau, ses systèmes de logging et d'indicateurs arrivaient à court de stockage, bloquant le monitoring. Inutile d'envisager de mettre à niveau la licence de son précédent fournisseur, en raison du coût prohibitif d'une telle opération.
L'équipe a donc commencé à créer un énorme backlog de requêtes de monitoring, empiétant sur le temps qu'elle aurait pu consacrer au développement d'un nouveau système. C'est alors qu'un problème encore plus critique est apparu : la perte de performances côté clients. Par exemple, lorsqu'un client souhaitait ouvrir un compte, le système plantait encore et encore, entraînant des latences énormes et une expérience client exécrable. Or, lorsqu'un client potentiel n'arrive pas à ouvrir un compte facilement, il se tourne vers une autre banque.
Une observabilité renforcée avec Elasticsearch
Les systèmes de KeyBank ne fournissaient donc plus les logs et les indicateurs dont la banque avait besoin pour enquêter sur les problèmes non liés à la sécurité. C'est pourquoi elle s'est tournée vers la Suite Elastic. À l'aide du cluster de développement Elasticsearch qu'elle avait configuré, elle a déployé Winlogbeat et Metricbeat sur des milliers de postes de travail sur son réseau de filiales et a commencé à indexer les données de logs et d'indicateurs. Quelques jours plus tard, elle disposait d'une mine d'informations, qui lui a permis d'identifier trois causes premières : une E/S de disque constamment élevée, une mémoire disponible faible et un réseau complètement saturé.
Étant donné que le nombre d'employés de KeyBank à visualiser les données de temps de réponse dans Kibana augmentait, un sentiment d'urgence s'est créé. Il fallait absolument procéder à une énorme actualisation de l'ensemble du système. La direction a donné son feu vert à l'équipe pour qu'elle déploie le premier cluster de production. L'afflux de données d'observabilité a conféré à l'équipe la visibilité dont elle avait besoin, mais celle-ci s'est retrouvée confrontée à un autre problème : le flux de données inondait son environnement de développement. C'est alors qu'elle s'est rendu compte qu'il lui fallait un plan de croissance.
"La mauvaise nouvelle, c'est qu'il est impossible de déterminer avec précision la charge de travail. La bonne nouvelle, c'est que nous avons appris en cours de chemin que nous devions changer. Nous avons donc conçu l'architecture de notre système de sorte à être capables de reconfigurer nos systèmes sans entraîner de période d'indisponibilité." — Mick Miller, KeyBank
Un scaling d'une précision chirurgicale
Pour gérer la croissance de ses besoins en monitoring, KeyBank fait évoluer le système de monitoring Elasticsearch à l'aide d'une approche itérative pour scaler son système de bout en bout. Après quelques ajustements, son architecture respecte désormais quelques principes directeurs qui permettent à l'équipe de faire preuve d'une "précision chirurgicale" dans les changements qu'elle effectue, sans impacter l'ensemble du système. Chaque niveau logique doit disposer des caractéristiques suivantes :
- Être scalable de façon indépendante
- Offrir une haute disponibilité
- Faire preuve de tolérance aux défaillances
Par chance, ce sont des domaines dans lesquels Elasticsearch et son architecture horizontale brillent particulièrement. Le processus de bout en bout de KeyBank depuis l'ingestion des données à l'indexation dans une base de données prend désormais moins d'une demi-seconde. Aussi, si elle ne remplit pas ce SLA, tout ce qui lui reste à faire, c'est de scaler. "Il y a tous ces avantages inattendus dont nous bénéficions grâce à la centralisation des données. Pour nous, Elasticsearch est une solution idéale en ce sens", affirme Mick Miller.
Vous souhaitez savoir comment (et quand) scaler votre système Elasticsearch ? Lisez l'article de blog KeyBank utilise Elastic pour mettre en place une solution de monitoring d'entreprise, dans le cadre de l'événement ElasticON 2019. Vous découvrirez également comment la banque a mis en œuvre l'automatisation et la virtualisation équilibrée sur les ressources de calcul physiques, et a ainsi économisé plus de 5 millions de dollars.