Strategien zur Wiederholung von Serviceaufträgen in AWS Batch - AWS Batch
Konfiguration von Wiederholungsstrategien

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Strategien zur Wiederholung von Serviceaufträgen in AWS Batch

Strategien zur Wiederholung von Serviceaufträgen ermöglichen es AWS Batch , fehlgeschlagene Serviceaufträge unter bestimmten Bedingungen automatisch zu wiederholen.

Serviceaufträge können aus verschiedenen Gründen mehrere Versuche erfordern:

  • Temporäre Serviceprobleme: Interne Dienstfehler, Drosselung oder vorübergehende Ausfälle können dazu führen, dass Aufträge bei der Übermittlung oder Ausführung fehlschlagen.

  • Fehler bei der Trainingsinitialisierung: Probleme beim Starten des Jobs, wie z. B. Probleme beim Abrufen von Bildern oder Initialisierungsfehler, können bei einem erneuten Versuch behoben werden.

Durch die Konfiguration geeigneter Wiederholungsstrategien können Sie die Erfolgsquoten von Aufträgen verbessern und die Notwendigkeit manueller Eingriffe reduzieren, insbesondere bei lang andauernden Schulungsaufgaben.

Anmerkung

Serviceaufträge wiederholen automatisch bestimmte Arten von Fehlern, wie z. B. Fehler bei unzureichender Kapazität, ohne dass Ihre konfigurierten Wiederholungsversuche unnötig werden. Ihre Wiederholungsstrategie behandelt in erster Linie andere Arten von Fehlern, z. B. Algorithmusfehler oder Serviceprobleme.

Konfiguration von Wiederholungsstrategien

Strategien zur Wiederholung von Serviceaufträgen werden mithilfe von konfiguriert ServiceJobRetryStrategy, das sowohl einfache Wiederholungszahlen als auch bedingte Wiederholungslogik unterstützt.

Wiederholungs-Konfiguration

Die einfachste Wiederholungsstrategie gibt die Anzahl der Wiederholungsversuche an, die unternommen werden sollen, wenn ein Serviceauftrag fehlschlägt:

{
  "retryStrategy": {
    "attempts": 3
  }
}

Mit dieser Konfiguration kann der Serviceauftrag bis zu dreimal wiederholt werden, falls er fehlschlägt.

Wichtig

Der attempts Wert gibt an, wie oft der Auftrag insgesamt in den RUNNABLE Status versetzt werden kann, einschließlich des ersten Versuchs. Ein Wert von 3 bedeutet, dass der Job zunächst einmal versucht und dann, falls er fehlschlägt, bis zu zwei weitere Male wiederholt wird.

Versuchen Sie die Konfiguration erneut mit evaluateOnExit

Sie können den evaluateOnExit Parameter verwenden, um Bedingungen anzugeben, unter denen Jobs wiederholt werden sollen oder unter denen sie fehlschlagen dürfen. Dies ist nützlich, wenn verschiedene Arten von Fehlern unterschiedlich behandelt werden müssen.

Das evaluateOnExit Array kann bis zu 5 Wiederholungsstrategien enthalten, von denen jede eine Aktion (RETRYoderEXIT) und Bedingungen spezifiziert, die auf Statusgründen basieren:

{
  "retryStrategy": {
    "attempts": 5,
    "evaluateOnExit": [
      {
        "action": "RETRY",
        "onStatusReason": "Received status from SageMaker: InternalServerError*"
      },
      {
        "action": "EXIT",
        "onStatusReason": "Received status from SageMaker: ValidationException*"
      },
      {
        "action": "EXIT",
        "onStatusReason": "*"
      }
    ]
  }
}

Diese Konfiguration:

  • Wiederholt Aufträge, die aufgrund von internen SageMaker AI-Serverfehlern fehlschlagen

  • Schlägt Aufträge, bei denen Validierungsausnahmen auftreten, sofort fehl (Client-Fehler, die nicht durch einen erneuten Versuch behoben werden können)

  • Beinhaltet eine Catch-All-Regel zum Beenden bei allen anderen Fehlertypen

Status, Grund, Musterabgleich

Der onStatusReason Parameter unterstützt den Musterabgleich mit bis zu 512 Zeichen. Muster können Platzhalter (*) verwenden und mit den von der SageMaker KI zurückgegebenen Statusgründen übereinstimmen.

Bei Serviceaufträgen wird Statusmeldungen von SageMaker KI das Präfix „Status erhalten von SageMaker:“ vorangestellt, um sie von AWS Batch-generierten Nachrichten zu unterscheiden. Zu den gängigen Mustern gehören:

  • Received status from SageMaker: InternalServerError*- Ordnen Sie interne Servicefehler zu

  • Received status from SageMaker: ValidationException*- Findet Fehler bei der Client-Validierung

  • Received status from SageMaker: ResourceLimitExceeded*- Fehler beim Ressourcenlimit abgleichen

  • *CapacityError*- Passen Sie kapazitätsbedingte Ausfälle an

Tipp

Verwenden Sie einen spezifischen Musterabgleich, um verschiedene Fehlertypen angemessen zu behandeln. Versuchen Sie es beispielsweise erneut mit internen Serverfehlern, schlagen Sie jedoch sofort bei Validierungsfehlern fehl, die auf Probleme mit den Auftragsparametern hinweisen.