Cloud Onboarding

Um ein vollständiges Cloud-Onboarding von Grund auf bis zur Produktion bereitzustellen, müssen viele Arbeiten durchgeführt werden. Sehen Sie, wie das geht.

Das Konzept muss vollständig mit dem Cloud-Architekturmodell übereinstimmen. Es wird davon ausgegangen, dass nur native SaaS-Dienste ohne IaaS-Computer verwendet werden. Der Ansatz der gesamten Architektur sollte serviceorientiert, vollständig horizontal und vertikal skalierbar sein. Dieser Artikel befasst sich mit dem Entwurf und der Erstellung der AWS-Infrastruktur. Die Cloud-Bereitstellung erfordert zuvor die Vorbereitung von DevOps.

Agenda

• Architekturentwurf

• Cloud-Ressourcen

• Schaffung einer Infrastruktur

• Zero Down Time

• Failure Prevention

Architekturentwurf

Die Cloud-Infrastruktur hängt von unserer Projektarchitektur ab, die ein Ausgangspunkt für die Gestaltung der Cloud-Bereitstellung ist.

Figure 1. Architektur

Cloud-Ressourcen

Basierend auf der Projektarchitektur entscheiden Architekten, welche Cloud-Ressourcen zum Erstellen eines Projekts in der Cloud verwendet werden sollen.

Figure 2. AWS Services

Internet Infrastruktur

Route 53

Unsere Anwendung verwendet zwei URLs.

• Web Simulator

• API Endpoint

Um DNS mit CloudFront zu verbinden, müssen wir Subdomains umleiten und auf eine bestimmte CloudFront-Distribution verweisen.

Route 53 kann auch als interner DNS für ECS-Container verwendet werden. Service Discovery registriert private IP-Adressen für fehlerfreie Container in der lokalen Zone. Dank dieser Anwendung kann zwischen internen Diensten über Aliase kommunizieren.

CloudFront

CloudFront bietet CDN-, Zertifikat-, Cache- und andere Webfunktionen. CloudFront hat Distributionen für alle unsere URLs wie Backend-API und UI-Simulator getrennt. Die Verteilung hat ihre eigenen spezifischen Parameter wie HTTP-Header usw. Um den Datenverkehr umzuleiten, sind zwei Origins konfiguriert - einer für die Backend-API und einer für die Frontend-Webanwendung.

Die Backend-API wird an den Backend-Loadbalancer und an ECS weitergeleitet. Die Frontend-Anwendung wird an den S3-Bucket weitergeleitet.

Um ein angemessenes Verhalten bereitzustellen, sind Pfadmuster und Umleitungsdefinitionen zu einem bestimmten Ursprung konfiguriert.

Um den Ursprung zu konfigurieren, sollten Sicherheitsparameter, Ursprungsziel und Zeitüberschreitungen angegeben werden.

AWS Certificate Manager

Die Infrastruktur verfügt über zwei öffentliche Endpunkte, daher verwenden wir zwei Zertifikate.

• HTTP/SSL Zertifikat - Zertifikat für Backend API

• HTTP/SSL Zertifikat - Zertifikat für Frontend Simulator

Hochverfügbarkeitsinfrastruktur

Elastic Load Balancer

Um den Internetverkehr von API-Anforderungen auszugleichen, sollte der Load Balancer konfiguriert werden.

Der Load Balancer ist über die Zielgruppe mit dem ECS-Container verbunden. Zielgruppe ist eine bestimmte Engine, die für die Verbindung von Load Balancern mit dem ECS-Service verantwortlich ist. ECS registriert automatisch eine neue private IP in der Zielgruppe.

Target Group

Die Target Group hat die Möglichkeit, Integritätsprüfungen zu registrieren, in denen der HTTP-Pfad, das Zeitlimit und das Erfolgscode für den Integritätsprüfungsdienst definiert werden können. Für den Spring Boot-Mikroservice kann Actuator beispielsweise Metriken für Integritätsprüfungen bereitstellen.

Service Discovery

Middleware Infrastruktur

Task Definitions

Wir verwenden Aufgabendefinitionen, um das Verhalten von Mikroservices und die erforderlichen Parameter zu beschreiben.

Der ECS-Cluster ist für die Arbeit mit Fargate-Aufgabendefinitionen und Dienstdefinitionen konfiguriert. Aufgabendefinitionen sind für die gesamte Konfiguration der Anwendung verantwortlich, z. B. Speichernutzung, CPU-Auslastung, Docker-Image-Adresse, Portdefinitionen, Systemvariablen usw.

Die Aufgabendefinition wird während des CI / CD-Prozesses automatisch über GitLab Runner bereitgestellt. Wenn die Aufgabendefinition einsatzbereit ist, ist es Zeit für einen neuen Dienst.

Elastic Container Service

ECS ist für die Bereitstellung und Skalierung von Docker-Images in einer AWS Cloud-Umgebung verantwortlich. Unsere Implementierung ist für die Verwendung eines Replikatservices konfiguriert. Für die Produktionsumgebung wird es auf viele Replikate skaliert.

Elastic Container Registry

Als Docker-Repository verwenden wir das in AWS platzierte ECR-Repository.

Storage Infrastruktur

Relational Database Service

Als Datenspeichersystem wird eine der RDS-Implementierungen wie die MariaDB SQL-Datenbank verwendet.

S3 Simple Cloud Storage

Innerhalb der Anwendung wird ein Bucket für die Handhabung des Ladestationssimulator-Frontends verwendet.

Lambda

Lambda verwendet, um statische Inhalte für den Ladestationssimulator zu sichern.

Network Infrastruktur

VPC

Ein VPS wird für die gesamte Infrastruktur verwendet. Der Datenverkehr wird zwischen privaten (vertrauenswürdigen) und öffentlichen Zonen aufgeteilt.

Subnets

Wir haben 6 Subnetze entworfen, 3 für die private Zone und 3 für die öffentliche Zone.

Private Subnets

• Subnet Private A

• Subnet Private B

• Subnet Private C

Public Subnets

• Subnet Public A

• Subnet Public B

• Subnet Public C

ACL

Wir haben eine ACL-Tabelleneinstellung. Der gesamte öffentliche Verkehr ist deaktiviert.

Internet Gateway

Wir verwenden ein Internet-Gateway, um Datenverkehr an das Internet weiterzuleiten.

Parametrisierung

Parameters

AWS SSM-Parameter werden von ECS-Diensten zur Parametrisierung der Infrastruktur verwendet.

Secret Manager

AWS SSM-Parameter werden von ECS-Diensten verwendet, um gesicherte Elemente zu parametrisieren.

User management

IAM

• ECS verwendet die AWS IAM-Rolle für die Ausführungsaufgabe

• ECS verwendet die AWS IAM-Richtlinie, um geheime Werte von SSM abzurufen

Security Management

Security Groups

• ELB-Sicherheit - Sicherheitsgruppen für Load Balancer

• Lambda-Sicherheit - Sicherheitsgruppen für die Lambda-Funktion

• ECS-Sicherheit - Sicherheitsgruppen für Docker-Dienste

• RDS-Sicherheit - Sicherheitsgruppen für die MariaDB-Datenbank

Logging

Log Gruppen

ede ECS-Dienstinstanz verfügt über eine eigene Protokollgruppe, in der Systemprotokolle gespeichert werden. Es ist sehr wichtig, die Aufbewahrungszeit einzurichten, um das Speichern alter Protokolle zu vermeiden.

Schaffung einer Infrastruktur

Jetzt können wir unsere Cloud-Infrastruktur über CI / CD-Mechanismen direkt auf einem separaten AWS-Sandbox-Konto bereitstellen.

Zero Down Time

Figure 3. Zero Down Time Flow

Failure Prevention

Eine erfolgreiche Bereitstellung ist nur ein Anfang der gesamten Cloud-Migration und Systemwartung. Wir müssen uns möglicher Fehler im Cloud-System bewusst sein, um geeignete Präventionsmechanismen bereitzustellen und zu konfigurieren. Und schließlich sollten wir verstehen, wie mögliche Auswirkungen dieser Probleme behoben werden können.

Kritische Ressourcen

Data Center

Um das Risiko zu bestimmen, müssen wir wissen, wie AWS Data Center mit getrennten Verfügbarkeitszonen funktioniert.

Figure 4. Beispiel für eine AWS-Region mit Zonendesign

Data Center: Region

Die Anwendung kann in einer der AWS-Regionen bereitgestellt werden. Das Risiko eines Ausfalls ist sehr gering. Im Falle eines Fehlers können die Auswirkungen auf die Anwendungsinfrastruktur jedoch nicht ermittelt werden.

Risiken

• Ausfallrisiko: "sehr gering"

• Auswirkungen auf die Anwendung: "nicht bestimmbar"

• Effekt: Systemausfall * ===== Data Center: Verfügbarkeit Zone

Design

• Vollständig isolierte Infrastruktur mit einem oder mehreren Rechenzentren

• Bedeutender Abstand der Trennung

• Einzigartige Energieinfrastruktur

• Viele 100 KB Server im Maßstab

• Rechenzentren, die über eine vollständig redundante und isolierte Metro-Glasfaser verbunden sind

Risiken

• Ausfallrisiko: "mittel"

• Auswirkungen auf die Anwendung: "hoch"

• Auswirkungen auf S3: keine

• Auswirkungen auf RDS: hoch

• Auswirkungen auf ECS: keine

• Effekt: "Möglicher Systemausfall" * ===== Middleware Infrastruktur

ECS

Fargate-Cluster und -Tasks sind hoch verfügbar, wodurch die Nichtverfügbarkeit von Middleware verhindert wird.

Mögliche Szenarien

• Die Logic Compute-Instanz ist fehlerhaft

  • Aktivität: LoadBalancer kennt aus der Integritätsprüfung den Fehler und wechselt die Instanz zu einer anderen

  • Mechanismus: * HA *, * Gesundheitscheck *

• Die Anwendung hat ein Leistungsproblem oder einen Speicherverlust

  • Aktivität: Stellen Sie die vorherige Version oder den Hotfix bereit

Risiken

• Ausfallrisiko: sehr gering

• Auswirkungen auf die Anwendung: sehr hoch

• AWS ECS SLA Level. Monatlicher Prozentsatz der Betriebszeit: Weniger als 99,99%, aber gleich oder größer als 99,0%

Storage

RDS

Figure 5. RDS

Die Datenbank verfügt über einen Mechanismus, der so konfiguriert ist, dass jeden Tag ein Schnappschuss erstellt wird.

Mögliche Szenarien

• Datenbank ist beschädigt

Aktivität: Der Administrator stellt die Datenbank aus dem Snapshot wieder her Mechanismus: Snapshot

Risiken

• Ausfallrisiko: gering

• Risiko eines Softwarefehlers: "mittel"

• Auswirkungen auf die Anwendung: "sehr hoch"

• Effekt: Systemausfall

• AWS RDS SLA Level. Monatlicher Prozentsatz der Betriebszeit: Weniger als 99,95%, aber gleich oder größer als 99,0% In Google Übersetzer öffnen

S3

Figure 6. S3

Die Daten werden im S3-Bucket gespeichert. Mechanismus: * S3-Replikation *, * S3-Versionierung *, * MFA *

Um die Sicherheit zu erhöhen und Datenverlust zu vermeiden, gibt es einen Versionsmechanismus, der für den S3 aktiviert werden kann.

Mögliche Szenarien

• S3-Datei geht verloren oder ist kaputt

  • Aktivität: Der Administrator stellt eine bestimmte Version der Datei mithilfe des Versionsmechanismus wieder her oder stellt die Datei aus der S3-Sicherung wieder her

  • Mechanismus: * S3-Replikation *, * S3-Versionierung *

• S3 ist inkonsistent:

  • Aktivität: Der Administrator kopiert Inhalte aus der S3-Sicherung

  • Mechanismus: * S3-Replikation *

• S3 wurde entfernt:

  • Aktivität: Der Administrator stellt den S3-Bucket aus dem entsprechenden Backup-S3-Bucket wieder her

  • Mechanismus: * MFA *

• S3 und seine Sicherung wird entfernt:

  • Aktivität: Daten gehen verloren

  • Mechanismus: * MFA *

Risiken

• Risiko eines Infrastrukturausfalls: sehr gering

• Risiko eines Softwarefehlers: "mittel"

• Auswirkungen auf die Anwendung: "sehr hoch"

• Effekt: inkonsistente Daten

• AWS S3 SLA Level. Monatlicher Prozentsatz der Betriebszeit: Weniger als 99,9%, aber größer oder gleich 99,0%

Empfehlungen

• Bereiten Sie das Infrastruktur-Audit für alle Unternehmensanforderungen vor

• Bereiten Sie Sicherheitstests vor

• Bereiten Sie Leistungstests vor

• Konfigurieren Sie den AWS WAF-Dienst

• Aktivieren Sie die Verwaltungs-MFA-Option für S3-Daten-Buckets

• Aktivieren Sie die kontenübergreifende Sicherung der Verwaltung

• Geben Sie vertrauliche Daten an, falls vorhanden, aktivieren Sie die Codierung im Ruhezustand

Zusammenfassung

Eine gut gestaltete Cloud-Umgebung kann die Grundlage Ihres Geschäftsmodells sein. Das Wichtigste ist, es richtig zu machen, mit guten und vertrauenswürdigen Standards, um keine Zeit und kein Geld zu verlieren.