Migracja samodzielnie zarządzanego brokera wiadomości do Amazon SQS

Amazon Payment Services to dostawca usług płatniczych, który działa w regionach geograficznych Bliskiego Wschodu i Afryki Północnej (MENA).

Jego misją jest zapewnienie firmom internetowym przystępnych cenowo i godnych zaufania usług płatniczych. Gwarantuje chronioną bramkę płatności online, która jest prosta i bezpieczna w użyciu.

Amazon Payment Services posiada regionalnych ekspertów w dziedzinie technologii przetwarzania płatności w ośmiu krajach w regionach Rady Współpracy Państw Zatoki Perskiej (GCC) i Lewantu. Oferuje rozwiązania dostosowane do firm w ich walucie międzynarodowej i lokalnej. Nieustannie ulepsza i skaluje swoje systemy, aby zapewnić możliwości przetwarzania w czasie zbliżonym do rzeczywistego. Wszystko, co robi, ma na celu stworzenie bezpiecznych, niezawodnych i satysfakcjonujących sieci płatniczych, które łączą Bliski Wschód z resztą świata.

Przypadek użycia kolejek komunikatów

Firma zbudowała wysokowydajny i elastyczny system kolejkowy do wysyłania wiadomości do klientów. Wdrożenie twórców opierało się na samodzielnie zarządzanym klastrze RabbitMQ i konsumentach. Konsument to oprogramowanie, które subskrybuje nazwę tematu w kolejce. Po zasubskrybowaniu każda wiadomość opublikowana w kolejce oznaczona tą samą nazwą tematu zostanie odebrana przez konsumenta do przetworzenia. Zarówno klaster, jak i konsumenci zostali wdrożeni w instancjach Amazon Elastic Compute Cloud (Amazon EC2). Wraz z rozwojem działalności twórcy stanęli w obliczu wyzwań związanych z istniejącą architekturą.

Wyzwania związane z architekturą kolejek wiadomości

Zarządzanie klastrem RabbitMQ z jego węzłami wdrożonymi w instancjach Amazon EC2 wiązało się z pewnymi obciążeniami operacyjnymi. Radzenie sobie z płatnościami na dużą skalę, zarządzanie kolejkami, wydajnością i dostępnością klastra RabbitMQ wprowadziło istotne wyzwania:

• Managing durability with RabbitMQ queues – gdy wiadomości są umieszczane w kolejce, są utrwalane i przetrwają restarty serwera. Jednak podczas okresu konserwacji mogą zostać utracone, ponieważ używano konfiguracji samozarządzającej.
• Back-pressure mechanism – w konfiguracji brakowało mechanizmu przeciwciśnienia, co skutkowało zalaniem klientów ogromną liczbą wiadomości w godzinach szczytu. Wszystkie wiadomości opublikowane w kolejce były wysyłane w tym samym czasie.
• Customer business requirements – wielu klientów ma wymagania biznesowe dotyczące opóźniania dostarczanych wiadomości o określony czas, aby obsłużyć ich przepływ. Dotychczasowa architektura nie obsługiwała tego opóźnienia.
• Retries – należało wdrożyć strategię wycofywania, aby rozłożyć wielokrotne ponowienia dla tymczasowo nieudanych wiadomości.

Poprzednia architektura przedstawiona na rysunku nr 1 była w stanie przetworzyć dużą ilość wiadomości w rozsądnym czasie dostarczenia. Jednak gdy kolejka komunikatów została zbudowana z powodu awarii sieci po stronie klienta, wpłynęło to na opóźnienie całego przepływu. Wymagało to ręcznego skalowania kolejek, co zwiększyło wysiłek ludzki, czas i koszty ogólne. Ze względu na to, że firma nadal się rozwijała, konieczne było utrzymanie ścisłej umowy dotyczącej poziomu usług (SLA).

Używanie Amazon SQS jako szkieletu komunikatów.

Główny zespół Amazon Payment Services zaprojektował rozwiązanie do korzystania z Amazon Simple Queue Service (SQS) z AWS Fargate (zobacz rysunek nr 2) Amazon SQS to w pełni zarządzana usługa kolejkowania wiadomości, która umożliwia klientom rozdzielenie i skalowanie mikrousług, systemów rozproszonych i bezserwerowych aplikacji. Jest to wysoce skalowalna, niezawodna i trwała usługa kolejkowania wiadomości, która zmniejsza złożoność i koszty ogólne związane z zarządzaniem i obsługą oprogramowania pośredniczącego zorientowanego na wiadomości.

Amazon SQS oferuje dwa rodzaje kolejek wiadomości. Standardowe kolejki SQS zapewniają maksymalną przepustowość, składanie zamówień typu best-effort i co najmniej jednorazową dostawę. Kolejki SQS FIFO zapewniają, że komunikaty są przetwarzane dokładnie raz, w dokładnie takiej kolejności, w jakiej zostały wysłane. W tej aplikacji wykorzystano kolejki SQS FIFO.

W kolejkach SQS FIFO komunikaty są przechowywane w partycjach (partycja to przydział pamięci replikowany w wielu strefach dostępności w regionie AWS). Dzięki dystrybucji wiadomości za pomocą identyfikatorów grup wiadomości twórcy byli w stanie osiągnąć lepszą optymalizację i wykorzystanie partycji dla kolejek Amazon SQS. Możliwe byłoby zaoferowanie wyższej dostępności, skalowalności i przepustowości przetwarzania wiadomości od konsumentów.

Ta bezserwerowa architektura zapewniła lepsze opcje skalowania dla oferowanych usług przetwarzania płatności. Pomaga to zarządzać szczytowymi zdarzeniami w regionie geograficznym MENA dla klientów bez potrzeby zapewniania pojemności. Architektura bezserwerowa pomaga w obniżeniu kosztów operacyjnych, ponieważ płaci się tylko za korzystanie z usług. Celem przy tworzeniu tej początkowej architektury było osiągnięcie spójności, skalowalności, przystępności cenowej, bezpieczeństwa i wysokiej wydajności.

Jak Amazon SQS odpowiedział na wskazane potrzeby

Migracja do Amazon SQS pomogła spełnić wiele wymagań i doprowadziła do bardziej niezawodnej usługi. Niektóre z głównych problemów obejmowały:

Utrata wiadomości podczas przerw konserwacyjnych

Przeprowadzając ręczne aktualizacje RabbitMQ i hostingowego systemu operacyjnego, czasami napotykano przestoje. Dzięki zastosowaniu Amazon SQS infrastruktura przesyłania wiadomości została zautomatyzowana, co zmniejszyło potrzebę wykonywania czynności konserwacyjnych.

Obsługa współbieżności

Różni klienci inaczej traktują wiadomości. Potrzebowano więc sposobu na dostosowanie współbieżności przez klienta. Dzięki identyfikatorowi grupy wiadomości SQS w kolejkach FIFO możliwe było użycie tagu, który grupuje wiadomości razem. Wiadomości należące do tej samej grupy wiadomości są zawsze przetwarzane jedna po drugiej, w ścisłej kolejności względem grupy wiadomości. Korzystając z tej funkcji i spójnego algorytmu haszującego, twórcy byli w stanie ograniczyć liczbę jednoczesnych wiadomości wysyłanych do klienta.

Opóźnienie wiadomości i ponawianie obsługi

Gdy wiadomości są wysyłane do kolejki, są natychmiast pobierane i odbierane przez klientów. Jednak wielu klientów prosi o opóźnienie swoich wiadomości w celu wstępnego przetworzenia, dlatego wprowadzono licznik opóźnienia wiadomości. W niektórych wiadomościach występują błędy, które można przesłać ponownie. Jednak okres między wielokrotnymi próbami musi zostać opóźniony do momentu otrzymania przez naszego klienta potwierdzenia dostarczenia lub do przekroczenia limitu ponownych prób. Korzystając z SQS, można było użyć operacji ChangeMessageVisibility, aby dostosować czasy opóźnień.

Skalowalność i przystępność

Aby zaoszczędzić koszty, kolejki Amazon SQS FIFO i zadania Amazon ECS Fargate działają tylko wtedy, gdy są potrzebne. Usługi te przetwarzają dane w mniejszych jednostkach i uruchamiają je równolegle. Można je skutecznie skalować, aby radzić sobie ze szczytowym natężeniem ruchu. Zadowoli to większość architektur, które obsługują niejednolity ruch bez konieczności stosowania dodatkowej logiki aplikacji.

Bezpieczna dostawa

Usługa oferowana przez autorów dostarcza wiadomości do klientów za pośrednictwem bezpiecznych kanałów host-to-host. Aby zabezpieczyć te dane poza naszą siecią prywatną, jako mechanizmu dostarczania używa się usługi Amazon Simple Notification Service (SNS). Amazon SNS zapewnia dostarczanie do punktu końcowego HTTPS wiadomości przychodzących do tematów i subskrypcji. AWS umożliwia szyfrowanie w stanie spoczynku i/lub w tranzycie dla wszystkich komponentów architektonicznych. Amazon SQS zapewnia również szyfrowanie oparte na usłudze zarządzania kluczami AWS (KMS) lub szyfrowanie zarządzane przez usługę w celu szyfrowania danych w spoczynku.

Wydajność

Aby określić ilościowo wydajność produktu, autorzy monitorują opóźnienie dostarczenia wiadomości. Ta metryka ocenia czas między wysłaniem wiadomości a otrzymaniem jej przez klienta z usług płatniczych Amazon. Ich celem jest, aby wiadomość została wysłana do klienta w czasie zbliżonym do rzeczywistego po przetworzeniu transakcji. Nowa architektura Amazon SQS/ECS umożliwiła nam osiągnięcie 200 ms z opóźnieniem p99.

Podsumowanie

W tym artykule twórcy pokazali, w jaki sposób korzystanie z Amazon SQS pomogło przekształcić i skalować ich usługę. Byli w stanie zaoferować bezpieczne, niezawodne i wysoce dostępne rozwiązanie dla firm. Korzystają z usług i technologii AWS, aby uruchomić bramkę płatności Amazon Payment Services oraz automatyzację infrastruktury, aby zapewnić doskonałą obsługę klienta. Korzystając z usług Amazon SQS i Amazon ECS Fargate, Amazon Payment Services może zaoferować klientom bezpieczne dostarczanie wiadomości na dużą skalę.

źródło: AWS