Ogólnokrajowe call center, oparte na chmurze AWS
Na zlecenie jednego z naszych Klientów, stworzyliśmy system call center o zasięgu krajowym, mogący obsłużyć do 50 000 połączeń w ciągu godziny, którego celem było przekazanie wskazanej przez Klienta informacji. Pierwszą działającą wersję systemu udostępniliśmy już po kilkunastu godzinach od startu projektu, wykorzystując do tego środowisko chmurowe Amazon Web Services ze szczególnym uwzględnieniem usługi AWS Connect oraz AWS Lambda.
Problem
Organizacja naszego Klienta, wraz z podległymi sobie strukturami, stanęły przed wyzwaniem wdrożenia ogólnopolskich rozwiązań informatycznych dla wszystkich mieszkańców Kraju. Klient potrzebował natychmiastowego uruchomienia w pełni zautomatyzowanego call center o dużej wydajności, które mogłoby zastąpić ręczne aktywności informacyjne, wykonywane dotąd przez pracowników struktur podległych Zleceniodawcy oraz inne czynności dotąd niemożliwe do realizacji ze względu na ograniczenia czasowe, kadrowe i technologiczne.
Kluczowe wymagania klienta sprowadzały się do następujących funkcji:
- Dzwonienia do przekazywanej codziennie bazy numerów z określonym komunikatem według konkretnego schematu zachowania i ponawiania,
- Automatyzacji procesu wysyłania instrukcji postępowania dla wybranych osób
- możliwości szybkiego wdrożenia rozwiązania (24h) oraz zmian ścieżek w przeciągu zaledwie kilka godzin,
- Raportowania i analityki danych na bazie wykonanych połączeń i odpowiedzi zebranych od pacjentów.
Wdrożenie
Hostersi podjęli się trudnego zadania stworzenia systemu call center w oparciu o infrastrukturę i potężne narzędzia chmury Amazon Web Services ze szczególnym uwzględnieniem usługi AWS Lambda i AWS Connect. Dzięki dostępności narzędzi AWS, wykonaliśmy wdrożenie w ciągu kilkunastu godzin, dopracowując je i coraz bardziej automatyzując w ramach kolejnych iteracji. Pozwoliło to na błyskawiczne odciążenie pracowników Klienta i działania informacyjne na niespotykaną dotąd skalę. Zaprojektowane call center pozwoliło również na dodatkową identyfikację osób które potencjalnie mogły być zainteresowane informacjami udostępnianymi przez Zleceniodawcę.
Opis architektury i działania systemu
Rozwiązanie zostało w całości stworzone w oparciu o Amazon Web Services i architekturę “serverless”, czyli zbudowane na bazie gotowych komponentów i serwisów chmurowych, działających w modelu PaaS. Mechanizmy „serverless” umożliwiły implementację i wdrożenie rozwiązania w ciągu zaledwie kilkunastu godzin, a uzyskanie pełnej automatyzacji przepływów oraz procesów w aplikacji zajęło kilka tygodni. Po ok. 2-3 tygodniach system stał się właściwie „samoobsługowy”, a jego kontrola sprowadzała się do wyrywkowego sprawdzenia prawidłowości przetwarzanych danych osób, do których wykonywane były połączenia telefoniczne z konkretnymi informacjami. Automat, stworzony na bazie AWS Connect, podczas przekazywania komunikatu głosowego także zadawał pytania swojemu rozmówcy, a wybrane przez niego opcje były rejestrowane i trafiały do bazy danych, stanowiąc element informacji w generowanych raportach. Warto wspomnieć, iż zmiany treści komunikatów i ich wdrożenie na środowisku produkcyjnym zajmowało kilka minut, również zmiany w logice ich prezentowania to zwykle kwestia kilkunastu/kilkudziesięciu minut.
Wydajność
W pierwszych tygodniach od uruchomienia projektu, to właśnie wydajność okazała się jednym z kluczowych wyzwań dla całego systemu. Wysokie oczekiwania względem ilości wykonywanych połączeń bardzo szybko doprowadziły do sytuacji, w której dotarliśmy do wartości granicznych standardowych limitów dla konta AWS w zakresie jednoczesnych wywołań funkcji AWS Lambda oraz jednocześnie wykonywanych połączeń dla Amazon Connect. Limity te, jako Advanced Consulting Partnerowi Amazon Web Services, udało nam się zwiększyć do następujących wartości:
- 5 000 - limit jednoczesnych wywołań funkcji Lambda
- 2 700 - limit jednocześnie wykonywanych połączeń dla Amazon Connect
Dzięki zwiększeniu limitów, aplikacja była w stanie obsłużyć 2700 jednoczesnych połączeń. Zapotrzebowanie nie było jednak aż tak duże i w praktyce system działał średnio przy 400-800 jednoczesnych połączeniach. Przy takiej ilości jednoczesnych połączeń oraz długości schematu zdefiniowanego w Amazon Connect obsługiwaliśmy w przeciągu godziny średnio około 10 000 – 20 000 osób. Uruchomiona infrastruktura pozwalała w naszym przypadku na obsłużenie maksymalnie 50 000 osób w ciągu godziny.
Implementacja mikroserwisów jako funkcje AWS Lambda
Mikroserwisy zostały zaimplementowane jako funkcje AWS Lambda oparte na zdarzeniach („event-driven”) lub uruchamiane według określonego harmonogramu („scheduled”, „scheduledriven”). Źródłem zdarzeń był najczęściej „contact flow” serwisu Amazon Connect lub serwis Step Functions. Funkcje AWS Lambda realizowały kluczową logikę biznesową systemu w tym:
- Sterowały wykonaniem „contact-flow” serwisu Amazon Connect, czyli procesem dzwonienia do klientów, na bazie danych pobranych z bazy danych (DynamoDB)
- Rejestrowały odpowiedzi klientów z Amazon Connect, które były podstawą do dalszego przetwarzania danych w postaci generowanych raportów bądź wiązały się z dodatkową obsługą klientów np. wykonaniem ponownego dzwonienia.
- Przetwarzały „surowe” dane dostarczane od Zleceniodawcy i transformowały je do postaci wymaganej przez mechanizm dzwonienia
- Generowały raporty na bazie zebranych od klientów odpowiedzi
- Klient nie zgłaszał żadnych obiekcji czy wątpliwości związanych z wykorzystaniem AWS Lambda i podejścia „serverless”.
Bezpieczeństwo
Całe rozwiązanie zostało bardzo „hermetyczne” osadzone w środowisku chmury AWS – nie są bowiem wystawiane żadne zewnętrzne końcówki (tzw. endpoints), które należałoby szczególnie chronić przed atakami. Jako, że rozwiązanie bazuje na architekturze „serverless”, cały wysiłek zarządzania fizyczną infrastrukturą, warstwą wirtualizacji, aktualizacjami systemu operacyjnego spoczywa na dostawcy chmury. Wszystkie dane w spoczynku („at rest”), jak i podczas procesu ich kopiowania, czy przesyłania („in transit”) z lokalnego centrum danych Zleceniodawcy do AWSa są szyfrowane. Szczególnie chroniony jest sam dostęp do środowiska chmurowego, do tzw. konta AWS – tylko wybrane osoby z odpowiednimi uprawnieniami mogą uzyskać do niego dostęp, ale także tylko po uprzednim dwuskładnikowym uwierzytelnieniu („MFA”) z wykorzystaniem fizycznego bądź wirtualnego urządzenia.
Metryki oraz wykrywanie problemów
Dla wykorzystywanych przez aplikację usług przygotowany został szereg metryk oraz alarmów na nich bazujących. Stworzony został dashboard w usłudze Amazon Cloudwatch, który pozwolił na obserwację wszystkich najważniejszych metryk w jednym miejscu. Poniżej przykład metryk wykorzystanych dla usługi Connect dzięki którym możliwa jest obserwacja ilości aktualnie wykonywanych połączeń oraz przygotowanie alarmu na wypadek przekroczenia limitu ustawionego dla konta AWS.
W przypadku funkcji uruchomionych w ramach usługi AWS Lambda wykorzystano przykładowo metryki, które pozwalały na obserwację wywołań funkcji oraz detekcję ewentualnych błędów z ich wykonywaniem.
Niezwłoczna reakcja na problemy z działaniem aplikacji i mocy wykorzystywanych serwisów była możliwa dzięki konfiguracji alarmów w usłudze Amazon Cloudwatch oraz wysyłaniu notyfikacji o ich wystąpieniu za pośrednictwem usługi Amazon SNS. Przykładem takiego alarmu może być przypadek, w którym funkcja AWS Lambda nie wykonywała się prawidłowo, a jej kolejne wywołania kończyły się błędem.
Schemat infrastruktury
Rezultaty
Dzięki kompetencjom zespołu Hostersi oraz wykorzystaniu środowiska Amazon Web Services, pierwszą działającą wersję systemu, udało się uruchomić w przeciągu kilkunastu godzin od startu projektu. Uruchomiona infrastruktura pozwala na obsłużenie 50 000 osób w ciągu godziny. Całe rozwiązanie jest wysoce bezpieczne, bo w całości osadzone w chmurze AWS. Infrastruktura opiera się na tzw. „serverless”, co oznacza, że cały wysiłek zarządzania fizyczną infrastrukturą, warstwą wirtualizacji, aktualizacjami systemu operacyjnego spoczywa na dostawcy chmury. Dla naszego klienta, oznacza to brak konieczności dodatkowych działań i angażowania zasobów do prawidłowego działania infrastruktury, bo wszystkie akcje dzieją się całkowicie automatycznie.
44-200 Rybnik
Poland
REGON: 240692928
KRS: 275333
