Amazon Kinesis Record duplicates는 어떻게 처리합니까?

Question

Amazon Kinesis Streams documentation에 따르면 레코드가 여러 번 전달 될 수 있습니다.

모든 레코드를 한 번만 처리하는 유일한 방법은 무결성 검사 (예 : DynamoDB, Elasticache 또는 MySQL/PostgreSQL)를 지원하는 데이터베이스에 임시 레코드를 저장하거나 각 Kinesis 샤드의 RecordId를 체크 포인트하는 것입니다.

더 효율적이고 중복 된 방법을 알고 계십니까?

Answer 1

우리는 정확히 문제가 있었다 . 우리의 경우 우리는 생산자가 각 메시지를 정확하게 한 번 전송했는지 여부를 확신 할 수 없었습니다. 따라서 수신 된 각 레코드에 대해 MD5를 즉석에서 계산하고 영구 저장 장치의 형태로 표시되는지 여부를 확인했지만 실제로 사용할 저장 장치는 무엇입니까? 가장 까다로운 비트.

우선 우리는 사소한 관계형 데이터베이스를 시도했지만 키네시스를 거치는 데이터의 양이 상당히 중요했기 때문에 이것은 읽기가 무거웠지만 쓰기가 힘든 경우이므로 시스템 전체의 주요 병목 현상이되었습니다. .

고유 메시지마다 MD5를 저장하는 DynamoDB 테이블을 갖게되었습니다. 우리가 가진 이슈는 메시지를 지우는 것이 그렇게 쉽지 않았기 때문입니다. 우리 테이블에는 파티션과 정렬 키가 포함되어 있지만 DynamoDB는 주어진 파티션 키를 가진 모든 레코드를 삭제할 수 없지만, 키 값 정렬 (시간과 용량 낭비). 불행히도 우리는 테이블 전체를 한 번만 놓아야했습니다. 차선책은 메시지 식별자를 저장하는 DynamoDB 테이블을 정기적으로 회전시키는 것입니다.

그러나 최근 DynamoDB는 매우 편리한 기능 (Time To Live)을 도입했습니다. 즉, 레코드 당 자동 만료 기능을 활성화하여 테이블의 크기를 제어 할 수 있습니다. 이러한 의미에서 DynamoDB는 ElastiCache와 매우 유사하지만 ElastiCache (적어도 Memcached 클러스터)는 훨씬 덜 내구성이 있습니다. 이중화가 없으며 작동 또는 실패의 규모가 큰 경우 종료 된 노드에있는 모든 데이터가 손실됩니다.

Answer 2

언급 한 사항은 "적어도 한 번"접근 방식을 사용하는 모든 대기열 시스템의 일반적인 문제입니다. 또한 대기열 시스템, 생산자 및 고객 모두가 동일한 메시지를 여러 번 처리 할 수 ​​있습니다 (ReadTimeout 오류 등으로 인해). Kinesis와 Kafka는 모두이 패러다임을 사용합니다. 불행히도 쉬운 대답은 아닙니다.

엄격한 트랜잭션 방식으로 "정확히 한 번"메시지 대기열을 사용해 볼 수도 있습니다. 예를 들어 AWS SQS가 수행하는 작업은 https://aws.amazon.com/about-aws/whats-new/2016/11/amazon-sqs-introduces-fifo-queues-with-exactly-once-processing-and-lower-prices-for-standard-queues/입니다. SQS 처리량은 키네시스보다 훨씬 작습니다.

문제를 해결하려면 응용 프로그램 도메인을 알고 제안 된 (데이터베이스 검사) 것과 같이 내부적으로 해결해야합니다. 특히 외부 서비스와 통신 할 때 (예를 들어 이메일 서버), 이중 처리를 방지하기 위해 작업 상태를 복구 할 수 있어야합니다 (전자 메일 서버 예제에서 이중 전송으로 인해 받는 사람의 사서함에 동일한 게시물).

다음 개념도 참조하십시오.

1. 에서-최소 한 번 배달 : http://www.cloudcomputingpatterns.org/at_least_once_delivery/
2. 정확히 한 번만 배달 : http://www.cloudcomputingpatterns.org/exactly_once_delivery/
3. 멱등 프로세서 : 모바일 앱에 대한 원격 측정 시스템을 구축 할 때 http://www.cloudcomputingpatterns.org/idempotent_processor/