“이벤트” 란

1. 시스템에서 발생하는 동작, 상태변경, 사실(Fact) 등을 나타낸다.
2. 항상 Immutable 하다.
3. 무기한으로 저장될 수 있다.
4. 요청/응답과 달리 한 번만 한 대의 서버에서 소비되지 않고, 여러 서비스에 걸쳐 소비될 수 있다.

아래는 Apache Kafka의 작동구조에 대한 이미지이다. [출처]

Event Driven Architecture 의 핵심 구성요소

Producer

이벤트의 생성자를 말한다.

Message Broker

이벤트를 저장하고, 라우팅하는 역할을 한다.

원하는 만큼 많은 수신자에게 이벤트를 수신할 수 있도록 해주며, 중복성을 추가한다.

브로커로 생성되면, 손실되지 않고 언제든지 메시지 브로커에서 이를 검색할 수 있다.

Consumer

이벤트를 수신하고 처리하는 소비자를 말한다.

Request/Response vs Event-Driven

• Synchronous vs Asynchronous
  • Request/Response의 경우, 요청 및 응답이라는 이름에서 알 수 있듯이 응답이 없을 경우 일반적으로 문제가 발생했다는 것을 뜻한다. 또한, 요청자는 응답자에게 필요한 만큼의 지연시간동안 지연시간이 발생하므로, 성능 면에서도 비효율적이다.
  • Event-Driven의 경우, 이벤트의 생성자가 소비자에게 어떠한 응답을 받거나 기대하지 않으므로 비동기적이다. 또한, 소비자에게 이벤트를 전달하는 것이 생성자의 통제나 책임 범위를 벗어난다. 이를 통해 생성자는 응답을 기다리지 않고 다른 작업을 처리할 수 있다.
• Inversion of Control
  • Request/Response의 경우 요청자는 응답자가 제공하는 API 등 여러 항목에 대해 알고 있어야 한다. 이는 정확하게 API를 요구사항에 맞추어 전송해야 한다는 뜻이며, 여러 서비스에 걸쳐 요청을 보내려면 모든 스펙에 대해 알고, 각 서비스에서 다루는 고유한 매개변수를 사용해 요청을 보내야 한다. 이것은 요청자가 응답자에게 의존하게 된다는 뜻이다.
  • Event-Driven의 경우, 생성자는 이벤트를 사용하는 소비자에 대해 신경 쓰지 않아도 된다. 이는 Producer와 Consumer를 개념적으로 완전히 분리한다.
    • 그렇다고 아무렇게나 이벤트를 생성하지 않고, 공통 언어를 사용해 변수나 소통하는 단어를 일치시킬 필요성이 있다.
• Loose Coupling
  • Request/Response의 경우, 결합도를 낮추기 위해 MSA 전환을 했지만 여전히 서비스간 결합도가 존재하며, 이로인해 성능저하 및 유지보수성을 낮추는 결과를 가져올 수 있다.
  • Event-Driven의 경우, “이벤트”가 생성자와 소비자를 분리하는 역할을 하여 서비스간 결합도를 최소화 시킨다.