kinesis 중복레코드 처리(atleast once)

Kiensis란?

Kinesis는 실시간으로 데이터 스트림을 수집, 처리, 분석해주는 AWS 서비스이다.

• 데이터 스트림 수집 및 저장
• 샤드의 수를 조절하여 스트림을 얼마나 받을지 조절할 수 있음

데이터 중복이 일어나는 이유

애플리케이션에 레코드가 두 번 이상 전달되는 주된 이s유는 두가지로 나눌 수 있다.

1. 생산자 재시도
2. 소비자 재시도

각각의 경우에 어떤 이유로 일어나는지 알아보자

생산자 재시도

생산자재시도가 일어나는 가장 큰 이유는 네트워크 이슈문제일 가능성이 크다
Kiensis 스트림에서 승인을 받기 전에 네트워크 관련 시간초과가 발생한다면 생산자는 레코드가 스트림에 전달되었는지 알 수 없다
이러한 경우 동일한 데이터에 대해 PutRecord를 2번 이상 호출 할 수있다.(최대 3번까지 호출가능)
중복을 철저히 방지해야하는 애플리케이션은 처리할 때 레코드에 기본키를 포함시켜서 처리해줘야 한다.

소비자 재시도

사실 생산자 재시도보다는 소비자 재시도가 훨씬 더 많이 발생한다
다음과 같은 경우에 동일한 샤읃의 레코드 프로세서가 중복실행된다

1. 작업자가 예기치 않게 종료된 경우
2. 작업자 인스턴스가 추가 또는 제거된 경우
3. 샤드가 병합 또는 분할된 경우
4. 애플리케이션이 배포된 경우

설명이 모호할 수 있으니 구체적인 예를 통해 흐름을 살펴보자
샤드 1개와 샤드를 처리하는 작업자 1개가 있다고 가정해보자
마지막 체크포인트가 레코드 번호 10000에 있다는 가정하에 다음의 이벤트 흐름을 살펴보자

1. 작업자가 샤드에서 다음 레코드 배치(레코트 10001부터 20000까지)를 읽습니다
2. 그런 다음 작업자가 레코드 배치를 연결된 레코드 프로세서로 전달합니다
3. 레코드 프로세서가 데이터를 집계하고 Amazon S3 파일을 생성하며 파일을 Amazon S3로 업로드합니다.
4. 새로운 체크포인트가 발생하기 전에 작업자가 예기치 않게 종료됩니다
5. 애플리케이션, 작업자 및 레코드 프로세서가 다시 시작됩니다
6. 이제 작업자가 마지막으로 성공한 체크포인트(여기서는 10001)에서 읽기 시작합니다

따라서 레코드 10001 ~ 20000이 두번 이상 소비됩니다

운영 시스템 해결방법

위와 같은 이유로 중복레코드에 대한 상황이 발생할 수 있음을 인지하고 현재 운영중인 시스템에서는 이에대한 해결방법을 세웠다
실제로 운영중인 시스템에서 각 레코드의 항목들에는 그 항목을 유일하게 결정지을 수 있는 key값이 들어가있다
결국 해당 data insert문에 대하여 merge into 문법을 사용하여 중복되지않게 적재되도록 처리하였다