Вам интересно узнать, как мы проводим ORCID Реестр и API? Хотели бы знать, как мы справляемся с высокой доступностью, масштабируемостью и восстановлением в случае аварии? Если да, то этот пост для вас!
Каждый месяц мы обрабатываем восемь миллионов просмотров страниц ORCID Registry, но основная часть нашего трафика приходится на API, которые в настоящее время получают более 100 миллионов обращений в месяц. Одна из наших основных стратегий - инвестировать в развитие надежной информационной инфраструктуры, поэтому мы должны быть уверены, что технология, которую мы используем для поддержки такого использования, является надежной и безопасной.
Реестр и остальная часть веб-сайта на orcid.org маршрутизируются через сеть доставки контента (CDN) - поставщика облачных услуг, который имеет более 150 центров обработки данных по всему миру. Когда ваш браузер подключается к orcid.org, статические части сайта обслуживаются из ближайшего к вам локального центра обработки данных, чтобы ускорить загрузку.
У CDN есть и другие полезные функции, такие как защита от распределенные атаки типа "отказ в обслуживании" (DDoS), а также сканирование безопасности в режиме реального времени на предмет угроз взлома.
Страницы реестра размещены в нашем главном центре обработки данных, где балансировка нагрузки осуществляется по кластеру серверов приложений, а данные реестра хранятся в кластере из трех мощных серверов баз данных в зашифрованных файловых системах. Одна из них - это основная база данных, в которой выполняются обновления, а два - это серверы-реплики, которые получают копию данных в режиме реального времени. Серверы-реплики используются для большинства операций «чтения» реестра и API-интерфейсов, но также являются серверами горячего резервирования, что означает, что они могут быть назначены главными в случае сбоя.
У нас есть ряд других серверов, поддерживающих производственную систему, которые перемешивают данные для построения поисковых индексов, поддерживают актуальный дамп общедоступных данных в другом центре обработки данных и запускают запланированные задачи, такие как напоминания по электронной почте.
Мы автоматически делаем резервную копию базы данных два раза в день, шифруем дамп и отправляем его другому поставщику облачных услуг на другом континенте, чтобы в случае аварии в нашем основном центре обработки данных мы могли использовать резервную копию базы данных для восстановления системы. Мы регулярно проверяем, работает ли этот процесс, используя временный автономный сервер.
Это прочная основа. Тем не мение, ORCiD продолжает расти, и мы все больше полагаемся на нашу исследовательскую информационную инфраструктуру. Поэтому нам нужно делать больше, чтобы сообщество могло и дальше зависеть от нас.
Что бы мы хотели улучшить?
Мы хотели бы иметь серверы приложений и реплики базы данных в нескольких местах, чтобы нам не приходилось полагаться на довольно длительный процесс восстановления базы данных или терять данные с момента последнего резервного копирования. Мы хотели бы иметь возможность предоставлять новые серверы за считанные минуты, а не часы, в случае внезапного увеличения спроса.
Мы рассматриваем возможность разделения наиболее важных частей системы, таких как регистрация, вход и авторизация, в изолированную систему, а также хотели бы убедиться, что проблемы с трафиком общедоступных API не влияют на API реестра и участников.
И нам нужна более гибкая архитектура с использованием стандартных отраслевых технологий, таких как Докерные контейнеры и Kubernetes, что поможет нам внести вышеупомянутые улучшения.
Сообщите нам, что вы думаете о наших планах! Как нас сравнить с вашей собственной организацией и другими услугами, на которые вы полагаетесь? Есть ли что-то еще, что мы можем или должны сделать? Вы можете что-нибудь посоветовать нам, основываясь на собственном опыте? Контакты с вашим вкладом и отзывами!
