이벤트 기반 아키텍처 스타일

이벤트 기반 아키텍처는 이벤트 스트림을 생성하는 이벤트 생산자, 이러한 이벤트를 수신 대기하는 이벤트 소비자 및 생산자에서 소비자로 이벤트를 전송하는 이벤트 채널로 구성됩니다.

이벤트는 거의 실시간으로 전달되므로 이벤트가 발생하는 즉시 소비자가 이벤트에 응답할 수 있습니다. 생산자는 소비자와 분리됩니다: 생산자는 어떤 소비자가 듣고 있는지 알지 못합니다. 소비자도 서로 분리되며 각 소비자에게 모든 이벤트가 표시됩니다. 이 프로세스는 소비자가 큐에서 메시지를 끌어오고 메시지가 한 번만 처리되는 경쟁 소비자 패턴 과 다르며 오류가 없다고 가정합니다. Azure IoT(사물 인터넷)와 같은 일부 시스템에서는 이벤트를 대량으로 수집해야 합니다.

이벤트 기반 아키텍처는 게시-구독 모델 또는 이벤트 스트림 모델을 사용할 수 있습니다.

• Pub/sub: 게시-구독 메시징 인프라는 구독을 추적합니다. 이벤트가 게시되면 각 구독자에게 이벤트를 보냅니다. 이벤트를 받은 후에는 재생할 수 없으며 새 구독자는 이벤트를 볼 수 없습니다.

• 이벤트 스트리밍: 이벤트는 로그에 기록됩니다. 이벤트는 파티션 내에서 엄격하게 정렬되며 내구성이 있습니다. 클라이언트는 스트림을 구독하지 않습니다. 대신 클라이언트는 스트림의 모든 부분에서 읽을 수 있습니다. 클라이언트는 스트림에서 자신의 위치를 발전시킬 책임이 있습니다. 즉, 클라이언트는 언제든지 조인할 수 있으며 이벤트를 재생할 수 있습니다.

소비자 측면에서 다음과 같은 몇 가지 일반적인 변형이 있습니다.

• 간단한 이벤트 처리: 이벤트는 소비자의 작업을 즉시 트리거합니다. 예를 들어 Azure Service Bus 트리거와 함께 Azure Functions를 사용하여 메시지가 Service Bus 토픽에 게시될 때마다 함수가 실행되도록 할 수 있습니다.

• 기본 이벤트 상관 관계: 소비자는 몇 가지 불연속 비즈니스 이벤트를 처리하고, 일부 식별자와 상관 관계를 지정하며, 이후 이벤트를 처리할 때 사용할 수 있도록 이전 이벤트의 정보를 유지합니다. NServiceBus 및 MassTransit 같은 라이브러리는 이 패턴을 지원합니다.

• 복잡한 이벤트 처리: 소비자는 Azure Stream Analytics와 같은 기술을 사용하여 일련의 이벤트를 분석하고 이벤트 데이터의 패턴을 식별합니다. 예를 들어 시간 기간 동안 포함된 디바이스의 판독값을 집계하고 이동 평균이 특정 임계값을 초과하는 경우 알림을 생성할 수 있습니다.

• 이벤트 스트림 처리: Azure IoT Hub 또는 Apache Kafka와 같은 데이터 스트리밍 플랫폼을 이벤트를 수집하고 스트림 프로세서에 피드하는 파이프라인으로 사용합니다. 스트림 프로세서는 스트림을 처리하거나 변환합니다. 애플리케이션의 여러 하위 시스템에 대한 여러 스트림 프로세서가 있을 수 있습니다. 이 접근 방법은 IoT 워크로드에 적합합니다.

이벤트의 원본은 IoT 솔루션의 물리적 디바이스와 같이 시스템 외부에 있을 수 있습니다. 이 경우 시스템은 데이터 원본에 필요한 볼륨 및 처리량으로 데이터를 수집할 수 있어야 합니다.

이벤트 페이로드를 구성하는 두 가지 주요 방법이 있습니다. 이벤트 소비자를 제어할 수 있는 경우 각 소비자에 대한 페이로드 구조를 결정할 수 있습니다. 이 전략을 사용하면 단일 워크로드 내에서 필요에 따라 접근 방식을 혼합할 수 있습니다.

• 페이로드에 필요한 모든 특성을 포함합니다 . 소비자가 외부 데이터 원본을 쿼리할 필요 없이 사용 가능한 모든 정보를 포함하도록 하려면 이 방법을 사용합니다. 그러나 여러 레코드 시스템( 특히 업데이트 후)으로 인해 데이터 일관성 문제가 발생할 수 있습니다. 계약 관리 및 버전 관리도 복잡해질 수 있습니다.

• 페이로드에 키만 포함합니다 . 이 방법에서 소비자는 기본 키와 같은 필요한 특성을 검색하여 데이터 원본에서 나머지 데이터를 독립적으로 가져옵니다. 이 메서드는 단일 레코드 시스템을 가지고 있으므로 더 나은 데이터 일관성을 제공합니다. 그러나 소비자가 데이터 원본을 자주 쿼리해야 하므로 첫 번째 방법보다 성능이 저하되는 경우가 있습니다. 더 작은 이벤트와 더 간단한 계약으로 인해 복잡성이 줄어들기 때문에 결합, 대역폭, 계약 관리 또는 버전 관리에 대한 우려가 적습니다.

위의 다이어그램에서 각 소비자 유형은 단일 상자로 표시됩니다. 소비자가 시스템에서 단일 실패 지점이 되지 않도록 하려면 일반적으로 소비자의 여러 인스턴스를 사용하는 것이 일반적입니다. 이벤트의 볼륨 및 빈도를 처리하려면 여러 인스턴스가 필요할 수도 있습니다. 단일 소비자는 여러 스레드에서 이벤트를 처리할 수 있습니다. 이 설정은 이벤트를 순서대로 처리해야 하거나 정확히 한 번 의미 체계가 필요한 경우 문제를 일으킬 수 있습니다. 자세한 내용은 조정 최소화를 참조하세요.

두 가지 기본 토폴로지가 여러 이벤트 기반 아키텍처 내에 존재합니다.

• Broker 토폴로지: 구성 요소는 발생 항목을 전체 시스템에 이벤트로 브로드캐스트합니다. 다른 구성 요소는 이벤트에 대해 작동하거나 이벤트를 무시합니다. 이벤트 처리 흐름이 비교적 간단한 경우 이 토폴로지가 유용합니다. 중앙 조정 또는 오케스트레이션이 없으므로 이 토폴로지도 동적일 수 있습니다. 이 토폴로지는 확장성, 응답성 및 구성 요소 내결함성을 제공하기 위해 고도로 분리됩니다. 다단계 비즈니스 트랜잭션의 상태를 소유 또는 인식하지 않는 구성 요소가 없으며, 작업은 비동기적으로 수행됩니다. 그 후 분산 트랜잭션은 다시 시작하거나 재생할 수 있는 기본 방법이 없기 때문에 위험합니다. 이 토폴로지가 데이터 불일치의 원인일 수 있으므로 오류 처리 및 수동 개입 전략을 신중하게 고려해야 합니다.

• 중재자 토폴로지: 이 토폴로지에서는 브로커 토폴로지의 몇 가지 단점을 해결합니다. 이벤트 흐름을 관리하고 제어하는 이벤트 중재자가 있습니다. 이벤트 중재자는 상태를 유지하며 오류 처리 및 다시 시작 기능을 관리합니다. 브로커 토폴로지와 달리 이 토폴로지에서 구성 요소는 발생 항목을 명령으로 브로드캐스트하고 지정된 채널에만 브로드캐스트합니다. 이러한 채널은 일반적으로 메시지 큐입니다. 소비자는 이러한 명령을 처리해야 합니다. 이 토폴로지에서는 더 많은 제어, 더 나은 분산 오류 처리 및 잠재적으로 더 나은 데이터 일관성을 제공합니다. 이 토폴로지는 구성 요소 간의 결합을 증가시키고 이벤트 중재자는 병목 상태 또는 안정성 문제가 될 수 있습니다.

이 아키텍처를 사용하는 경우

다음과 같은 경우 이 아키텍처를 사용해야 합니다.

• 여러 하위 시스템이 동일한 이벤트를 처리해야 하는 경우.
• 최소 시간 지연을 사용한 실시간 처리가 필요합니다.
• 패턴 일치 또는 시간 창에 따른 집계와 같은 복잡한 이벤트 처리가 필요합니다.
• 예를 들어 IoT와 마찬가지로 대용량 및 높은 속도의 데이터가 필요합니다.

이점

이 아키텍처의 이점은 다음과 같습니다.

• 생산자와 소비자가 분리됩니다.
• 지점 간 통합이 없습니다. 시스템에 새 소비자를 쉽게 추가할 수 있습니다.
• 소비자는 이벤트가 발생하면 즉시 응답할 수 있습니다.
• 확장성이 뛰어나고 탄력적이며 분산되어 있습니다.
• 하위 시스템에서 이벤트 스트림을 독립적으로 확인할 수 있습니다.

과제

• 배달 보장.

  일부 시스템, 특히 IoT 시나리오에서는 이벤트가 배달되도록 보장하는 것이 중요합니다.

• 이벤트를 순서대로 또는 한 번만 처리.

  복원력 및 확장성을 위해 각 소비자 유형은 일반적으로 여러 인스턴스에서 실행됩니다. 이 프로세스는 이벤트를 소비자 유형 내에서 순서대로 처리해야 하거나 idempotent 메시지 처리 논리가 구현되지 않은 경우 챌린지를 만들 수 있습니다.

• 서비스 간 메시지 조정

  비즈니스 프로세스에는 전체 워크로드에서 일관된 결과를 얻기 위해 메시지를 게시하고 구독하는 여러 서비스가 있는 경우가 많습니다. 안무 패턴 및 사가 오케스트레이션과 같은 워크플로 패턴을 사용하여 다양한 서비스에서 메시지 흐름을 안정적으로 관리할 수 있습니다.

• 오류 처리.

  이벤트 기반 아키텍처는 주로 비동기 통신을 사용합니다. 오류 처리는 비동기 통신의 과제입니다. 이 문제를 해결하는 한 가지 방법은 별도의 오류 처리기 프로세서를 사용하는 것입니다. 이벤트 소비자가 오류를 경험하면 오류 처리기 프로세서에 잘못된 이벤트를 즉시 비동기적으로 보내고 계속 진행합니다. 오류 처리기 프로세서는 오류를 수정하고자 시도하며, 원래 수집 채널로 이벤트를 다시 전송합니다. 그러나 오류 처리기 프로세서가 실패하면 관리자에게 잘못된 이벤트를 보내 추가 검사를 수행할 수 있습니다. 오류 처리기 프로세서를 사용하는 경우 잘못된 이벤트는 다시 제출할 때 순서대로 처리됩니다.

• 데이터 손실.

  비동기 통신의 또 다른 과제는 데이터 손실입니다. 이벤트를 성공적으로 처리하고 다음 구성 요소에 전달하기 전에 구성 요소가 충돌하는 경우 이벤트가 삭제되고 최종 대상으로 전달되지 않습니다. 데이터 손실 가능성을 최소화하려면 전송 중인 이벤트를 유지하며 다음 구성 요소가 이벤트 수신을 승인하는 경우에만 이벤트를 제거하거나 큐에서 제거합니다. 이러한 기능을 클라이언트 승인 모드 및 마지막 참가자 지원이라고 합니다.

• 기존 요청-응답 패턴의 구현입니다.

  경우에 따라 이벤트 생산자는 주문을 진행하기 전에 고객 자격 획득과 같은 이벤트 소비자의 즉각적인 응답을 요구합니다. 이벤트 기반 아키텍처에서는 요청-응답 메시징을 사용하여 동기 통신을 수행할 수 있습니다.

  이 패턴은 일반적으로 요청 큐와 응답 큐라는 두 개의 큐로 구현됩니다. 이벤트 생산자는 요청 큐에 비동기 요청을 보내고, 해당 작업에 대한 다른 작업을 일시 중지하고, 회신 큐에서 응답을 기다립니다. 이 방법을 사용하면 이 패턴을 동기 프로세스로 효과적으로 전환할 수 있습니다. 그런 다음 이벤트 소비자는 요청을 처리하고 응답 큐를 통해 회신을 다시 보냅니다. 이 방법은 일반적으로 추적에 세션 ID를 사용하므로 이벤트 생산자는 특정 요청과 관련된 응답 큐의 메시지를 알 수 있습니다. 원래 요청은 회신 헤더 또는 상호 합의된 다른 사용자 지정 특성에서 응답 큐의 이름(잠재적으로 임시)을 지정할 수도 있습니다.

• 적절한 수의 이벤트를 유지 관리합니다.

  과도한 수의 세분화된 이벤트를 생성하면 시스템이 포화되고 과부하가 발생하여 이벤트의 전체 흐름을 효과적으로 분석하기가 어려울 수 있습니다. 이 문제는 변경 내용을 롤백해야 할 때 악화됩니다. 반대로, 이벤트를 과도하게 통합하면 문제가 발생하여 이벤트 소비자의 불필요한 처리 및 응답이 발생할 수 있습니다.

  적절한 균형을 달성하려면 이벤트의 결과와 소비자가 이벤트 페이로드를 검사하여 응답을 확인해야 하는지 여부를 고려합니다. 예를 들어 규정 준수 검사 구성 요소가 있는 경우 규 격 및 비규격의 두 가지 이벤트 유형만 게시하는 것으로 충분할 수 있습니다. 이 방법을 사용하면 관련 소비자만 각 이벤트를 처리하여 불필요한 처리를 방지할 수 있습니다.

기타 고려 사항

• 이벤트에 포함할 데이터의 양은 성능과 비용 모두에 영향을 주는 중요한 고려 사항일 수 있습니다. 이벤트에서 직접 처리하는 데 필요한 모든 관련 정보를 배치하여 처리 코드를 간소화하고 추가 조회를 제거할 수 있습니다. 몇 가지 식별자와 같은 최소한의 정보만 이벤트에 추가하면 전송 시간과 비용을 줄일 수 있습니다. 그러나 이 방법을 사용하려면 처리 코드가 필요한 추가 정보를 검색해야 합니다. 자세한 내용은 다이어트에 이벤트를 넣어 참조 하세요.

• 요청은 요청 처리 구성 요소에만 표시됩니다. 그러나 이러한 구성 요소가 해당 구성 요소를 사용하지 않거나 사용하지 않더라도 이벤트는 워크로드의 여러 구성 요소에 표시되는 경우가 많습니다. "위반 가정" 사고 방식을 사용하려면 의도하지 않은 정보 노출을 방지하기 위해 이벤트에 포함할 정보를 염두에 두어야 합니다.

• 많은 애플리케이션은 이벤트 기반 아키텍처를 기본 아키텍처로 사용합니다. 이 접근 방식을 다른 아키텍처 스타일과 결합하여 하이브리드 아키텍처를 만들 수 있습니다. 일반적인 조합에는 마이크로 서비스,파이프 및 필터가 포함됩니다. 이벤트 기반 아키텍처를 통합하여 병목 상태를 제거하고 요청량이 많은 동안 다시 압력을 제공하여 시스템 성능을 향상시킵니다.

• 특정 도메인은 여러 이벤트 생산자, 소비자 또는 이벤트 채널에 걸쳐 있는 경우가 많습니다. 특정 도메인을 변경하면 많은 구성 요소에 영향을 줄 수 있습니다.

관련 참고 자료

• 연출 및 오케스트레이션 사이에서 선택하는 고려 사항에 관한 커뮤니티 토론 비디오.