Von AWS zu Google Cloud migrieren: Von AWS Lambda zu Cloud Run migrieren

Last reviewed 2024-10-21 UTC

Google Cloud bietet Tools, Produkte, Anleitungen und professionelle Dienste für die Migration serverloser Arbeitslasten von Amazon Web Services (AWS) Lambda zu Google Cloud. Google Cloud bietet zwar mehrere Dienste, mit denen Sie serverlose Anwendungen entwickeln und bereitstellen können, in diesem Dokument liegt der Schwerpunkt jedoch auf der Migration zu Cloud Run, einer serverlosen Laufzeitumgebung. Sowohl AWS Lambda als auch Cloud Run haben Gemeinsamkeiten wie die automatische Ressourcenbereitstellung, die Skalierung durch den Cloud-Anbieter und ein Pay-per-Use-Preismodell.

In diesem Dokument erfahren Sie, wie Sie einen Plan für die Migration serverloser Arbeitslasten von AWS Lambda zu Cloud Run entwerfen, implementieren und validieren. Außerdem bietet sie eine Orientierungshilfe für diejenigen, die die potenziellen Vorteile und den Prozess einer solchen Migration bewerten möchten.

Dieses Dokument ist Teil einer mehrteiligen Reihe zur Migration von AWS zu Google Cloud, die folgende Dokumente enthält:

Weitere Informationen zur Auswahl der richtigen serverlosen Laufzeitumgebung für Ihre Geschäftslogik finden Sie unter Verwaltete Containerlaufzeitumgebung auswählen. Eine umfassende Zuordnung von AWS- und Google Cloud-Diensten finden Sie unter AWS- und Azure-Dienste mit Google Cloud vergleichen.

Für diese Migration zu Google Cloud empfehlen wir die Ausführung des unter Migrate to Google Cloud: Erste Schritte beschriebenen Migrations-Frameworks.

Diese Grafik veranschaulicht den Migrationsprozess:

Migrationspfad mit vier Phasen

Die Migration von Ihrer Quellumgebung zu Google Cloud kann in einer Reihe von Iterationen erfolgen. Beispielsweise können Sie einige Arbeitslasten zuerst und andere später migrieren. Für jede separate Migrationsiteration folgen Sie den Phasen des allgemeinen Migrations-Frameworks:

  1. Arbeitslasten und Daten bewerten und erkennen.
  2. Grundlage in Google Cloud planen und erstellen.
  3. Arbeitslasten und Daten zu Google Cloud migrieren.
  4. Google Cloud-Umgebung optimieren.

Weitere Informationen zu den Phasen dieses Frameworks finden Sie unter Zu Google Cloud migrieren: Erste Schritte.

Um einen effektiven Migrationsplan zu entwerfen, empfehlen wir, jeden Schritt des Plans zu validieren und sicherzustellen, dass Sie eine Rollback-Strategie haben. Informationen zur Validierung Ihres Migrationsplans finden Sie unter Migrate to Google Cloud: Best Practices zur Validierung eines Migrationsplans.

Die Migration serverloser Arbeitslasten umfasst häufig mehr als nur die Übertragung von Funktionen von einem Cloud-Anbieter zum anderen. Da cloudbasierte Anwendungen auf einem vernetzten Dienstnetzwerk basieren, müssen bei der Migration von AWS zu Google Cloud möglicherweise abhängige AWS-Dienste durch Google Cloud-Dienste ersetzt werden. Angenommen, Ihre Lambda-Funktion interagiert mit Amazon SQS und Amazon SNS. Wenn Sie diese Funktion migrieren möchten, müssen Sie wahrscheinlich Pub/Sub und Cloud Tasks verwenden, um eine ähnliche Funktionalität zu erzielen.

Die Migration bietet Ihnen auch die Möglichkeit, die Architektur und Designentscheidungen Ihrer serverlosen Anwendung gründlich zu überprüfen. Bei dieser Überprüfung können Sie möglicherweise folgende Möglichkeiten entdecken:

  • Mit integrierten Google Cloud-Funktionen optimieren: Prüfen Sie, ob Google Cloud-Dienste einzigartige Vorteile bieten oder besser zu den Anforderungen Ihrer Anwendung passen.
  • Architektur vereinfachen: Prüfen Sie, ob eine Optimierung möglich ist, indem Sie Funktionen zusammenführen oder Dienste in Google Cloud anders verwenden.
  • Kosteneffizienz verbessern: Bewerten Sie die potenziellen Kostenunterschiede beim Ausführen Ihrer überarbeiteten Anwendung in der Google Cloud-Infrastruktur.
  • Codeeffizienz verbessern: Refaktorisieren Sie Ihren Code parallel zur Migration.

Planen Sie die Migration strategisch. Betrachten Sie die Migration nicht als Rehost-Vorgang (Lift-and-Shift). Nutzen Sie die Migration als Chance, das Gesamtdesign und die Codequalität Ihrer serverlosen Anwendung zu verbessern.

Quellumgebung bewerten

In der Bewertungsphase bestimmen Sie die Anforderungen und Abhängigkeiten für die Migration Ihrer Quellumgebung zu Google Cloud.

Die Bewertungsphase ist für den Erfolg der Migration entscheidend. Sie benötigen umfassende Kenntnisse über die zu migrierenden Arbeitslasten, deren Anforderungen, Abhängigkeiten und über Ihre aktuelle Umgebung. Sie müssen Ihre Ausgangssituation verstehen, um eine Google Cloud-Migration erfolgreich planen und ausführen zu können.

Die Bewertungsphase umfasst die folgenden Aufgaben:

  1. Ein umfassendes Inventar Ihrer Arbeitslasten erstellen.
  2. Arbeitslasten nach ihren Attributen und Abhängigkeiten katalogisieren.
  3. Die Teams auf Google Cloud vorbereiten.
  4. Tests und Proofs of Concept in Google Cloud erstellen.
  5. Die Gesamtbetriebskosten (TCO) der Zielumgebung berechnen.
  6. Migrationsstrategie für Ihre Arbeitslasten auswählen.
  7. Tools für die Migration auswählen.
  8. Migrationsplan und Zeitplan definieren.
  9. Migrationsplan validieren.

Weitere Informationen zur Bewertungsphase und zu diesen Aufgaben finden Sie unter Zu Google Cloud migrieren: Arbeitslasten bewerten und erkennen. Die folgenden Abschnitte basieren auf Informationen in jenem Dokument.

Inventar Ihrer AWS Lambda-Arbeitslasten erstellen

Um den Umfang Ihrer Migration zu definieren, erstellen Sie ein Inventar und erfassen Informationen zu Ihren AWS Lambda-Arbeitslasten.

Um ein Inventar Ihrer AWS Lambda-Arbeitslasten zu erstellen, empfehlen wir Ihnen, einen Mechanismus zur Datenerhebung zu implementieren, der auf AWS APIs, AWS-Entwicklertools und der AWS-Befehlszeile basiert.

Nachdem Sie Ihr Inventar erstellt haben, sollten Sie Informationen zu jeder AWS Lambda-Arbeitslast im Inventar erfassen. Konzentrieren Sie sich bei jeder Arbeitslast auf Aspekte, mit denen Sie potenzielle Probleme antizipieren können. Analysieren Sie diese Arbeitslast auch, um zu verstehen, wie Sie die Arbeitslast und ihre Abhängigkeiten möglicherweise ändern müssen, bevor Sie zu Cloud Run migrieren. Wir empfehlen, zuerst Daten zu den folgenden Aspekten jeder AWS Lambda-Arbeitslast zu erfassen:

  • Der Anwendungsfall und das Design
  • Das Quellcode-Repository
  • Die Bereitstellungsartefakte
  • Aufruf, Trigger und Ausgabe
  • Laufzeit- und Ausführungsumgebungen
  • Die Arbeitslastkonfiguration
  • Zugriffssteuerung und Berechtigungen
  • Compliance- und rechtliche Anforderungen
  • Bereitstellungs- und Betriebsabläufe

Anwendungsfall und Design

Wenn Sie Informationen zum Anwendungsfall und zum Design der Arbeitslasten erfassen, können Sie eine geeignete Migrationsstrategie ermitteln. Anhand dieser Informationen können Sie auch feststellen, ob Sie Ihre Arbeitslasten und ihre Abhängigkeiten vor der Migration ändern müssen. Für jede Arbeitslast empfehlen wir Folgendes:

  • Sie erhalten Informationen zum spezifischen Anwendungsfall, für den die Arbeitslast dient, und identifizieren Abhängigkeiten von anderen Systemen, Ressourcen oder Prozessen.
  • Analysieren Sie das Design und die Architektur der Arbeitslast.
  • Bewerten Sie die Latenzanforderungen der Arbeitslast.

Quellcode-Repository

Wenn Sie den Quellcode Ihrer AWS Lambda-Funktionen inventarisieren, können Sie Ihre AWS Lambda-Arbeitslasten für die Kompatibilität mit Cloud Run umstrukturieren. Um dieses Inventar zu erstellen, müssen Sie die Codebasis im Blick behalten, die in der Regel in Versionskontrollsystemen wie Git oder in Entwicklungsplattformen wie GitHub oder GitLab gespeichert ist. Das Inventar Ihres Quellcodes ist für Ihre DevOps-Prozesse wie CI/CD-Pipelines (Continuous Integration/Continuous Development) unerlässlich, da diese Prozesse auch aktualisiert werden müssen, wenn Sie zu Cloud Run migrieren.

Bereitstellungsartefakte

Wenn Sie wissen, welche Bereitstellungsartefakte für die Arbeitslast erforderlich sind, können Sie besser nachvollziehen, ob Sie Ihre AWS Lambda-Arbeitslasten möglicherweise umstrukturieren müssen. Ermitteln Sie, welche Bereitstellungsartefakte für die Arbeitslast erforderlich sind, und erfassen Sie dazu die folgenden Informationen:

  • Der Typ des Bereitstellungspakets, mit dem die Arbeitslast bereitgestellt werden soll.
  • Jede AWS Lambda-Ebene, die zusätzlichen Code enthält, z. B. Bibliotheken und andere Abhängigkeiten.
  • Alle AWS Lambda-Erweiterungen, von denen die Arbeitslast abhängt.
  • Die von Ihnen konfigurierten Qualifikationen zum Angeben von Versionen und Aliassen.
  • Die Version der bereitgestellten Arbeitslast.

Aufruf, Trigger und Ausgabe

AWS Lambda unterstützt mehrere Aufrufmechanismen, z. B. Trigger, und verschiedene Aufrufmodelle, z. B. synchrone und asynchrone Aufrufe. Für jede AWS Lambda-Arbeitslast empfehlen wir, die folgenden Informationen zu Triggern und Aufrufen zu erfassen:

  • Die Trigger und Ereignisquellenzuordnungen, die die Arbeitslast aufrufen.
  • Ob die Arbeitslast synchrone und asynchrone Aufrufe unterstützt.
  • Die URLs und HTTP(S)-Endpunkte der Arbeitslast.

Ihre AWS Lambda-Arbeitslasten können mit anderen Ressourcen und Systemen interagieren. Sie müssen wissen, welche Ressourcen die Ausgaben Ihrer AWS Lambda-Arbeitslasten verbrauchen und wie diese Ressourcen diese Ausgaben verbrauchen. Anhand dieser Informationen können Sie feststellen, ob Sie etwas ändern müssen, das von diesen Ergebnissen abhängen könnte, z. B. andere Systeme oder Arbeitslasten. Für jede AWS Lambda-Arbeitslast empfehlen wir, die folgenden Informationen zu anderen Ressourcen und Systemen zu erfassen:

  • Die Zielressourcen, an die die Arbeitslast Ereignisse senden kann.
  • Die Ziele, an die Informationsdatensätze für asynchrone Aufrufe gesendet werden.
  • Das Format der Ereignisse, die von der Arbeitslast verarbeitet werden.
  • Wie Ihre AWS Lambda-Arbeitslast und ihre Erweiterungen mit AWS Lambda-APIs oder anderen AWS-APIs interagieren.

Damit Ihre AWS Lambda-Arbeitslasten funktionieren, müssen sie möglicherweise persistente Daten speichern und mit anderen AWS-Diensten interagieren. Für jede AWS Lambda-Arbeitslast empfehlen wir, die folgenden Informationen zu Daten und anderen Diensten zu erfassen:

  • Ob die Arbeitslast auf Virtual Private Clouds (VPCs) oder andere private Netzwerke zugreift.
  • Wie die Arbeitslast nichtflüchtige Daten speichert, z. B. mithilfe von sitzungsspezifischen Datenspeichern und Amazon Elastic File System (EFS).

Laufzeit- und Ausführungsumgebungen

AWS Lambda unterstützt mehrere Ausführungsumgebungen für Ihre Arbeitslasten. Damit AWS Lambda-Ausführungsumgebungen korrekt Cloud Run-Ausführungsumgebungen zugeordnet werden können, empfehlen wir, für jede AWS Lambda-Arbeitslast Folgendes zu prüfen:

  • Die Ausführungsumgebung der Arbeitslast.
  • Die Befehlssatzarchitektur des Computerprozessors, auf dem die Arbeitslast ausgeführt wird.

Wenn Ihre AWS Lambda-Arbeitslasten in sprachspezifischen Laufzeitumgebungen ausgeführt werden, sollten Sie für jede AWS Lambda-Arbeitslast Folgendes beachten:

  • Der Typ, die Version und die eindeutige Kennung der sprachspezifischen Laufzeitumgebung.
  • Alle Änderungen, die Sie an der Laufzeitumgebung vorgenommen haben.

Arbeitslastkonfiguration

Damit Sie Ihre Arbeitslasten bei der Migration von AWS Lambda zu Cloud Run konfigurieren können, empfehlen wir Ihnen, die Konfiguration der einzelnen AWS Lambda-Arbeitslasten zu prüfen.

Erfassen Sie für jede AWS Lambda-Arbeitslast Informationen zu den folgenden Einstellungen für Parallelität und Skalierbarkeit:

  • Die Gleichzeitigkeitserkennung.
  • Die Skalierungseinstellungen.
  • Die Konfiguration der Instanzen der Arbeitslast in Bezug auf die verfügbare Arbeitsspeichermenge und die zulässige maximale Ausführungszeit.
  • Ob für die Arbeitslast AWS Lambda SnapStart, die reservierte Nebenläufigkeit oder die bereitgestellte Nebenläufigkeit verwendet wird, um die Latenz zu reduzieren.
  • Die von Ihnen konfigurierten Umgebungsvariablen sowie die von AWS Lambda konfigurierten Umgebungsvariablen, von denen die Arbeitslast abhängt.
  • Die Tags und die attributbasierte Zugriffssteuerung.
  • Der Zustandsautomat zum Umgang mit Ausnahmebedingungen.
  • Die Basis-Images und Konfigurationsdateien (z. B. das Dockerfile) für Bereitstellungspakete, die Container-Images verwenden.

Zugriffssteuerung und Berechtigungen

Im Rahmen Ihrer Bewertung empfehlen wir Ihnen, die Sicherheitsanforderungen Ihrer AWS Lambda-Arbeitslasten und deren Konfiguration im Hinblick auf Zugriffssteuerung und Verwaltung zu bewerten. Diese Informationen sind wichtig, wenn Sie ähnliche Steuerelemente in Ihrer Google Cloud-Umgebung implementieren müssen. Berücksichtigen Sie für jede Arbeitslast Folgendes:

  • Die Ausführungsrolle und die Berechtigungen.
  • Die Identitäts- und Zugriffsverwaltungskonfiguration, die die Arbeitslast und ihre Schichten für den Zugriff auf andere Ressourcen verwenden.
  • Die Identitäts- und Zugriffsverwaltungskonfiguration, die andere Konten und Dienste für den Zugriff auf die Arbeitslast verwenden.
  • Die Governance-Kontrollen

Compliance- und rechtliche Anforderungen

Informieren Sie sich für jede AWS Lambda-Arbeitslast über die Compliance- und rechtlichen Anforderungen:

  • Prüfen Sie, ob die Arbeitslast Compliance- und behördliche Anforderungen erfüllen muss.
  • Prüfen Sie, ob die Arbeitslast diese Anforderungen derzeit erfüllt.
  • Prüfen Sie, ob es zukünftige Anforderungen gibt, die erfüllt werden müssen.

Compliance- und rechtliche Anforderungen sind möglicherweise unabhängig vom von Ihnen verwendeten Cloud-Anbieter und können sich auch auf die Migration auswirken. Beispielsweise müssen Sie möglicherweise dafür sorgen, dass Daten- und Netzwerkverkehr innerhalb der Grenzen bestimmter Regionen bleibt, z. B. der Europäischen Union (EU).

Bereitstellungs- und operative Prozesse bewerten

Es ist wichtig, ein klares Verständnis von der Funktionsweise Ihrer Bereitstellungs- und Betriebsprozesse zu haben. Diese Prozesse sind ein grundlegender Teil der Praktiken, die die Produktionsumgebung und die dort ausgeführten Arbeitslasten vorbereiten und verwalten.

Die Bereitstellungs- und Betriebsprozesse können die Artefakte erstellen, die Ihre Arbeitslasten benötigen. Daher sollten Sie Informationen zu jedem Artefakttyp erfassen. Ein Artefakt kann beispielsweise ein Betriebssystempaket, ein Bereitstellungspaket für Anwendungen, ein Betriebssystem-Image, ein Container-Image oder etwas anderes sein.

Berücksichtigen Sie zusätzlich zum Artefakttyp, wie Sie die folgenden Aufgaben ausführen:

  • Entwickeln Sie Ihre Arbeitslasten: Bewerten Sie die Prozesse, die Entwicklungsteams zum Erstellen Ihrer Arbeitslasten eingerichtet haben. Wie entwerfen, codieren und testen Ihre Entwicklungsteams beispielsweise Ihre Arbeitslasten?
  • Generieren Sie Artefakte, die Sie in Ihrer Quellumgebung bereitstellen. Zum Bereitstellen Ihrer Arbeitslasten in der Quellumgebung generieren Sie möglicherweise bereitstellbare Artefakte wie Container-Images oder Betriebssystem-Images oder passen vorhandene Artefakte an, z. B. Betriebssystemimages von Drittanbietern durch Installieren und Konfigurieren von Software. Durch Erfassen von Informationen zum Generieren dieser Artefakte können Sie dafür sorgen, dass die generierten Artefakte für die Bereitstellung in Google Cloud geeignet sind.

  • Artefakte speichern: Wenn Sie Artefakte in einer Artefakt-Registry in Ihrer Quellumgebung speichern, müssen Sie die Artefakte in Ihrer Google Cloud-Umgebung verfügbar machen. Verwenden Sie dazu Strategien wie die folgenden:

    • Richten Sie eine Kommunikationskanal zwischen den Umgebungen ein: Artefakte in der Quellumgebung werden über die Google Cloud-Zielumgebung erreichbar.
    • Refaktorieren Sie den Artefakt-Build-Prozess: Führen Sie eine geringfügige Refaktorierung Ihrer Quellumgebung durch, damit Sie Artefakte sowohl in der Quell- als auch in der Zielumgebung speichern können. Dieser Ansatz unterstützt die Migration durch Erstellen einer Infrastruktur wie ein Artefakt-Repository, bevor Sie Artefakterstellungsprozesse in der Google Cloud-Zielumgebung implementieren müssen. Sie können diesen Ansatz direkt implementieren oder auf dem vorherigen Ansatz aufbauen, der zuerst einen Kommunikationskanal einrichtet.

    Wenn Artefakte sowohl in der Quell- als auch in der Zielumgebung verfügbar sind, können Sie sich auf die Migration konzentrieren, ohne im Rahmen der Migration Artefakterstellungsprozesse in der Google Cloud-Zielumgebung implementieren zu müssen.

  • Scannen und signieren Sie Code . Im Rahmen Ihrer Artefakterstellungsprozesse verwenden Sie möglicherweise Codescans, um sich vor allgemeinen Sicherheitslücken und unbeabsichtigten Netzwerken zu schützen, sowie Codesignaturen, die dafür sorgen, dass nur vertrauenswürdiger Code in Ihren Umgebungen ausgeführt wird.

  • Stellen Sie Artefakte in der Quellumgebung bereit. Nachdem Sie bereitstellbare Artefakte generiert haben, stellen Sie diese möglicherweise in Ihrer Quellumgebung bereit. Wir empfehlen, jeden Bereitstellungsprozess zu bewerten. Die Bewertung sorgt dafür, dass Ihre Bereitstellungsprozesse mit Google Cloud kompatibel sind. Außerdem können Sie damit den Aufwand ermitteln, der für eine eventuelle Refaktorierung der Prozesse erforderlich ist. Wenn Ihre Bereitstellungsprozesse beispielsweise nur mit Ihrer Quellumgebung funktionieren, müssen Sie sie unter Umständen so refaktorieren, dass sie auf Ihre Google Cloud-Umgebung abzielen.

  • Laufzeitkonfiguration einfügen. Sie können die Laufzeitkonfiguration für bestimmte Cluster, Laufzeitumgebungen oder Arbeitslastbereitstellungen einfügen. Die Konfiguration kann Umgebungsvariablen und andere Konfigurationswerte wie Secrets, Anmeldedaten und Schlüssel initialisieren. Damit Ihre Prozesse zur Einfügung von Laufzeitkonfigurationen in Google Cloud funktionieren, empfehlen wir Ihnen zu bewerten, wie Sie die Arbeitslasten konfigurieren, die in Ihrer Quellumgebung ausgeführt werden.

  • Logging, Monitoring und Profilerstellung: Bewerten Sie die Logging-, Monitoring- und Profilerstellungsprozesse, die Sie eingerichtet haben, um den Zustand Ihrer Quellumgebung, die relevanten Messwerte und die Verwendung der Daten zu überwachen, die von diesen Prozessen bereitgestellt werden.

  • Authentifizierung Prüfen Sie, wie Sie sich in Ihrer Quellumgebung authentifizieren.

  • Ressourcen bereitstellen und konfigurieren Zur Vorbereitung Ihrer Quellumgebung haben Sie möglicherweise Prozesse entwickelt und implementiert, die Ressourcen bereitstellen und konfigurieren. Beispielsweise verwenden Sie Terraform zusammen mit Konfigurationsverwaltungstools, um Ressourcen in der Quellumgebung bereitzustellen und zu konfigurieren.

Bewertung abschließen

Nachdem Sie das Inventar aus Ihrer AWS Lambda-Umgebung erstellt haben, schließen Sie die restlichen Aktivitäten der Bewertungsphase ab, wie unter Zu Google Cloud migrieren: Arbeitslasten bewerten und erkennen beschrieben.

Grundlage planen und aufbauen

In der Planungs- und Erstellungsphase stellen Sie die Infrastruktur bereit und konfigurieren sie für Folgendes:

  • Unterstützung Ihrer Arbeitslasten in Ihrer Google Cloud-Umgebung.
  • Verbinden Ihrer Quellumgebung und Ihrer Google Cloud-Umgebung, um die Migration abzuschließen.

Die Planungs- und Erstellungsphase besteht aus den folgenden Aufgaben:

  1. Erstellen Sie eine Ressourcenhierarchie.
  2. Konfigurieren Sie Identity and Access Management (IAM) von Google Cloud.
  3. Richten Sie die Abrechnung ein.
  4. Richten Sie die Netzwerkverbindung ein.
  5. Erhöhen Sie die Sicherheit.
  6. Logging, Monitoring und Benachrichtigungen einrichten

Weitere Informationen zu den einzelnen Aufgaben finden Sie unter Migrate to Google Cloud: Planen und erstellen Sie Ihre Grundlage.

AWS Lambda-Arbeitslasten migrieren

So migrieren Sie Ihre Arbeitslasten von AWS Lambda zu Cloud Run:

  1. Cloud Run-Umgebung entwerfen, bereitstellen und konfigurieren
  2. Refaktorisieren Sie Ihre AWS Lambda-Arbeitslasten bei Bedarf, damit sie mit Cloud Run kompatibel sind.
  3. Refaktorisieren Sie Ihre Bereitstellungs- und Betriebsabläufe, um Arbeitslasten in Cloud Run bereitzustellen und zu beobachten.
  4. Migrieren Sie die Daten, die für Ihre AWS Lambda-Arbeitslasten erforderlich sind.
  5. Prüfen Sie die Migrationsergebnisse in Bezug auf Funktionalität, Leistung und Kosten.

Um Probleme während der Migration zu vermeiden und den für die Migration erforderlichen Aufwand zu schätzen, empfehlen wir Ihnen zu prüfen, wie sich AWS Lambda-Features mit ähnlichen Cloud Run-Features vergleichen lassen. Die Funktionen von AWS Lambda und Cloud Run können beim Vergleich ähnlich aussehen. Die Unterschiede beim Design und bei der Implementierung der Features bei den beiden Cloud-Anbietern können sich jedoch erheblich auf die Migration von AWS Lambda zu Cloud Run auswirken. Diese Unterschiede können sowohl Ihre Design- als auch Ihre Refactoring-Entscheidungen beeinflussen, wie in den folgenden Abschnitten hervorgehoben.

Cloud Run-Umgebung entwerfen, bereitstellen und konfigurieren

Der erste Schritt in der Migrationsphase besteht darin, Ihre Cloud Run-Umgebung so zu gestalten, dass sie die Arbeitslasten unterstützt, die Sie von AWS Lambda migrieren.

Verwenden Sie die Daten, die Sie in der Bewertungsphase zu jeder AWS Lambda-Arbeitslast erfasst haben, um Ihre Cloud Run-Umgebung richtig zu entwerfen. Mithilfe dieser Daten können Sie Folgendes tun:

  1. Wählen Sie die richtigen Cloud Run-Ressourcen für die Bereitstellung Ihrer Arbeitslast aus.
  2. Cloud Run-Ressourcenkonfiguration entwerfen
  3. Cloud Run-Ressourcen bereitstellen und konfigurieren

Die richtigen Cloud Run-Ressourcen auswählen

Wählen Sie für jede zu migrierende AWS Lambda-Arbeitslast die richtige Cloud Run-Ressource zum Bereitstellen Ihrer Arbeitslasten aus. Cloud Run unterstützt die folgenden Hauptressourcen:

  • Cloud Run-Dienste: Eine Ressource, die eine containerisierte Laufzeitumgebung hostet, einen eindeutigen Endpunkt bereitstellt und die zugrunde liegende Infrastruktur automatisch nach Bedarf skaliert.
  • Cloud Run-Jobs: Eine Ressource, mit der ein oder mehrere Container vollständig ausgeführt werden.

In der folgenden Tabelle wird zusammengefasst, wie AWS Lambda-Ressourcen diesen Hauptressourcen von Cloud Run zugeordnet sind:

AWS Lambda-Ressource Cloud Run-Ressource
AWS Lambda-Funktion, die durch ein Ereignis ausgelöst wird, z. B. solche, die für Websites und Webanwendungen, APIs und Mikrodienste, die Streamingdatenverarbeitung und ereignisgesteuerte Architekturen verwendet werden. Cloud Run-Dienst, den Sie mit Triggern aufrufen können.
Eine AWS Lambda-Funktion, die geplant wurde, z. B. für Hintergrundaufgaben und Batchjobs. Cloud Run-Job, der vollständig ausgeführt wird.

Neben Diensten und Jobs bietet Cloud Run zusätzliche Ressourcen, die diese Hauptressourcen erweitern. Weitere Informationen zu allen verfügbaren Cloud Run-Ressourcen finden Sie unter Cloud Run-Ressourcenmodell.

Cloud Run-Ressourcenkonfiguration entwerfen

Bevor Sie Ihre Cloud Run-Ressourcen bereitstellen und konfigurieren, entwerfen Sie die Konfiguration. Bestimmte AWS Lambda-Konfigurationsoptionen, z. B. Ressourcenlimits und Zeitüberschreitungen für Anfragen, sind mit ähnlichen Cloud Run-Konfigurationsoptionen vergleichbar. In den folgenden Abschnitten werden die Konfigurationsoptionen beschrieben, die in Cloud Run für Dienstauslöser und Jobausführung, Ressourcenkonfiguration und Sicherheit verfügbar sind. In diesen Abschnitten werden auch AWS Lambda-Konfigurationsoptionen hervorgehoben, die mit denen in Cloud Run vergleichbar sind.

Cloud Run-Diensttrigger und Jobausführung

Dienstauslöser und Jobausführung sind die wichtigsten Designentscheidungen, die Sie bei der Migration Ihrer AWS Lambda-Arbeitslasten berücksichtigen müssen. Cloud Run bietet verschiedene Optionen zum Auslösen und Ausführen der ereignisbasierten Arbeitslasten, die in AWS Lambda verwendet werden. Außerdem bietet Cloud Run Optionen für Streaming-Arbeitslasten und geplante Jobs.

Wenn Sie Ihre Arbeitslasten migrieren, ist es oft hilfreich, zuerst zu erfahren, welche Trigger und Mechanismen in Cloud Run verfügbar sind. Diese Informationen helfen Ihnen, die Funktionsweise von Cloud Run besser zu verstehen. Anhand dieser Informationen können Sie dann ermitteln, welche Cloud Run-Funktionen mit AWS Lambda-Funktionen vergleichbar sind und welche Cloud Run-Funktionen bei der Refaktorisierung dieser Arbeitslasten verwendet werden könnten.

Weitere Informationen zu den Diensttriggern, die Cloud Run bietet, finden Sie unter den folgenden Links:

  • HTTPS-Aufruf: Senden Sie HTTPS-Anfragen, um Cloud Run-Dienste auszulösen.
  • HTTP/2-Aufruf: Senden Sie HTTP/2-Anfragen, um Cloud Run-Dienste auszulösen.
  • WebSockets: Verbinden von Clients mit einem WebSockets-Server, der auf Cloud Run ausgeführt wird.
  • gRPC-Verbindungen: Sie können mit gRPC eine Verbindung zu Cloud Run-Diensten herstellen.
  • Asynchroner Aufruf: Aufgaben mit Cloud Tasks in die Warteschlange stellen, damit sie asynchron von Cloud Run-Diensten verarbeitet werden.
  • Geplanter Aufruf: Mit Cloud Scheduler können Sie Cloud Run-Dienste nach einem Zeitplan aufrufen.
  • Ereignisbasierte Aufrufe: Sie können Eventarc-Trigger erstellen, um Cloud Run-Dienste bei bestimmten Ereignissen im CloudEvents-Format aufzurufen.
  • Integration mit Pub/Sub: Cloud Run-Dienste über Pub/Sub-Push-Abos aufrufen.
  • Einbindung in Workflows: Sie können einen Cloud Run-Dienst aus einem Workflow aufrufen.

Weitere Informationen zu den Jobausführungsmechanismen von Cloud Run finden Sie in den folgenden Ressourcen:

In der folgenden Tabelle sehen Sie, welche Cloud Run-Aufruf- oder Ausführungsmechanismen mit AWS Lambda-Aufrufmechanismen vergleichbar sind. Wählen Sie für jede Cloud Run-Ressource, die Sie bereitstellen müssen, den richtigen Aufruf- oder Ausführungsmechanismus aus.

AWS Lambda-Funktion Cloud Run-Funktion
HTTPS-Trigger (Funktions-URLs) HTTPS-Aufruf
HTTP/2-Trigger (teilweise unterstützt über ein externes API-Gateway) HTTP/2-Aufruf (nativ unterstützt)
WebSockets (unterstützt über externes API-Gateway) WebSockets (nativ unterstützt)
– (gRPC-Verbindungen werden nicht unterstützt) gRPC-Verbindungen
Asynchrone Aufrufe Cloud Tasks-Integration
Geplante Aufrufe Cloud Scheduler-Integration
Ereignisbasierter Trigger in einem proprietären Ereignisformat Ereignisbasierte Aufrufe im CloudEvents-Format
Integration von Amazon SQS und Amazon SNS Pub/Sub-Integration
AWS Lambda Step Functions Workflow-Integration
Cloud Run-Ressourcenkonfiguration

Zusätzlich zu den Designentscheidungen, die Sie für das Auslösen und Ausführen Ihrer migrierten Arbeitslasten getroffen haben, unterstützt Cloud Run mehrere Konfigurationsoptionen, mit denen Sie verschiedene Aspekte der Laufzeitumgebung optimieren können. Diese Konfigurationsoptionen umfassen Ressourcendienste und Jobs.

Wie bereits erwähnt, können Sie die Funktionsweise von Cloud Run besser nachvollziehen, wenn Sie sich zuerst mit allen verfügbaren Konfigurationsoptionen vertraut machen. So können Sie AWS Lambda-Funktionen mit ähnlichen Cloud Run-Funktionen vergleichen und leichter entscheiden, wie Sie Ihre Arbeitslasten umstrukturieren.

Weitere Informationen zu den Konfigurationen, die Cloud Run-Dienste bieten, finden Sie in den folgenden Ressourcen:

Weitere Informationen zu den Jobs, die Cloud Run bietet, finden Sie in den folgenden Ressourcen:

In der folgenden Tabelle sehen Sie, welche Cloud Run-Konfigurationsoptionen mit den AWS Lambda-Konfigurationsoptionen vergleichbar sind. Wählen Sie für jede Cloud Run-Ressource, die Sie bereitstellen müssen, die richtigen Konfigurationsoptionen aus.

AWS Lambda-Funktion Cloud Run-Funktion
Bereitgestellte Parallelität Mindestanzahl von Instanzen
Reservierte Nebenläufigkeit pro Instanz
(Der Nebenläufigkeitspool wird von AWS Lambda-Funktionen in Ihrem AWS-Konto gemeinsam genutzt.)		 Maximale Anzahl von Instanzen pro Dienst
– (nicht unterstützt, eine Anfrage wird einer Instanz zugeordnet) Gleichzeitige Anfragen pro Instanz
– (von der Arbeitsspeicherzuweisung abhängig) CPU-Zuweisung
Skalierbarkeitseinstellungen Instanz-Autoscaling für Dienste
Parallelität für Jobs
Instanzkonfiguration (CPU, Arbeitsspeicher) CPU- und Arbeitsspeicherlimits
Maximale Ausführungszeit Zeitlimit für Anfragen an Dienste
Zeitlimit für Aufgaben bei Jobs
AWS Lambda SnapStart CPU-Boost beim Starten
Umgebungsvariablen Umgebungsvariablen
Sitzungsspezifischer Speicher In-Memory-Volume-Bereitstellungen
Amazon Elastic File System-Verbindungen NFS-Volume-Bereitstellungen
S3-Volume-Bereitstellungen werden nicht unterstützt Cloud Storage-Volume-Bereitstellungen
AWS Secrets Manager in AWS Lambda-Arbeitslasten Secrets
Workload-URLs und HTTP(S)-Endpunkte Automatisch zugewiesene URLs
Cloud Run-Integrationen mit Google Cloud-Produkten
Sitzungsbindung (mit einem externen Load Balancer) Sitzungsaffinität
Qualifikationen Revisionen

Zusätzlich zu den in der vorherigen Tabelle aufgeführten Funktionen sollten Sie auch die Unterschiede zwischen der Bereitstellung von Instanzen der Ausführungsumgebung mit AWS Lambda und Cloud Run berücksichtigen. AWS Lambda stellt für jede gleichzeitige Anfrage eine einzelne Instanz bereit. Mit Cloud Run können Sie jedoch die Anzahl der gleichzeitigen Anfragen festlegen, die von einer Instanz verarbeitet werden können. Das Bereitstellungsverhalten von AWS Lambda entspricht also dem Festlegen der maximalen Anzahl gleichzeitiger Anfragen pro Instanz in Cloud Run auf 1. Wenn Sie die maximale Anzahl gleichzeitiger Anfragen auf einen Wert über 1 festlegen, können Sie erheblich Kosten sparen, da die CPU und der Arbeitsspeicher der Instanz von den gleichzeitigen Anfragen gemeinsam genutzt werden, aber nur einmal in Rechnung gestellt werden. Die meisten HTTP-Frameworks sind für die parallele Verarbeitung von Anfragen ausgelegt.

Sicherheit und Zugriffssteuerung in Cloud Run

Wenn Sie Ihre Cloud Run-Ressourcen entwerfen, müssen Sie auch die Sicherheits- und Zugriffssteuerungen festlegen, die Sie für Ihre migrierten Arbeitslasten benötigen. Cloud Run unterstützt mehrere Konfigurationsoptionen, mit denen Sie Ihre Umgebung schützen und Rollen und Berechtigungen für Ihre Cloud Run-Arbeitslasten festlegen können.

In diesem Abschnitt werden die Sicherheits- und Zugriffssteuerungen beschrieben, die in Cloud Run verfügbar sind. Anhand dieser Informationen können Sie nachvollziehen, wie Ihre migrierten Arbeitslasten in Cloud Run funktionieren, und die Cloud Run-Optionen ermitteln, die Sie möglicherweise benötigen, wenn Sie diese Arbeitslasten neu strukturieren.

Weitere Informationen zu den Authentifizierungsmechanismen von Cloud Run finden Sie in den folgenden Ressourcen:

Weitere Informationen zu den Sicherheitsfunktionen von Cloud Run finden Sie in den folgenden Ressourcen:

In der folgenden Tabelle sehen Sie, welche Cloud Run-Sicherheits- und Zugriffssteuerungen mit denen in AWS Lambda vergleichbar sind. Wählen Sie für jede Cloud Run-Ressource, die Sie bereitstellen müssen, die richtigen Zugriffssteuerungen und Sicherheitsfunktionen aus.

AWS Lambda-Funktion Cloud Run-Funktion
Zugriffssteuerung mit AWS Identity Access and Management Zugriffssteuerung mit IAM von Google Cloud
Rolle für die Ausführung IAM-Rolle von Google Cloud
Berechtigungsgrenzen IAM-Berechtigungen und benutzerdefinierte Zielgruppen in Google Cloud
Governance-Kontrollen Organisationsrichtliniendienst
Codesignierung Binärautorisierung
Vollständiger VPC-Zugriff Detaillierte Zugriffssteuerung für ausgehenden VPC-Traffic

Cloud Run-Ressourcen bereitstellen und konfigurieren

Nachdem Sie die Cloud Run-Ressourcen für die Bereitstellung Ihrer Arbeitslasten ausgewählt haben, stellen Sie diese bereit und konfigurieren sie. Weitere Informationen zur Bereitstellung von Cloud Run-Ressourcen finden Sie unter:

AWS Lambda-Arbeitslasten refaktorisieren

Wenn Sie Ihre AWS Lambda-Arbeitslasten zu Cloud Run migrieren möchten, müssen Sie sie möglicherweise refaktorisieren. Wenn eine ereignisbasierte Arbeitslast beispielsweise Trigger akzeptiert, die Amazon CloudWatch-Ereignisse enthalten, müssen Sie diese Arbeitslast möglicherweise so refaktorisieren, dass sie Ereignisse im CloudEvents-Format akzeptiert.

Es gibt mehrere Faktoren, die sich auf den Umfang des Refaktorings auswirken können, das für jede AWS Lambda-Arbeitslast erforderlich ist, z. B.:

  • Architektur Überlegen Sie, wie die Arbeitslast architektonisch gestaltet ist. Bei AWS Lambda-Arbeitslasten, bei denen die Geschäftslogik klar von der Logik zum Zugriff auf AWS-spezifische APIs getrennt ist, ist beispielsweise weniger Refactoring erforderlich als bei Arbeitslasten, bei denen die beiden Logiken vermischt sind.
  • Idempotenz: Überlegen Sie, ob die Arbeitslast idempotent in Bezug auf ihre Eingaben ist. Für eine Arbeitslast, die idempotent für Eingaben ist, ist möglicherweise weniger Refactoring erforderlich als für Arbeitslasten, die den Status der bereits verarbeiteten Eingaben beibehalten müssen.
  • Status Überlegen Sie, ob die Arbeitslast zustandslos ist. Für eine zustandslose Arbeitslast ist möglicherweise weniger Refaktorisierung erforderlich als für Arbeitslasten, die den Status beibehalten. Weitere Informationen zu den von Cloud Run unterstützten Diensten zum Speichern von Daten finden Sie unter Cloud Run-Speicheroptionen.
  • Laufzeitumgebung. Überlegen Sie, ob die Arbeitslast Annahmen über die Laufzeitumgebung trifft. Für diese Arten von Arbeitslasten müssen Sie möglicherweise dieselben Annahmen in der Cloud Run-Laufzeitumgebung erfüllen oder die Arbeitslast umstrukturieren, wenn Sie dies nicht für die Cloud Run-Laufzeitumgebung annehmen können. Wenn für eine Arbeitslast beispielsweise bestimmte Pakete oder Bibliotheken verfügbar sein müssen, müssen Sie sie in der Cloud Run-Laufzeitumgebung installieren, in der die Arbeitslast gehostet wird.
  • Konfigurationseinschleusung Überlegen Sie, ob die Arbeitslast die Verwendung von Umgebungsvariablen und Geheimnissen zum Einschleusen (Festlegen) der Konfiguration unterstützt. Bei einer Arbeitslast, die diese Art der Injektion unterstützt, ist möglicherweise weniger Refactoring erforderlich als bei Arbeitslasten, die andere Konfigurations-Injektionmechanismen unterstützen.
  • APIs Überlegen Sie, ob die Arbeitslast mit AWS Lambda APIs interagiert. Eine Arbeitslast, die mit diesen APIs interagiert, muss möglicherweise umgeschrieben werden, um Cloud APIs und Cloud Run APIs zu verwenden.
  • Fehlerberichte Prüfen Sie, ob die Arbeitslast Fehler über Standardausgabe und Fehlerstreams meldet. Bei einer Arbeitslast, die eine solche Fehlermeldung enthält, ist möglicherweise weniger Refactoring erforderlich als bei Arbeitslasten, die Fehler mit anderen Mechanismen melden.

Weitere Informationen zum Entwickeln und Optimieren von Cloud Run-Arbeitslasten finden Sie in den folgenden Ressourcen:

Bereitstellungs- und operative Prozesse refaktorieren

Nachdem Sie Ihre Arbeitslasten refaktoriert haben, refaktorieren Sie Ihre Bereitstellungs- und Betriebsprozesse so, dass sie Folgendes tun:

  • Stellen Sie Ressourcen in Ihrer Google Cloud-Umgebung bereit und konfigurieren Sie sie, anstatt Ressourcen in der Quellumgebung bereitzustellen.
  • Erstellen und konfigurieren Sie Arbeitslasten und stellen Sie sie in Ihrer Google Cloud bereit, anstatt sie in der Quellumgebung bereitzustellen.

Sie haben zuvor in der Bewertungsphase Informationen zu diesen Prozessen erfasst.

Welche Art der Refaktorierung für diese Prozesse berücksichtigt werden muss, hängt davon ab, wie Sie sie entwickelt und implementiert haben. Die Refaktorierung hängt auch davon ab, was der Endstatus für jeden Prozess sein soll. Sie könnten beispielsweise Folgendes versuchen:

  • Sie haben diese Prozesse in Ihrer Quellumgebung implementiert und Sie möchten ähnliche Prozesse in Google Cloud entwerfen und implementieren. Sie können diese Prozesse beispielsweise so refaktorieren, dass sie Cloud Build, Cloud Deploy undInfrastructure Manager verwenden.
  • Sie haben diese Prozesse möglicherweise in einer Drittanbieterumgebung außerhalb Ihrer Quellumgebung implementiert. In diesem Fall müssen Sie diese Prozesse refaktorieren, damit sie auf Ihre Google Cloud-Umgebung statt auf Ihre Quellumgebung abzielen.
  • Eine Kombination der beiden Ansätze.

Die Refaktorierung von Bereitstellungs- und operativen Prozessen kann komplex sein und einen erheblichen Aufwand erfordern. Wenn Sie versuchen, diese Aufgaben im Rahmen Ihrer Arbeitslastmigration auszuführen, kann die Arbeitslastmigration komplexer werden und Risiken aussetzen. Nachdem Sie Ihre Bereitstellungs- und operativen Prozesse bewertet haben, haben Sie wahrscheinlich ein Verständnis für ihr Design und ihre Komplexität. Wenn Sie davon ausgehen, dass Sie viel Aufwand für die Refaktorierung Ihrer Bereitstellungs- und operativen Prozesse betreiben müssen, empfehlen wir, diese Prozesse als Teil eines separaten, dedizierten Projekts zu refaktorieren.

Weitere Informationen zum Entwerfen und Implementieren der Bereitstellungsprozesse in Google Cloud finden Sie unter:

In diesem Dokument geht es um die Bereitstellungsprozesse, mit denen die zu bereitstellenden Artefakte erstellt und in der Ziellaufzeitumgebung bereitgestellt werden. Die Refaktorierungsstrategie hängt stark von der Komplexität dieser Prozesse ab. Die folgende Liste enthält eine mögliche allgemeine Refactoring-Strategie:

  1. Artefakt-Repositories in Google Cloud bereitstellen Sie können beispielsweise Artifact Registry verwenden, um Artefakte und Build-Abhängigkeiten zu speichern.
  2. Refaktorieren Sie Ihre Build-Prozesse, um Artefakte sowohl in Ihrer Quellumgebung als auch in Artifact Registry zu speichern.
  3. Refaktorisieren Sie Ihre Bereitstellungsprozesse, um Arbeitslasten in Ihrer Ziel-Google Cloud-Umgebung bereitzustellen. Sie können beispielsweise mit dem Bereitstellen einer kleinen Teilmenge Ihrer Arbeitslasten in Google Cloud beginnen und dabei Artefakte verwenden, die in Artifact Registry gespeichert sind. Anschließend erhöhen Sie die Anzahl der in Google Cloud bereitgestellten Arbeitslasten schrittweise, bis alle zu migrierenden Arbeitslasten in Google Cloud ausgeführt werden.
  4. Refaktorisieren Sie Ihre Build-Prozesse, damit Artefakte nur in Artifact Registry gespeichert werden.
  5. Migrieren Sie gegebenenfalls ältere Versionen der zu bereitstellenden Artefakte aus den Repositories in Ihrer Quellumgebung in die Artifact Registry. Sie können beispielsweise Container-Images in Artifact Registry kopieren.
  6. Nehmen Sie die Repositories in Ihrer Quellumgebung außer Betrieb, wenn Sie sie nicht mehr benötigen.

Um Rollbacks aufgrund unerwarteter Probleme während der Migration zu erleichtern, können Sie Container-Images sowohl in Ihren aktuellen Artifact-Repositories in Google Cloud speichern, während die Migration zu Google Cloud ausgeführt wird. Schließlich können Sie im Rahmen der Außerbetriebnahme Ihrer Quellumgebung die Erstellungsprozesse für Container-Images refaktorieren, sodass Artefakte nur in Google Cloud gespeichert werden.

Auch wenn es für den Erfolg einer Migration nicht unbedingt entscheidend ist, müssen Sie möglicherweise Ihre älteren Versionen Ihrer Artefakte aus Ihrer Quellumgebung in Ihre Artefakt-Repositories in Google Cloud migrieren. Wenn Sie beispielsweise Ihre Arbeitslasten zu beliebigen Zeitpunkten zurücksetzen möchten, müssen Sie möglicherweise frühere Versionen Ihrer Artefakte zu Artifact Registry migrieren. Weitere Informationen finden Sie unter Images aus einer Drittanbieter-Registry migrieren.

Wenn Sie Ihre Artefakte in Artifact Registry speichern, empfehlen wir Ihnen, Einstellungen zu konfigurieren, um Ihre Artefakt-Repositories zu schützen, z. B. Zugriffssteuerung, Daten-Exfiltrationsprävention, Sicherheitslücken-Scans und Binärautorisierung. Weitere Informationen finden Sie unter Zugriff steuern und Artefakte schützen.

Betriebsprozesse refaktorieren

Im Rahmen der Migration zu Cloud Run empfehlen wir Ihnen, Ihre operativen Prozesse zu überarbeiten, um Ihre Cloud Run-Umgebung kontinuierlich und effektiv zu überwachen.

Cloud Run kann in die folgenden Betriebsdienste eingebunden werden:

Daten migrieren

In der Bewertungsphase zu Beginn dieses Prozesses sollten Sie ermittelt haben, ob die migrierten AWS Lambda-Arbeitslasten von Daten in Ihrer AWS-Umgebung abhängen oder Daten in dieser Umgebung generieren. Möglicherweise haben Sie beispielsweise festgestellt, dass Sie Daten von AWS S3 zu Cloud Storage oder von Amazon RDS und Aurora zu Cloud SQL und AlloyDB for PostgreSQL migrieren müssen. Weitere Informationen zur Migration von Daten von AWS zu Google Cloud finden Sie unter Von AWS zu Google Cloud migrieren: Erste Schritte.

Ähnlich wie bei der Refaktorierung von Bereitstellungs- und Betriebsabläufen kann die Migration von Daten von AWS zu Google Cloud komplex sein und erheblichen Aufwand erfordern. Wenn Sie versuchen, diese Aufgaben im Rahmen der Migration Ihrer AWS Lambda-Arbeitslasten auszuführen, kann die Migration komplex werden und Risiken bergen. Nachdem Sie die zu migrierenden Daten analysiert haben, haben Sie wahrscheinlich ein Verständnis für die Größe und Komplexität der Daten. Wenn Sie davon ausgehen, dass Sie viel Aufwand für die Migration dieser Daten betreiben müssen, empfehlen wir, die Daten als Teil eines separaten, dedizierten Projekts zu migrieren.

Migrationsergebnisse prüfen

Die Validierung der Arbeitslastmigration ist kein einmaliges Ereignis, sondern ein kontinuierlicher Prozess. Sie müssen vor, während und nach der Migration von AWS Lambda zu Cloud Run auf Tests und Validierung achten.

Um eine erfolgreiche Migration mit optimaler Leistung und minimalen Unterbrechungen zu ermöglichen, empfehlen wir Ihnen, die Arbeitslasten, die Sie von AWS Lambda zu Cloud Run migrieren, mit dem folgenden Verfahren zu validieren:

  • Bevor Sie mit der Migrationsphase beginnen, sollten Sie Ihre vorhandenen Testfälle so umarbeiten, dass die Ziel-Google Cloud-Umgebung berücksichtigt wird.
  • Validieren Sie während der Migration die Testergebnisse bei jedem Migrationsmeilenstein und führen Sie gründliche Integrationstests durch.
  • Führen Sie nach den Migrationen die folgenden Tests durch:
    • Baseline-Tests: Legen Sie Leistungsbenchmarks der ursprünglichen Arbeitslast in AWS Lambda fest, z. B. Ausführungszeit, Ressourcennutzung und Fehlerraten bei unterschiedlichen Lasten. Wiederholen Sie diese Tests in Cloud Run, um Abweichungen zu erkennen, die auf Migrations- oder Konfigurationsprobleme hinweisen könnten.
    • Funktionstests: Sorgen Sie dafür, dass die Kernlogik Ihrer Arbeitslasten konsistent bleibt, indem Sie Testfälle erstellen und ausführen, die verschiedene Eingabe- und erwartete Ausgabeszenarien in beiden Umgebungen abdecken.
    • Lasttests: Steigern Sie den Traffic nach und nach, um die Leistung und Skalierbarkeit von Cloud Run unter realen Bedingungen zu bewerten. Beheben Sie Abweichungen wie Fehler und Ressourceneinschränkungen, um eine reibungslose Migration zu ermöglichen.

Google Cloud-Umgebung optimieren

Die Optimierung ist die letzte Phase Ihrer Migration. In dieser Phase iterieren Sie Optimierungsaufgaben, bis Ihre Zielumgebung Ihre Optimierungsanforderungen erfüllt. Die Iteration umfasst folgende Schritte:

  1. Bewerten Sie die aktuelle Umgebung, Teams und Optimierungsschleife.
  2. Optimierungsanforderungen und -ziele festlegen.
  3. Umgebung und Teams optimieren.
  4. Verbessern Sie die Optimierungsschleife.

Wiederholen Sie diese Sequenz, bis Sie Ihre Optimierungsziele erreicht haben.

Weitere Informationen zum Optimieren Ihrer Google Cloud-Umgebung finden Sie unter Migrate to Google Cloud: Optimieren Sie Ihre Umgebung und den Leistungsoptimierungsprozess.

Nächste Schritte

Beitragende

Autoren:

Weitere Beitragende: