Inteligentne miasto
Wstęp
Chciałbym dzisiaj zaproponować przygotowanie projektu architektonicznego opisującego zbudowanie systemów dla inteligentnego miasta. W celu wykonania transformacji cyfrowej
miasta należy podejść do problemu całościowo tzn. najpierw należy wykonać
inwentaryzację posiadanych zasobów i oferowanych usług biznesowych. Następnie
należy zebrać wywiad z użytkownikami obecnych systemów oraz z interesariuszami, a w tym z odbiorcami
końcowymi usług. Tak pozyskane dane wraz z wykonaną inwentaryzacją pozwolą
zdiagnozować problemy dotyczące obsługi sygnalizacji (brak zielonej fali), obsługa miejsc parkingowych (brak możliwości rezerwacji miejsc parkingowych) czy komunikacja miejsca (nieoptymalne połączenia - mieszkańcy tracą dużo czasu na dojazd do pracy). Dobra diagnoza pozwoli zaproponować architekturę TO-BE
w podziale na domeny:
- biznesową,
- aplikacyjną,
- danych,
- techniczną (infrastrukturalną)
Dodatkowo należy zdefiniować wymagania niefunkcjonalne oraz pryncypia
architektoniczne, które będą drogowskazem dla wszystkich dalszych działań.
Pryncypia architektoniczne
Pryncypia architektoniczne dla naszego miasta wraz z modelem
motywacji zostały umieszczone na poniższym diagramie.
Stan obecny i architektura AS-IS
W celu przygotowania architektury AS-IS należy przeprowadzić
inwentaryzację w podziale na domeny:
- architektura biznesowa (procesy biznesowe, usługi biznesowe, aktorzy, itp.)
- architektura aplikacyjna (stworzone lub zakupione systemy i aplikacje, licencje, opisy integracji między komponentami, interfejsy)
- architektura danych (należy zdefiniować encje danych, właścicieli danych biznesowych, zdefiniować dane referencyjne oraz przepływy danych oraz sposoby ich wykorzystania)
- architektura techniczna (serwery fizyczne i wirtualne, systemy operacyjne, bazy danych, licencje, komponenty sieciowe fizyczne i wirtualne, systemy do backupu danych, ułożenie komponentów w podsieciach, pozostałe komponenty takie jak: firewall, WAF, IAM, HSM, SIEM, Gateway, itp.)
Z uwagi na możliwość wystąpienia drobnej przestępczości należy
zweryfikować możliwość ataków na systemy. Należy wykonać testy penetracyjne i
wykonać stosowne zabezpieczenia jeśli będą potrzebne.
Po pozyskaniu wiedzy dotyczącej architektury AS-IS należy
przeprowadzić badania satysfakcji w obszarach:
1. Użytkownicy wewnętrzni systemu w podziale na departamenty:
- Zebranie informacji czy procesy biznesowe działają bez problemów
- Czy są wąskie gardła w procesach
- Jak działa i czy jest dostępna automatyzacja procesów
- Propozycje usprawnień
2. Interesariusze i odbiorcy biznesowi (grupa, która chce jak najszybciej dojechać (sterowanie ruchem) i móc zaparkować pojazd):
- Zebranie opinii o jakości działania usługi
- Pozyskanie informacji o problemach poruszania się i parkowania
- Propozycje i uwagi dotyczące usprawnień (lista życzeń)
3. Użytkownicy końcowi (użytkownicy indywidualni potrzebujący dojechać w określone miejsce)
- Krótkie uwagi dotyczące usługi (co jest dobre, a co nie),
- możliwości usprawnień
Architektura TO-BE
Warstwa biznesowa
Rozpoczynając od warstwy architektury biznesowej należy
zdefiniować podstawowe procesy biznesowe oraz powiązane usługi biznesowe.
Najważniejsze są oczywiście zewnętrzne usługi i procesy, które możemy podzielić
na usługi dla biznesu i usługi dla odbiorcy indywidualnego. Same usługi zostały
zdefiniowane na wysokim poziomie ogólności.
Część elementów powinna zostać rozbudowana i opisana
dokładniej:
- rozliczenia za korzystanie z usługi powinny być naliczane za faktyczne wykorzystanie usługi
- powinna być weryfikacja, czy miejsce jest zajęte przez samochód, dla którego była wykonana rezerwacja. Miejsca powinny być monitorowane, a obraz powinien być przetwarzany i powinien być rejestrowany numer rejestracyjny
- podstawowa usługa przejazdu i parkowania powinna być spójna i intuicyjna do przejścia
Procesu i usługi dedykowane dla klienta wewnętrznego zostały
zwizualizowane poniżej
Warstwa aplikacyjna
Wymagania dotyczące warstwy aplikacyjnej i funkcjonalności
jakie muszą zostać dostarczone wynikają bezpośrednio lub pośrednio z wyższej
warstwy – warstwy biznesowej. Główne założenia dla warstwy aplikacyjnej:
1. Wszystkie czujniki, komponenty kontrolujące światła drogowe i dostępność miejsc parkingowych są podłączone do jednego systemu zarządzającego tymi komponentami – mówimy tutaj o IoT
2. Użytkownik końcowy ma dostęp do swojego konta i funkcjonalności poprzez portal WWW
3. Funkcjonalności podstawowe pracują w oparciu o konteneryzację i orchiestrację np. k8s.
4. Zostaną stworzone minimalnie 2 podsieci:
a. Dla komponentów udostępniających usługi WWW
b. Dla wewnętrznych komponentów, które nie udostępniają usług zewnętrznych
5. Zdefiniowane procesy będą działały w oparciu o zdefiniowane workflow
6. Procesy wyszukania najlepszej trasy, zarezerwowania miejsca parkingowego w okolicy, czy weryfikacji czy faktycznie oczekiwany samochód zaparkował na miejscu wyznaczanym będą odbywały się z wykorzystaniem ML (rozpoznawanie obrazów, wyznaczenie najlepszej ścieżki lub rezerwacja miejsca o określonej porze w okolicy)
7. Wszystkie działania będą zbierane i agregowane w BigData – będziemy mogli weryfikować , czy klient zastanawiał się nad wyborem opcji doręczenia, ceną itp. Na podstawie tych danych będziemy mogli skierować do takich użytkowników pakiety promocyjne w przyszłości.
8. Tworzone API musi być udokumentowane. W tym celu należy wykorzystać OpenAPI.
9. Wytwarzany kod aplikacji musi przechodzić automatyczną weryfikację np. Sonar oraz ręczną rewizję kodu
10. Tworzone oprogramowanie powinno być zgodne z podejściem DevOps
11. Tworzone oprogramowanie bazuje na wzorcach GOF, przy wykorzystaniu języka java należy bazować dodatkowo na wzorcach J2EE. Integracja między aplikacjami muszą korzystać z dobrych praktyk integracyjnych wzorców architektonicznych
Założenia dla warstwy aplikacyjnej zostały rozpisane
powyżej. Z uwagi, że mamy zbudować Smart Citi oraz możemy korzystać z najnowszych
dostępnych rozwiązań to nasza architektura na najwyższym poziomie powinna
wyglądać następująco (HLD):
Istniejące systemy do zarządzania majątkiem, obsługą
zgłoszeń i roszczeń oraz systemami geolokalizacyjnymi powinny zostać
dostosowane. Powinny zostać zbudowane nowe systemy w oparciu o chmurę AWS,
które będą zapewniały HA, bezpieczeństwo dla podłączonych urządzeń IoT (Anazon
IoT) oraz analizę danych w BigData (Athena), czy wykorzystanie ML dla lepszego
zrozumienia działań klienta w portalu (Amazon Personalize) oraz wyszukanie
najlepszej drogi lub wybranie najdogodniejszego miejsca parkingowego w punkcie
docelowym podróży (Amazon SageMaker). Proces rezerwacji, płatności oraz wyboru
parkingu będzie opierał się o kroki w procesie (Amazon StepFunction). Wszystkie
potwierdzenia, zmiany itp. będą notyfikowane do klienta (SNS). Dla potrzeb
całości zostaną wykorzystane kolejki SQS oraz komponenty, które będą zasilały
systemy typu BigData np. Kinesis.
Portal Użytkownika zostanie zbudowany w oparciu
konteneryzację, którą będzie zarządzał kubernetes (k8s). Całość zostanie
uruchomiona w jednym regionie. VPC (Virtual Private Cloud) zostanie uruchomiona
w dwóch strefach (nienależnych serwerowniach w ramach regionu). Aplikacja zostanie podzielona na frontend i
backend. Reguły zostaną tak zdefiniowane, że do warstwy backendowej nie będzie
dostępu z zewnątrz. Jedynie będą mogły się tam dostać w komponenty warstwy frontendowej.
Na maszynach EC2 zostaną postawione Master i Worker Nody K8s.
Integracje z urządzeniami peryferyjnymi wykonane będą za
pomocą komponentu Amazon IoT. Do tego komponentu będą podłączone ścieżki:
1. BigData -> na potrzeby procesowania wyników zestawień wraz z podłączonym narzędziem BI
2. Workflow -> na potrzeby:
a.
rejestracji przejazdu i sterowania ruchem
(wykorzystanie ML), weryfikacji zaparkowanego pojazdu (wykorzystanie ML) na
potrzeby przeciwdziałania drobnej przestępczości,
b.
Informowania portalu klienta o dostępności i
zwolnieniu miejsca parkingowego. Na tej podstawie będą wykonywane naliczenia
Bezpieczeństwo
Główne wymagania dla potrzeb zapewnienie bezpieczeństwa
całego rozwiązania:
1. Dla aplikacji jest wymagany cykliczny audyt bezpieczeństwa
2. Przed uruchomieniem produkcyjnym wymagane jest uruchomienie testów penetracyjnych
3. Wszystkie komponenty IoT komunikują się z systemem centralnym z wykorzystaniem przydzielonego certyfikatu X.509
4. Portal WWW wymaga uwierzytelnienia i autoryzacji. Zabezpieczony jest protokołem TLS w wersji minimalnie 1.2
5. Wewnętrza komunikacja między komponentami odbywa się z wykorzystaniem certyfikatów (Zero Trust Networking (ZTN))
6. Wymagane jest użycie Firewalla i WAF
7. Dostęp do podsieci jest zdefiniowany i określony. Otwarte są jedynie konieczne porty do obsługi funkcjonalności
8. Wszystkie żądania API muszą być uwierzytelnione, a wewnętrzne wywołania muszą być zgodne ze zdefiniowanymi politykami bezpieczeństwa
9. Zabezpieczenie API musi być wykonane za pośrednictwem OAuth2
10. Uwierzytelnienie z systemów zewnętrznych (google, facebook, LinkedIn) musi się odbywać za pośrednictwem SAML 2.0
Wymagania niefunkcjonalne
Wymagania niefunkcjonalne są bardzo istotną częścią
aplikacji. Wymagania te mogą decydować o kosztach całej aplikacji. Poniżej
podstawowe wymagania:
1. Aplikacje muszą być tak stworzone, aby dawały się skalować horyzontalnie
2. Aplikacje muszą zapewniać HA więc muszą być rozmieszczone przynajmniej w 2 serwerowniach oddalonych od siebie. Musi być zapewnione zapasowe łącze
3. Dostęp do danych wrażliwych oraz do systemów musi być audytowany
4. Musi być zapewniony backup danych
5. Dokumentacja projektu musi się zgadzać z wytworzonym oprogramowaniem
6. Dokumentacja API powinna bazować na standardach OpenAPI (wraz ze swaggerem)
Analiza luki
Z uwagi, że mamy architekturą AS-IS i TO-BE musimy stworzyć
proces dojścia ze stanu obecnego do stanu docelowego. W celu realizacji tego
zadania konieczne będzie rozpisanie zadań koniecznych do wykonania z
odpowiednio ustawionymi priorytetami. Należy uwzględnić takie elementy jak:
1. stworzenie fasad do przykrycia wcześniejszych funkcjonalności – jeśli były już integracje z zewnętrznymi dostawcami
2. przeprowadzenie migracji danych w koniecznych obszarach
3. przepisanie lub zastąpienie komponentów oznaczonych do usunięcia
4. stworzenie nowych komponentów i ich priorytetyzacja