Lambda-Workload ermitteln

Erstellen Sie einen Migrationsdatensatz mit genügend Nachweisen, um das Quellverhalten zu reproduzieren und zu vergleichen.

Führen Sie die folgenden Schritte aus, um die Lambda-Workload zu ermitteln:

  1. Zeichnen Sie Konfiguration, Deployment-Pfad, Abhängigkeiten, Schichten, native Bibliotheken, Umgebungsvariablen, VPC-Einstellungen, IAM-Rolle, Trigger, Eigentümer und Betriebskontakte auf.
  2. Erfassen Sie Baseline-Metriken: Aufrufrate, Peak Concurrency, p95- und p99-Dauer, maximale Dauer, belegter Speicher, Payload-Größen, Fehler, Timeouts, Throttles, Wiederholungen, DLQ- oder Fehleranzahl, Queuealter oder -rückstand, Alarmschwellenwerte und Downstream-Kapazitätslimits.
  3. Speichern Sie repräsentative Erfolgsereignisse, fehlerhafte Ereignisse, doppelte Ereignisse, Timeoutfälle, Berechtigungsfehler, Downstream-Fehlerbeispiele und Quelllogbeispiele mit verdeckten sensiblen Werten.

Suchen Sie nach: Ein vollständiger Bestandsdatensatz mit Evidenzlinks, anfänglichen Risikonotizen und Lücken, die eine Bestätigung durch den Verantwortlichen erfordern.

Ausgabe: Verlassen Sie sich nicht nur auf Konfigurationsexporte. Logs, Metriken, Alarme und repräsentative Ereignisse zeigen in der Regel Verhalten, das die Konfiguration allein nicht anzeigt.

Jede aufgezeichnete Funktion für die OCI Functions-Migration bewerten

Erfassen Sie die Anforderungen, erforderlichen Änderungen und die Migrationsentscheidung für jede abgetastete Funktion.

Um jede Samplingfunktion für die OCI Functions-Migration zu bewerten, führen Sie einen Bewertungsdatensatz mit den folgenden Elementen für jede Samplingfunktion aus:

  • Funktionsname und Anwendungseigentümer
  • Geschäftszweck und Kritikalität
  • Laufzeit und Version
  • Trigger- und eingehende Ereignisformate
  • Verwendete AWS-Services und SDK-Aufrufe
  • Ausführungszeit, Arbeitsspeicher, Nebenläufigkeit und Payload-Größe
  • Wiederholen, Bestellen, Duplizieren und Fehlerverhalten
  • IAM-Berechtigungen und Netzwerkabhängigkeiten
  • Aktuelle Logs, Metriken, Alarme und Service Level Objectives
  • Erforderliche OCI Functions-Konfiguration und Triggermuster
  • Erforderliche Änderungen an Code, Adapter oder Deployment
  • Bekannte Lücken und ungelöste Risiken

Verwenden Sie eines der folgenden Bewertungsresultate:

  • OCI Functions-Migration bereit: Die Workload kann mit begrenzten Änderungen zu OCI Functions verschoben werden.
  • OCI Functions-Migration mit Änderungen: Die Workload erfordert einen Adapter, gezielte Codeänderungen, Konfigurationsänderungen oder betriebliche Änderungen.
  • Ausnahmeprüfung erforderlich: OCI Functions erfüllt möglicherweise keine dokumentierte Workload-Anforderung. Fahren Sie nicht mit einer Nicht-Functions-Architektur fort, ohne die in diesem Playbook beschriebene Ausnahmeüberprüfung.

Der Anwendungseigentümer und der Migrationseigentümer müssen die Bewertung prüfen, bevor die Implementierung beginnt.

OCI Functions-Migrationsanforderungen bewerten

Bestimmen Sie den OCI Functions-Migrationsansatz für eine Workload.

So bewerten Sie die Migrationsanforderungen von OCI Functions:

  1. Prüfen Sie die Trigger-, Laufzeit-, Abhängigkeits-, Ausführungsdauer-, Speicher-, Nebenläufigkeits-, Payload-, IAM-, Netzwerk- und Betriebsanforderungen der Workload, um den Migrationsansatz von OCI Functions zu bestimmen.
  2. Trennen Sie portierbare Geschäftslogik von AWS-spezifischem Ereignisparsing, SDK-Aufrufen, IAM-Annahmen, Logging und Wiederholungsverarbeitung.

    Dadurch werden die erforderlichen Migrationsänderungen vor dem Implementierungsbeginn sichtbar.

  3. Verwenden Sie die folgenden OCI Functions-Migrationsmuster als Ausgangspunkt.
    Workload-Muster OCI Functions-Migrationsmuster Validieren
    Zustandslose, ereignisgesteuerte Workload mit kurzer Ausführungszeit OCI Functions Payload, Arbeitsspeicher, Timeout, Parallelität, Abhängigkeiten und erforderlicher Downstream-Zugriff
    HTTP-API-Workload OCI API Gateway plus OCI Functions Authentifizierung, Methoden, Routen, Header, Payload-Größe, Fehlerantworten, Latenz und Timeout
    Objekt-, Benachrichtigungs-, Queue-, Stream- oder Logereignisprozessor OCI Functions mit den entsprechenden OCI-Ereignissen, Oracle Cloud Infrastructure Queue, OCI-Benachrichtigungen, OCI Streaming oder OCI Connector Hub-Service Ereignisformat, Lieferverhalten, Wiederholungen, Bestellung, doppelte Bearbeitung, Fehlerziel und Gegendruck

OCI Functions ist das Standardziel für Lambda-Migrationsinitiativen, wenn es die Funktions-, Performance-, Sicherheits- und Betriebsanforderungen der Workload erfüllt.

OCI-Zielarchitektur entwerfen

Definieren Sie Aufruf-, Identity-, Secret-, Netzwerk-, Abhängigkeits-, Beobachtbarkeits- und Cutover-Muster.

So entwerfen Sie die OCI-Zielarchitektur:

  1. Wählen Sie den Aufrufpfad und das erwartete Dokument für Authentifizierung, Payload-Ausprägung, Header oder Metadaten, Latenz, Wiederholungen, Bestellung, Batchverhalten, doppelte Zustellung, Filterung und Fehlerziel aus.
  2. Definieren Sie OCI Functions-Anwendung, Compartment, Image Repository, VCN, Subnetze, Routentabellen, Sicherheitsregeln, Servicegateway oder NAT-Gateway, privaten Zugriff, Egress-Anforderungen und Downstreamendpunkte.
  3. Identifizieren Sie jeden OCI-Service oder externen Endpunkt, den die Funktion zur Laufzeit aufruft, einschließlich OCI Object Storage, OCI Queue, OCI Streaming, OCI Vault, Datenbanken und APIs von Drittanbietern.
  4. Definieren Sie Betriebssignale wie Logfelder, Korrelations-ID, Aufrufanzahl, Dauer, Fehler, Timeouts, Kapazitätssymptome, nachgelagerte Fehler, Dashboard-Ansichten, Alarme und Runbook-Schritte.

Suchen Sie nach einer Zusammenfassung der Zielarchitektur mit Komponentenliste, Integrationspfad, Sicherheitsdesign, Betriebsdesign und Anleitung zur Neuerstellung von Diagrammen.

Überlegungen: Das Architekturdesign ist nur abgeschlossen, wenn normaler Ablauf, Wiederholungsablauf, Fehlerfluss, Ablauf mit abgelehntem Zugriff und Rollback-Ablauf beschrieben werden.

Designüberlegungen und Zielauswahl

Berücksichtigen Sie diese Aspekte bei der Designprüfung.

Sie sind absichtlich handlungsorientiert, so dass Gutachter nach Beweisen fragen können, anstatt allgemeine Aussagen der Bereitschaft zu akzeptieren.

  • Zielanpassung: Verwenden Sie OCI Functions für zustandslose, ereignisgesteuerte, kurz laufende, containerisierbare Arbeit, die den Ziellimits und dem Aufrufmodell entspricht. Verwenden Sie ein anderes Ziel für Workloads mit langer Ausführungszeit, zustandsbehaftet, Daemon-ähnlich, orchestrierungslastig, mitarbeiterähnlich oder AWS-servicegekoppelt.
  • Payloads und Timeouts: Zeichnen Sie tatsächliche Anforderungs- und Antwortgrößen, maximale Dauer, Timeoutanzahl und Anruferantwortsemantik auf. Übergeben Sie große Daten per Referenz an OCI Object Storage, OCI Queue, OCI Streaming oder einen anderen Speicher, anstatt über die Funktions-Payload.
  • Abhängigkeiten: Konvertieren Sie Annahmen auf ZIP- und Lambda-Ebene in Image- oder Shared-Base-Image-Abhängigkeiten. Testen Sie native Librarys, Imagegröße, Abhängigkeitsversionen, Startverhalten, eingebettete SDK-Annahmen und Laufzeitverhalten.
  • Nebenläufigkeit und Skalierung: Bestand, warum AWS reservierte oder bereitgestellte Nebenläufigkeit verwendet wurde: reservierte Kapazität, Traffic-Cap, Reduzierung des Kaltstarts, Drosselung durch Ereignisquellen oder nachgelagerter Schutz. Entwerfen Sie OCI-Verhalten mit Kapazitätsplanung, gegebenenfalls bereitgestellter Nebenläufigkeit, Auslösung von Kontrollen, Druckrückständen und nachgelagerten Limits.
  • Trigger: Ereignisausprägung validieren, Wiederholung, Bestellung, Batchverhalten, doppelte Zustellung, Filterung, Fehlerziel und Idempotenz. Das Trigger-Verhalten ist in der Regel der Migrationsbereich mit dem höchsten Risiko.
  • Vorgänge: Logs, Metriken, Alarme, Dashboards, Traces, Runbooks, Rollback-Trigger und Rollback-Eigentümer werden als Migrationsgegenstände behandelt, nicht als Post-Cutover-Bereinigung.

Leitfaden zur Zielgruppenauswahl

Arbeitsauslastungsmerkmal Empfohlenes OCI-Ziel Warum
Zustandslose, ereignisgesteuerte, kurz laufende, containerisierbare Funktion OCI Functions Nächstgelegene Anpassung, wenn Payload-, Timeout-, Speicher-, Trigger-, Abhängigkeits-, Netzwerk- und Nebenläufigkeits-Constraints erfüllt werden.
HTTP-API-Funktion mit einfachem Anforderungs-/Antwortverhalten OCI API Gateway plus OCI Functions Gute Passform, wenn Authentifizierung, Header, Payload-Größe, Timeout, Latenz, Statuscode und Antwortsemantik validiert werden.
Objekt-, Benachrichtigungs-, Queue-, Stream- oder Logereignisprozessor OCI Functions mit OCI-Ereignissen, OCI-Benachrichtigungen, OCI Connector Hub, OCI Streaming über Connector Hub oder neu gestaltetem Messaging Flow Potenzielle Anpassung, aber Lieferung, Wiederholung, Bestellung, Batch, Duplikat, Giftnachricht und Fehlerverhalten müssen neu gestaltet und getestet werden.
Job mit langer Ausführungszeit oder Worker-ähnlicher Prozess OCI Container Instances, OKE, OCI Compute oder zerlegter Workflow Vermeidet Funktionsaufrufe und Laufzeit-Constraints, während ein Container oder ein servicebasierter Deployment-Pfad beibehalten wird.
Integrationsintensive Orchestrierung Oracle Integration, Workflow-Service oder Neugestaltung Passen Sie besser an, wenn die Workload Systeme koordiniert, auf externen Zustand wartet oder kompensierende Schritte verwaltet, anstatt eine kleine Recheneinheit auszuführen.
Zustandsbehafteter Prozess, dauerhafter lokaler Status oder Daemon OCI Compute, OKE oder Neugestaltung OCI Functions ist kein dauerhafter lokaler Status oder Daemon-Ausführungsmodell.

OCI-Ressourcen und Deployment-Zugriff vorbereiten

Bereiten Sie die minimale Zielumgebung vor, die zum Erstellen, Bereitstellen und Testen von Rauch erforderlich ist.

So bereiten Sie OCI-Ressourcen und Deployment-Zugriff vor:

  1. Erstellen oder identifizieren Sie das Compartment, die OCI Functions-Anwendung, VCN-Subnetze, das OCI Container Registry-Repository, OCI Vault-Secret-Speicherorte, Loggingressourcen und Monitoringalarme.
  2. Konfigurieren Sie den Entwickler- und CI/CD-Zugriff für das Erstellen von Images, das Übertragen von Images, das Bereitstellen von Funktionen, das Aufrufen von Rauchversuchen und das Lesen von Logs.
  3. Erstellen Sie dynamische Gruppenregeln und Policy-Anweisungen für den Laufzeitzugriff. Umfang nach Compartment und Ressource, sofern möglich, insbesondere für Buckets, Streams, Queues, OCI Vault-Secrets und Datenbanken.
  4. Smoke-Test-Image-Push, Funktionsbereitstellung, direkter Aufruf, Log-Emission, Secret Read, abgelehnter Secret-Lesevorgang und ein repräsentativer Downstream-Serviceaufruf.

Suchen Sie nach einer fertigen Zielumgebung mit dokumentierten Zugriffspfaden und einem bestandenen Rauchtest.

Überlegungen: Stellen Sie sicher, dass Deployment-Identität und Laufzeitidentität getrennt sind, wenn der Prozess andere Berechtigungen erfordert.