IT@BANK 2021 | TECHNOLOGIE – BLUESOFT | Bank przed wyborem scenariusza wykorzystania chmury

Michał Smereczyński
Azure Lead Architect, Pion usług dla sektora bankowego i finansowego, Bluesoft

Biorąc pod uwagę charakterystykę pracy instytucji finansowych, zmienność danych, a także obłożenie zespołów zarządzających nimi i ich przepływami – szczególnie w dobie pandemii i wzmożonego zapotrzebowania na usługi sektora bankowego – żaden z wymienionych kroków nie jest łatwy i szybki do przejścia.

Rynek usług dostarczanych w modelu chmury publicznej – budowany przez sprawdzonych przez banki dostawców technologii, takich jak firma Microsoft – sprawił, że nie tylko pojawiły się nowe narzędzia, tworzone z myślą o wsparciu instytucji finansowych w przejściu tych kroków, ale sprawił także, że wykształciła się zupełnie nowa gałąź branży technologicznej, wspierająca instytucje w adopcji nowego dla nich modelu przechowywania i przetwarzania danych.

Doświadczony partner

Rolą takiego partnera wspierającego bank, jest dogłębna znajomość rekomendowanej platformy chmurowej – jej możliwości, ograniczeń i skuteczności w różnych scenariuszach wykorzystania. Partner wspiera tym samym bank w realizacji założonych scenariuszy, które często obejmują podjęcie decyzji, które dane można przetwarzać w chmurze publicznej, a których nie można. Partner często także uświadamia bankowi, że ten wybór nie jest konieczny, jeśli scenariusz, który ma być realizowany przewiduje wykorzystanie tylko danych publicznych lub połączenie tychże z danymi, które zostały poddane procesowi anonimizacji (co oznacza, że w efekcie przetwarzania wstępnego nie jest możliwe ustalenie, jakiej osoby fizycznej dotyczą dane) lub pseudonimizacji (co oznacza przetwarzanie wstępne danych w taki sposób, aby nie można ich było powiązać z konkretną osobą bez użycia dodatkowych informacji).

Wykorzystywanie chmury

Scenariusze wykorzystania chmury publicznej w banku lub innej instytucji finansowej można pogrupować na wiele sposobów. Jednym z nich jest podział według popularności oferowanych dziś rozwiązań – popularności, która jest pochodną szerokiego wachlarza usług dostępnych na wybranej platformie chmury publicznej i względnie niskiego progu wejścia w ewaluację tych rozwiązań. Do grupy najpopularniejszych scenariuszy należą przede wszystkim hurtownie danych relacyjnych i nierelacyjnych oraz platforma analityczna służąca do konsumpcji tych danych – w przypadku chmury publicznej Microsoft Azure jest to scenariusz, który może być zrealizowany przy użyciu zaledwie dwóch w pełni zarządzanych przez dostawcę usług (bez konieczności uruchamiania serwerów i zarządzania nimi w jakikolwiek sposób) – Azure Synapse Analytics oraz Power BI.

Kolejną grupą scenariuszy są scenariusze migracyjne dla infrastruktury (maszyn fizycznych i wirtualnych) z centrum danych banku do chmury publicznej. To rozwiązanie bardziej angażujące dla samego banku, ale na ogół dyktowane jest jasnymi wskaźnikami ekonomicznymi lub technologicznymi. O ile wskaźnik ekonomiczny wymaga głębszej analizy, o tyle wskaźnik technologiczny potrafi być zerojedynkowy – tu za przykład posłużyć może wsparcie dla systemów operacyjnych i baz danych, które dziś jest już możliwe tylko w chmurze Microsoft Azure – np. Windows Server 2008 czy SQL Server 2008.

Ostatnią grupą scenariuszy, a zarazem tą, na której chcemy się skupić najbardziej, jest grupa, w której banki rzadziej szukają opcji adopcji chmury publicznej. Rok 2021 pokazał nam, że ta sytuacja się zmienia i to właśnie branża finansowa jest tą, która wraca ze scenariuszami wykorzystania infrastruktury chmury publicznej do jej właściwych korzeni – wynajmu mocy obliczeniowej w perspektywie planowanych i nieplanowanych wzrostów zapotrzebowania na obliczenia. Flagowymi przykładami realizacji tego typu scenariuszy są obliczenia dotyczące analizy i oceny ryzyka dla poszczególnych usług lub całego rynku oraz analiza transakcji i wykrywanie tych, które klasyfikowane powinny być jako podejrzane.

Realizowanie założeń

Oba wspomniane scenariusze mogą być realizowane w warstwie programowej na wiele sposobów. W niektórych przypadkach będzie to dedykowane oprogramowanie uznanego w branży producenta, a w innych będzie to rozwiązanie zbudowane w oparciu o popularny, otwarto-źródłowy stos technologiczny. Jednakże niemal zawsze łączyć się one będą w takich punktach wspólnych, jak infrastruktura (na ogół klaster obliczeniowy złożony z N maszyn) i model matematyczny, który moc obliczeniową N maszyn przekłada na to, co jest w tym procesie najważniejsze – na wynik. Wynik ten jest znowu na ogół opatrzony dwoma parametrami – dokładnością/jakością i sprawnością jego otrzymywania (to znaczy, ile czasu musimy na niego czekać). Oba te parametry zależą w równej mierze od skali infrastruktury, jaką mamy do dyspozycji, ilości danych, jakie mamy do dyspozycji i algorytmu (modelu matematycznego, który odpowiednio umie wykorzystać dwie poprzednie składowe).

O wątpliwościach w dziedzinie danych wspomnieliśmy na początku – ich klasyfikacja może wymagać anonimizacji lub pseudonimizacji w procesie wstępnego przygotowania do przetwarzania w chmurze. Jednak dane wykorzystywane do oceny ryzyka są w dużej mierze danymi publicznymi lub nie są klasyfikowane jako dane niemożliwe do przetwarzania w chmurze. Niezależnie od procesu klasyfikacji i wstępnego przetwarzania, dane muszą trafić do magazynu w chmurze, jeśli chcemy je przetwarzać z dostateczną dla dużej skali wydajnością.

Pierwszym etapem tej drogi będzie warstwa transportu z centrum danych banku do chmury i nie jest to ścieżka jednej opcji. Platforma Microsoft Azure daje nam wybór opcji, które powinny zaspokoić najbardziej wymagające działy bezpieczeństwa – od zaszyfrowanego z użyciem TLS transferu za pośrednictwem publicznego internetu, przez tunel VPN, po dedykowane łącze telekomunikacyjne pomiędzy centrum danych banku i siecią Microsoft w wybranym regionie geograficznym, czyli usługę Azure ExpressRoute działającą z pominięciem publicznych łączy internetowych.

Drugi etap to składowanie. W zależności od architektury rozwiązania, może to być relacyjna baza danych (np. Azure SQL Database, Azure SQL DB for PostgreSQL/MySQL/MariaDB lub dowolna, inna baza danych, której uruchomienie jest możliwe na platformie Azure w formie maszyn wirtualnych), baza nierelacyjna, jak Azure CosmosDB (w tym zgodna z MongoDB) czy magazyn danych – plikowy Azure Files ze wsparciem dla NFS i SMB, obiektowy Azure Blob Storage ze wsparciem dla REST i NFS czy Azure Data Lake ze wsparciem dla HDFS.

Trzeci etap to przetwarzanie danych. W celu zminimalizowania kosztów, instytucja może zdecydować się na posiadanie i zarządzanie tylko minimalną liczbą obliczeniowych węzłów roboczych, aby spełnić minimalne wymagania, gdy zapotrzebowanie jest niskie. Zadania obliczeń rozproszonych o wysokim zapotrzebowaniu na moc obliczeniową (w celu przyspieszenia wykonania obliczeń i/lub zwiększenia ich dokładności) można wypchnąć na serwery o wysokiej wydajności na platformie Azure, elastycznie skalując w górę (niemal bez limitu) i w dół (do zera) zgodnie z zapotrzebowaniem na obciążenie. Usługa Azure Batch pozwala na odłączenie się od warstwy zarządzania tymi serwerami – nie jest to konieczne z uwagi na krótki cykl życia maszyn (wyłącznie na potrzeby obliczeń) – i skupienie się na przygotowaniu zadań obliczeniowych do wykonania. Komunikacja z usługą Azure Batch może być wykonywana programowo i może być przygotowana jako rozszerzenie do używanego oprogramowania. Azure Batch nie jest usługą dedykowaną obliczeniom, lecz orkiestracji uruchamiania tego typu zadań – oznacza to, że binaria lub całe stosy wykorzystywane aktualnie w banku mogą być z dużą dozą prawdopodobieństwa zaadoptowane do usługi Azure Batch. Najważniejszą cechą tego modelu dostarczania mocy obliczeniowej jest fakt, że płacimy za każdą zakończoną minutę działania każdego wykorzystanego procesora – możemy wykorzystać ich kilkanaście czy kilkadziesiąt przez wiele godzin albo dziesiątki tysięcy przez kilka minut.