이벤트 기반 마이크로서비스: 오류 처리

단순하고 확장 가능하며 견고함

이벤트 기반 마이크로서비스 아키텍처의 기본 사항에 익숙하지 않은 경우 이 이벤트 기반 마이크로서비스: 개요 게시물을 확인해야 합니다.

뭐가 문제 야?

시스템이 분산되면(마이크로서비스 기반 시스템과 같이) 이점과 함께 오류 가능성이 발생합니다. 예로는 연결 문제, 직렬화/역직렬화 문제, 다운스트림 시스템 중단, 피어 시스템 중단, 버그 및 계속되는 목록이 있습니다. 이러한 오류를 간단하고 반복 가능한 방식으로 처리하는 것은 프로젝트의 성공에 중요합니다.

이것은 어려운 문제처럼 들리지만 솔루션의 핵심은 복잡성을 단순화하고 분해하는 것입니다. 우리는 오류를 일시적인 오류와 일시적이지 않은 오류의 두 가지 유형으로 나눌 수 있습니다. 이러한 예가 아래에 나열되어 있습니다.

일시적인 오류:

연결 문제
시스템 중단

일시적이지 않은 오류:

직렬화/역직렬화 문제
버그

이 두 가지 유형의 오류는 반복 가능한 방식으로 처리할 수 있습니다. 일시적인 오류는 재시도하여 처리할 수 있습니다. 이러한 오류는 주어진 시간에 스스로 수정해야 하기 때문입니다. 일시적이지 않은 오류는 사람의 개입이 필요하므로 책임 팀에 문제를 해결하도록 경고하고 통지하여 처리해야 합니다. 아래에서 두 가지 유형의 오류를 처리하는 방법을 살펴보겠습니다.

데드 레터 이벤트

비일시적 오류부터 살펴보겠습니다. 예상치 못한 재앙이 발생했을 때 시스템은 어떻게 해야 합니까?

분산 시스템은 여러 이벤트를 동시에 처리하므로 마지막으로 하고 싶은 일은 시스템을 통해 들어오는 데이터 파이프라인을 차단하는 것입니다. 그러나 우리는 또한 이 처리할 수 없는 데이터를 잃고 싶지 않습니다. 따라서 이러한 일이 발생하면 오류 이벤트를 처리된 것으로 표시하고 파이프라인에서 꺼내서 데드 레터 이벤트 형태로 옆으로 범프합니다. 데드 레터 이벤트는 데이터 손실이 없도록 입력 이벤트의 모든 정보를 담고 있으며, 추후 재처리가 가능합니다.

일단 우리가 이것을 하면 재앙을 피할 수 있습니다. 정상적인 데이터는 여전히 흐르고 있으며 어떠한 정보도 손실되지 않았습니다. 이 시점에서 우리의 목표는 누군가에게 알리고 데드 레터 이벤트를 안내하는 것입니다. 이벤트 버스에 이러한 데드 레터가 있으므로 사용 중인 메시지 버스 기술과 관련된 모니터링 도구를 사용하여 이를 수행할 수 있습니다. 모든 배달 못한 편지 대기열은 이벤트를 수신할 때마다 경고해야 합니다. 이 시점에서 오류의 원인을 수정할 수 있고 관련 데드 레터 이벤트를 수동으로 시스템에 다시 플러시하여 중단된 부분부터 다시 가져올 수 있습니다.

재시도 이벤트

주어진 시간에 오류의 원인이 자체적으로 해결되면 시스템은 어떻게 해야 합니까? 일시적인 오류의 경우 재시도 이벤트를 사용하여 처리해야 합니다.

재시도 이벤트의 프로세스는 데드 레터 이벤트와 동일하게 시작됩니다. 데이터 흐름이 있고 이벤트 오류가 발생하면 유효한 이벤트 흐름을 유지하면서 다시 처리된 것으로 표시하고 옆으로 범프합니다.

이것이 차이가 발생하는 곳이며 오류 데이터는 주어진 시간 후에 자동으로 재처리될 재시도 이벤트에 입력됩니다. 이 시간은 오류 유형과 이전에 실패한 횟수에 따라 다를 수 있습니다. 재시도 이벤트가 너무 여러 번 실패하면 안전 예방책으로 누군가에게 알리기 위해 데드 레터 이벤트로 전환해야 합니다. 이는 예상보다 일시적이지 않기 때문입니다.

예상 실패

간단하게 하기 위해 주의해야 할 점은 오류(위에 설명된 대로)를 예상 오류와 분리하는 것입니다. 예상되는 오류는 비즈니스 논리 또는 엔지니어링 논리의 일부로 허용되는 오류입니다. 이는 응용 프로그램 수준 논리에서 처리되며 올바른 다운스트림 작업을 유발하는 맞춤 이벤트가 있어야 하며 재시도 또는 데드 레터가 생성되어서는 안 됩니다.

예상되는 실패의 예는 은행 시스템일 수 있습니다. 사용자가 무언가를 지불하고 싶지만 계정에 충분한 자금이 없는 경우와 같습니다. 이로 인해 애플리케이션 로직에서 처리해야 하는 트랜잭션 실패가 발생해야 하며 잠재적으로 관련 사용자에게 결제 거부 알림이 표시될 수 있습니다.

유사한 용어는 쉽게 혼동될 수 있으며 예상 오류와 예기치 않은 오류를 명확하게 구분하는 것이 매우 중요하고 호출해야 하는 이유입니다.

카프카로 구현

Kafka를 재시도 또는 데드 레터 처리를 구현하는 방법으로 보면 두 가지 간단한 솔루션이 있습니다. 이 두 접근 방식 모두 데드 레터 이벤트와 재시도 이벤트는 Kafka 주제에 저장됩니다. 데드 레터에 대한 주제 및 각 재시도 지연 기간에 대한 여러 주제. 첫 번째 솔루션은 모든 마이크로 서비스에 오류 논리를 포함하는 것이고 두 번째 솔루션은 새로운 특정 재시도 및 데드 레터 마이크로 서비스의 오류를 처리하는 것입니다. 우리는 이 두 가지 접근 방식의 장점과 단점을 살펴볼 것입니다.

첫 번째 접근 방식은 구현이 복잡하지만 훌륭하게 작동합니다. 다양한 지연으로 여러 번 재시도할 수 있는 경우 여러 대기열이 필요합니다. 각 재시도 길이에 대해 하나의 대기열. 이는 Kafka 대기열이 정렬되어 이벤트가 순서대로 처리되기 때문입니다. 재시도 논리와 함께 요청 시 배달 못한 편지 대기열을 플러시할 수 있는 추가 논리가 필요합니다. 이러한 대기열을 관리하려면 각 개별 마이크로서비스에 논리가 필요하므로 시스템 전체의 복잡성이 증가합니다.

두 번째 접근 방식은 모든 마이크로 서비스에서 재시도 복잡성을 제거하고 단일 재시도 마이크로 서비스에 배치하지만 동일한 방식으로 작동합니다. 재시도 마이크로 서비스의 작업은 모든 재시도를 추적하고 조치하는 것입니다. 이 마이크로서비스는 이벤트를 수신하여 재시도할 이벤트와 해당 이벤트를 재시도하는 타임스탬프를 모두 사용하여 자체 주제에 기록합니다. 그런 다음 타임스탬프에 도달하면 이러한 재시도 이벤트를 푸시합니다. 또한 요청 시 배달 못한 편지 대기열 플러시를 처리하는 단일 배달 못한 편지 서비스를 사용할 수도 있습니다.

이 두 가지 접근 방식 외에도 Kafka 주제 대신 데이터베이스를 사용하여 재시도를 저장하는 옵션도 있습니다. 이것은 재시도 구현을 단순화하고(다른 재시도 기간에 대해 중복된 주제가 없기 때문에) 더 복잡한 재시도 기간 논리를 허용합니다(각 지연 기간에 대해 주제를 생성하는 것으로 제한되지 않음). 여기에는 두 가지 제한 사항이 있습니다. 재시도 데이터베이스가 다운된 경우 해당 시간 동안 재시도를 수행할 수 없습니다. 그리고 트랜잭션이 되지 않는 데이터베이스와의 인터페이스를 통한 잠재적인 이벤트 중복이 있기 때문에 정확히 한번의 이벤트 전달을 지원하지 않습니다.

다음은 나열된 각각의 장점과 단점에 대한 표입니다.

TL;DR

분산 시스템이 제대로 작동하려면 원활한 오류 처리가 필요합니다. 간단한 솔루션은 재시도하여 일시적인 오류를 처리하고 경고를 통해 일시적이지 않은 오류를 처리하는 것입니다.

https://medium.com/usertesting-engineering/event-based-microservices-error-handling-7c84e3cb1332