자꾸 지각하는 이벤트는 어떻게 해야할까

 

 

특정 요건에서는 이벤트의 순서가 반드시 보장되어야 하는 경우가 있다.

 

 

철수는 100원을 가진 상태에서 100원을 더 입금하고 200원을 결제했다.

 

하지만 어떤 이유로 먼저 발행된(t=5)인 100원 입금 이벤트보다 나중에 발행된(t=10) 200원 인출 이벤트가 먼저 도착했다.

 

철수는 잔액 부족으로 결제를 실패할 것이다 !!

 

자칫 이렇게 순서가 어긋나게 도착하는 경우는 안 일어날 것이라고 생각할 수 있다.

 

하지만 절대 어긋나지 않을 것이라는 보장은 없다.

 

순서를 보장하지 않는 경우, 결국 부정확한 결과를 초래할 수 있다.

 

오늘은 이런 비순차 이벤트, 지각 이벤트에 대해 말해보고자 한다.

 

• 여러 파티션에서 이벤트를 소비할 경우, 이벤트 처리 순서를 어떻게 정할 것인지?
• 순서가 어긋난 이벤트, 지각 이벤트는 어떻게 처리할 것인지?
• 서비스는 처리 결과를 확정적으로 생산할 수 있는지?

 

1. 확정성을 지키기 위한 기반

이벤트 기반 마이크로서비스의 처리 상태는 보통 다음과 같다.

• 이벤트를 실시간에 가깝게 처리
• 과거부터 이벤트를 처리해서 현재를 따라잡기 (catch up)

처리 방식에 관계없이, 가장 중요한 목표는 동일한 출력을 내도록 하는 것이다.

 

하지만 이벤트의 지연, 프로듀서/컨슈머 장애, 네트워크 이슈 등의 이유로 확정적으로 처리하는 방법은 없다.

 

따라서 최대한 요건을 충족하기 위해 여러 전략을 사용할 수 있다.

 

1-1. 타임스탬프

이벤트 스트림에서 오프셋과 타임스탬프를 통해 이벤트 처리 상태를 확인할 수 있다.

 

오프셋 (offset)
컨슈머가 이벤트를 어디까지 읽었는지 나타내는 값

타임스탬프 (timestamp)
이벤트가 생성된 시간

 

아래는 전체 프로세스에서 나타낸 타임스탬프 순서이다.

 

 

• 이벤트 시간 (event time)
  • 이벤트 발생 시점에 프로듀서가 이벤트에 할당한 로컬 타임스탬프
• 브로커 인입 시간 (broker ingestion time)
  • 이벤트가 브로커에 인입된 시간
  • 브로커가 할당한 타임스탬프 or 인입 시간으로 설정
• 컨슈머 인입 시간 (consumer ingestion time)
  • 이벤트가 컨슈머에 인입된 시간
  • 이벤트 시간 or 월클럭 시간으로 설정
• 처리 시간 (processing time)
  • 컨슈머가 이벤트 처리를 완료한 월클럭 시간

 

이벤트 시간이 브로커를 통해 전달되어 컨슈머도 이벤트 생성 시간을 알 수 있기 때문에, 이벤트 처리 시점에 선후 관계를 파악할 수 있다.

 

이벤트 타임스탬프는 이벤트 시간이나 브로커 인입 시간을 사용하면 된다.
월클럭이나 컨슈머 인입 시간은 실행 시점에 따라 달라지기 때문에 사용하면 안 된다.
대부분은 로컬 시스템이 할당한 이벤트 시간을 사용하는게 좋고, 불가능 하다면 브로커 인입 시간이 최선이다.

 

 

하지만 여기서 문제가 있는데, 여러 프로듀서가 정확하게 시간 동기화가 불가능하기 때문에

여러 프로듀서로부터 받은 이벤트의 경우, 정확하게 선후 관계를 결정짓는게 어려워질 수 있다.

 

각 프로듀서간 시간을 최대한 동기화하기 위해 클럭 타임을 네트워크 타임 프로토콜(NTP) 서버와 동기화한다.

 

네트워크 타임 프로토콜 (Network Time Protocol)
네트워크의 모든 디바이스에서 시간을 동기화하기 위해 사용하는 프로토콜.
LAN 환경에서 오차를 15분당 수 밀리초 정도로 좁힐 수 있다.
참조 : https://www.ntp.org/

 

따라서, 이벤트를 처리하는 시점에 타임스탬프를 이용해서 발생한 순서대로 정렬하여 처리하는 이벤트 스케줄링을 구현함으로써 재연 가능한 결과를 일관되게 얻을 수 있다.

 

1-2. 워터마크

워터마크(watermark)는 이벤트 시간의 진행 상황을 추적하고, 주어진 이벤트 시간까지의 모든 데이터가 처리 완료됐음을 선언하기 위해 사용한다.

 

주요 스트림 처리 프레임워크(아파치 스파크,플링크, 삼자, 빔)에서 통용되게 사용되는 방법이다.

 

 

t=18인 이벤트부터 t=25인 이벤트를 모두 읽었고, node1은 t=25인 이벤트를 마지막으로 소비하고 내부 이벤트 시간을 25로 업데이트 했다.

 

각 워터마크를 수신한 노드들은 자신의 내부 이벤트 시간을 업데이트하고, 의존 관계에 있는 다른 노드에 차례로 전파한다.

 

워터마크는 타임스탬프가 그 값보다 작은 이벤트는 지각 이벤트로 간주해야 한다는 것을 알릴 뿐이고, 이벤트 스케줄링에는 영향을 미치지 않는다.

 

워터마크는 추후에 윈도(window) 개념과 묶어 활용된다.

 

2. 비순차/지각 이벤트 처리

이제 타임스탬프를 활용하여 비순차/지각 이벤트를 감지하는 것을 알았다.

 

비순차/지각 이벤트는 데이터가 얼마나 중요한가에 따라 어떻게 처리할지 결정해야 한다.

 

• 지각 이벤트가 발생할 가능성은?
• 서비스는 얼마나 오랫동안 지각 이벤트를 기다려야 하는지?
• 지각 이벤트를 누락하면 어떤 영향을 미치는지?
• 지각 이벤트를 위해 오래 기다리면 어떤 점에서 이로운지?
• 유지하기 위해 디스크, 메모리가 얼마나 많이 필요한지?
• 지각 이벤트를 기다리는 비용이 그로 인해 얻는 혜택을 능가하는지?

 

여러 비즈니스 요건을 따져보고, 아래와 같은 처리를 할 수 있다.

 

• 이벤트 폐기(drop event) : 이벤트를 버린다.
• 대기(wait) : 일정 시간 윈도우 결과 출력을 늦춘다. 지연 시간이 늘어나는 만큼 확정성을 높이는 방법이다.
• 유예 기간(grace period) : 윈도우가 완료된 것으로 간주되면 바로 결과를 출력하고, 유예 기간 동안 가용한 상태로 열어둔다. 지각 이벤트가 도착할 때 마다 업데이트 하여 새로운 값을 출력한다.

유예 기간은 대기와 달리 지각 이벤트 도착시 즉시 업데이트가 발생한다는 차이점이 있다.

 

 

대기 시간, 유예 기간, 처리 방법 모두 정해진 정답이 없고 데이터 중요도에 따라 서비스별로 구축하면 된다.