Tworzenie Multi-Edge Data Architectures na AWS Wavelength i MongoDB

Wraz z pojawieniem się szybkich sieci 5G, przedsiębiorstwa starały się dostarczać doświadczenia z niskimi opóźnieniami w przemysłowym Internecie Rzeczy IoT (IIoT), mediach i rozrywce, motoryzacji i wielu innych.

U podstaw tych doświadczeń o niskim opóźnieniu leżą dane – niezależnie od tego, czy jest to robot naziemny, smartfon konsumencki, czy samochód bezzałogowy. Bezproblemowa wymiana danych od producenta 5G do konsumenta, takich jak uczenie maszynowe (ML), a nawet technologia generatywnej sztucznej inteligencji (AI), ma kluczowe znaczenie dla zasilania tych nowych doświadczeń.

Zapewnienie, że wymagane dane są dostępne dla konsumentów z możliwie najmniejszym opóźnieniem w dowolnej lokalizacji (na przykład za pośrednictwem wielu stref długości fal AWS), przy jednoczesnym zapewnieniu jednego widoku całego zestawu danych, nie jest łatwym zadaniem.

Od 2020 r. MongoDB i Amazon Web Services (AWS) współpracują ze sobą w celu zdefiniowania wzorców referencyjnych dla rozproszonych wzorców baz danych o niskim opóźnieniu w hybrydowych technologiach brzegowych AWS. W szczególności ten artykuł opiera się na wcześniejszej demonstracji MongoDB Realm na AWS Wavelength poprzez wzmocnienie istniejącej architektury o trzy nowe główne funkcje:

• Replikacja od brzegu do chmury: Replikacja od brzegu do chmury w środowisku multi-edge jest włączona za pośrednictwem Atlas Device Sync.
• Dynamiczne wykrywanie brzegowe: Implementacja Atlas Functions kieruje klientów mobilnych do optymalnej instancji MongoDB Realm działającej na krawędzi.
• Aplikacja skonteneryzowana: natywne wdrożenie usługi Amazon Elastic Kubernetes Service (Amazon EKS) udostępnia bazę danych MongoDB Realm bezpośrednio w sieci operatora.

W tym artykule autorzy zademonstrują również, jak używać kontrolera AWS Load Balancer do wdrażania Application Load Balancer (ALB) przed bazą danych.

MongoDB jest partnerem kompetencyjnym AWS Data and Analytics oraz sprzedawcą AWS Marketplace. Firma zajmująca się platformą danych dla programistów, MongoDB umożliwia innowatorom uwolnienie mocy oprogramowania i danych.

Przypadki użycia długości fal AWS dla MongoDB

Od inteligentnej produkcji i konserwacji zapobiegawczej po rolnictwo – nie brakuje aplikacji o małych opóźnieniach, które korzystają z mobilnego przetwarzania brzegowego.

Rozszerzenie istniejących obciążeń w MongoDB do brzegów ma kilka głównych korzyści:

• Bezpieczeństwo: Obecnie odpowiedzi z zapytań do baz danych muszą przechodzić – zaszyfrowane lub w inny sposób – przez publiczny Internet, aby wrócić do klienta mobilnego. Aby chronić bardzo wrażliwe obciążenia przed ogromną większością złośliwych podmiotów, mobilne przetwarzanie brzegowe oferuje możliwość, aby cały ruch mobilny nigdy nie opuszczał sieci dostępu radiowego (RAN) do publicznego Internetu.
• Wydajność i niezawodność: minimalizacja przyrostowych przeskoków do punktu końcowego aplikacji, szczególnie w momentach dużego przeciążenia, może znacznie zmniejszyć budżet opóźnień aplikacji. Co więcej, w przypadku aplikacji o dużym wolumenie, opartych na transakcjach, zaledwie 10 ms oszczędności w połączeniu z ponad milionem transakcji może skutkować ponad dwiema godzinami oszczędności w zakresie opóźnień.

AWS Wavelength Reference Architecture 

Aby zaprojektować to rozwiązanie, będziemy musieli rozszerzyć region AWS do wybranej strefy długości fali AWS, w której wdrożymy kontenerową aplikację Realm do komunikacji zwrotnej z Atlasem MongoDB w regionie nadrzędnym.

Amazon VPC

Dla każdego regionu, w którym został uruchomiony klaster MongoDB Atlas lub aplikacja AWS Wavelength zone, musz mieć być w posiadaniu wirtualnej chmury prywatnej (VPC).

W scenariuszach, w których wdrożono dużą liczbę Amazon VPC lub wykorzystuje się strefy długości fal wielu operatorów (Verizon, Vodafone, Bell Canada), skonfiguruj peering VPC i upewnij się, że skonfigurowano dwukierunkowy peering.

Pełną listę regionów z dostępnymi strefami długości fali można znaleźć na stronie Lokalizacje długości fali AWS.

MongoDB Atlas

Korzystając z MongoDB Atlas, w pełni zarządzanej bazy danych, możesz utworzyć instancję klastra MongoDB Atlas w dowolnym wybranym regionie. Obsługiwane regiony atlasu można znaleźć w dokumentacji atlasu MongoDB.

MongoDB Realm

W poprzednim artykule autorzy wdrożyli samodzielnie zarządzane instancje MongoDB działające na instancjach Amazon Elastic Compute Cloud (Amazon EC2) i zarządzane przez MongoDB Cloud Manager. Jednak w środowisku stref o wielu długościach fal wzrasta złożoność synchronizacji danych między tymi strefami. Złożoność tę można rozwiązać, wprowadzając MongoDB Realm i Atlas Device Sync, które automatyzują synchronizację danych między punktami końcowymi opartymi na Realm a Atlasem.

MongoDB Atlas Functions

Aby określić optymalny punkt końcowy krawędzi, możesz wykorzystać interfejsy API wykrywania brzegów, takie jak Verizon 5G Edge Discovery Service, w modelu cienkiego klienta, aby przenieść wykrywanie usług typu północ-południe do aplikacji, a nie do urządzenia.

Amazon EKS

Możliwość orkiestracji aplikacji z pojedynczej, scentralizowanej płaszczyzny kontroli zmniejsza narzut związany z konfiguracją wielu niezależnych klastrów lub grup automatycznego skalowania. W przypadku brzegowej bazy danych obliczeniowych użyjesz Amazon EKS do stworzenia wysoce skalowalnego środowiska w celu uruchamiania obciążeń wielokrawędziowych.

W ramach klastra EKS wdrożysz kontenery zawierające aplikację, taką jak broker MQTT, wraz z bazą danych MongoDB Realm.

Aby dowiedzieć się więcej o Amazon EKS na AWS Wavelength, zobacz artykuł na blogu AWS na temat wdrażania rozproszonych geograficznie klastrów EKS na AWS Wavelength.

Omówienie rozwiązania

W tej sekcji autorzy krok po kroku zaprezentują, w jaki sposób wdrożyć każdy z odpowiednich komponentów, zaczynając od rejestru usługi wykrywania krawędzi, podstawowej infrastruktury w AWS, a następnie klastra MongoDB i aplikacji kontenerowej.

Krok 1: Utwórz Edge Discovery Automation   

Na początek potrzebujesz sposobu, aby zapewnić, że Twoja siatka usługi Edge Discovery jest zawsze aktualna z najnowszymi punktami końcowymi skierowanymi do operatorów. Dlatego przed uruchomieniem jakiejkolwiek infrastruktury brzegowej musisz skonfigurować zautomatyzowany przepływ pracy, który dynamicznie rejestruje punkt końcowy długości fali AWS. Można tego dokonać za pośrednictwem Amazon EventBridge i AWS Lambda.

Krok 2: Utwórz klaster Atlas

Następnie utwórz bazę danych regionu nadrzędnego w AWS. Korzystając z MongoDB Atlas, MongoDB utrzyma wysoką dostępność klastra w wybranym regionie.

Krok 3: Utwórz klaster Amazon EKS

Aby wdrożyć aplikację AWS Wavelength, musisz najpierw utworzyć instancję zasobów regionu nadrzędnego. Na przykład klaster Amazon EKS musi zostać uruchomiony z dwiema podsieciami w regionie nadrzędnym (na przykład us-east-1a, us-east-1b).

Krok 4: Utwórz aplikację Realm

W przypadku Twojej aplikacji brzegowej możesz skorzystać z usługi MongoDB Atlas App Services, aby utworzyć aplikację IoT, która zawiera kod aplikacji dla Twojej statycznej strony internetowej i pliki CSS. W przypadku przykładowej aplikacji możesz postępować zgodnie ze wskazówkami zamieszczonymi w artykule na blogu MongoDB, aby skorzystać z innowacji o niskim opóźnieniu dzięki MongoDB Atlas, Realm i AWS Wavelength.

Równolegle, dla dynamicznej logiki aplikacji, utwórz obraz kontenera, który zapisuje w instancji bazy danych Realm w samym kontenerze; na przykład możesz odwiedzić ten serwer proxy MQTT do Realm na GitHub. Wykorzystanie tego projektu pozwala oddzielić doświadczenia odporne na opóźnienia, takie jak interfejs użytkownika aplikacji, od krytycznej dla opóźnień płaszczyzny danych komunikatów IoT.

Krok 5: Skonfiguruj aplikację Realm

Następnie musisz skonfigurować aplikację MongoDB Realm za pomocą kodu aplikacji. Aby to zrobić, wypchnij zdalną konfigurację (ze wstępnie opracowanej aplikacji).

Następnie musisz skonfigurować funkcję Atlas, bezserwerową funkcję sterowaną zdarzeniami, która wywołuje usługę Edge Discovery w celu kierowania do optymalnego punktu końcowego MongoDB Realm.

W tej funkcji wyodrębniasz wywołujący adres IP, abyś mógł wywołać interfejs API Edge Discovery Service (EDS) w imieniu klienta mobilnego. Następnie uwierzytelniasz usługę Edge Discovery i wysyłasz zapytanie do optymalnych rekordów serviceEndpoint, które zwracają optymalny adres IP Carrier odpowiadający najbliższej strefie długości fali (mecresponse.data.serviceEndpoints[0].serviceEndpoint.IPv4Address).

Pamiętaj jednak, że klucze EDS, appKey i secretKey należy traktować jako poufne i poza kodem, na przykład przy użyciu AWS Secrets Manager.

exports = async function({ query, headers, body}, response) {
    const ipAddr = headers["X-Forwarded-For"][0];
    console.log("Using IP: " + ipAddr);  
    try {
      var tokenresponse = await axios.request(
        { 
          url: "https://5gedge.verizon.com/api/ts/v1/oauth2/token",
          method: 'post',
          headers: {"Content-Type": "application/x-www-form-urlencoded"},
          data: qs.stringify({"grant_type" : "client_credentials"}),
          auth: {"username": appKey, "password": secretKey}
        }
      );
    } catch(ex) {
      console.log(ex);
    } 
    try {
      var mecresponse = await axios.request(
        { 
          url: "https://5gedge.verizon.com/api/mec/eds/serviceendpoints?serviceEndpointsIds="+serviceEndpointsId+"&UEIdentityType=IPAddress&UEIdentity="+ipAddr,
          method: 'get',
          headers: {"Content-Type": "application/x-www-form-urlencoded", "Authorization": "Bearer "+tokenresponse.data.access_token},
          data: qs.stringify({"grant_type" : "client_credentials"})
        }
      );
      
    return mecresponse.data.serviceEndpoints[0].serviceEndpoint.IPv4Address; 
    } catch(ex) {
      console.log(ex);
    }
};

Krok 6: Uruchom Self-Managed Nodes 

Aby zakończyć wdrażanie klastra EKS, wdróż samodzielnie zarządzane węzły procesu roboczego w wybranych strefach długości fal AWS. Aby dowiedzieć się więcej o konfigurowaniu samozarządzających się węzłów w Wavelength, zapoznaj się z dokumentacją AWS, która opisuje, jak używać eksctl do wdrażania w strefach Wavelength.

Krok 7: Wdróż aplikacje Realm

Następnie utwórz manifest wdrożenia, realm.yaml, który zawiera obiekty usługi Deployment i ClusterIP.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: realm-database
  labels:
    app: realm-iot
spec:
  replicas: 1
  selector:
    matchLabels:
      app: realm-iot
  template:
    metadata:
      labels:
        app: realm-iot
    spec:
      containers:
      - name: realm-app-demo
        image: <your-realm-app-image>
        ports:
        - containerPort: 80    
      nodeSelector:
        failure-domain.beta.kubernetes.io/zone: <your-wavelength-zone-ID>

---
apiVersion: v1
kind: Service
metadata:
  name: realm-service
spec:
  selector:
    app: realm-iot
  ports:
    - port: 80
      targetPort: 80

Następnie możesz skonfigurować kontroler AWS Load Balancer, aby udostępnił moduł równoważenia obciążenia aplikacji podczas tworzenia obiektu wejściowego.

Wnioski

Aby dowiedzieć się więcej o MongoDB i AWS Wavelength, możesz przejrzeć praktyczne warsztaty z AWS re:Invent lub przeglądać przypadki użycia, architektury referencyjne i oficjalne dokumenty w MongoDB w sieciach brzegowych:

• Realizing the Benefits of 5G with MongoDB and Verizon 5G Edge: z tego opracowania dowiesz się, w jaki sposób szybkość, przepustowość, niezawodność i szybkość reakcji sieci Verizon w połączeniu z zaawansowaniem platformy danych dla programistów MongoDB nowej generacji mogą zmienić różne branże.
• Delivering Data Faster with Verizon 5G Edge and MongoDB: poznaj podstawy mobilnego przetwarzania brzegowego, przepływu pracy API wykrywania brzegowego oraz architektury MongoDB Atlas.
• Computing in the Real World: poznaj branżowe zastosowania mobilnego przetwarzania brzegowego (MEC) w przemysłowym IoT, inteligentnej produkcji, motoryzacji i nie tylko.

Możesz także dowiedzieć się więcej na temat MongoDB w AWS Marketplace.

Źródło: AWS