Event-driven Architecture & Programming

1. 동기와 비동기

- 동기(Synchronous)

    : 요청자가 처리자의 종료시점을 확인

- 비동기( Asynchronous)

    : 요청자가 처리자의 종료시점에 신경쓰지 않는 방식

 

- 작업 처리 시간

   : 작업A - 1s, 작업B - 2s, 작업C - 2s

   - 동기: 1 + 2 + 2 = 5s

   - 비동기: 2s, 동시에 처리되기 때문에 작업 중 가장 긴 시간.

 

2. Event

- 외부에서 들어오는 요청

- Consumer module이 소비하여 비즈니스 로직을 처리하기 위한 데이터 조각

- 관찰의 대상이 되는 사건 정보를 담고 있다.

 

3. Event Driven의 주요 요소 (4가지)

- Event

    : 관찰하기로 약속한 사건
    : message, notification

- Producer

    : 이벤트 감지와 생성

    : publisher, event source

- Consumer

    : 이벤트를 소비하여 로직 생성

    : receiver, subscriber

- Event Bus

    : Producer에서 Consumer로 이벤트 전달

    : message queue

 

4. Event Driven 제약 사항

- 이벤트는 발생한 사건에 대해 약속된 형식 사용

- 불변: 과거 메시지 변경 불가

- 발생한 사건에 대한 결과 상태 전달

- 생성자는 이벤트 처리 상태에 관심 X

- 처리자는 이벤트 생성자에 관심 가지지 X

 

5. Event Driven 설계 시 고려사항

- Loosely Coupling (필수!)

- Remove Dependency

- Non-blocking transaction

- Asynchronized Callback

- Fallback / Retry

- Event logging

 

6. Event Driven Architecture Pattern

  1) Single Producer - Single Consumer

    : 단순!

  2) Single Producer - Multi Consumer

    : 이벤트 처리 비용이 이벤트 생성 비용보다 높은 경우(일반적인 경우)

  3) Dead letter queue

    : 설정한 Retry 한계까지 이벤트가 처리되지 않은 경우 main message에서 제거하고

      사후 분석을 위해서 DLQ(배달 못한 편지 대기열)로 이동

  4) Time to Live

    : 처리되지 않은 이벤트의 생명 주기를 제한하여 만료되면 이벤트 폐기(오래된 이벤트는 의미 없다 판단하여 폐기)

  5) Asynchronous request-response

    : queue를 사용하지 않는 경우로 polling 방식(요청자가 간헐적으로 확인)

      -> 과도한 요청이 발생하여 성능 저하 발생

  6) Event Splitting

    : 한 이벤트에 대하여 여러 로직 처리가 필요한 경우(처리 + 집계 + 로깅... 등)

 

7-1. Event Driven Architecture의 특장점

- 서비스 간 호출이 많은 Micro Architecture에 적합

- Infra Structure의 유연한 사용 가능

    ex) 오토스케일링이 더 유연하게 가능

- Polyglot

- 가용성, 응답성 ↑ --> 효율성, 성능 ↑

     : 요청이 많아질수록 성능 향상 기대

- Fault Isolation

 

7-2. Event Driven Architecture의 단점

- 설계 복잡도 증가

- Message Broker 의존성 증가

    -> 이걸 극복하기 위해서는 보호하는 아키텍처 설계가 요구됨, ex) 2중화, 모니터링 등

- 코드 가독성 하락

- 디버깅 난이도 상승

    -> 로그를 잘 찍어서 확인하는 것 뿐...

- log를 통한 System flow 가독성 하락

 

8. Event Driven 프로그래밍

- Consumer <-> Producer는 Broker를 통해 소통

- Message 생성 후 소비 전까지는 Queue에 저장

- Consumer <-> Producer의 분리로 인한 이점

    - N개의 Consumer와 Producer 동시 처리

    - 실패한 작업 재시도 및 logging 로직 단순화

    - Consumer scale out으로 컴퓨터 리소스 확장

        -> 사실상 클라우드에서만 가능하다!