원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Wer in verteilten Systemen bereits für Zahlungen oder Benachrichtigungsintegrationen verantwortlich war, wird die Frustration über verlorene oder doppelt gesendete Daten kennen, die durch Antwortverzögerungen externer Dienste oder Netzwerkabbrüche verursacht werden. Da Webhooks mindestens eine Zustellung garantieren, führt dies zu Datenkorruption, wenn der empfangene Server nicht ordnungsgemäß vorbereitet ist. Dieser Beitrag behandelt, wie man Störungssituationen in der lokalen Umgebung simuliert und Schutzlogiken implementiert, bevor das Ganze in der Produktionsumgebung bereitgestellt wird.
Um reale Ausfallszenarien vor der Bereitstellung in der Produktion zu validieren, muss in der lokalen Umgebung eine Chaos-Test-Pipeline eingerichtet werden. Die Kombination aus ngrok-Tunneling und Docker-basiertem Toxiproxy ermöglicht es, Zeitüberschreitungen und Netzwerkabbrüche von externen Anbietern zu reproduzieren. Durch den Aufbau dieser Umgebung lässt sich der Zeitaufwand für die Analyse und Behebung von Ausfallursachen um 2 Stunden verkürzen.
Das Vorgehen zum Einleiten von Netzwerkausfällen mit Toxiproxy sieht wie folgt aus: Erstens werden die Backend-Anwendung, Toxiproxy und ngrok über Docker Compose verbunden, sodass Anfragen über die öffentliche ngrok-URL über den Toxiproxy-Port 8666 an Port 8080 der Anwendung weitergeleitet werden. Zweitens wird eine cURL-Anfrage an die Toxiproxy-Verwaltungs-API gesendet, um eine Antwortverzögerung von 25000 Millisekunden zu injizieren und so Zeitüberschreitungsbedingungen externer Dienste wie Stripe auszulösen. Drittens wird das Toxic reset_peer angewendet, um den Socket gewaltsam zu schließen und zu überprüfen, ob der Verbindungspool wiederhergestellt und die Protokolle erfasst werden.
Doppelte Transaktionen durch erneutes Senden von Webhooks verursachen Datenkorruption während des Zahlungsgenehmigungsprozesses. Ein Speicher-Cache ist ungeeignet, da er Race Conditions in einer verteilten Serverumgebung nicht verhindern kann. Für eine zuverlässige Unterbindung von Duplikaten müssen Transaktionen und eindeutige Einschränkungen (Unique Constraints) eines RDBMS als Idempotenz-Gate genutzt werden.
Der Implementierungsablauf zur Steuerung gleichzeitiger Anfragen auf Datenbankebene ist wie folgt: Erstens wird eine Tabelle processed_webhooks erstellt und für den eindeutigen Ereignisbezeichner im Payload eine UNIQUE-Einschränkung vergeben. Zweitens werden in einer FastAPI- und SQLAlchemy-Umgebung atomare Insert-Anweisungen verwendet, um den Status als in Bearbeitung zu protokollieren und bei Konkurrenzkonflikten IntegrityError abzufangen. Drittens wird bei Verletzung der Unique-Einschränkung der Status des bestehenden Datensatzes abgefragt; handelt es sich um eine bereits verarbeitete Anfrage, wird ohne Datenmanipulation ein 200 OK zurückgegeben, um das erneute Senden durch den externen Dienst zu stoppen. Diese Struktur verhindert Datenkorruptionsunfälle durch doppelte Anfragen.
Wenn während der Webhook-Verarbeitung Fehler in externen Abhängigkeiten auftreten, entstehen Ereignisse, die die Anzahl der Wiederholungsversuche überschreiten, und werden in einer Dead-Letter-Queue isoliert. Wenn fehlgeschlagene Ereignisse unberücksichtigt bleiben, häufen sich Dateninkonsistenzen an, weshalb ein Batch-Prozess erforderlich ist, der sie bei Normalisierung des Systems sicher wieder einspeist. Durch den Aufbau eines Python-basierten Skripts zur manuellen Wiederherstellung lässt sich die wöchentlich 3 Stunden in Anspruch nehmende manuelle SQL-Wiederherstellung einsparen.
Der Implementierungsablauf des Batch-Skripts zur Wiederverarbeitung isolierter, fehlgeschlagener Ereignisse ist wie folgt: Erstens wird eine Tabelle dlq_webhooks erstellt, um den ursprünglichen Payload, die Fehlermeldung und die Anzahl der Versuche aufzuzeichnen, und Daten mit is_resolved gleich falsch werden abgefragt. Zweitens wird zur Vermeidung von Netzwerklast bei der Wiederverarbeitung ein exponentielles Backoff- und Jitter-Algorithmus angewendet, um entsprechend der berechneten Verzögerungszeit zu warten. Drittens wird eine HTTP-Anfrage an den internen Endpunkt gesendet, bei Erfolg is_resolved auf wahr aktualisiert und bei Fehlschlag die Anzahl der Versuche erhöht, wobei eine Obergrenze gesetzt wird, um Endlosschleifen zu verhindern.
Um die Stabilität des Webhook-Systems aufrechtzuerhalten, ist ein Observability-System erforderlich, das die Empfangsfehlerrate und die Anzahl der angesammelten Dead-Letter-Queues in Echtzeit verfolgt. Um die Erschöpfung zu verhindern, bei der On-Call-Ingenieure aufgrund vorübergehender Infrastrukturschwankungen jede Nacht Benachrichtigungen erhalten, müssen hierarchische Benachrichtigungsrichtlinien basierend auf der Art des Fehlers festgelegt werden.
Das Monitoring-Konfigurationsverfahren zur Reduzierung von Fehlalarmen und zur Reaktion auf tatsächliche Störungen ist wie folgt: Erstens wird die Webhook-Fehlerrate basierend auf der Anzahl der HTTP-5xx- und Timeout-Antworten im Verhältnis zur Gesamtzahl der Empfänge in den letzten 10 Minuten berechnet. Zweitens werden vorübergehende Infrastrukturfehler und Geschäftslogikfehler im Dashboard visuell getrennt dargestellt. Drittens werden PagerDuty-Notrufe nur dann ausgelöst, wenn die Fehlerrate 15 Prozent und die Dead-Letter-Queues 100 Einträge überschreiten, während einfache Timeouts nachts stummgeschaltet werden, um die On-Call-Belastung zu verringern.
