맨위로가기

이벤트 기반 아키텍처

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

이벤트 기반 아키텍처는 이벤트 발생, 전달, 처리를 기반으로 하는 소프트웨어 설계 방식이다. 시스템은 이벤트 발생자, 이벤트 채널, 이벤트 처리 엔진으로 구성되며, 단순, 스트림, 복합, 온라인 이벤트 처리 등 다양한 방식으로 이벤트를 처리한다. 브로커 또는 중재자 토폴로지를 사용하며, 도메인 이벤트와 통합 이벤트 두 가지 유형의 이벤트를 활용한다. 데이터 손실, 오류 처리, 이벤트 진화, 의미적 결합 등의 과제가 있으며, 느슨한 결합과 분산 환경을 제공한다.

더 읽어볼만한 페이지

  • 이벤트 (컴퓨팅) - 메시지 큐
    메시지 큐는 프로세스나 스레드 간 비동기 통신을 제공하여 송신자와 수신자가 동시에 상호 작용할 필요 없이 메시지를 교환하도록 하며, 메시지는 수신자가 검색할 때까지 저장되고 시스템 장애 시 복원력을 제공하지만 보안 취약점, 특정 기업 종속성 등의 논란도 존재한다.
  • 이벤트 (컴퓨팅) - 비동기 입출력
    비동기 입출력은 입출력 완료를 기다리지 않고 다른 작업을 처리하는 방식으로, 완료 시 콜백이나 시그널을 통해 결과를 알려주어 효율적인 자원 활용과 성능 향상을 가져다준다.
  • 서비스 지향 - 멀티테넌시
    멀티테넌시는 단일 애플리케이션 인스턴스로 여러 고객에게 서비스를 제공하여 SaaS 및 클라우드 환경에서 비용과 관리 효율성을 높이고 데이터 활용 가치를 창출하는 소프트웨어 아키텍처 방식이다.
  • 서비스 지향 - 서비스 지향 아키텍처
    서비스 지향 아키텍처(SOA)는 기능들을 독립적인 서비스 단위로 분리하여 느슨하게 결합함으로써, 네트워크를 통해 접근 가능한 서비스를 재사용하고 결합하여 응용 프로그램을 구축하는 소프트웨어 아키텍처이다.
  • 소프트웨어 구조 - Ajax
    Ajax는 웹 페이지 전체를 새로고침하지 않고 비동기적으로 서버와 통신하여 웹 애플리케이션의 일부를 업데이트하는 웹 개발 기술로, XMLHttpRequest 객체의 등장으로 가능해졌으며 HTML, CSS, DOM, JavaScript, JSON 등의 기술을 통합하여 동적인 사용자 인터페이스를 구현한다.
  • 소프트웨어 구조 - 멀티테넌시
    멀티테넌시는 단일 애플리케이션 인스턴스로 여러 고객에게 서비스를 제공하여 SaaS 및 클라우드 환경에서 비용과 관리 효율성을 높이고 데이터 활용 가치를 창출하는 소프트웨어 아키텍처 방식이다.
이벤트 기반 아키텍처

2. 역사적 배경

'이벤트'는 상태의 중요한 변화로 정의될 수 있다.[1] 예를 들어, 소비자가 차를 구매했을 때, 자동차의 상태는 "판매 중"에서 "판매 완료"로 변경된다. 자동차 딜러의 시스템 아키텍처는 이러한 상태 변경을 다른 애플리케이션에 알리는 이벤트로 취급할 수 있다.

이 아키텍처 패턴은 느슨하게 결합된 소프트웨어 컴포넌트와 서비스 간에 이벤트를 전송하는 애플리케이션 및 시스템의 설계 및 구현에 적용될 수 있다.

이벤트 기반 아키텍처는 SOA를 보완할 수 있는데, 이는 서비스가 들어오는 이벤트에서 발생된 트리거에 의해 활성화될 수 있기 때문이다.[4][5] SOA 2.0은 SOA 및 EDA 아키텍처가 제공하는 함축적 의미를 더 풍부하고 강력한 수준으로 발전시킨다.

2. 1. 초기 역사

주어진 원본 소스에는 '이벤트 기반 아키텍처'의 '초기 역사'에 대한 내용이 직접적으로 나타나 있지 않다. 요약에 따르면 초기 형태는 인터럽트 처리, 운영체제의 시그널 처리 등에서 찾아볼 수 있다고 하지만, 원본 소스에는 해당 내용이 없으므로, 섹션 내용을 작성할 수 없다.

2. 2. 현대

현대적인 이벤트 기반 아키텍처는 메시지 큐, 이벤트 버스, 이벤트 스트림 처리 등의 기술 발전에 힘입어 더욱 정교해지고 있다. 특히, 분산 시스템 환경에서 복잡한 이벤트 처리를 위한 다양한 패턴과 프레임워크가 등장하고 있다.

이벤트 기반 아키텍처를 중심으로 시스템을 구축하면 분산 컴퓨팅 모델에서 수평적 확장성이 단순화되고 장애에 대한 복원력이 향상된다. 이는 애플리케이션 상태를 고가용성을 위해 여러 개의 병렬 스냅샷으로 복사할 수 있기 때문이다.[2] 새로운 이벤트는 어디에서나 시작될 수 있지만, 더 중요한 것은 데이터 저장소 네트워크 전체에 전파되어 각 이벤트가 도착하면 업데이트된다는 것이다. 추가 노드를 추가하는 것도 쉬워진다. 애플리케이션 상태의 복사본을 가져와 이벤트 스트림을 공급하고 실행하기만 하면 된다.[3]

이벤트 기반 아키텍처는 SOA를 보완할 수 있는데, 이는 서비스가 들어오는 이벤트에서 발생된 트리거에 의해 활성화될 수 있기 때문이다.[4][5]

3. 주요 특징

'''이벤트'''는 "상태의 중요한 변화"로 정의될 수 있다.[1] 예를 들어, 소비자가 차를 구매했을 때, 자동차의 상태는 "판매 중"에서 "판매 완료"로 변경된다. 이러한 상태 변경은 시스템 내 다른 애플리케이션에 알림을 줄 수 있는 이벤트로 처리될 수 있다.

이 아키텍처 패턴은 느슨하게 결합된 소프트웨어 컴포넌트와 서비스 간에 이벤트를 전송하는 애플리케이션 및 시스템의 설계 및 구현에 적용될 수 있다.

이벤트 기반 아키텍처는 분산 컴퓨팅 모델에서 수평적 확장성을 단순화하고 장애에 대한 복원력을 향상시킨다. 애플리케이션 상태를 고가용성을 위해 여러 개의 병렬 스냅샷으로 복사할 수 있기 때문이다.[2] 새로운 이벤트는 어디에서나 시작될 수 있지만, 데이터 저장소 네트워크 전체에 전파되어 각 이벤트가 도착하면 업데이트된다. 추가 노드를 추가하려면 애플리케이션 상태의 복사본을 가져와 이벤트 스트림을 공급하고 실행하면 된다.[3]

이벤트 기반 아키텍처는 서비스 지향 아키텍처 (SOA)를 보완할 수 있는데, 이는 서비스가 들어오는 이벤트에서 발생된 트리거에 의해 활성화될 수 있기 때문이다.[4][5]

3. 1. 구성 요소

이벤트 기반 시스템은 일반적으로 이벤트 발생자(Producer/Publisher), 이벤트 소비자(Consumer/Subscriber), 그리고 이벤트 채널(Channel/Broker/Bus)로 구성된다.[1]

  • 이벤트 발생자(Producer/Publisher): 이벤트 발생자는 이벤트의 발생을 감지하고, 이를 이벤트 채널에 게시한다. 이벤트 발생자는 이벤트 소비자에 대한 정보를 알지 못한다.
  • 이벤트 소비자(Consumer/Subscriber): 이벤트 소비자는 이벤트 채널을 구독하고, 특정 이벤트가 발생하면 이에 대한 처리를 수행한다.
  • 이벤트 채널(Channel/Broker/Bus): 이벤트 채널은 이벤트 발생자와 소비자 사이에서 이벤트를 전달하는 역할을 한다. 이벤트 채널의 물리적 구현은 메시지 지향 미들웨어와 같은 전통적인 컴포넌트, 또는 점대점 통신을 기반으로 할 수 있다.


이벤트 기반 아키텍처는 논리적으로 네 개의 계층으로 구성될 수 있다.

1. 이벤트 프로듀서(Event Producer): 사실을 감지하고 해당 사실을 이벤트 메시지로 표현한다. (예: 이메일 클라이언트, 전자 상거래 시스템, 모니터링 에이전트, 물리적 센서)

2. 이벤트 채널: 이벤트 생성기로부터 수집된 정보를 이벤트 엔진 또는 싱크로 전달하는 메커니즘이다. (예: TCP/IP 연결, 플랫 파일, XML 형식, 이메일 등)

3. 이벤트 처리 엔진: 이벤트를 식별하고 적절한 반응을 선택 및 실행하는 논리 계층이다.

4. 이벤트 결과: 이벤트의 결과가 나타나는 논리적 계층이다.

3. 1. 1. 작동 원리

이벤트 기반 시스템은 일반적으로 이벤트 발생자(또는 에이전트), 이벤트 소비자(또는 싱크) 및 이벤트 채널로 구성된다.[1] 발생자는 이벤트를 감지, 수집 및 전송한다. 이벤트 발생자는 이벤트 소비자를 알지 못하며, 소비자가 존재하는지, 또 이벤트가 어떻게 사용되거나 추가 처리되는지도 알지 못한다.[1] 싱크는 이벤트가 제시되는 즉시 반응을 적용한다. 반응은 싱크 자체에 의해 완전히 제공될 수도 있고, 이벤트를 필터링, 변환하여 다른 컴포넌트로 전달하거나, 자체 포함된 반응을 제공할 수도 있다.[1] 이벤트 채널은 이벤트 발생자에서 이벤트 소비자로 이벤트가 전송되는 통로이다.[1] 이벤트의 정확한 분배에 대한 지식은 이벤트 채널 내에 있다.

이벤트 처리 엔진은 이벤트를 식별하고 적절한 반응을 선택 및 실행하는 논리 계층이며, 여러 단언을 트리거할 수 있다. 예를 들어, 이벤트 처리 엔진에 입력되는 이벤트가 재고 부족인 제품 ID인 경우, "제품 ID 주문" 및 "직원에게 알림"과 같은 반응을 트리거할 수 있다.[10] 이것은 이벤트의 결과가 나타나는 논리적 계층이다. 이메일 전송, 애플리케이션 화면 경고 표시 등 다양한 방식으로 수행될 수 있다.[10]

3. 1. 2. 이벤트 구조

이벤트는 이벤트 헤더와 이벤트 페이로드(payload)라고도 하는 이벤트 본문, 두 부분으로 구성될 수 있다.[1] 이벤트 헤더는 이벤트 이름, 이벤트의 타임스탬프, 이벤트 유형과 같은 정보를 포함할 수 있다. 이벤트 페이로드는 감지된 상태 변경의 세부 정보를 제공한다. 이벤트 본체는 이벤트 자체의 발생에 대한 반응으로 적용될 수 있는 패턴 또는 로직과 혼동해서는 안 된다.

이벤트 기반 아키텍처에서 이벤트 페이로드를 구조화하는 주요 방법은 다음 두 가지이다.

방법설명장점단점
모든 속성 포함이벤트 페이로드 내에 필요한 모든 속성을 포함한다.
키 또는 ID만 포함이벤트 페이로드에 키 또는 ID만 포함하여 소비자가 데이터베이스와 같은 외부 데이터 소스에서 필요한 데이터를 가져오도록 한다.



이러한 방법은 이진 선택이 아닌 스펙트럼의 두 끝점을 나타낸다. 소프트웨어 아키텍트는 이벤트 소비자의 특정 요구 사항을 충족하도록 이벤트 페이로드의 크기를 신중하게 조정해야 한다.

3. 2. 사회문화적 의의

이벤트 기반 아키텍처는 실시간 상호작용을 가능하게 하고, 개인에게 맞춤화된 서비스를 제공하며, 빠른 의사 결정을 지원하여 사용자 경험을 향상시킨다.[1] 예를 들어, 소비자가 자동차를 구매하면 자동차의 상태가 "판매 중"에서 "판매 완료"로 바뀌는데, 이러한 변화를 이벤트로 처리하여 관련 시스템에 알릴 수 있다.[1] 이를 통해 기업은 변화하는 환경에 빠르게 대응하고, 새로운 비즈니스 기회를 창출할 수 있다.

4. 이벤트 처리 유형

이벤트 기반 아키텍처(EDA)는 처리 방식에 따라 다음과 같이 분류할 수 있다.

이벤트 처리에는 크게 단순 이벤트 처리, 이벤트 스트림 처리, 복합 이벤트 처리, 온라인 이벤트 처리의 네 가지 유형이 있다. 이러한 유형들은 완성된 이벤트 기반 아키텍처에서 함께 사용되는 경우가 많다.


  • 단순 이벤트 처리: 특정하고 측정 가능한 상태 변화와 직접 관련된 이벤트를 처리한다.
  • 이벤트 스트림 처리: 일반 이벤트와 주목할 만한 이벤트 모두를 처리한다.
  • 복합 이벤트 처리: 여러 이벤트 간의 인과 관계, 시간 관계, 공간 관계 등을 분석하여 복합적인 상황을 추론한다.[1]
  • 온라인 이벤트 처리: 이기종 시스템에서 복잡한 시나리오와 관련된 이벤트를 안정적으로 구성할 수 있게 해준다.

4. 1. 단순 이벤트 처리 (Simple Event Processing)

이벤트는 "상태의 중요한 변화"로 정의될 수 있다.[1] 단순 이벤트 처리는 특정하고 측정 가능한 상태 변화와 직접 관련된 이벤트를 다룬다. 단순 이벤트 처리에서는 주목할 만한 이벤트가 발생하면 그에 따른 작업이 시작된다. 단순 이벤트 처리는 일반적으로 작업의 실시간 흐름을 제어하여 지연 시간과 비용을 줄이는 데 사용된다.[10]

예를 들어, 단순 이벤트는 타이어 압력이나 주변 온도의 변화를 감지하는 센서에 의해 생성될 수 있다. 자동차의 타이어 압력 이상은 센서에서 단순 이벤트를 생성하여 운전자에게 타이어 상태를 알리는 노란색 경고등을 켜도록 한다.

4. 2. 이벤트 스트림 처리 (Event Stream Processing, ESP)

이벤트 스트림 처리(ESP)는 일반 이벤트와 주목할 만한 이벤트 모두를 처리한다. 일반 이벤트(예: 주문, RFID 전송)는 주목할 만한지 여부를 선별하여 정보 구독자에게 스트리밍된다. 이벤트 스트림 처리는 기업 내부 및 주변의 실시간 정보 흐름을 지원하여 적시에 의사 결정을 내릴 수 있도록 돕는다.[10]

4. 3. 복합 이벤트 처리 (Complex Event Processing, CEP)

복합 이벤트 처리(CEP)는 여러 이벤트 간의 인과 관계, 시간 관계, 공간 관계 등을 분석하여 복합적인 상황을 추론하는 방식이다.[1] 이를 통해 비즈니스 이상 징후를 감지하거나 위협을 예측하고, 이에 대한 대응을 할 수 있다. CEP는 정교한 이벤트 해석기, 이벤트 패턴 정의 및 일치, 상관 관계 기법을 사용한다.

4. 4. 온라인 이벤트 처리 (Online Event Processing, OLEP)

온라인 이벤트 처리(OLEP)는 비동기 분산 이벤트 로그를 사용하여 복잡한 이벤트를 처리하고 영구 데이터를 관리한다.[11] OLEP는 이기종 시스템에서 복잡한 시나리오와 관련된 이벤트를 안정적으로 구성할 수 있게 해준다. 따라서 매우 유연한 분산 패턴을 높은 확장성과 함께 가능하게 하며 강력한 일관성을 제공한다. 하지만 처리 시간에 대한 상한을 보장할 수 없다.

5. 토폴로지

이벤트 기반 아키텍처는 크게 브로커 토폴로지와 중재자 토폴로지 두 가지로 나뉜다. 브로커 토폴로지는 구성 요소가 오케스트레이터 없이 전체 시스템에 이벤트를 브로드캐스트하는 방식으로, 최고의 성능과 확장성을 제공한다. 반면 중재자 토폴로지는 중앙 오케스트레이터가 이벤트 워크플로우를 제어하는 방식으로, 더 나은 제어 및 오류 처리 기능을 제공한다. 이 두 가지 토폴로지를 결합한 하이브리드 모델을 사용할 수도 있다.[1]

하위 섹션에서 '''브로커 토폴로지'''와 '''중재자 토폴로지'''에 대해 더 자세히 설명한다.

5. 1. 브로커 토폴로지 (Broker Topology)

이벤트 기반 아키텍처는 브로커(Broker) 토폴로지와 중재자(Mediator) 토폴로지 두 가지 주요 유형으로 나뉜다. 브로커 토폴로지는 중앙 집중형 브로커 없이 구성 요소들이 전체 시스템에 이벤트를 브로드캐스트하는 방식이다.[1] 이 방식은 높은 성능과 확장성을 제공한다.

브로커 토폴로지에서는 각 구성 요소가 이벤트를 직접 게시하고 구독한다. 중앙 브로커가 없기 때문에 병목 현상이 발생할 가능성이 적고, 시스템 확장도 용이하다.

5. 2. 중재자 토폴로지 (Mediator Topology)

중재자 토폴로지는 이벤트의 워크플로우를 제어하는 중앙 오케스트레이터(중재자)가 존재하는 방식이다.[1] 이 토폴로지는 이벤트 처리 순서를 제어하고 오류를 처리하는 데 유리하다.[1] 중재자 토폴로지는 브로커 토폴로지와 함께 두 가지 주요 이벤트 기반 아키텍처 토폴로지 중 하나이며, 이 둘을 결합한 하이브리드 모델도 사용할 수 있다.[1]

6. 이벤트 유형

EDA에는 다양한 유형의 이벤트가 있으며, 그 분류에 대한 의견은 다를 수 있다. 얀 추이(Yan Cui)에 따르면, 이벤트에는 크게 두 가지 범주가 있다.[7]

6. 1. 도메인 이벤트 (Domain Events)

도메인 이벤트는 특정 비즈니스 도메인 내에서 중요한 발생을 나타낸다. 이러한 이벤트는 경계 컨텍스트로 제한되며 비즈니스 로직을 보존하는 데 필수적이다. 일반적으로 도메인 이벤트는 처리하는 데 필요한 정보만 포함하므로 페이로드가 더 가볍다. 이는 이벤트 리스너가 일반적으로 동일한 서비스 내에 있으며 해당 요구 사항을 더 명확하게 이해하기 때문이다.

6. 2. 통합 이벤트 (Integration Events)

통합 이벤트는 서로 다른 바운디드 컨텍스트 간의 변경 사항을 전달하는 역할을 하며, 전체 시스템에서 데이터 일관성을 보장하는 데 매우 중요하다.[7] 통합 이벤트는 잠재적 수신자의 요구 사항이 크게 다를 수 있으므로 추가적인 속성을 가진 더 복잡한 페이로드를 갖는 경향이 있다.[7] 이는 종종 더 철저한 통신 방식으로 이어져 모든 관련 정보가 효과적으로 공유되도록 과도한 통신을 유발한다.[7]

7. 구현 및 예시

'''이벤트'''는 "상태의 중요한 변화"로 정의될 수 있다.[1] 예를 들어, 소비자가 차를 구매했을 때, 자동차의 상태는 "판매 중"에서 "판매 완료"로 변경된다. 자동차 딜러의 시스템 아키텍처는 이 상태 변경을 아키텍처 내의 다른 애플리케이션에 알려줄 수 있는 이벤트로 취급할 수 있다. 공식적인 관점에서, 생성, 게시, 전파, 감지 또는 소비되는 것은 (일반적으로 비동기식) 메시지인 이벤트 알림이며, 메시지 전송을 트리거한 상태 변경 자체인 이벤트가 아니다. 이벤트는 이동하지 않고, 단지 발생할 뿐이다. 그러나, ''이벤트''라는 용어는 종종 환유법적으로 알림 메시지 자체를 나타내기 위해 사용되는데, 이는 다소 혼란을 야기할 수 있다.

이 아키텍처 패턴은 느슨하게 결합된 소프트웨어 컴포넌트와 서비스 간에 이벤트를 전송하는 애플리케이션 및 시스템의 설계 및 구현에 적용될 수 있다. 이벤트 기반 시스템은 일반적으로 이벤트 발생자(또는 에이전트), 이벤트 소비자(또는 싱크) 및 이벤트 채널로 구성된다. 발생자는 이벤트를 감지, 수집 및 전송하는 책임을 진다. 이벤트 발생자는 이벤트의 소비자를 알지 못하며, 소비자가 존재하는지조차 알지 못한다. 싱크는 이벤트가 제시되는 즉시 반응을 적용하는 책임을 진다.

이벤트 채널은 이벤트 발생자에서 이벤트 소비자로 이벤트가 전송되는 통로이다. 이벤트 채널의 물리적 구현은 메시지 지향 미들웨어와 같은 전통적인 컴포넌트 또는 점대점 통신을 기반으로 할 수 있다.

이벤트 기반 아키텍처를 중심으로 시스템을 구축하면 분산 컴퓨팅 모델에서 수평적 확장성이 단순화되고 장애에 대한 복원력이 향상된다.[2] 새로운 이벤트는 어디에서나 시작될 수 있지만, 데이터 저장소 네트워크 전체에 전파되어 각 이벤트가 도착하면 업데이트된다. 추가 노드를 추가하는 것도 쉽다.[3]

이벤트 기반 아키텍처는 서비스 지향 아키텍처 (SOA)를 보완할 수 있는데, 이는 서비스가 들어오는 이벤트에서 발생된 트리거에 의해 활성화될 수 있기 때문이다.[4][5]

7. 1. 자바 스윙 (Java Swing)

java

public class FooPanel extends JPanel implements ActionListener {

public FooPanel() {

super();

JButton btn = new JButton("Click Me!");

btn.addActionListener(this);

this.add(btn);

}

@Override

public void actionPerformed(ActionEvent ae) {

System.out.println("Button has been clicked!");

}

}

```

다른 방법은 다음과 같다.

```java

public class FooPanel extends JPanel {

public FooPanel() {

super();

JButton btn = new JButton("Click Me!");

btn.addActionListener(new ActionListener() {

public void actionPerformed(ActionEvent ae) {

System.out.println("Button has been clicked!");

}

});

this.add(btn);

}

}

```

위 코드는 자바 GUI 프로그래밍에서 이벤트 처리를 보여주는 예시이다. `FooPanel` 클래스는 `JPanel`을 상속받고 `ActionListener` 인터페이스를 구현한다. `"Click Me!"`라는 텍스트가 있는 `JButton` 객체를 만들고, 이 버튼에 `ActionListener`를 추가한다. `actionPerformed` 메소드는 버튼이 클릭될 때 실행되어, `"Button has been clicked!"`라는 메시지를 콘솔에 출력한다.

두 번째 코드 예시는 익명 클래스를 사용하여 `ActionListener`를 구현하는 방법을 보여준다. 첫 번째 예시와 같은 기능을 수행하지만, `ActionListener`를 별도의 클래스로 정의하지 않고 버튼에 바로 추가한다.

7. 2. 자바스크립트 (JavaScript)

javascript

(() => {

'use strict';

class EventEmitter {

constructor() {

this.events = new Map();

}

on(event, listener) {

if (typeof listener !== 'function') {

throw new TypeError('The listener must be a function');

}

let listeners = this.events.get(event);

if (!listeners) {

listeners = new Set();

this.events.set(event, listeners);

}

listeners.add(listener);

return this;

}

off(event, listener) {

if (!arguments.length) {

this.events.clear();

} else if (arguments.length === 1) {

this.events.delete(event);

} else {

const listeners = this.events.get(event);

if (listeners) {

listeners.delete(listener);

}

}

return this;

}

emit(event, ...args) {

const listeners = this.events.get(event);

if (listeners) {

for (let listener of listeners) {

listener.apply(this, args);

}

}

return this;

}

}

this.EventEmitter = EventEmitter;

})();

```

사용 예시:

```javascript

const events = new EventEmitter();

events.on('foo', () => { console.log('foo'); });

events.emit('foo'); // "foo" 출력

events.off('foo');

events.emit('foo'); // 아무것도 발생하지 않음

```

`EventEmitter` 클래스는 자바스크립트에서 이벤트를 처리하는 데 사용되는 클래스이다. 위의 코드는 `EventEmitter` 클래스의 구현 예시와 사용 방법을 보여준다.

8. 안티패턴

현재 주어진 원본 소스(`source`)가 비어있고, 하위 섹션(`sub-contents`)에 "타임아웃 안티패턴"에 대한 내용만 존재하므로, 이 섹션의 내용을 참고하여 작성할 수 있습니다.

"타임아웃 안티패턴"은 마크 리처즈가 명명한 것으로, 분산 시스템에서 타임아웃 값을 설정할 때 발생하는 문제점을 다룬다. 따라서, 이 내용을 바탕으로 "안티패턴" 섹션에 다음과 같이 간략하게 언급할 수 있다.

```text

분산 시스템에서는 타임아웃 값을 설정하는 것과 관련된 "타임아웃 안티패턴"이 존재한다.[1]

8. 1. 타임아웃 안티패턴

마크 리처즈(Mark Richards)가 명명한 "타임아웃 안티패턴"은 분산 시스템에서 타임아웃 값을 설정하는 데 따르는 어려움을 설명한다.[1] 짧은 타임아웃은 적법한 요청을 조기에 실패시킬 수 있으며, 복잡한 해결책을 필요로 한다. 반면 긴 타임아웃은 느린 오류 응답과 열악한 사용자 경험을 초래할 수 있다. 회로 차단기 패턴은 하트비트, "합성 트랜잭션" 또는 실시간 사용량 모니터링과 같은 메커니즘을 통해 서비스 상태를 모니터링하여 이러한 문제를 해결할 수 있다. 이러한 접근 방식은 더 빠른 오류 감지를 가능하게 하고, 분산 아키텍처에서 전반적인 사용자 경험을 개선할 수 있다.

9. 도전 과제

이벤트 기반 아키텍처는 다음과 같은 여러 가지 도전 과제를 안고 있다.


  • 적절한 이벤트 균형: 시스템이 너무 많은 상세한 이벤트를 생성하면, 전체 이벤트 흐름을 효과적으로 분석하기 어려워진다. 이는 롤백이 필요할 때 더욱 심각해진다. 반대로, 이벤트가 지나치게 통합되면 불필요한 처리 및 이벤트 소비자의 응답을 유발할 수 있다. 마크 리처드는 각 이벤트의 영향과 소비자가 작업을 결정하기 위해 이벤트 페이로드를 검토해야 하는지 여부를 고려하여 최적의 균형을 찾을 것을 권장한다. 예를 들어, 규정 준수 확인 시나리오에서는 규정 준수 및 비규정 준수, 두 가지 유형의 이벤트만 게시하는 것이 적절할 수 있다. 이렇게 하면 각 이벤트가 관련 소비자만 처리하도록 보장하여 불필요한 작업을 줄일 수 있다.

9. 1. 오류 처리

이벤트 기반 아키텍처 사용 시 어려운 점 중 하나는 오류 처리이다. 이 문제를 해결하는 한 가지 방법은 별도의 오류 처리 프로세서를 사용하는 것이다.[6] 이벤트 소비자가 오류를 경험하면, 오류가 발생한 이벤트를 즉시 비동기적으로 오류 처리 프로세서로 전송하고 계속 진행한다. 오류 처리 프로세서는 오류 수정을 시도하고 이벤트를 원래 채널로 다시 보낸다. 그러나 오류 처리 프로세서가 실패하면, 오류가 발생한 이벤트를 추가 조사를 위해 관리자에게 보낼 수 있다. 오류 처리 프로세서를 사용하는 경우, 오류가 발생한 이벤트는 재전송될 때 순서가 뒤바뀌어 처리된다는 점에 유의해야 한다.[6]

9. 2. 데이터 손실

구성 요소 중 하나가 이벤트를 성공적으로 처리하고 다음 구성 요소로 넘기기 전에 충돌하면, 이벤트가 삭제되어 최종 목적지에 도달하지 못할 수 있다.[6] 데이터 손실 가능성을 최소화하려면 전송 중인 이벤트를 지속적으로 유지하고, 다음 구성 요소가 이벤트 수신을 확인한 경우에만 이벤트를 제거하거나 대기열에서 제거할 수 있다. 이러한 기능은 일반적으로 "클라이언트 확인 모드"와 "최종 참가자 지원"이라고 한다.[6]

9. 3. 이벤트 진화 전략

시스템이 발전함에 따라 이벤트 스키마는 변경될 수 있다. 시맨틱 버전 관리 및 스키마 진화와 같은 전략을 통해 이전 버전과의 호환성을 유지해야 한다.[9] 이러한 전략에는 이전 버전 및 이후 버전과의 호환성을 유지하기 위한 이벤트 버전 관리가 포함될 수 있다.[9] 어댑터는 이전 형식과 새 형식 간에 이벤트를 변환하여 구성 요소 간의 일관된 처리를 보장할 수 있다.[9] 이러한 기술을 통해 복잡하고 분산된 환경에서 시스템이 호환 가능하고 안정적으로 진화할 수 있다.[9]

9. 4. 극도로 느슨한 결합과 분산

이벤트 기반 아키텍처는 극도로 느슨하게 결합되어 있으며, 잘 분산되어 있다. 이벤트가 거의 모든 것이 될 수 있고 거의 모든 곳에 존재할 수 있기 때문에 이러한 아키텍처는 훌륭하게 분산된다. 이벤트 자체가 그 원인의 결과를 알지 못하므로 아키텍처는 극도로 느슨하게 결합되어 있다. 예를 들어, 현관문이 열릴 때 정보를 기록하는 경보 시스템이 있다면, 문 자체는 문이 열릴 때 경보 시스템이 정보를 추가할 것이라는 사실을 알지 못하고, 단지 문이 열렸다는 것만 알 뿐이다.[10]

9. 5. 의미적 결합(Semantic Coupling)과 추가 연구

이벤트 기반 아키텍처는 공간, 시간, 동기화 측면에서 느슨한 결합을 가지며, 정보 교환 및 분산 워크플로우를 위한 확장성 있는 인프라를 제공한다.[12] 그러나 이벤트 아키텍처는 이벤트 구독 및 패턴을 통해 기본 이벤트 스키마와 값의 의미에 긴밀하게 결합된다.[12] 스마트 시티 및 센서 웹과 같이 크고 개방된 배포 환경에서는 이벤트의 높은 수준의 의미적 이질성 때문에 이벤트 기반 시스템의 개발 및 유지 관리가 어렵다.[12] 이러한 이벤트 기반 시스템 내에서 의미적 결합 문제를 해결하기 위해, 이벤트의 근사 의미적 매칭 사용은 활발하게 연구되는 분야이다.[12]

9. 6. 동기식 트랜잭션

EDA에서 동기식 트랜잭션은 요청-응답 패러다임을 사용하여 구현할 수 있다.

  • 두 개의 별도 큐를 생성한다. 하나는 요청용이고 다른 하나는 응답용이다. 이벤트 생산자는 응답을 받을 때까지 대기해야 한다.
  • 각 요청에 대해 하나의 전용 임시 큐를 생성한다.

9. 7. 이벤트 흐름 계층

이벤트 기반 아키텍처(EDA)는 논리적으로 다음 네 개의 계층으로 구성된다.[10]

계층설명
이벤트 생성기(Event Producer)사실을 감지하고 해당 사실을 이벤트 메시지로 표현한다. 예를 들어, 이메일 클라이언트, 전자 상거래 시스템, 모니터링 에이전트 또는 일종의 물리적 센서가 될 수 있다.[10] 다양한 데이터 소스에서 수집된 데이터를 평가를 위해 단일 표준화된 데이터 형태로 변환하는 것이 이 계층의 중요한 과제이다.[10]
이벤트 채널(Event Channel)이벤트 생성기로부터 수집된 정보를 이벤트 엔진[10] 또는 싱크로 전달하는 메커니즘이다. TCP/IP 연결, 또는 모든 유형의 입력 파일(플랫 파일, XML 형식, 이메일 등)일 수 있다. 여러 이벤트 채널을 동시에 열 수 있다. 일반적으로 이벤트 처리 엔진이 거의 실시간으로 처리해야 하기 때문에 이벤트 채널은 비동기적으로 읽힌다. 이벤트는 대기열에 저장되어 이벤트 처리 엔진에 의해 나중에 처리되기를 기다린다.
이벤트 처리 엔진(Event Processing Engine)이벤트를 식별하고 적절한 반응을 선택 및 실행하는 논리 계층이다. 또한 여러 단언을 트리거할 수 있다. 예를 들어, 이벤트 처리 엔진에 입력되는 이벤트가 재고 부족인 제품 ID인 경우, "제품 ID 주문" 및 "직원에게 알림"과 같은 반응을 트리거할 수 있다.[10]
이벤트 결과(Downstream Activity)이벤트의 결과가 나타나는 논리적 계층이다. 예를 들어, 누군가에게 이메일이 전송되고 애플리케이션은 화면에 일종의 경고를 표시할 수 있다.[10] 싱크(이벤트 처리 엔진)에서 제공하는 자동화 수준에 따라 다운스트림 활동이 필요하지 않을 수 있다.


참조

[1] 간행물 Event-driven Applications: Costs, Benefits and Design Approaches California Institute of Technology 2006
[2] 웹사이트 Event Sourcing https://martinfowler[...] 2005-12
[3] 웹사이트 Parallel Model https://martinfowler[...] 2005-12
[4] 웹사이트 Event-driven services in SOA https://www.infoworl[...] 2020-07-21
[5] 웹사이트 Event-driven architecture poised for wide adoption https://www.computer[...] 2020-07-21
[6] 서적 Fundamentals of Software Architecture: An Engineering Approach O'Reilly Media
[7] 서적 Serverless Architectures on AWS Manning
[8] 서적 Microservices AntiPatterns and Pitfalls O'Reilly
[9] 서적 Designing Event-Driven Systems O'Reilly Media
[10] 간행물 Event-Driven Architecture Overview Patricia Seybold Group 2006-02-02
[11] 웹사이트 Online Event Processing - ACM Queue https://queue.acm.or[...] 2019-05-30
[12] 논문 "Approximate Semantic Matching of Heterogeneous Events.” In 6th ACM International Conference on Distributed Event-Based Systems (DEBS 2012), 252–263" http://www.edwardcur[...] 2012
[13] 간행물 Event-Driven Applications: Costs, Benefits and Design Approaches California Institute of Technology 2006


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com