SAP Concur : la journalisation Elastic comme stratégie DevOps
Note de la rédaction : Avec la sortie d’Elastic Stack 7.11, le nouveau framework d’alerting est désormais généralement disponible. Outre les connecteurs existants vers des plateformes tierces comme Slack, PagerDuty et ServiceNow, la version 7.11 ajoute Microsoft Teams à la liste des intégrations d’alerting intégrées. Pour en savoir plus sur cette mise à jour, consultez notre blog sur la publication des alerting.
Cet article revient sur une présentation faite par la communauté lors de l’Elastic{ON} 2018. Vous souhaitez voir d’autres conférences de ce genre ? Consultez les archives de la conférence ou découvrez les prochaines dates de l'Elastic{ON}Tour près de chez vous.
Vous avez sans doute déjà eu recours à SAP Concur pour saisir une note de frais. Avec plus de 45 millions d’utilisateurs à travers plus de 150 pays (couvrant 70 % du classement Fortune 500), Concur est une solution leader pour la gestion des voyages et des frais. En 2016 seulement, cette offre SaaS a traité plus de 87 milliards de dollars USD de dépenses, soit quotidiennement plus de 2,4 millions de reçus et 187 millions de dollars USD de factures. Si cela peut paraître important pour la comptabilité, cela génère un volume encore plus conséquent de lignes de logs qu’une solution de journalisation doit être capable de gérer au quotidien.
Concur est présent sur le marché depuis plus de 20 ans ; à mesure que ses offres produits ont grandi et évolué, sa solution de journalisation a suivi la même trajectoire. Cela ne concerne pas seulement la technologie employée, mais également la portée et l’intention derrière son usage. D’une solution initiale basée sur SQL servant au stockage simple de logs, leur solution actuelle — bâtie sur l’Elastic Stack — favorise désormais une appropriation complète des applications de bout en bout, tout en alignant le développement, les tests et les opérations. Pour le futur, l’équipe LAMA (Logging, Alerting, Monitoring, and Analytics) de Concur projette d’exploiter le machine learning d’Elastic pour l’analytique opérationnelle et les insights, ainsi que pour automatiser les déploiements et les annulations. Ils ont accompli des avancées majeures en matière de logs, mais ce passage du simple stockage à l’analytique ne s’est pas fait en un jour.
Conçue initialement sur une base de données relationnelle, leur solution de journalisation ingérait des données de log au format XML via RabbitMQ, et les utilisateurs étaient ravis de pouvoir facilement interroger leurs logs grâce au SQL. Mais avec l’essor du service, l’utilisation s’est intensifiée. Le pic d’ingestion atteignant 200 Go par jour — avec des taux dépassant 1 500 documents par seconde — le service a atteint ses limites. Les problèmes de performance pouvaient contraindre les utilisateurs à patienter jusqu’à 20 minutes avant qu’un log ne soit accessible dans le système. La seule solution alors envisageable pour l’équipe était de migrer leur base de données vers un matériel plus performant, une méthode qui n’était pas viable sur le long terme. Ce qu’il leur fallait, c’était une scalabilité horizontale ; ils ont donc cherché une meilleure alternative.
Après avoir effectué des recherches sur Elasticsearch et entendu parler de différentes réussites d’entreprises dans des situations comparables, Concur a sélectionné l’Elastic Stack comme solution de journalisation. C’était une solution rapide, puissante et évolutive — et, fait (peut-être plus) important pour leurs utilisateurs internes, elle possédait un composant de visualisation que leurs utilisateurs appréciaient grandement. Auparavant, les différentes équipes créaient leurs propres interfaces et tableaux de bord, supportant souvent des frais de licence pour les outils requis. Avec Kibana, Concur a obtenu une solution de visualisation unifiée, éliminant ainsi le recours à des outils de visualisation maison ou tiers.
La première mise en œuvre d’Elastic a été effectuée avec Elasticsearch 1.1 et Kibana 3, l’ingestion étant assurée par Logstash, RabbitMQ (comme ils l’utilisaient avec la solution SQL) et Fluentd. L’équipe de journalisation a également été en mesure de construire son propre plug-in d’alerte (un avantage lié à la nature open source d’Elastic), car il n’en existait pas encore au sein de l’Elastic Stack. Entre la rapidité accrue d’Elasticsearch, les visualisations de Kibana et les fonctionnalités d’alerte de leur plug-in Watcher maison, l’adoption du service s’est généralisée chez Concur et l’ingestion a bondi à 5 000 doc/s. C’est un niveau que leur solution SQL n’aurait jamais pu gérer.
Passer de la solution à la stratégie avec Elastic
Depuis cette mise en œuvre initiale, la solution de journalisation de Concur s’est développée avec l’Elastic Stack. En 2015, ils sont passés à Elasticsearch 2.3 et Kibana 4.5, ont acheté un abonnement Gold, et ont commencé à utiliser Beats (en remplacement de Fluentd), Watcher (pour remplacer leur solution locale) et Shield (pour la sécurité). Ils ont également créé un autre plug-in personnalisé, cette fois une interface utilisateur d’agrégation personnalisée. À mesure que leur solution de journalisation s’améliorait, l’adoption aussi, et en 2017, leur taux d’ingestion atteignait 60 000 doc/sec (4 To/jour).
Après avoir pris part à l’Elastic{ON} 2017, Concur a de nouveau mis à niveau ses systèmes, cette fois pour bénéficier de la recherche inter-clusters, d’une sécurité améliorée (requise pour garantir la conformité au RGPD) et d’autres fonctionnalités récentes de la Suite Elastic apprises durant la conférence. En utilisant la recherche inter-clusters, ils ont réussi à scinder leur cluster monolithique en plusieurs clusters de plus petite taille, répartis sur plusieurs régions. Cette mise à jour — ainsi que leur passage à un abonnement Platinum — leur a permis d’établir l’environnement qu’ils utilisent aujourd’hui, avec diverses sources d’ingestion, des clusters Elasticsearch dans plusieurs régions (5 To/jour aux États-Unis) et des tableaux de bord Kibana utilisés par les équipes d’exploitation, les SRE, le support, la direction, etc. Tout cela est géré par une équipe LAMA constituée de six ingénieurs et deux managers.
Découvrez comment Concur est passé du stockage de logs à l’activation de la propriété en regardant Elastic @ SAP Concur : Conduire le parcours vers le DevOps et la propriété de bout en bout d’Elastic{ON} 2018. Vous apprendrez aussi comment ils ont permis le déploiement de services de logging en un clic, comment ils ont configuré les mappings (non dynamiques) et les champs pour plus de 200 équipes, et quels sont leurs plans pour tirer parti de la puissance de l’Elastic Machine Learning.
