Box joue la carte de l'observabilité et déploie la Suite Elastic – microservice après microservice

Ces dernières années, l'équipe d'ingénieurs de Box s'inquiétait de plus en plus de voir que son back-end de reporting existant ne scalait pas. Et avec le développement de la roadmap de Box, l'équipe Observabilité voulait adopter une solution plus fiable et plus économique que celle fournie par Splunk pour répondre à ses besoins de logging applicatif et opérationnel.

Les processus en question étaient stratégiques, et les enjeux étaient d'autant plus importants que Box continuait la transformation de son infrastructure monolithique en centaines de microservices, dans l'objectif de doper sa croissance, d'innover et de proposer à ses clients de nouvelles fonctionnalités.

La solution de logging de Box étant facturée en fonction du volume de données ingérées, il arrivait à Box de renoncer à des projets de logging pour limiter les coûts, ou aux ingénieurs de ne pas logger les événements des microservices récemment déployés.

C'était la dure réalité de l'époque. Or, cela ne cadrait pas avec la mission que s'était fixée Box : se transformer rapidement en plateforme de gestion de contenu dans le cloud et faire partie des leaders du marché. Pour assurer cette transformation, Box devait décomposer son monolithe en microservices, ce qui nécessitait plus de logging – pas moins.

Sans compter que Box utilisait MySQL pour le reporting d'entreprise, ce qui générait aussi son lot de problèmes. Entre autres, il était impossible de fournir les données des logs d'utilisation des grandes entreprises (par exemple les données relatives aux ouvertures, aux déplacements ou aux partages de fichiers), en raison du nombre incalculable d'événements générés.

En 2015, après un tour d'horizon qui lui a permis de comparer les tarifs, l'évolutivité, les services de support technique et la sécurité, Box a opté pour Elastic.

En misant sur la Suite Elastic, Box joue la carte d'une observabilité évolutive et parée pour l'avenir, avec un modèle tarifaire basé sur la quantité de mémoire gérée, et non plus sur l'ingestion des données. Grâce à ce passage à Elastic, Box est en mesure d'extraire des logs de ses microsystèmes pour analyser les performances et les comportements, tout en renforçant ses capacités de reporting et en opérant une réduction drastique des coûts. Mieux : ces logs sont maintenant disponibles instantanément.

Box s'était d'abord tourné vers Elastic pour le reporting. C'est ainsi que tout a commencé. Le remplacement de MySQL par Elastic pour le reporting a été une réussite. La confiance en Elastic était née. Tout cela a encouragé Box à troquer sa solution de logging contre Elastic, en commençant par remplacer un nouveau microservice à la fois.

Mais un nouveau système de reporting et de logging doit aussi remporter l'adhésion des ingénieurs, à défaut de quoi, il risque de tomber aux oubliettes ou d'être adopté trop lentement. Avec la Suite Elastic, les ingénieurs de Box sont plus motivés que jamais lorsqu'il s'agit de générer des rapports à grande échelle et de programmer des logs pour des microservices, nouveaux ou existants. Et avec une telle adhésion, Box est bien parti pour continuer sa réussite.

Box avait initialement commencé son parcours avec quelques téraoctets de stockage et une poignée de développeurs. Rattachés à l'équipe Stockage, ils développaient et adoptaient les nouvelles fonctionnalités de reporting de Box en s'appuyant sur des consultants Elastic sur site et sur des sessions de formation Elastic. Aujourd'hui, chez Box, ce sont environ 500 ingénieurs répartis dans un grand nombre d'équipes qui ont adopté la Suite Elastic pour le reporting et le logging, et qui visualisent chaque jour des téraoctets de données via des centaines de tableaux de bord Kibana.

Comme évoqué plus haut, la première étape du parcours de Box avec Elastic a consisté à faire migrer les logs d'entreprise vers Elasticsearch à des fins de reporting, et de les utiliser comme back-end pour l'analyse des données. Ce pipeline de données devait par la suite évoluer pour soutenir le nouvel environnement de logging adossé à Elastic.

Pour son projet de reporting, l'entreprise capitalise sur des fonctionnalités de sécurité obligatoires, comme le contrôle d'accès basé sur les rôles et l'authentification des utilisateurs. Armée de ces fonctionnalités (et d'autres, qui permettent par exemple de savoir qui a accédé à quel fichier Box, à quel moment et à quel emplacement), l'entreprise a pu satisfaire aux obligations de conformité impliquant la sécurité et la confidentialité des données.

Baptisé "Newsroom" en interne, le premier projet de reporting Elasticsearch a résolu des problèmes de filtrage et d'incohérences entre les logs d'entreprise et l'analyse des données métier. Exit, les problèmes de création de rapports non conformes aux SLA. Jusque-là, il arrivait que les rapports des grandes entreprises ne chargent pas du tout, et que ceux des entreprises de taille moyenne prennent un temps fou.

Autres exemples de problèmes résolus :

• Possibilité de filtrer efficacement les logs d'utilisation par dossiers et par utilisateurs
• Possibilité de recueillir les événements associés à certains utilisateurs de l'entreprise ou à certains dossiers
• Rapports statistiques de la console Administrateur non corrompus
• Résolution des incohérences entre les logs d'entreprise et l'analyse des données métier

La solution de logging qu'utilisait Box jusque-là facturait les volumes de données ingérées, qui étaient à ce moment-là de l'ordre de 7 téraoctets par jour. Depuis, Box est passé à 20 téraoctets par jour, et ne devrait pas s'arrêter en si bon chemin. Pour ne pas se ruiner, Box devait jusque-là renoncer à implémenter des fonctionnalités d'observabilité sur l'ensemble de sa plateforme de microservices et devait se limiter à certains d'entre eux, alors que ceux-ci ne cessaient de se multiplier. Une position intenable, que le passage à Elastic a résolue.

Mais les coûts étaient loin d'être le seul problème. Sur l'ancienne plateforme de logging, les échecs des indexeurs n'étaient pas rares. La latence était elle aussi problématique, et l'alerting n'était pas fiable.

Sans perdre de vue ces problèmes, et face à l'explosion des volumes de données générés chaque jour par le logging, l'entreprise décide de reconcevoir son infrastructure de logging en 2017.

Box se lance donc dans le transfert continu et sécurisé de l'ensemble de son logging applicatif et opérationnel vers Elasticsearch. Pour ce faire, l'entreprise adopte une approche en trois axes, qui distingue la conservation, le logging ad hoc et le logging interactif. Le tout, via un pipeline baptisé en interne "Arta", pour Almost-Real-Time-Analytics (analyse en quasi temps réel).

Pour Box, il est absolument essentiel de développer et de maintenir des systèmes ultraperformants, qui respectent les niveaux garantis par les SLA. Ses ingénieurs doivent donc avoir une visibilité sur leurs systèmes et sur les logs qu'ils génèrent. Selon Salman Ahmed, le système de logging Elastic offre à l'équipe Observabilité des capacités de recherche très avancées, avec une surcharge minimale de l'indexation. Le tout, à un prix raisonnable.

Armés de cette observabilité propulsée par Elastic, mais aussi de centaines de tableaux de bord Kibana permettant de visualiser ces données, les ingénieurs de Box ont accès à de précieuses informations en quelques clics. Ils peuvent détecter si des clients rencontrent des problèmes à l'ouverture de leurs fichiers, si des collaborateurs ont été ajoutés à des fichiers, si des fichiers ont été ajoutés à des dossiers, et ainsi de suite. Avec cette nouvelle solution de logging, les ingénieurs sont aussi en mesure de résoudre rapidement les problèmes (problèmes de latence lors de l'importation d'un fichier client, par exemple), ce qui leur permet de respecter les objectifs de disponibilité des SLA.

De plus, afin de continuer à assurer à ses clients une expérience irréprochable, le logging joue un rôle central dans le code de Box : il permet de veiller à ce que les modifications apportées au code sont bien appliquées, explique Dave Ward, directeur technique senior chez Box.

"Lorsqu'on apporte une modification pour ajouter une nouvelle fonctionnalité ou un correctif, on doit vérifier si la modification produit bien le résultat escompté et si l'exécution du code ne génère pas d'erreurs", nous dit-il. "Si le pipeline d'observabilité ne fonctionne pas comme prévu, on ne peut pas garantir l'intégrité de nos systèmes. Adosser Arta à Elasticsearch est indispensable à notre activité si nous voulons maintenir notre agilité et la cadence de nos lancements à grande échelle."

Aujourd'hui, Box se prépare à exécuter dans Arta bon nombre de ses flux de logging de production orientés développeurs. Parallèlement aux flux de logging, nouveaux et existants, que génère le développement continu de microservices, l'équipe Box travaille à l'optimisation de la stabilité, de la résilience et de l'efficience opérationnelle, ainsi qu'à une nouvelle réduction des coûts.

Pour les années à venir, Box réfléchit aussi à la centralisation d'un plus grand nombre d'indicateurs de traçage sur une seule et même plateforme propulsée par Elastic. L'entreprise a aussi noué un partenariat actif avec les ingénieurs Elastic, avec qui elle affine ses produits et partage de précieux commentaires.

Box manifeste de l'intérêt pour d'autres fonctionnalités Elastic comme Elastic APM pour le monitoring des performances applicatives, Machine Learning pour la détection et le signalement des problèmes, ainsi que les fonctionnalités de mapping geoIP d'Elastic, qui lui permettraient, en partant de l'adresse IP, de visualiser dans Kibana de quel endroit du monde proviennent les requêtes.

Box envisage aussi d'exploiter Elastic SIEM pour piloter ses opérations de sécurité, et Canvas pour donner du peps à ses tableaux de bord Kibana. Sans compter la multitude d'autres fonctionnalités Elastic à l'étude.

Du point de vue financier, l'adoption d'Elastic a permis à Box de diviser par deux les coûts liés aux volumes de données. Ajoutons à cela que les problèmes de reporting et les incidents rencontrés sous MySQL sont maintenant de l'histoire ancienne. Il en va de même pour la latence, qui était en partie due à l'indexation en lecture de son ancienne solution de logging, contrairement à l'indexation en écriture d'Elastic.

"Avant, nous cherchions nos données non plus dans une botte, mais dans un champ de foin." C'est ainsi que Deepak Wadhwani décrit la différence de latence. "Lancer des recherches dans Kibana avec Elasticsearch est incroyablement plus rapide", résume-t-il.

D'un point de vue moins quantifiable, en matière de ROI, Box encourage activement ses ingénieurs à générer le bon nombre de logs, c'est-à-dire celui qu'il faut pour atteindre le niveau d'observabilité dont l'entreprise à besoin pour développer des produits ultraperformants.

Grâce à ces changements et à d'autres améliorations subtiles, Box peut aujourd'hui respecter ses accords SLA internes et externes, tout en encourageant ses développeurs à innover, à mesure que l'entreprise monte en charge.