이벤트 스트림을 설계하는 방법, 파트 3

이전 1 부 및 2 부 참조.

당신의 관계 이벤트 정의 그리고 이벤트 스트림 그 자체는 주요 디자인입니다. 내가 얻는 가장 일반적인 질문 중 하나는“여러 이벤트 유형을 한 스트림에 넣어도 괜찮습니까? 아니면 각 이벤트 유형을 자체 스트림에 게시해야합니까?”

이 기사는 이러한 질문에 답하는 데 기여하는 요소를 탐색하고 자신의 사용 사례에 대한 최상의 답변을 찾는 데 도움이되는 일련의 권장 사항을 제공합니다.

소비자 사용 사례를 예로 들어 보겠습니다

상태 변화에 대한 일반적인 경고 (DELTAS)
이벤트 순서 (DELTAS) 처리
전송 상태 (사실)
믹싱 사실과 델타

이벤트 스트림을 구성하는 방법을 결정할 때 소비자의 유스 케이스는 최고를 고려해야합니다. 이벤트 스트림은 한 번만 작성된 데이터 소스이지만 많은 다른 소비자가 여러 번 읽을 수 있습니다.

우리는 그들이 자신의 요구에 따라 데이터를 사용할 수 있도록 가능한 한 쉽게 만들고 싶습니다.

사용 사례 : 일반적인 변경에 대한 경고

델타는 일반적인 변화 경보에 매우 효과적입니다. 응용 프로그램은 응용 프로그램 내부에서 노출 된 델타 이벤트에 응답 할 수 있습니다. 스트림 당 하나의 유형 만 있도록 이벤트를 분할하면 높은 세분성을 제공하고 소비자 애플리케이션이 관심있는 델타 만 구독 할 수 있습니다.

사용 사례 : 델타 이벤트의 처리 시퀀스

그러나 단일 애플리케이션이 여러 델타를 읽어야하고 이벤트 간 순서가 매우 중요하다면 어떨까요? 스트림 당 하나의 이벤트에 따라 이벤트가 순서대로 읽고 처리 될 수있는 위험을 도입하여 일관되지 않은 시퀀싱 결과를 제공합니다.

Kafka Streams 및 Flink와 같은 스트림 프로세서에는 일반적으로 “이벤트 일정”이라고하는 프로세스 인 오름차순 타임 스탬프 및 오프셋 순서에서 이벤트를 처리하는 논리가 포함되어 있습니다. 예를 들어, Kafka Streams는 최상의 효과 알고리즘을 사용하여 다음 레코드를 프로세스 할 레코드를 선택하는 반면 Flink는 워터 마킹 전략을 사용하여 타임 스탬프를 기반으로 레코드를 처리합니다. 모든 스트림 처리 프레임 워크가 이벤트 스케줄링을 지원하는 것은 아니며 레이스 조건 결과에 따라 처리 주문을 크게 발산합니다.

하루가 끝나면 이벤트 일정조차도 최선의 시도입니다. 응용 프로그램 또는 하드웨어의 간헐적 실패뿐만 아니라 프레임 워크 자체의 해결되지 않은 코너 케이스 및 레이스 조건으로 인해 주문 외 처리는 여전히 발생할 수 있습니다.

이것은 보이는 것만 큼 끔찍하지 않습니다. 스트리밍 사용 사례의 많은 (대다수가 아닌 경우) 주제 간의 처리 순서에 민감하지 않습니다. 민감한 사람들의 경우 워터 마킹 및 이벤트 일정은 대부분의 경우에 꽤 잘 작동하는 경향이 있습니다. 그리고 완벽하게 엄격한 순서가 필요한 이벤트 시퀀스에? 글쎄, 계속 읽으십시오.

엄격한 주문은 어떻습니까?

그러나 더 강한 보증으로 무언가가 필요하다면 어떻게합니까? 이벤트의 정확하고 엄격한 순서는 비즈니스 사용 사례의 중요한 요소 일 수 있습니다.

이 경우 소비자가 작성된 것과 동일한 순서로 수신 할 수 있도록 모든 이벤트를 단일 이벤트 스트림에 넣는 것이 좋습니다. Kafka는 파티션별로 만 주문을 보장하기 때문에 동일한 키의 모든 이벤트가 동일한 파티션으로 이동하도록하기 위해 일관된 파티션 전략이 필요합니다.

이 기술은 사용하고있는 주제의 수를 줄이는 것이 아닙니다. 주제는 상대적으로 저렴하며, 가지고있는 데이터와 그들이 제공하는 목적을 기반으로 주제를 구축하도록 선택해야합니다. 주제 수를 단순히 줄입니다. Apache Kafka는 문제없이 수천 개의 주제를 처리 할 수 있습니다.

단일 스트림, 다중 델타 유형

관련 이벤트 유형을 단일 주제 파티션에 넣으면 소비자 처리를위한 엄격한 증분 순서가 제공되지만 이벤트 순서를 엄격하게 제어해야하므로 모든 이벤트가 단일 생산자가 작성해야합니다.

이 예에서는 쇼핑 카트의 모든 추가, 제거 및 할인 코드를 단일 이벤트 스트림의 단일 파티션으로 병합했습니다.

사용 사례 : 델타 이벤트의 처리 시퀀스

확대되면이 행사 스트림과 결합 된 단일 소비자를 볼 수 있습니다. 스트림의 각 유형을 이해하고 해석 할 수 있어야합니다. 주제를 여러 이벤트 유형에 대한 주제로 바꾸지 않고 소비자가 간단히 파악할 것으로 기대하는 것이 중요합니다. 오히려 소비자는 각 델타 유형을 처리하는 방법을 알아야하며, 기존 유형에 대한 새로운 유형 또는 변경 사항은 응용 프로그램 소유자간에 협상해야합니다.

Flink SQL을 사용하여 스트림을 분할하십시오

또한 Flink와 같은 스트림 프로세서를 사용하여 단일 카트 이벤트 스트림을 델타 당 이벤트 스트림으로 분할하여 각 이벤트를 새로운 주제에 기록합니다. 소비자는 이러한 목적으로 지어진 델타 스트림을 구독하도록 선택하거나 원래 스트림을 구독하고 신경 쓰지 않는 이벤트를 필터링 할 수 있습니다.

주의의 말

그러나주의의 한마디. 이 패턴은 생산자와 소비자 서비스간에 매우 강한 커플 링을 초래할 수 있습니다. 일반적으로 이벤트 소싱을 사용하는 한 쌍의 시스템과 같이 강력하게 결합 된 응용 프로그램에만 적합합니다. 또한이 두 응용 프로그램이 분리 할 가치가 있는지 또는 단일 응용 프로그램으로 재 설계 해야하는지 스스로에게 물어봐야합니다.

사용 사례 : 사실과 상태를 전송합니다

사실은 이벤트 조정 상태 전송으로 알려진 능력을 제공합니다. 각 이벤트는 특정 시점에서 특정 엔티티의 상태를 완전히 볼 수 있습니다.

사실 이벤트는 상태를 전송하는 데 훨씬 더 나은 옵션을 제시하고 소비자가 일련의 이벤트를 해석 할 필요가 없으며 훨씬 느슨한 커플 링 옵션을 제공합니다. 이 경우 이벤트 스트림 당 단일 이벤트 유형 만 사용됩니다. 다양한 스트림의 사실이 혼합되지 않습니다.

스트림 당 하나의 사실 유형 만 유지하면 액세스가 필요한 모든 응용 프로그램으로 읽기 전용 상태를 훨씬 쉽게 전송할 수 있습니다. 사실의 스트림은 비즈니스 문제를 해결하기 위해 목적으로 제작 된 응용 프로그램 및 서비스를 작성하기위한 데이터 빌딩 블록 역할을 효과적으로 작용합니다.

스트림 당 단일 사실 유형

Kafka Streams 또는 Flink와 같이 응용 프로그램을 구축 할 수있는 도구를 살펴보면 스트림 당 한 유형의 사실에 대한 규칙이 다시 나타납니다.

이 예에서 Flink SQL 응용 프로그램은 항목 사실을 테이블로 구체화합니다. 쿼리는 테이블 스키마, Kafka 주제 소스, 키 열 및 키 및 값 스키마 형식을 지정합니다.

Flink SQL은 엄격한 스키마 정의를 시행하고 이벤트를 준수하지 않는 이벤트를 버릴 것입니다. 이는 테이블 스키마 요구 사항을 충족하지 않는 데이터를 삽입하려는 경우 관계형 데이터베이스가 예외를 던지는 방법과 동일합니다.

이질적인 사실 스트림에 가입

다른 스트림에서 여러 유형의 사실을 소비 할 때 Flink SQL의 조인 기능을 활용하고 자신의 비즈니스 로직에 필요한 필드 만 선택하고 나머지를 버릴 수 있습니다. 이 예에서 Flink SQL 응용 프로그램은 인벤토리 및 항목 사실 모두에서 소비되며 ID, 가격, 이름 및 주식 만 선택하지만 재고가 하나 이상있는 경우 기록을 유지합니다. 데이터는 필터링되고 함께 결합 된 다음 재고 내 항목 사실 스트림으로 방출되며, 이는 필요한 모든 응용 프로그램에서 사용할 수 있습니다.

모범 사례 : 한 가지 사실 전체를 기록하십시오

이벤트를 녹음 할 때는 단일 상세한 이벤트에서 일어난 모든 일을 유지하는 것이 중요합니다.

고려하십시오 주문하다 (위)는 두 a로 구성됩니다 카트 엔티티와 a 사용자 실재. 주문 이벤트를 만들 때 모든 CART 정보와 해당 시점에서 사용자의 모든 사용자 정보를 삽입합니다. 우리는 이벤트를 단일 원자 메시지로 기록하여 일어난 일을 정확하게 표현합니다. 우리는합니다 ~ 아니다 다른 여러 주제에서 여러 이벤트로 나누십시오!

소비자는 이벤트에서 실제로 원하는 데이터 만 자유롭게 선택할 수 있으며 항상 복합 이벤트를 분할 할 수 있습니다. 그러나 처음부터 나누면 원래 이벤트를 재구성하는 것이 훨씬 어렵습니다.

모범 사례는 초기 이벤트에 고유 한 ID를 제공 한 다음 모든 파생 이벤트로 전파하는 것입니다. 이것은 이벤트 추적을 제공합니다. 향후 게시물에서 이벤트 ID를 더 자세히 다룰 것입니다.

사용 사례 : 믹싱 사실과 델타

소비자는 또한 필요한 사실을 선택하고 선택한 델타와 결합하여 응용 프로그램을 구성 할 수 있습니다.

이 접근법은 각 소비자의 요구에 따라 데이터를 쉽게 혼합 할 수 있으므로 이벤트 스트림 당 단일 유형에 의해 가장 잘 작동합니다.

요약

단일 델타 유형의 단일 스트림을 사용하면 응용 프로그램이 특정 에지 조건에 쉽게 응답 할 수 있지만 자체 상태를 구축하고 자신의 비즈니스 논리를 적용 할 책임이 있습니다.

스트림 당 단일 델타는 상태를 완벽하게 집계하려고 할 때 어려움을 초래할 수 있습니다. 또한 집계를 구축하기 위해 어떤 이벤트를 고려해야하는지 알아 내려고 할 때 어려울 수 있습니다.

일련의 델타에서 집계를 구축하는 것과 같이 엄격한 순서에 관심이있는 경우 동일한 스트림에 여러 이벤트 유형을 동일한 스트림에 넣으십시오. 최종 상태를 구성하는 데 필요한 모든 데이터와 생산자가 게시 한 것과 정확히 같은 순서로 제공됩니다.

단점은 실제로 신경 쓰지 않는 경우에도 각 이벤트를 소비하고 처리해야한다는 것입니다.

마지막으로, 사실 스트림에는 단일 이벤트 유형을 사용하십시오. 이 정보는이 정보를 테이블 당 잘 정의 된 단일 스키마와 함께 관계형 데이터베이스에 저장하는 방법과 동일합니다. 스트림 소비자는 Kafka Streams 또는 Flink와 같은 도구를 사용하여 자신의 사용 사례에 필요한 사실을 혼합, 일치 및 혼합 할 수 있습니다.