Czy chcesz dowiedzieć się, jak organizujemy ORCID Rejestr i interfejsy API? Chcesz wiedzieć, jak radzimy sobie z wysoką dostępnością, skalowalnością i odtwarzaniem w przypadku awarii? Jeśli tak, to ten wpis jest dla Ciebie!
Obsługujemy osiem milionów odsłon każdego miesiąca w serwisie ORCID Registry, ale większość naszego ruchu pochodzi z interfejsów API, które obecnie otrzymują ponad 100 milionów odsłon miesięcznie. Jedną z naszych podstawowych strategii jest inwestowanie w rozwój solidnej infrastruktury informatycznej, dlatego musimy mieć pewność, że technologia, której używamy do obsługi tego zastosowania, jest niezawodna i bezpieczna.
Rejestr i reszta witryny na orcid.org są kierowane przez sieć dostarczania treści (CDN) — dostawcę usług w chmurze, który ma ponad 150 centrów danych na całym świecie. Kiedy Twoja przeglądarka łączy się z orcid.org, statyczne części witryny są obsługiwane z lokalnego centrum danych w Twojej okolicy, aby umożliwić szybsze ładowanie.
CDN ma kilka innych przydatnych funkcji, takich jak ochrona przed rozproszone ataki typu odmowa usługi (DDoS)oraz skanowanie bezpieczeństwa w czasie rzeczywistym pod kątem zagrożeń hakerskich.
Strony Rejestru są hostowane w naszym głównym centrum danych, gdzie ruch jest równoważony w klastrze serwerów aplikacji, podczas gdy dane Rejestru są przechowywane w klastrze trzech potężnych serwerów baz danych w zaszyfrowanych systemach plików. Jedna to główna baza danych, w której dokonywane są aktualizacje, a dwie to serwery replik, które otrzymują kopię danych w czasie rzeczywistym. Serwery replik są używane do większości operacji „odczytu” rejestru i interfejsów API, ale są również serwerami rezerwowymi, co oznacza, że w przypadku awarii mogą zostać awansowane na serwery nadrzędne.
Mamy asortyment innych serwerów obsługujących system produkcyjny, które tasują dane w celu tworzenia indeksów wyszukiwania, przechowują aktualny zrzut danych publicznych w innym centrum danych i wykonują zaplanowane zadania, takie jak przypomnienia e-mailowe.
Dwa razy dziennie automatycznie tworzymy kopię zapasową bazy danych, szyfrujemy zrzut i przesyłamy go do innego dostawcy usług w chmurze na innym kontynencie, abyśmy w przypadku awarii w naszym głównym centrum danych mogli użyć kopii zapasowej bazy danych do przywrócenia systemu. Regularnie testujemy, czy ten proces działa, korzystając z tymczasowego serwera offline.
To jest solidna podstawa. Jednakże, ORCiD stale się rozwija i w coraz większym stopniu polegamy na nas jako na części infrastruktury informacyjnej badań. Musimy więc zrobić więcej, aby społeczność mogła nadal na nas polegać.
Co chcielibyśmy poprawić?
Chcielibyśmy mieć serwery aplikacji i repliki baz danych w wielu lokalizacjach, abyśmy nie musieli polegać na dość długim procesie przywracania bazy danych ani tracić danych od ostatniej kopii zapasowej. Chcielibyśmy móc dostarczać nowe serwery w ciągu kilku minut, a nie godzin, w przypadku nagłego wzrostu zapotrzebowania.
Rozważamy oddzielenie najbardziej krytycznych części systemu, takich jak rejestracja, logowanie i autoryzacja, do izolowanego systemu, a także chcemy mieć pewność, że problemy z publicznym ruchem API nie będą miały wpływu na Rejestr i API członków.
Chcielibyśmy też bardziej elastycznej architektury wykorzystującej standardowe technologie branżowe, takie jak Docker containers i Kubernetes, co pomoże nam wprowadzić ulepszenia, o których mowa powyżej.
Daj nam znać, co myślisz o naszych planach! Jak wypadamy w porównaniu z Twoją własną organizacją i innymi usługami, na których polegasz? Czy jest coś więcej, co moglibyśmy lub powinniśmy zrobić? Czy masz dla nas jakąś radę opartą na własnym doświadczeniu? Kontakt z twoim wkładem i opinią!