Êtes-vous intéressé à en savoir plus sur la façon dont nous hébergeons le ORCID Registre et API ? Souhaitez-vous savoir comment nous gérons la haute disponibilité, l'évolutivité et la récupération en cas de sinistre ? Si oui, alors cet article est pour vous !
Nous traitons huit millions de pages vues chaque mois sur le ORCID Registry, mais la majeure partie de notre trafic se fait sur les API, qui reçoivent actuellement plus de 100 millions de visites par mois. L'une de nos stratégies de base consiste à investir dans le développement d'une infrastructure d'information robuste, nous devons donc être sûrs que la technologie que nous utilisons pour prendre en charge cette utilisation est fiable et sécurisée.
Le Registre et le reste du site sur orcid.org sont acheminés via un réseau de diffusion de contenu (CDN) - un fournisseur de services cloud qui possède plus de 150 centres de données dans le monde. Lorsque votre navigateur se connecte à orcid.org, les parties statiques du site sont servies à partir d'un centre de données local près de chez vous, pour permettre des temps de chargement plus rapides.
Le CDN possède d'autres fonctionnalités utiles, telles que la protection contre les attaques par déni de service distribué (DDoS), et une analyse de sécurité en temps réel contre les menaces de piratage.
Les pages du Registre sont hébergées dans notre centre de données principal, où le trafic est équilibré sur un cluster de serveurs d'applications, tandis que les données du Registre sont stockées dans un cluster de trois serveurs de base de données puissants, sur des systèmes de fichiers cryptés. L'une est une base de données principale, où les mises à jour sont effectuées et deux sont des serveurs répliques, qui reçoivent une copie des données en temps réel. Les serveurs répliques sont utilisés pour la plupart des opérations de « lecture » du Registre et des API, mais sont également des serveurs de secours à chaud, ce qui signifie qu'ils peuvent être promus maîtres en cas de panne.
Nous avons un assortiment d'autres serveurs prenant en charge le système de production, qui mélangent les données pour créer des index de recherche, conservent un vidage à jour des données publiques dans un autre centre de données et exécutent des tâches planifiées telles que des rappels par e-mail.
Nous sauvegardons automatiquement la base de données deux fois par jour, chiffrons le vidage et le transmettons à un autre fournisseur de services cloud sur un autre continent afin qu'en cas de sinistre dans notre centre de données principal, nous puissions utiliser la sauvegarde de la base de données pour restaurer le système. Nous testons régulièrement que ce processus fonctionne à l'aide d'un serveur hors ligne temporaire.
C'est une base solide. cependant, ORCiD continue de croître et l'on compte de plus en plus sur nous dans le cadre de l'infrastructure d'information sur la recherche. Nous devons donc faire plus pour que la communauté puisse continuer à dépendre de nous.
Que voudrions-nous améliorer ?
Nous aimerions avoir des serveurs d'applications et des répliques de bases de données à plusieurs endroits, afin de ne pas avoir à nous fier au processus de restauration de base de données quelque peu long, ou de perdre des données depuis la dernière sauvegarde. Nous aimerions pouvoir provisionner de nouveaux serveurs en quelques minutes plutôt qu'en quelques heures, en cas d'augmentation soudaine de la demande.
Nous envisageons de séparer les parties les plus critiques du système telles que l'enregistrement, la connexion et l'autorisation à un système isolé, et souhaitons également nous assurer que les problèmes de trafic des API publiques n'affectent pas le registre et les API membres.
Et nous aimerions une architecture plus flexible utilisant des technologies standard telles que Conteneurs Docker ainsi que Kubernetes, ce qui nous aidera à apporter les améliorations mentionnées ci-dessus.
Dites-nous ce que vous pensez de nos projets ! Comment nous comparons-nous à votre propre organisation et aux autres services sur lesquels vous comptez ? Y a-t-il plus que nous pourrions ou devrions faire? Avez-vous des conseils à nous donner en fonction de votre propre expérience ? Nous contacter avec votre contribution et vos commentaires !