Tworzenie i konsumowanie webhooków ptaków

Rzeczywiste przetwarzanie i przechowywanie danych będzie realizowane przez funkcję lambda, która jest wywoływana przez nasz load balancer aplikacji (ALB). 

Pierwszym krokiem jest stworzenie twojej funkcji lambda poprzez przejście do usługi Lambda w AWS i kliknięcie „Utwórz funkcję”. Zostaniesz poproszony o nadanie nazwy swojej funkcji lambda oraz wybranie, w jakim języku programowania napisać swoją funkcję. W tym przykładzie używamy Pythona jako języka uruchomieniowego.

Teraz musimy opracować naszą funkcję lambda. Na chwilę załóżmy, że nasz load balancer aplikacji został skonfigurowany i przesyła ładunek webhooka do naszej funkcji lambda – lambda otrzyma ładunek zawierający pełne nagłówki i treść. Ładunek jest przekazywany do naszej funkcji lambda przy użyciu obiektu „event” jako słownika. Możesz odwoływać się do nagłówków i treści ładunku niezależnie, uzyskując dostęp do obiektów „headers” i „body” w ładunku. W tym przykładzie po prostu odczytamy nagłówek „x-messagesystems-batch-id”, gdzie identyfikator wsadu jest unikalną wartością utworzoną przez Bird dla wsadu webhooka, i użyjemy go jako nazwy pliku podczas przechowywania treści jako pliku płaskiego w S3; jednak możesz chcieć dodać dodatkowe funkcjonalności, takie jak kontrole uwierzytelniania lub obsługę błędów, w razie potrzeby.

Przechowując ładunek w pliku płaskim na S3, będziemy musieli określić nazwę wiadra S3, lokalizację i nazwę pliku, w którym dane ładunku będą przechowywane. W naszej przykładowej funkcji lambda robimy to w funkcji „store_batch”. W tym przykładzie zamierzamy przechować cały wsad jako jeden plik, co pomaga zapewnić, że dane są zbierane i przechowywane zanim połączenie HTTP między Bird a twoim punktem końcowym wygaśnie. Choć możesz dostosować ustawienia czasu oczekiwania połączenia na swoim load balancerze, nie ma gwarancji, że połączenie nie wygasnie po stronie przesyłania (w tym przypadku Bird) ani że połączenie nie zostanie przerwane, zanim twoja funkcja lambda zakończy wykonywanie. Najlepszą praktyką jest utrzymanie funkcji konsumenta jak najbardziej efektywnej i zarezerwowanie działań przetwarzania danych dla dalszych procesów, gdzie to możliwe – jak konwersja zbiorczego ładunku w formacie JSON na plik CSV lub ładowanie danych zdarzeń do bazy danych.

Ważne jest, aby zauważyć, że możesz potrzebować zaktualizować uprawnienia dla swojej funkcji lambda. Twoja rola wykonawcza będzie potrzebować uprawnień PutObject i GetObject dla S3. Najlepszą praktyką jest przestrzeganie zasady minimalnych uprawnień, więc zalecam ustawienie tych uprawnień tylko dla wiadra S3, w którym będą przechowywane ładunki webhooków.

Przykład naszej funkcji konsumenta lambda można znaleźć tutaj.

Jako szybka uwaga dotycząca identyfikatora wsadu:  Bird grupuje zdarzenia w jeden ładunek, gdzie każdy wsad może zawierać od 1 do 350 lub więcej rekordów zdarzeń.  Wsad otrzyma unikalny identyfikator wsadu, który można wykorzystać do wyświetlenia statusu wsadu, korzystając z API Webhooks Zdarzeń lub w twoim koncie Bird, klikając na strumień webhooków i wybierając „Status wsadu.” W przypadku, gdy ładunek webhooka nie mógł zostać dostarczony, na przykład podczas przekroczenia czasu połączenia, Bird automatycznie ponowi próbę wsadu używając tego samego identyfikatora wsadu. Może to się zdarzyć, gdy twoja funkcja lambda działa blisko maksymalnego czasu odpowiedzi wynoszącego 10 sekund i jest to powód do optymalizacji funkcji konsumenta w celu skrócenia czasu wykonania.

Aby obsłużyć wszystkie działania przetwarzania danych, zalecam utworzenie osobnej funkcji lambda, która będzie uruchamiana za każdym razem, gdy nowy plik zostanie utworzony w wiadrze S3 – dzięki temu przetwarzanie danych jest realizowane asynchronicznie w stosunku do transmisji danych i nie ma ryzyka utraty danych z powodu przerwanego połączenia. Omówię funkcję przetwarzającą lambda w późniejszej części.