Cloud

Otomoto – architektura

W poprzednim wpisie opisałem rezultat prostych badać nad zestawem ogłoszeń pobranych z otomoto.pl. Teraz chciałbym opisać w jaki sposób stworzyłem rozwiązanie oparte na chmurze Amazon AWS.

Wstęp

Oczywiście, można wyobrazić sobie, że całość działa na w jednej aplikacji uruchomionej na dowolnym komputerze, jednak ja chciałem przy tej okazji nauczyć się stosować wiedzę zdobytą podczas przygotowania się do egzaminu AWS Architect Associate i późniejszej praktyce w projektach.

Wpisem tym chciałbym Was zachęcić do nauki chmury AWS. Jeśli więc jesteś .netowcem i znasz podstawy chmury (Azure, GCP) to ten wpis jest dla Ciebie. AWS ma bardzo dobre wsparcie dla platformy .NET jaki i Visual Studio. Do tego ma specjalny darmowy program (free-tier) pozwalający przez rok korzystać z wielu usług za darmo.

Całe poniższe rozwiązanie działa całkowicie za darmo. Nie wliczam tutaj kosztu Raspberry bo już go mam i wykorzystuje ją również do innych celów.

Cel solucji

Celem rozwiązania jest stworzenie mechanizmu pobierania nowych ogłoszeń z otomoto i zapisanie ich w plikach (S3) oraz bazie danych Mysql (RDS). Architektura powinna być odporna na problemy sprzętowe zapisywać dane na “pewnym” nośniku. Dodatkowo w przypadku awarii sprzętu (RPi) żadne dane nie mogą być utracone a cała platforma powinna odzyskać sprawność i być w stanie ściągnąć zaległe i bieżące ogłoszenia.
Ktoś mógłby zapytać po co tutaj mieszać chmurę z jakimś IoT? Niestety zabezpieczenia otomoto nie pozwalają ściągać szczegółów ogłoszenia z chmury.

Architektura

Poniżej przedstawiłem diagram rozwiązania i postaram się przybliżyć Wam co poszczególne serwisy AWS robią i jak przebiega cały proces .

Najpierw lista użytych serwisów (słownik):

  • AWS CloudWatch (scheduler): służy do cyklicznego odpytywania Otomoto o ostatnio dodane ogłoszenia. Scheduler wyzwala lambdę.
  • AWS Lambda: to podstawowe serwis do uruchamiania kodu w chmurze. W rozwiązaniu występują dwa rodzaje lambd: odczytująca nowe ogłoszenia i reagująca na nowy plik w S3.
  • DynamoDB: szybka dokumentowa baza danych. Wykorzystuję ją do przechowywania stanu, tj. zapisania id i daty ostatnio pobranych ogłoszeń.
  • SQS: Kolejka służąca do zlecania pobierania szczegółów ogłoszenia przez RPi.
  • S3: Storage plików. Trzymane są tam pliki JSON.
  • RDS: to zarządzalna baza danych. Ja zdecydowałem się na MySQL. Do dyspozycji mamy : MSSQL, Postgres, Oracle i Aurora.

Jak to działa?

Wszystko zaczyna się od schedulera którego funkcjonalność realizowana jest przez serwis CloudWatch. Raz na 5 minut wyzwalana jest funkcja która pobiera listę ostatnio dodanych ogłoszeń. Lambda odczytuje dane z DynamoDB na temat ostatniego ogłoszenia tak by móc zapytać o kolejne. Funkcja kończy działanie dodając do kolejki wiadomości z Id ogłoszeń które posłużą RPi do ściągnięcia ich szczegółów.
Raspberry (RPi) pobiera szczegóły ogłoszenia i zapisuje je w formie JSON na S3.
Kolejna Lambda Function otrzymuje event o nowo utworzonym pliku i przetwarzając go zapisuje dane w relacyjnej bazie danych (RDS: MySql).

Korzyści

Oprócz oczywistej korzyści jaką jest darmowy plan na rok znalazłem jeszcze kilka wartych wspomnienia konsekwencji użycia chmury:
Serverless: przede wszystkim skupiam się na kodzie a nie infrastrukturze. Niezależnie od tego czy mam do pobrania 10 czy 1000 ogłoszeń AWS lambda świetnie sobie z tym poradzi. Darmowy plan zapewnia 1 milion uruchomień lambd miesięcznie. Do deploymentu lambdy użyłem Serverless framework.
SQS (kolejki): dają możliwość asynchronicznego przetwarzania danych. Wyłączenie RPi od sieci nie stanowi problemu. Po ponownym podłączeniu zacznie ona na nowo pobierać wiadomości z kolejki i cały proces odzyska sprawność. Nie powinienem utracić ani jednego ogłoszenia.
S3 (storage): pozwala mi bardzo tanio przechowywać dane. Za darmo do 5GB.

Gdzie jest .net?

Zarówno obie lambda functions jak i sama Raspberry PI obsługują .net. Cały kod postanowiłem napisać w C#. Oprócz Amazon SDK użyłem Dappera, Flurl, MoreLinq

Rzeczy które chciałbym zaimplementować to: opisanie infrastruktury kodem (Terraform) oraz napisać chociaż gram testów jednostkowych.

Statystyki i podsumowanie

Jak dotąd udało mi się zebrać około 700 000 ogłoszeń które w sumie zajmują około 14GB danych (po rozpakowaniu).
Chętnie przyjmę wszelkie komentarze i wskazówki co do kolejnych wpisów na ten temat.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.