이벤트 기반 아키텍처 스타일Event-driven architecture style

이벤트 기반 아키텍처는 이벤트 스트림을 생성하는 이벤트 생산자와 이벤트를 수신 대기하는 이벤트 소비자로 구성됩니다.An event-driven architecture consists of event producers that generate a stream of events, and event consumers that listen for the events.

이벤트 기반 아키텍처 스타일의 다이어그램

이벤트는 거의 실시간으로 전달되므로 이벤트가 발생하는 즉시 소비자가 이벤트에 응답할 수 있습니다.Events are delivered in near real time, so consumers can respond immediately to events as they occur. 생산자와 소비자가 분리되므로 생산자는 수신 대기 중인 소비자를 알 수 없습니다.Producers are decoupled from consumers — a producer doesn't know which consumers are listening. 소비자도 서로 분리되며 각 소비자에게 모든 이벤트가 표시됩니다.Consumers are also decoupled from each other, and every consumer sees all of the events. 이는 소비자가 큐에서 메시지를 끌어오고 오류가 없다고 가정할 경우 메시지가 한 번만 처리되는 경쟁 소비자 패턴과 다릅니다.This differs from a Competing Consumers pattern, where consumers pull messages from a queue and a message is processed just once (assuming no errors). IoT와 같은 일부 시스템에서는 매우 높은 볼륨으로 이벤트를 수집해야 합니다.In some systems, such as IoT, events must be ingested at very high volumes.

이벤트 기반 아키텍처는 게시자/구독자 모델 또는 이벤트 스트림 모델을 사용할 수 있습니다.An event driven architecture can use a pub/sub model or an event stream model.

  • 게시자/구독자: 메시징 인프라에서 구독을 추적합니다.Pub/sub: The messaging infrastructure keeps track of subscriptions. 이벤트가 게시되면 각 구독자에게 이벤트를 보냅니다.When an event is published, it sends the event to each subscriber. 이벤트를 받은 후에는 재생할 수 없으며 새 구독자에게 이벤트가 표시되지 않습니다.After an event is received, it cannot be replayed, and new subscribers do not see the event.

  • 이벤트 스트리밍: 이벤트가 로그에 기록됩니다.Event streaming: Events are written to a log. 이벤트가 파티션 내에 엄격하게 정렬되며 지속 가능합니다.Events are strictly ordered (within a partition) and durable. 클라이언트는 스트림을 구독하지 않고, 대신 스트림의 일부에서 읽을 수 있습니다.Clients don't subscribe to the stream, instead a client can read from any part of the stream. 클라이언트가 스트림에서 해당 위치를 진행해야 합니다.The client is responsible for advancing its position in the stream. 즉, 클라이언트가 언제든지 연결하고 이벤트를 재생할 수 있습니다.That means a client can join at any time, and can replay events.

소비자 측면에서 다음과 같은 몇 가지 일반적인 변형이 있습니다.On the consumer side, there are some common variations:

  • 단순 이벤트 처리.Simple event processing. 이벤트가 즉시 소비자에서 작업을 트리거합니다.An event immediately triggers an action in the consumer. 예를 들어 서비스 버스 토픽에 메시지를 게시할 때마다 함수가 실행되도록 서비스 버스 트리거와 함께 Azure Functions를 사용할 수 있습니다.For example, you could use Azure Functions with a Service Bus trigger, so that a function executes whenever a message is published to a Service Bus topic.

  • 복합 이벤트 처리.Complex event processing. 소비자가 Azure Stream Analytics 또는 Apache Storm과 같은 기술을 사용하여 이벤트 데이터에서 패턴을 찾으면서 일련의 이벤트를 처리합니다.A consumer processes a series of events, looking for patterns in the event data, using a technology such as Azure Stream Analytics or Apache Storm. 예를 들어 포함된 디바이스에서 일정 기간 동안 읽은 값을 집계하고 이동 평균이 특정 임계값을 초과하면 알림을 생성할 수 있습니다.For example, you could aggregate readings from an embedded device over a time window, and generate a notification if the moving average crosses a certain threshold.

  • 이벤트 스트림 처리.Event stream processing. Azure IoT Hub 또는 Apache Kafka와 같은 데이터 스트리밍 플랫폼을 파이프라인으로 사용하여 이벤트를 수집하고 스트림 프로세서에 공급합니다.Use a data streaming platform, such as Azure IoT Hub or Apache Kafka, as a pipeline to ingest events and feed them to stream processors. 스트림 프로세서는 스트림을 처리하거나 변환합니다.The stream processors act to process or transform the stream. 애플리케이션의 각 하위 시스템에 사용되는 여러 스트림 프로세서가 있을 수 있습니다.There may be multiple stream processors for different subsystems of the application. 이 접근 방법은 IoT 워크로드에 적합합니다.This approach is a good fit for IoT workloads.

이벤트의 소스가 IoT 솔루션의 물리적 디바이스와 같이 시스템 외부에 있을 수도 있습니다.The source of the events may be external to the system, such as physical devices in an IoT solution. 이 경우 시스템이 데이터 원본에 필요한 볼륨 및 처리량으로 데이터를 수집할 수 있어야 합니다.In that case, the system must be able to ingest the data at the volume and throughput that is required by the data source.

위의 논리 다이어그램에서 각 소비자 유형은 단일 상자로 표시됩니다.In the logical diagram above, each type of consumer is shown as a single box. 실제로는 소비자가 시스템의 단일 실패 지점이 되지 않도록 한 소비자의 여러 인스턴스가 있는 것이 일반적입니다.In practice, it's common to have multiple instances of a consumer, to avoid having the consumer become a single point of failure in system. 이벤트의 볼륨 및 빈도를 처리하기 위해 여러 인스턴스가 필요할 수도 있습니다.Multiple instances might also be necessary to handle the volume and frequency of events. 또한 단일 소비자가 여러 스레드의 이벤트를 처리할 수 있습니다.Also, a single consumer might process events on multiple threads. 이벤트가 순서대로 처리되어야 하거나 정확히 한 번 처리되어야 하는 경우 이것이 문제가 될 수 있습니다.This can create challenges if events must be processed in order, or require exactly-once semantics. 조정 최소화를 참조하세요.See Minimize Coordination.

이 아키텍처를 사용하는 경우When to use this architecture

  • 여러 하위 시스템이 동일한 이벤트를 처리해야 하는 경우.Multiple subsystems must process the same events.
  • 최소 시간 지연의 실시간 처리.Real-time processing with minimum time lag.
  • 패턴 일치 또는 일정 기간의 집계와 같은 복합 이벤트 처리.Complex event processing, such as pattern matching or aggregation over time windows.
  • 높은 볼륨 및 높은 데이터 개발속도(예: IoT).High volume and high velocity of data, such as IoT.

이점Benefits

  • 생산자와 소비자가 분리됩니다.Producers and consumers are decoupled.
  • 지점 간 통합이 없습니다.No point-to point-integrations. 시스템에 새 소비자를 쉽게 추가할 수 있습니다.It's easy to add new consumers to the system.
  • 이벤트가 도착하는 즉시 소비자가 이벤트에 응답할 수 있습니다.Consumers can respond to events immediately as they arrive.
  • 확장성이 있고 배포 가능합니다.Highly scalable and distributed.
  • 하위 시스템에서 이벤트 스트림을 독립적으로 확인할 수 있습니다.Subsystems have independent views of the event stream.

과제Challenges

  • 배달 보장.Guaranteed delivery. 일부 시스템, 특히 IoT 시나리오에서는 이벤트가 배달되도록 보장하는 것이 중요합니다.In some systems, especially in IoT scenarios, it's crucial to guarantee that events are delivered.
  • 이벤트를 순서대로 또는 한 번만 처리.Processing events in order or exactly once. 복원 및 확장성을 위해 일반적으로 각 소비자 유형이 여러 인스턴스에서 실행됩니다.Each consumer type typically runs in multiple instances, for resiliency and scalability. 이벤트가 소비자 유형 내에서 순서대로 처리되어야 하거나 처리 논리가 비멱등적인 경우 이것이 문제가 될 수 있습니다.This can create a challenge if the events must be processed in order (within a consumer type), or if the processing logic is not idempotent.