1. 마이크로 서비스 아키텍처(MSA: Micro Service Architecture) 문제점
💡 마이크로 서비스 아키텍처(MSA: Micro Service Architecture) 문제점
- 각각의 서비스는 독립적으로 배포 되며, 다른 서비스와 통신하여 전체 기능을 제공합니다. - 이는 확장성과 유연성을 높여주지만, 다음과 같은 문제점을 가지고 있습니다.
문제점
설명
서비스 간의 통신 복잡성 문제
각 서비스는 독립적으로 배포되고 다른 서비스와 통신하며, 이로 인해 통신 복잡성이 증가하고 네트워크 지연이나 통신 오류가 발생할 수 있습니다.
데이터 일관성 유지 문제
독립적인 서비스는 각자의 데이터를 가지고 있어, 전체 시스템의 데이터 일관성을 유지하는 것이 어렵습니다.
서비스 디스커버리 문제
서비스가 많아지면, 각 서비스의 위치를 찾는 것이 어렵습니다.
트랜잭션 관리 문제
각 서비스는 독립적으로 동작하며, 이로 인해 여러 서비스에서 동시에 발생하는 트랜잭션을 관리하기 어렵습니다,
보안 및 권한 관리 문제
서비스가 분산되어 동작하므로 각 서비스에 대한 보안 및 권한 관리가 복잡 해집니다. 보안 취약점이 발생할 수 있으며, 이를 해결하기 위해 추가적인 보안 시스템이 필요할 수 있습니다.
💡 마이크로 서비스 아키텍처(MSA: Micro Service Architecture) 내에서 발생하는 문제점에 대해 이벤트 기반 아키텍처(EDA: Event-Driven Architecture)를 이해하고 특징 및 주요 모델에 대해 알아봅니다.
2) 이벤트 기반 아키텍처(EDA: Event-Driven Architecture)
💡 이벤트 기반 아키텍처(EDA: Event-Driven Architecture)
- 분리된 서비스 혹은 시스템들 간의 이벤트를 게시, 소비 또는 라우팅 동작을 통해 각 정보를 공유하는 형태로 구성된 아키텍처를 의미합니다. - 다시 말해, 분리된 서비스들 간의 ‘상태 변화’가 발생한 경우에, 이벤트 생성자는 비동기식으로 이벤트를 게시(Publish)하며, 소비자는 사전에 특정 이벤트 수신을 구독(Subscribe)하여 이벤트가 게시되면 해당 이벤트를 수신하여 동작 처리를 수행합니다. 라우팅은 이 생성자와 소비사 사이에 이벤트 통신을 중재합니다.
- 이를 통해, 이벤트를 게시하는 이벤트 생성자와, 이벤트를 처리하는 이벤트 소비자는 독립적으로 동작할 수 있습니다. 그렇기에 서로 간의 ‘느슨한 결합’으로 구성되어 확장성과 유연성이 향상됩니다. - 이벤트 기반 아키텍처는 주로 실시간 응용 프로그램, 분산 네트워크, 마이크로서비스, 서버리스 아키텍처 등 환경에 적합합니다.
💡 이벤트 기반 아키텍처 처리 과정 예시
- 해당 이미지에서는 이벤트 생성자(Event Proceducers)는 Website, Mobile App, Retail App가 존재하고 이벤트 소비자(Event Consumers)로 인벤토리 서비스, 주문 서비스, 결제 서비스가 있습니다. - 해당 이미지에서는 'WebSite'에서 'Order Events'가 발생하여, 이벤트 라우터를 통해서 'Order Servcie'로 전달되어 처리되는 과정에 대해 알아봅니다.
1. 이벤트 생성자(Event Proceducers)인 'WebSite'내에서 '이벤트(Event)'가 발생하였습니다. - 사용자가 웹 사이트에서 '물품'을 구매하기 위해 동작을 수행하였습니다(Event)
2. 해당 이벤트는 이벤트 라우터(Event Router)로 전달이 됩니다. - 사용자의 물품 구매를 위한 이벤트가 라우터로 전달이 됩니다.
3. 이벤트 게시가 수행되기 전에 이벤트 라우터(Event Router)를 통해, 'Order Events'에 대한 이벤트 수신에 대한 구독을 지정한 이벤트 소비자(Event Consumers)인 'Order Service'가 있습니다. - Order Service는 Order Event를 받겠다는 구독을 이벤트 라우터로부터 해 둔 상태입니다.
4. 이벤트 라우터로 해당 이벤트가 전달이 되면, 이벤트 소비자(Event Consumers)인 'Order Service'로 전달이 됩니다. - Order Event가 발생하여 라우터를 통해 Order Service로 전달이 되었습니다.
5. 이벤트 소비자(Event Consumers)에서는 이에 대한 이벤트들을 통해 이후 동작 처리를 수행합니다. - Order Service에서는 추가적으로 Order State Store의 상태를 변경하고 Shopping Service에게 이벤트를 전달하여 Shopping State Store의 상태를 변경합니다.
1. MSA 문제 대비 이벤트 기반 아키텍처 특징
💡 MSA 문제 대비 이벤트 기반 아키텍처 특징
- 이전 MSA 환경에서 발생하였던 문제에 대해서 EDA 환경에서는 어떻게 대처가 되는지에 대해 알아봅니다.
MSA 환경 문제
EDA의 특징
EDA의 특징 설명
서비스 간의 통신 복잡성 문제
통신 복잡성 해결
- '이벤트 라우터'를 통해 서비스 간의 '통신을 중개'하므로 통신 복잡성이 감소하고, 느슨한 결합으로 인해 네트워크 지연이나 통신 오류에 대한 영향이 줄어듭니다.
데이터 일관성 유지 문제
데이터 일관성 유지
- '이벤트의 상태 변화를 통해 데이터를 공유'하므로, 독립적인 서비스 간의 데이터 일관성을 유지하는 데 도움이 됩니다.
서비스 디스커버리 문제
서비스 디스커버리 해결
- '이벤트 라우터'를 통해 이벤트를 송수신하기 때문에, 서비스 위치를 찾는 문제가 해결됩니다.
트랜잭션 관리 문제
트랜잭션 관리 개선
- '이벤트 기반'으로 동작하므로, 여러 서비스에서 발생하는 트랜잭션을 더 효과적으로 관리할 수 있습니다.
보안 및 권한 관리 문제
보안 및 권한 관리 개선
- 이벤트 라우터를 통해 서비스 간 통신을 중개하므로, 각 서비스에 대한 보안 및 권한 관리를 효과적으로 수행할 수 있습니다.
2. 이벤트 기반 아키텍처 추가 특징
💡 이벤트 기반 아키텍처 추가 특징
- MSA에서 발생한 문제 대비 특징도 존재하지만 EDA만에 추가적인 특징에 대해서도 알아봅니다.
특징
상세 설명
이기종 시스템의 통합
- '각 시스템 간의 기술스택의 독립성을 유지'하면서 상호 운용성을 유지하고자 할때 유용합니다. 이벤트 라우터가 시스템 간의 간접성과 상호 운용성을 설정하므로 독립성을 유지하면서 메시지와 데이터를 교환할 수 있습니다.
시스템 변경이나 확장
- 시스템 간의 느슨한 결합을 지원하므로, 변경이나 확장이 필요한 경우 시스템의 다른 부분에 큰 영향을 주지 않고 변경이나 확장을 할 수 있어 유연성이 향상됩니다.
리소스 상태 모니터링 및 알람
- 리소스를 지속적으로 확인하는 것이 아니라, '이벤트 라우터'를 사용하여 이상 징후, 변경 사항 및 업데이트에 대한 알림을 모니터링하고 수신할 수 있습니다.
팬아웃 및 병렬 처리
- 이벤트에 반응하여 작동해야 하는 시스템이 많은 경우, EDA를 사용하여 각 소비자에게 푸시할 사용자 지정 코드를 작성할 필요 없이 이벤트를 팬아웃할 수 있으며 동시에 병렬 처리가 가능합니다.
[ 더 알아보기 ] 💡 그러면 이벤트 생성자(Event Proceducers) 처리 결과를 응답받지 못하는 건가?
- 이벤트 기반 아키텍처에서 이벤트 생성자는 일반적으로 이벤트 수신자로부터 처리 결과에 대한 직접적인 응답을 받지 않습니다. - 이는 이벤트 생성자와 소비자가 비동기적으로 동작하며, 서로 독립적으로 수행되기 때문입니다. 그러나 필요에 따라 이벤트 수신자는 처리 결과를 다른 이벤트로 생성하여 다시 이벤트 라우터를 통해 송신할 수 있습니다.
💡 팬아웃(fan-out)
- 한 이벤트를 여러 수신자에게 전달하는 것을 의미합니다. - 이벤트 기반 아키텍처에서는 중앙 이벤트 라우터가 여러 소비자에게 동시에 전송하므로 각 소비자는 동일한 이벤트를 독립적으로 처리할 수 있습니다. - 이를 통해 시스템은 병렬 처리를 할 수 있고 이는 성능 향상과 확장성에 도움이 됩니다.
3. 이벤트 기반 아키텍처 주요 구성 요소 : 이벤트, 이벤트 버스, 이벤트 채널
💡 이벤트 기반 아키텍처(EDA: Event-Driven Architecture) 구성 요소
- 이벤트 기반 아키텍처는 ‘이벤트’를 기반으로 데이터가 발생하고 수행되는 과정에서 구성요소에 대해 알아봅니다.
3.1. 이벤트(Event)
💡 이벤트(Event)
- 시스템 혹은 서비스의 ‘상태 변화’를 나타내는 정보나 신호를 의미합니다. 데이터 변경, 사용자 행동 또는 시스템의 내부 상태변화 등을 의미합니다.
- 이러한 이벤트는 특정 작업이나 행동에 대한 트리거하는 역할로 수행되며, 이벤트를 수신하는 이벤트 소비자가 이에 대응하는 이벤트 처리를 수행합니다. - 예를 들어, 어떤 작업이 시작되거나 완료되었음을 나타내는 신호나 데이터가 변경되었음을 나타내는 신호등이 이벤트가 될 수 있습니다.
- 이벤트 기반 아키텍처의 핵심 구성 요소로서, 시스템 간의 '이벤트 통신을 중개'하는 역할을 합니다. 이는 이벤트 생성자(Event Producers)가 생성한 이벤트를 수집하고, 이를 이벤트 소비자(Event Consumers)에게 전달하는 중개자 역할을 수행합니다.
- 이 과정에서 이벤트 버스는 이벤트를 수집, 필터링, 변환, 라우팅, 전달 등의 기능을 수행하며, 이를 통해 시스템 간의 느슨한 결합을 유지하고 효과적인 이벤트 처리를 가능하게 합니다. - 여러 서비스가 발생시키는 이벤트를 효율적으로 관리하고 전달하기 위해 사용되며, 이를 통해 시스템 전반의 유연성과 확장성을 향상할 수 있습니다.
[ 더 알아보기 ] 💡 이벤트 버스의 경우 EDA에서 이벤트 브로커(Event Broker)나 이벤트 라우터(Event Router)와 같은 것일까?
- 이들은 유사한 개념을 가지고 있습니다. 주로 애플리케이션 내에서 서로 이벤트를 보낼 수 있게 중앙에서 이를 중개하는 역할을 수행합니다. - 이벤트 브로커나 이벤트 라우터의 경우 이벤트 버스보다 더 넓은 범위의 이벤트를 관리하며, 동일하게 생성한 곳에서 필요한 곳으로 이벤트를 전달하는 역할을 수행합니다. - 더 넓은 범위의 이벤트 관리는 단순히 애플리케이션 내부에서만 아니라 여러 애플리케이션, 서비스, 네트워크 등을 통합하여 이벤트를 관리할 수 있다는 것을 의미합니다.
3.3. 이벤트 채널(Event Channel)
💡 이벤트 채널(Event Channel)
- 이벤트 생성자와 이벤트 소비자 사이의 ‘통신 경로’를 나타냅니다. 이벤트 생성자(Event Proceduer)는 이벤트를 담을 수 있는 ‘이벤트 채널(Event Channel)’을 만들고 특정 이벤트를 해당 채널에서 게시(Publish)하며, 이 채널을 구독(Subscribe)하는 이벤트 소비자들(Event Consumers)에게 해당 이벤트를 전송합니다.
- 이벤트 채널의 경우는 같은 채널에 있는 모든 이벤트 소비자에게 보낼 수 있다는 점이 특징입니다. 그렇기에 불필요한 이벤트 처리를 피하고 성능을 개선할 수 있습니다. - 이벤트 채널은 여러 가지 방식으로 구현될 수 있으며, 이벤트의 유형, 크기, 발생 빈도 및 전달되어야 하는 대상에 따라 다양할 수 있습니다. 이벤트 채널은 이벤트를 신뢰성 있게 전달하는 것을 목표로 하며, 이벤트 발생자와 이벤트 수신자 사이의 느슨한 결합을 가능하게 합니다.
4. 이벤트-버스 패턴(Event-Bus Pattern) 흐름 처리과정
💡 이벤트-버스 패턴(Event-Bus Pattern) 흐름 처리과정
- 이벤트 기반 아키텍처(EDA)의 구성요소들은 소프트웨어 아키텍처 패턴 중 하나인 '이벤트-버스 패턴'으로 구성되어 있기에 이에 대한 처리과정에 대해 알아봅니다.
1. 게시자(Publisher) = 이벤트 생성자 - 이벤트 소스는 특정 조건이 충족되면 이벤트를 생성합니다. 이 이벤트는 일반적으로 상태 변경이나 특정 행동에 의해 발생합니다.
2. 게시자(Publisher) → (Event) → 이벤트 버스(Event Channel) - 이벤트를 전달받은 경우 이벤트 버스로 전달이 됩니다. 이 이벤트 버스에서는 특정 이벤트 채널로 라우팅을 수행합니다.
3. 구독자(Subscriber) = 이벤트 소비자 = 이벤트 리스너(Event Listener) - 특정 채널만 구독하고 있던 구독자만 반응하여 이벤트가 전달되어, 해당 이벤트를 기반으로 처리를 수행합니다.
4. 이벤트 리스너가 이벤트를 처리한 후, 해당 이벤트는 소멸됩니다.
https://adjh54.tistory.com/454
3) 이벤트 기반 아키텍처(EDA: Event-Driven Architecture) 모델 : 게시/구독 모델, 메시지 큐 모델, 이벤트 스트리밍 모델
💡 이벤트 기반 아키텍처(EDA: Event-Driven Architecture) 모델 : 게시/구독 모델, 메시지 큐 모델, 이벤트 스트리밍 모델
- 이벤트 기반 아키텍처 내의 게시/구독 모델, 메시지 큐 모델, 이벤트 스트리밍 모델에 대해서 상세하게 알아봅니다.
1. 게시/구독 모델(Pub/Sub Model)
💡 게시/구독 모델(Pub/Sub Model)
- 소프트웨어 아키텍처 종류 중 하나인 '게시-구독 패턴'을 이용하여, 메시지 게시자(Pub)와 메시지 구독자(Sub)를 서로 분리된 상태에서 메시지를 주고 받는 메시징 패턴을 의미합니다. - 즉, 메시지 라우터라는 중재자를 통해, 게시자는 이벤트를 게시만 수행하고 구독자는 메시지만 수신하는 역할만 수행하여, 서로 간의 결합도를 낮추고 유연성을 높여 각각 처리에 집중할 수 있도록 합니다.
- 해당 모델의 핵심은 게시자와 구독자는 서로 알지 못하며 이벤트 브로커를 통해 느슨하게 연결되어 있다는 점이 특징입니다. 이로 인해 시스템의 유연성과 확장성이 향상됩니다.
주요 용어
설명
게시자(Publisher)
- 특정 주제에 대한 메시지를 생성하고 게시하는 역할을 수행합니다.
이벤트 라우터(Event Router)
- 등록된 구독자(Subscriber)에게 메시지를 라우팅하고 전달하는 역할을 수행합니다.
구독자(Subscriber)
- 자신이 관심 있는 주제를 구독하며 해당 주제에 대한 메시지가 게시되면 이를 받아서 처리하는 역할을 수행합니다.
주제(Topic)
- 메시지가 속한 카테고리나 분류를 나타내며, 구독자는 특정 주제를 구독하여 관련 메시지만 수신합니다.
이벤트 필터(Event Filter)
- 이벤트 라우터에서 특정 이벤트를 선별하여 구독자에게 제공하는 역할을 수행합니다.
팬아웃(Fan Out)
- 특정 이벤트를 동시에 여러 구독자에게 전달하는 행위를 나타냅니다. 이는 병렬 처리와 성능 향상에 중요한 역할을 합니다.
[ 더 알아보기 ] 💡 소프트웨어 아키텍처, 게시-구독 패턴(Publish–subscribe pattern)
- 게시자(publisher)와 구독자(subscriber) 사이에서 메시지를 전달하는 방식을 말합니다. 이 패턴에서는 게시자가 메시지를 생성하고, 그 메시지는 하나 이상의 특정 채널을 통해 전달됩니다. - 구독자는 자신이 받고 싶은 메시지의 채널을 구독하고, 해당 채널을 통해 전송되는 모든 메시지를 받습니다. - 게시-구독 패턴은 발행자와 구독자 사이의 결합도를 낮추어 시스템의 유연성을 높이는 데 도움이 됩니다.
💡 Topic이 이벤트 채널(Event Channel)과 유사한 개념인가?
- 'Topic'은 특정 주제에 대한 메시지를 분류하는 방법을 나타내며, 이는 이벤트 채널의 개념과 유사합니다. 이벤트 채널은 특정 이벤트를 담을 수 있는 '통신 경로'를 의미하며, 특정 이벤트를 해당 채널에서 생성하고 이를 구독하는 구독자들에게 전달합니다.
- 팬아웃은 특정 이벤트를 동시에 여러 구독자에게 전달하는 행위를 나타냅니다. 이전의 흐름과 다르게 게시자(Publisher)는 이벤트 라우터로 Topic을 등록합니다. 이 등록한 Topic은 팬아웃을 통해서 일괄적으로 여러 구독자(Subscriber)에게 전달이 됩니다. 이렇게 구독자에게 전달이 되면 각각 메시지를 독립적으로 처리를 합니다.
- 이 처리 방식은 시스템의 처리 용량을 늘리고, 각 구독자가 자신의 속도로 작업을 독립적으로 처리할 수 있도록 해주며, 병렬 처리를 할 수 있게 해 줍니다. - 예를 들어, 신제품 출시 알림이라는 하나의 이벤트가 있을 때, 이 이벤트는 '신제품 알림' 토픽, '마케팅 팀' 토픽, '고객 서비스 팀' 토픽 등으로 팬아웃될 수 있습니다. 각 토픽을 구독하는 구독자들은 동일한 이벤트를 독립적으로 받아 처리할 수 있게 됩니다.
- 이벤트 생성자(Event Proceduer)가 생성한 하나의 이벤트가 이벤트 소비자(Event Consumer)에게 하나의 이벤트로 전달되어 서로 간의 통신을 지원하는 모델입니다.
- 해당 메시지는 FIFO(First-In-First-Out) 순서로 먼저 들어온 메시지가 먼저 나가는 순서로 처리됩니다. - 주요한 특징 중 하나는 메시지의 안정적인 전달을 보장합니다. 네트워크 장애나 일시적인 서비스 다운과 같은 이슈가 발생해도 메시지는 큐에 저장되어 있으므로, 문제가 해결되면 메시지는 손실 없이 이벤트 소비자에게 전달될 수 있습니다. 또한 메시지는 큐에서 일정 순서로 처리되므로, 메시지의 전달 순서도 보장됩니다.
- 단, 메시지 큐 모델은 한 번에 하나의 이벤트 소비자(Event Consumer)에게 전달할 수 있다는 제약이 있습니다. 한번 소비된 메시지는 큐에서 제거되므로 동일한 메시지를 통해 여러 이벤트 소비자에게 소비하는 것은 불가능합니다. 이러한 제약은 특정 시나리오에서는 문제가 될 수 있습니다. - 예를 들어, 여러 시스템이 동일한 이벤트에 반응해야 하는 이벤트 기반 아키텍처에서는 이러한 제약이 큰 문제가 될 수 있습니다.
💡 게시/구독 모델과 같이 한번에 하나의 이벤트로 여러 소비자에게 메시지를 전달할 수는 없는가?
- 메시지 큐 모델은 한번에 하나의 이벤트 소비자에게 전달되는 메시지 구조로, 소비된 메시지는 큐에서 제거되므로 동일한 메시지를 동시에 여러 이벤트 소비자에게 전달하는 것은 기본적으로 불가능합니다. - 하지만, 이를 해결하기 위해 각 이벤트 소비자가 자신만의 큐를 가지고 이 큐에 동일한 메시지를 복사하여 저장하는 방식을 이용하여 동시에 여러 이벤트 소비자에게 전달할 수도 있습니다.
[ 더 알아보기 ] 💡AMQP(Advanced Message Queuing Protocol) 클라이언트
- AMQP라는 메시징 프로토콜을 사용하여 메시지를 생성하고 송신하는 역할을 합니다. 이 클라이언트는 메시지 기반의 미들웨어를 사용하여 애플리케이션 간에 메시지를 안전하게 전송할 수 있습니다. - RabbitMQ와 같은 메시징 브로커를 사용하면, 이러한 AMQP 클라이언트를 통해 메시지를 브로커에 송신하고, 브로커는 이 메시지를 적절한 큐에 라우팅 하여 다른 클라이언트에게 전달합니다.
3. 게시/구독 모델(Pub/Sub Model)과 메시지 큐 모델(Message Queue Model) 차이
💡 메시지 큐 모델(Message Queue Model)과 게시/구독 모델(Pub/Sub Model) 차이
- 메시지의 큐의 경우, 전달하려는 이벤트가 각각 큐에 담겨서 이를 '순차적'으로 전달합니다. - 게시/구독 모델의 경우, 이벤트 라우터 내의 Topic에 대해 메시지로 추가되어 이를 '동시에' 비 동기적으로 전달합니다.
- 실시간으로 발생하는 데이터를 '연속적인 스트림'으로 처리하는 아키텍처 패턴입니다. 이 모델은 데이터를 실시간으로 분석하고 처리하는 데에 특히 유용합니다.
- 이벤트 스트리밍 모델에서는 이벤트 발생자들이 생성하는 이벤트들이 이벤트 스트림이라는 연속적인 데이터 흐름을 형성하게 됩니다. 이벤트 스트림은 일반적으로 시간 순서대로 정렬되며, 이벤트 발생자는 새로운 이벤트를 스트림의 끝에 계속 추가합니다.
- 이벤트 소비자는 이벤트 스트림을 구독하고, 실시간으로 업데이트되는 스트림에서 이벤트를 읽어옵니다. 이벤트 소비자는 청취하고 있는 이벤트 스트림에서 새로운 이벤트가 추가될 때마다 이를 인지하고, 필요한 작업을 수행합니다. - 이벤트 스트리밍 모델은 실시간 분석, 실시간 대시보드, 실시간 경고 및 알림 등과 같은 실시간 연산을 지원하기 위해 설계되었습니다. 이 모델은 또한 대규모 데이터를 처리하는 데에도 유용하며, 특히 이벤트 데이터가 연속적으로 발생하고, 이러한 이벤트를 실시간으로 처리해야 하는 경우에 적합합니다.
이벤트를 생성하는 원본으로, 사용자 행동, 시스템 메시지, 서비스 상태 변화 등 다양한 요인이 될 수 있습니다.
이벤트 캡처(Event Capture)
이벤트 소스에서 발생한 이벤트를 식별하고 기록하는 과정입니다.
이벤트 스트림(Event Stream)
시간 순서대로 정렬된 이벤트의 연속적인 흐름을 나타냅니다. 새로운 이벤트가 발생하면, 이를 스트림의 끝에 추가합니다.
이벤트 커넥터(Event Connector)
이벤트 생성자와 이벤트 소비자 사이의 데이터 전송을 담당합니다. 다양한 데이터 소스와 목적지 사이의 이벤트 흐름을 가능하게 합니다.
스트림 프로세싱(Stream Processing)
실시간 데이터 스트림을 분석하고 처리하는 기술입니다. 이를 통해, 이벤트가 발생하는 즉시 대응할 수 있으며, 실시간 인사이트 및 의사결정을 가능하게 합니다.
이벤트 생성자(Event Producer)
다양한 소스에서 발생하는 이벤트를 캡쳐하고, 이를 데이터 스트림으로 변환하여 이벤트 스트림에 추가합니다.
이벤트 소비자(Event Consumer)
이벤트 스트림을 구독하고, 실시간으로 업데이트되는 스트림에서 이벤트를 읽어옵니다. 새로운 이벤트가 스트림에 추가될 때마다, 필요한 작업을 수행합니다.
이벤트 스트리밍 플랫폼(Event Streaming Platform)
이벤트 생성자와 소비자, 이벤트 스트림, 커넥터, 스트림 프로세싱 기능 등을 통합적으로 관리하고 운영하는 시스템을 의미합니다. 이를 통해 실시간 이벤트 스트리밍 및 처리, 데이터 파이프라인 관리 등의 기능을 제공합니다.
4.1. 이벤트 스트리밍 유형 -1 : 스트리밍 플랫폼 이용
💡 이벤트 스트리밍 유형 -1 : 스트리밍 플랫폼 이용
- 데이터 스트리밍 플랫폼을 사용하여 실시간으로 이벤트를 수집하고 처리합니다. Apache Kafka와 같은 플랫폼은 이벤트 생성자로부터 데이터를 받아 연속적인 이벤트 스트림을 형성하고, 이 스트림을 필요에 따라 처리하거나 변환합니다.
- 이벤트 소비자는 이 스트림을 구독하여 실시간으로 업데이트되는 데이터를 읽어올 수 있습니다. 새로운 이벤트가 스트림에 추가될 때마다 이를 인지하고 필요한 작업을 수행합니다. 이렇게 하여, 실시간 분석, 실시간 대시보드, 실시간 경고 및 알림 등의 실시간 연산이 가능합니다. - 또한, 이벤트 스트리밍 모델은 대규모 데이터 처리에도 유용하며, 특히 이벤트 데이터가 연속적으로 발생하고, 이러한 이벤트를 실시간으로 처리해야 하는 경우에 적합합니다
💡 이벤트 스트리밍 유형 : 스트리밍 플랫폼을 이용한 수행과정 1. 이벤트 생성자(Event Producer)는 이벤트 소스를 기반으로 ‘이벤트(Event)를 발생’시킵니다.
- 최초 이벤트 생성자는 ‘이벤트’ 전달을 위해 이벤트 생성을 위한 원본인 이벤트 소스를 기반으로 ‘이벤트’를 발생시킵니다.
2. 이벤트 생성자(Event Producer)는 변환한 이벤트 스트림을 커넥터를 통해 ‘이벤트 스트리밍 플랫폼(Event Streaming Platform)에 등록’합니다.
- 이벤트 생성자는 이벤트를 캡처하여 이벤트 스트림으로 변환하여 커넥터를 통해 이를 이벤트 스트리밍 플랫폼에 등록합니다. - 이벤트 스트림의 형태는 시간 순서대로 정렬된 이벤트 스트림을 형성하여 새로운 이벤트가 발생하면 이벤트 스트림의 끝에 추가됩니다.
3. 이벤트 소비자는 이벤트 플랫폼에 ‘특정 이벤트를 구독’하다가 데이터가 들어오면 ‘커넥터를 통해 전달’ 받습니다.
- 이벤트 소비자는 특정 이벤트를 전달받기 위해 이벤트 플랫폼의 이벤트를 구독하다가 데이터가 들어오면 커넥터를 통해 전달받습니다. - 해당 이벤트는 실시간으로 업데이트되는 스트림에서 커넥터를 통해 읽어옵니다.
4.2. 이벤트 스트리밍 유형 -2: 단순 처리
💡 이벤트 스트리밍 유형 -2: 단순 처리
- 이벤트가 발생하면 이벤트 소비자에 의해 즉시 처리되는 방식으로 작동합니다. - 이벤트 소비자는 시스템의 다른 부분에서 발생하는 이벤트를 감시하고, 특정 이벤트가 발생하면 즉시 반응하여 특정 작업을 수행합니다. - 이런 방식은 실시간 처리와 반응이 필요한 시스템에서 특히 유용합니다. - 예를 들어, 실시간 모니터링 시스템에서는 센서 데이터를 실시간으로 수집하고 분석할 수 있어야 합니다. 이런 경우, 센서에서 데이터가 생성되면 즉시 이벤트가 발생하고, 이벤트 소비자는 이 이벤트를 받아 데이터를 분석하고 필요한 작업을 수행합니다. 이렇게 하면, 시스템은 실시간으로 데이터를 처리하고 반응할 수 있습니다.
- 스트리밍 플랫폼을 이용하는 경우, Apache Kafka와 같은 플랫폼이 데이터의 연속적인 흐름을 관리하고, 필요에 따라 처리하거나 변환하는 역할을 합니다. - 이 방식은 대규모 데이터를 실시간으로 처리하고 복잡한 데이터 파이프라인을 관리해야 하는 경우에 특히 유용합니다.
- 단순 처리의 경우, 이벤트가 발생하면 즉시 이벤트 소비자에 의해 처리되는 방식으로 작동합니다. 이 방식은 실시간 처리와 반응이 필요한 시스템에서 특히 유용합니다. - 단순 처리는 스트리밍 플랫폼을 이용하는 것에 비해 구현이 간단하지만, 복잡한 데이터 처리나 대규모 데이터 처리에는 한계가 있을 수 있습니다.
