¿Está interesado en conocer cómo organizamos el ORCID Registro y API? ¿Le gustaría saber cómo nos ocupamos de la alta disponibilidad, escalabilidad y recuperación en caso de desastre? Si es así, ¡esta publicación es para ti!
Gestionamos ocho millones de páginas vistas cada mes en el ORCID Registry, pero la mayor parte de nuestro tráfico está en las API, que actualmente reciben más de 100 millones de visitas al mes. Una de nuestras estrategias principales es invertir en el desarrollo de una infraestructura de información sólida, por lo que debemos estar seguros de que la tecnología que utilizamos para respaldar este uso es confiable y segura.
El Registro y el resto del sitio web en orcid.org se enrutan a través de una red de entrega de contenido (CDN), un proveedor de servicios en la nube que tiene más de 150 centros de datos en todo el mundo. Cuando su navegador se conecta a orcid.org, las partes estáticas del sitio se sirven desde un centro de datos local cerca de usted, para permitir tiempos de carga más rápidos.
La CDN tiene otras funciones útiles, como la protección contra ataques distribuidos de denegación de servicio (DDoS)y escaneo de seguridad en tiempo real contra amenazas de piratería.
Las páginas del Registro se alojan en nuestro centro de datos principal, donde el tráfico se equilibra en un grupo de servidores de aplicaciones, mientras que los datos del Registro se almacenan en un grupo de tres potentes servidores de bases de datos, en sistemas de archivos cifrados. Uno es una base de datos maestra, donde se realizan actualizaciones y dos son servidores réplica, que reciben una copia de los datos en tiempo real. Los servidores de réplica se utilizan para la mayoría de las operaciones de "lectura" del Registro y las API, pero también son servidores de reserva activa, lo que significa que se pueden promover como maestros en caso de falla.
Tenemos una variedad de otros servidores que respaldan el sistema de producción, que mezclan datos para crear índices de búsqueda, mantienen un volcado actualizado de datos públicos en un centro de datos diferente y ejecutan tareas programadas como recordatorios por correo electrónico.
Hacemos automáticamente una copia de seguridad de la base de datos dos veces al día, encriptamos el volcado y lo enviamos a otro proveedor de servicios en la nube en un continente diferente para que, en caso de un desastre en nuestro centro de datos principal, podamos usar la copia de seguridad de la base de datos para restaurar el sistema. Regularmente probamos que este proceso está funcionando usando un servidor fuera de línea temporal.
Esta es una base sólida. Sin emabargo, ORCiD sigue creciendo y cada vez se confía más en nosotros como parte de la infraestructura de información de investigación. Por lo tanto, debemos hacer más para asegurarnos de que la comunidad pueda seguir dependiendo de nosotros.
¿Qué nos gustaría mejorar?
Nos gustaría tener servidores de aplicaciones y réplicas de bases de datos en varias ubicaciones, de modo que no tengamos que depender del proceso de restauración de la base de datos, algo prolongado, o perder datos desde la última copia de seguridad. Nos gustaría poder aprovisionar nuevos servidores en cuestión de minutos, en lugar de horas, en caso de un aumento repentino de la demanda.
Estamos considerando separar las partes más críticas del sistema, como el registro, el inicio de sesión y la autorización, en un sistema aislado, y también nos gustaría asegurarnos de que los problemas de tráfico de API públicas no afecten a las API de registro y miembros.
Y nos gustaría una arquitectura más flexible utilizando tecnologías estándar de la industria como Contenedores Docker y Kubernetes, lo que nos ayudará a realizar las mejoras mencionadas anteriormente.
¡Háganos saber lo que piensa de nuestros planes! ¿Cómo nos comparamos con su propia organización y otros servicios en los que confía? ¿Hay más que podamos o deberíamos hacer? ¿Tiene algún consejo para nosotros basado en su propia experiencia? Contáctenos con sus comentarios y sugerencias!
