Wieloetapowa migracja infrastruktury Capsim do chmury AWS

Capsim to amerykańska spółka działająca od ponad 20 lat w branży szkoleń biznesowych opartych na realistycznych grach biznesowych.  Główną działalnością firmy jest wdrażanie skomplikowanych symulacji biznesowych pozwalających podnosić użytkownikom swoje kompetencje menadżerskie. Oferta Capsim skierowana jest do uczelni wyższych, firm i korporacji na całym świecie. Chęć wdrożenia nowych rozwiązań oraz rozwój i skalowanie dotychczasowych narzędzi spowodował konieczność zmiany infrastruktury w ramach której funkcjonowała aplikacja Klienta.

Specyfika infrastruktury

Zaprojektowana i uruchomiona infrastruktura Capsim składa się z dwóch warstw aplikacyjnych (front-end, middle-tier), warstwy backend (DB), cache oraz dodatkowej warstwy NFS. Warstwy front-end i middle-tier działają w oparciu o Auto Scaling Groups (ASG), do których ruch jest kierowany za pośrednictwem Elastic Load Balancer’ów. Takie podejście zapewnia elastyczne skalowanie zasobów, dostosowane do obecnego ruchu i obciążenia infrastruktury generowanego przez użytkowników.

Dostęp do infrastruktury nie jest publiczny i odbywa się wyłącznie poprzez tunel VPN (site-to-site IPsec). Dostęp do instancji możliwy jest również przez AWS Session Managera, z poziomu konsoli AWS.

Na potrzeby realizacji migracji uzyskaliśmy również dostęp do serwerów deweloperskich Klienta, utrzymywanych w zewnętrznej serwerowni i fizycznych pomieszczeniach należących do Capsim.        

Warstwa Frontend

Instancje uruchamiane są w ramach ASG z użyciem przygotowanych  Launch Template, a używane w nich obrazy AMI, zawierające preinstalowane oprogramowanie Adobe ColdFusion, budowane są w oparciu o dedykowane do tego  instancje EC2. Warstwa ta używa Amazon Elasticache (Redis) do przechowywania sesji użytkowników. Oprócz CloudFusion, na serwerach znajduje się IIS który odpowiada za proxy do aplikacji CF, przez co aplikacje te nie są bezpośrednio dostępne – umożliwia to zastosowanie dodatkowych narzędzi security w tej warstwie. Jednocześnie, aplikacje NodeJS, które również występują w ramach tej warstwy, zostały odseparowane i uruchamiane są w ramach osobnej grupy (ASG). Takie podejście pozwoliło na uzyskanie elastycznego skalowania zasobów, które są obecnie w użyciu, bez zbędnego skalowania całej warstwy front-end.

Warstwa middle-tier

Podobnie jak w warstwie front-end instancje uruchamiane są w oparciu o ASG i Launch Template. W ramach tej warstwy zainstalowaliśmy technologie Java, a także  PDFcreator który z biegiem czasu przeniesiony został na osobną instancję i dostępny jest publicznie dla Klientów Capsim, a ruch kierowany jest przez AWS Load Balancer.

Warstwa backend

W tej warstwie uruchomiony jest klaster bazodanowy (HA), który jest źródłem danych dla wszystkich aplikacji.

Charakterystyka migracji

Część elementów aplikacji którą mieliśmy migrować, została napisana wiele lat temu, co za tym idzie, posiadała duży dług technologiczny, który uniemożliwił nam zastosowanie standardowych rozwiązań. Ponadto większość elementów aplikacji okazała się mało elastyczna. Okazało się również, że w ciągu roku mogliśmy uzyskać dostęp jedynie do trzech okien serwisowych, których czas trwania wynosił maksymalnie 6 godzin, co w połączeniu z limitowaną przepustowością łącza w serwerowni klienta sprawiało, że niemożliwe było zrealizowanie migracji w ramach wyłącznie jednego okna serwisowego – aplikacja składa się bowiem z dziesiątek baz danych SQL z których pojedyncze, swoim rozmiarem przekraczały 800 GB!

Kluczowym problemem związanym z migracją baz Capsim, okazała się synchronizacja danych. Tradycyjna replikacja, ze względu na specyfikę aplikacji oraz samych baz danych nie wchodziła w grę. Wyjściem z tej sytuacji było podzielenie procesu na dwa etapy. W pierwszym etapie migracja miała charakter lift and shift, a dopiero później, w drugiej części przenieśliśmy wszystkie zasoby Klienta do Amazon RDS.

Pierwsza faza polegała na dodaniu kolejnego serwera  do klastra bazodanowego, który w procesie Log Shippingu, co określony interwał czasu, wysyłał zmiany na dołączony serwer. W ten sposób zagwarantowaliśmy sobie  synchronizację danych niemal w trybie rzeczywistym oraz czas na aktualizację.   W drugiej fazie dokonaliśmy migracji z pośredniego serwera SQL (EC2) do usługi RDS. Krok pośredni, który został zastosowany, pozwolił na znaczne przyspieszenie migracji danych (w porównaniu do bezpośredniej migracji do RDS), według szacunków o około 70%. Wszystko dzięki zastosowaniu backbone AWS (network) oraz dostępu do funkcji umożliwiających import danych do RDS bezpośrednio z S3, do którego została wykonana wyeksportowana kopia danych. Zorganizowanie całej operacji zajęło nam niemal rok, a sama migracja, zgodnie z wymaganiami Klienta – niespełna 6 godzin.

Podsumowanie

Dla Capsim zrealizowaliśmy skomplikowaną, kilkuetapową migrację infrastruktury posiadającej dług technologiczny. Wsparliśmy proces unowocześniania stacku technologicznego Klienta, a całą realizację udało nam się zmieścić w zaledwie trzech kilkugodzinnych slotach, dostępnych w przeciągu całego roku. Po migracji Klient dysponuje nowoczesną, skalowalną i wysoce dostępną infrastrukturą. Obecnie wspólnie pracujemy nad kolejnym etapem ewolucji - zamianą blue green deploymentu, opartego o ASG, na rozwiązanie oparte o kontenery.

PYTANIA? SKONTAKTUJ SIĘ Z NAMI

Zobacz również:

Migracja i budowa infrastruktury w AWS sla SimpleMinine.net

Wdrożenienarzędzia automatyzującego budowę kolejnych infrastruktur dla firmy Flying Bisons

Wdrożenie infrastruktury chmurowej dla Magic Commerce, opartej o mikroserwisy, kontenery i podejście IaC

Ogólnokrajowe call center, oparte na chmurze AWS