이벤트 (컴퓨팅)
컴퓨팅에서 이벤트(event)는 사용자의 입력, 하드웨어 인터럽트, 시스템 알림, 데이터나 상태의 변화와 같이 시스템이 모니터링하도록 설계된 감지 가능한 사건이나 상태의 변화를 의미한다. 이벤트는 이벤트 핸들러와 연관되어 있을 때 반응을 유발한다. 핸들러는 동기적으로 실행될 수 있는데, 이 경우 실행 스레드는 이벤트 핸들러가 처리를 완료할 때까지 차단된다. 혹은 비동기적으로 실행될 수도 있으며, 이 경우 이벤트는 나중에 처리될 수 있다. 동기적 처리가 실행을 차단하는 것처럼 보이더라도, 많은 시스템의 기반 메커니즘은 여전히 이벤트 루프에 의해 관리되는 비동기 방식이다.[1][2]
이벤트는 콜백, 메시지 객체, 신호, 인터럽트와 같은 다양한 메커니즘을 통해 구현될 수 있으며, 이벤트 자체는 사용된 구현 메커니즘과는 별개이다. 버블링, 캡처링, 게시/구독(pub/sub)과 같은 이벤트 전파 모델은 이벤트가 시스템 내에서 어떻게 배포되고 처리되는지를 정의한다. 기타 주요 측면으로는 이벤트 루프, 이벤트 큐잉 및 우선순위 지정, 이벤트 소싱, 복잡한 이벤트 처리 패턴 등이 있다. 이러한 메커니즘은 사건 기반 시스템의 유연성과 확장성에 기여한다.[1][2]
이벤트 대 메시지
[편집]분산 시스템에서 이벤트는 사실이나 상태 변화(예: OrderPlaced)를 나타내며, 일반적으로 여러 소비자에게 비동기적으로 브로드캐스팅되어 느슨한 결합과 확장성을 촉진한다. 이벤트는 일반적으로 즉각적인 응답을 기대하지 않지만, 인프라 수준에서 확인(acknowledgment) 메커니즘이 구현되는 경우가 많다(예: Kafka 커밋 오프셋, SNS 전달 상태). 이는 이벤트 패턴 자체의 내재된 부분이라기보다는 인프라 차원의 구현이다.[3][4]
반면, 메시지는 명령어(예: ProcessPayment), 이벤트(예: PaymentProcessed), 문서(예: DataPayload)를 포괄하는 더 넓은 역할을 수행한다. 이벤트와 메시지 모두 기술 스택과 구현 방식에 따라 최소 한 번(at-least-once), 최대 한 번(at-most-once), 정확히 한 번(exactly-once)과 같은 다양한 전달 보증을 지원할 수 있다. 그러나 정확히 한 번 전달은 인프라 수준의 진정한 '정확히 한 번' 의미론보다는 주로 멱등성(idempotency) 메커니즘을 통해 달성된다.[3][4]
이벤트와 메시지 모두에 대한 전달 패턴으로는 게시/구독(일대다)과 지점 간(일대일) 방식이 있다. 요청/응답 방식도 기술적으로는 가능하지만, 이는 순수한 사건 기반 시스템보다는 메시징 패턴과 더 관련이 깊다. 이벤트는 상태 전파 및 결합이 해제된 알림에 탁월하며, 메시지는 명령어 실행, 워크플로 조정, 명시적 조정에 더 적합하다.[3][4]
현대적인 아키텍처는 이 두 가지 접근 방식을 결합하는 경우가 많으며, 분산 상태 변화 알림에는 이벤트를 활용하고, 특정 타이밍, 순서 및 전달 요구 사항에 기반한 대상 명령어 실행이나 구조화된 워크플로에는 메시지를 활용한다.[3][4]
이벤트 진화 전략
[편집]분산 시스템에서 이벤트 진화는 서비스 전반의 일관되지 않은 이벤트 스키마 관리와 점진적인 시스템 업데이트 중 호환성 보장과 같은 과제를 제기한다. 사건 기반 아키텍처(EDA)의 이벤트 진화 전략은 시스템이 중단 없이 이벤트 변경 사항을 처리할 수 있도록 보장할 수 있다. 이러한 전략에는 하위 호환성 및 상위 호환성을 유지하기 위한 의미론적 버전 관리(semantic versioning)나 스키마 진화와 같은 이벤트 버전 관리가 포함될 수 있다. 어댑터는 이전 형식과 새 형식 간의 이벤트를 변환하여 구성 요소 간의 일관된 처리를 보장한다. 이러한 기술을 통해 시스템은 복잡한 분산 환경에서 호환성과 신뢰성을 유지하면서 진화할 수 있다.[1]
이벤트 세마포어
[편집]컴퓨터 과학에서 이벤트(또는 이벤트 세마포어)는 특정 조건이 참이 되었을 때 대기 중인 프로세스에 이를 알리기 위해 사용되는 동기화 메커니즘의 한 유형이다.
이벤트는 불리언 상태를 가지며 다음 연산을 지원하는 추상 자료형이다.
- wait - 실행 시, 이벤트 상태가 참(true)으로 설정될 때까지 실행 중인 프로세스를 일시 중단한다. wait 호출 이전에 이미 상태가 참으로 설정되어 있다면, wait는 아무런 효과가 없다.
- set - 이벤트 상태를 참으로 설정하고 대기 중인 모든 프로세스를 해제한다.
- clear - 이벤트 상태를 거짓(false)으로 설정한다.
이벤트의 다양한 구현체는 이러한 가능한 연산의 서로 다른 부분 집합을 제공할 수 있다. 예를 들어, 마이크로소프트 윈도우가 제공하는 구현체는 wait(WaitForObject 및 관련 함수), set(SetEvent), clear(ResetEvent) 연산을 제공한다. 이벤트 객체 생성 시 지정할 수 있는 옵션을 통해 SetEvent의 동작을 변경하여, 단일 스레드만 해제하고 해당 스레드가 해제된 직후 자동으로 상태가 거짓으로 돌아가게 만들 수 있다.
reset 함수가 부족한 이벤트, 즉 한 번만 완료될 수 있는 이벤트는 퓨처(future)라고 알려져 있다.[5] 반면 모니터(monitor)는 완료 신호와 상호 배제를 결합하고, 생산자와 소비자가 모니터 내에서 동시에 실행되지 않도록 하여 이벤트와 임계 구역을 결합한 형태이므로 더 범용적이다.
같이 보기
[편집]각주
[편집]- 1 2 3 Stopford, Ben (May 2018). 《Designing Event-Driven Systems》. O'Reilly Media. ISBN 9781492038245.
- 1 2 Fowler, Martin (2002년 11월 5일). 《Patterns of Enterprise Application Architecture》. Addison-Wesley Professional. ISBN 978-0321127426.
- 1 2 3 4 Kleppmann, Martin (2017). 《Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems》. O'Reilly Media. ISBN 978-1449373320.
- 1 2 3 4 《Building Event-Driven Microservices: Leveraging Organizational Data at Scale》. ISBN 978-1492057895.
- ↑ 500 lines or less, "A Web Crawler With asyncio Coroutines" by A. Jesse Jiryu Davis and Guido van Rossum says "implementation uses an asyncio.Event in place of the Future shown here. The difference is an Event can be reset, whereas a Future cannot transition from resolved back to pending."
외부 링크
[편집]- Article Another Look at Events by Jasmin Blanchette
- Article Event Handlers and Callback Functions by Sjoerd Visscher
- A High Level Design of the Sub-Farm Event Handler
- An Events Syntax for XML
- Distributed Events and Notifications
- Event order
- Write an Event Handler