Wywoływanie asynchronicznych zewnętrznych interfejsów API za pomocą AWS Step Functions

Interfejsy API dostawców zewnętrznych mogą pomóc organizacjom w usprawnieniu operacji, obniżeniu kosztów i zapewnieniu klientom lepszych usług. Istnieje jednak wiele wyzwań związanych z integracją z usługami stron trzecich, takich jak bezpieczeństwo, niezawodność i koszty.

Organizacje muszą zapewnić, że ich systemy poradzą sobie z problemami z wydajnością lub przestojami. W niektórych przypadkach wywołanie zewnętrznego interfejsu API może wiązać się z kosztami, takimi jak opłaty licencyjne. Jeśli istnieje umowa dotycząca przestrzegania maksymalnej liczby żądań na sekundę (RPS) z zewnętrznym dostawcą interfejsu API, system musi się odpowiednio dostosować.

Ten artykuł blogowy posłuży autorom za przykład, jak zbudować architekturę do wywoływania interfejsu API zewnętrznego dostawcy za pomocą AWS Step Functions, ze szczegółowymi wskazówkami dotyczącymi niezawodności.

Ta aranżacja ma zastosowanie w każdej branży, która opiera się na technologii i danych korzystających z integracji interfejsu API zewnętrznego dostawcy. Przykłady obejmują aplikacje handlu elektronicznego dla sprzedawców internetowych integrujące się z zewnętrznymi bramkami płatniczymi, przewoźnikami lub aplikacjami w sektorze opieki zdrowotnej i bankowości.

Omówienie wywoływania asynchronicznych zewnętrznych interfejsów API

To rozwiązanie opisuje wykorzystanie usług AWS do zbudowania orkiestratora kontrolującego częstotliwość wywołań usług innych firm, które implementują wzorzec wywołania zwrotnego usługi w celu przetwarzania długotrwałych zadań. Ta architektura jest również dostępna w sekcji AWS Reference Architecture Diagrams w AWS Architecture Center.

Tak jak na rysunku nr 1, architektura zapewnia kontrolę nad przekazywaniem połączeń do usługi zewnętrznej zgodnie z jej umową o maksymalnym RPS przy użyciu funkcji Step Functions. Step Functions wstrzymuje główne przepływy pracy żądań, dopóki nie otrzymasz wezwania zwrotnego z systemu zewnętrznego wskazującego na zakończenie zadania.

Pora prześledzić każdy krok.

1. Skonfiguruj Step Functions do obsługi cyklu życia długotrwałych żądań do strony trzeciej. Wewnątrz przepływu pracy dodaj krok żądania, który go wstrzymuje, używając elementu waitForTaskToken jako wywołania zwrotnego, aby kontynuować. Ustaw limit czasu, aby zgłosić błąd przekroczenia limitu czasu, jeśli wywołanie zwrotne nie zostanie odebrane.
2. Wyślij token zadania i zażądaj ładunku do kolejki Amazon Simple Queue Service (Amazon SQS). Użyj Amazon CloudWatch do monitorowania jego długości. Rozważ dostosowanie umowy z usługą strony trzeciej, jeśli długość kolejki przekroczy limit określony na maksymalnym RPS z osobą trzecią.
3. Użyj AWS Lambda, aby sondować Amazon SQS i uruchomić ekspresowy przepływ pracy Step Functions. Kontroluj szybkość wywołań Lambda przy użyciu rozmiaru partii sondowania, zarezerwowanej współbieżności i maksymalnej współbieżności, omówionych bardziej szczegółowo w dalszej części artykułu.
4. Opcjonalnie dodaj dynamiczne opóźnienie wewnątrz Lambdy kontrolowanej przez AWS AppConfig, jeśli system nadal potrzebuje niższej częstotliwości wywołań, aby zachować zgodność z zakontraktowanym RPS.
5. Step Functions wywołuje Amazon API Gateway HTTP proxy API skonfigurowany z limitem szybkości w celu zachowania zgodności z zakontraktowanym RPS. API Gateway jest zabezpieczającym serwerem proxy, który zapewnia, że Twój system nie łamie umowy RPS podczas dynamicznego dostosowywania parametrów częstotliwości wywołań.
6. Wywołaj zewnętrzny interfejs API usługi asynchronicznej innej firmy, wysyłając ładunek wykorzystany z kolejki żądań i odbierając identyfikator zadania z usługi. Wysyłaj nieudane żądania do kolejki niedostarczonych wiadomości (DLQ) za pomocą Amazon SQS.
7. Przechowuj token głównego przepływu pracy i identyfikator zadania z usługi innej firmy w tabeli Amazon DynamoDB. Jest to używane jako mapowanie do skorelowania identyfikatora zadania z tokenem zadania.
8. Po zakończeniu działania usługi zewnętrznej odbierz ukończony identyfikator zadania w punkcie końcowym elementu webhook wywołania zwrotnego zaimplementowanym za pomocą API Gateway.
9. Przekształć zewnętrzne wywołania zwrotne za pomocą szablonów mapowania API Gateway, dodaj ładunek i identyfikator zadania do kolejki Amazon SQS i natychmiast odpowiedz dzwoniącemu.
10. Użyj Lambda, aby sprawdzić kolejkę wywołania zwrotnego Amazon SQS, a następnie zakwestionuj przechowywany token. Użyj tokenu, aby odblokować oczekujący przepływ pracy, wywołując SendTaskSuccess i wywołanie zwrotne DLQ w celu przechowywania komunikatów zakończonych niepowodzeniem.
11. W głównym przepływie pracy przekaż identyfikator zadania do następnego kroku i wywołaj procesor Step Functions, aby pobrać wyniki innych firm. Na koniec przetwórz wyniki usługi zewnętrznej.

Kontrolowanie częstotliwości wywołań zewnętrznych interfejsów API

Aby zachować zgodność z umowami RPS innych firm, zastosuj mechanizm kontrolujący częstotliwość wywołań swojego systemu. Częstotliwość kwestionowania wiadomości z żądania Amazon SQS (lub kroku 3 w architekturze) ma bezpośredni wpływ na częstotliwość wywołań.

Różne parametry mogą być używane do kontrolowania częstotliwości wywołań dla Lambdy z Amazon SQS jako wyzwalaczem „źródła zdarzenia”, na przykład:

1. Wielkość serii: Liczba rekordów do wysłania do funkcji w każdej partii. W przypadku kolejki standardowej może to być do 10 000 rekordów. W przypadku kolejki FIFO, maksymalna liczba to 10. Samo użycie rozmiaru partii nie ograniczy szybkości wywołań. Należy go używać w połączeniu z innymi parametrami, takimi jak zarezerwowana współbieżność lub maksymalna współbieżność.
2. Okno wsadowe: maksymalny czas gromadzenia rekordów przed wywołaniem funkcji, w sekundach. Dotyczy to tylko kolejek standardowych.
3. Maksymalna współbieżność: określa limity liczby jednoczesnych wystąpień funkcji, które może wywołać źródło zdarzenia Amazon SQS. Maksymalna współbieżność to ustawienie na poziomie źródła zdarzenia.

Konfiguracja wyzwalacza pokazana jest na rysunku nr 2.

Inne parametry konfiguracyjne Lambdy mogą być również używane do kontrolowania szybkości wywołań. Będą to:

1. Zarezerwowana współbieżność: gwarantuje maksymalną liczbę jednoczesnych wystąpień funkcji. Gdy funkcja ma zarezerwowaną współbieżność, żadna inna funkcja nie może używać tej współbieżności. Można to wykorzystać do ograniczenia i zmniejszenia częstotliwości wywołań.
2. Zapewniona współbieżność: Inicjuje żądaną liczbę środowisk wykonawczych, aby były przygotowane do natychmiastowej odpowiedzi na wywołania Twojej funkcji. Pamiętaj, że skonfigurowanie udostępnionej współbieżności powoduje naliczenie opłat na Twoje konto AWS.

Te dodatkowe parametry konfiguracyjne Lambda są pokazane na rysunku nr 3.

Maksymalizacja zewnętrznej architektury API

Podczas tej implementacji architektury należy wziąć pod uwagę kilka przypadków użycia, aby upewnić się, że tworzysz odpowiedni Orchestrator.

Prześledź kilka przykładów:

• Jeżeli system zewnętrzny nie odpowie na żądanie API w kroku 8, w kroku 1 wystąpi wyjątek timeout. W głównym automacie stanów należy skonfigurować sensowny timeout w kroku 1. Wartość timeout powinna uwzględniać maksymalny czas odpowiedzi system zewnętrzny.

Możliwości obsługi błędów w sekcji Step Functions przewodnika AWS Step Functions Developer zapewniają możliwość zaimplementowania własnej logiki dla różnych typów błędów. Skonfiguruj błędy przekroczenia limitu czasu przy użyciu stanu błędu States.Timeout.

• Opóźnienie dynamiczne wewnątrz funkcji Lambda – jak wspomniano w kroku 4 –powinno być używane tylko tymczasowo w przypadku ruchu typu burst. Jeśli strona zewnętrzna ma umowę o bardzo niskim RPS, rozważ inne alternatywy wprowadzenia opóźnienia.

Na przykład Amazon EventBridge Scheduler może być używany do wyzwalania funkcji Lambda w regularnych odstępach czasu w celu wykorzystania wiadomości z Amazon SQS. Pozwala to uniknąć kosztów stanu bezczynności/oczekiwania funkcji Lambda.

Wnioski

Za pomocą tego artykułu omówiono, jak zbudować kompleksową orkiestrację w celu zarządzania cyklem życia żądania, pięć różnych parametrów kontrolujących częstotliwość wywoływania usług innych firm oraz ograniczanie wywołań do interfejsu API usługi zewnętrznej na maksymalny kontrakt RPS.

Autorzy rozważają również przypadki użycia funkcji obsługi błędów w Step Functions i monitorują systemy za pomocą CloudWatch. Ponadto ta architektura przyjmuje w pełni zarządzane usługi AWS Serverless, eliminując niezróżnicowane „heavy lifting” w budowaniu wysoce dostępnych, niezawodnych, bezpiecznych i ekonomicznych systemów w AWS.

Źródło: AWS