본문 바로가기

빗썸 테크코스 아카데미/1주차(Event Driven)

1일차 이벤트 드리븐 아키텍쳐 & 프로그래밍

동기 (Synchronous)와 비동기(Asynchronous)

1. 동기

말그대로 동시에 일어난다는 의미입니다. 예를 들어 커피를 시켰을때, 커피가 만들어질때까지 옆에서 기다린다면 동기적 프로그래밍이라고 할수 있습니다. 결과가 발생할때까지 결과값을 기다리는것을 의미합니다

2. 비동기

동시에 일어나지 않는것을 의미합니다. 예를 들어 커피를 시켰을때, 진동벨을 통해 커피가 만들어질때까지 기다리지 않는다면 비동기적 프로그래밍이라고 할 수 있습니다. 결과가 발생할때까지 결과값을 기다리지 않고 다른 할일을 처리하다가 결과값을 받는것을 의미합니다.

 

블록킹(Blocking)과 논 블록킹(Non - Blocking)

1. 블록킹 

호출한 함수의 상태와 연관이 있다. A가 B를 호출하고 B를 계속 기다린다면, 그 방식을 블록킹이다.

블록킹

2. 논블록킹 

호출한 함수의 상태와 연관이 있다. A가 B를 호출하고 B를 계속 기다리지 않은채 자신을 일을 수행한다면, 그 방식을 논블록킹 방식이라 칭한다.

논블록킹

 

MicroService Architecture(MSA)와 Event Driven

1. 배경

기존의 모노리틱 환경에서의 시스템 장애는 전체 서비스의 장애로 이어졌고 이는 치명적이였다. 이러한 치명적인 리스크를 회피하기 위해서 서비스들을 여러가지 서버로 나누는 작업을 진행하였고 이 구성이 MSA 구성이고 이러한 MSA환경하에서의 단점을 극복하기 위해 나온것이 Event Driven이다.

 

이벤트 드리븐 구성 요소

2. 원리

기본적인 원리는 Producer라고 Event를 발생시키는 요소가 Event를 Event queue 혹은 Message queue와 같은 queue에저장하게 된다. 이렇게 저장된 Event들은 Event Bus를 통해 이벤트를 처리하는 Consumer에게 전달되고 이벤트를 처리하게 된다.

3. 구성요소

1. Event

관찰하기로 약속된 주요 사건

2. Producer 

이벤트 감지와 생성

3. Consumer 

이벤트 버스에서 받아와서 논리로직 수행하는 주체

4. Event Bus

이벤트를 보내는 역할, 이벤트를 실어보내는 역할 event queue, producer서 consumer로 이벤트를 전달

 

Event Driven Architecture 설계시 고려사항

1. Loosely coupling

 

2. Removing dependencies

 

3. Nonblocking transaction

 

4. Asynchronized callback

 

5. Fallback / Retry

이전 상황을 인지하고 실패시 그 부분으로 Fallback하는 것을 의미한다. 예를 들어 이메일 인증하고 핸드폰 인증시 핸드폰 인증에서 오류가 발생했다면 이메일 인증 후의 부분으로 Retry되어야 한다.

6. Event Logging 

여러 Consumer와 Producer가 존재하므로 각 Consumer들이 처리하는 Event에 대한 로깅이 중요하다.

 

Event Driven Architecture Pattern

1. Single Producer - Single Consumer

하나의 프로듀서와 하나의 컨슈머를 가지는 구조로 일반적인 동기 프로그래밍의 구조라고 생각하면 된다.

2. Single Producer - Multi Consumer

컨슈머가 복잡한 로직을 가지고 있고 시간이 오래걸리는 작업일 경우, 다수의 컨슈머를 배치하는 경우이다.

3. Dead letter QueueTime to Live

설정한 Retry limitation동안 이벤트가 처리되지 않을 경우 main message queue에서 제거하고 사후 분석을 위해 DLQ로 이동한다.

4. Time to Live

처리 되지 않은 이벤트의 생명 주기를 제한하여 만료되면 이벤트를 폐기한다.

5. Event spliting

한 Event에 대해 여러 로직의 처리가 필요한 경우, 여러 부분으로 나뉜 이벤트들의 각 부분을 Consumer들이 처리하는 구조이다.

 

Event Driven Programming

1. Consumer <> Producer는 Broker를 통해 소통

하나의 프로듀서와 하나의 컨슈머를 가지는 구조로 일반적인 동기 프로그래밍의 구조라고 생각하면 된다.

2. Message 생성 후 소비 전까지 Queue에 저장

컨슈머가 복잡한 로직을 가지고 있고 시간이 오래걸리는 작업일 경우, 다수의 컨슈머를 배치하는 경우이다.

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

  • 1. N개의 consumer, producer 동시 처리
  • 2. 실패한 작업 재시도 및 logging 로직 단순화
  • 3. Consumer Scale out으로 컴퓨팅 리소스 확장

컨슈머와 프로듀서의 기본적인 코드 양식 : 프로듀서는 publish()하고 컨슈머는 subscribe()하다 라고 생각하면 된다.

 

Event Driven Architecture 장점

1. MSA환경에 적합

비동기적으로 다수의 컨슈머가 이벤트 버스를 통해 다수의 이벤트를 처리하는 형식이므로 Service간 호출이 많은 Microservice Architecture에 적합하다.

2. 확장성, 유연성

다수의 서버로 구성되어 있으므로, Infra의 Scale out에 장점을 가진다. 또한 특정 언어나 DB나 환경에 구애받지 않고 새로운 환경으로 새로운 서버를 구성할수 있다(Infra structure, Polyglot)

3. 가용성, 응답성

다수의 서버로 구성되어 있으므로, Infra의 Scale out에 장점을 가진다. 또한 특정 언어나 DB나 환경에 구애받지 않고 새로운 환경으로 새로운 서버를 구성할수 있다(Infra structure, Polyglot)

4. 확장성, 유연성

많은 요청의 서비스일수록 성능 향상을 기대할수 있으며, 가용성과 응답성이 좋아진다.

5. Failut isolation

하나의 서버가 장애가 나게 될시 다른 서버로 번지는 문제를 방지할수 있다. 서버의 장애가 계속되면, 물론 문제가 되겠으나 모노리틱 환경에서의 치명적인 리스크를 벗어날수 있다.

 

Event Driven Architecture 단점

1. 설계 복잡도

설계 복잡도가 증가한다. 다수의 컨슈머와 다수의 프로듀서 또 중앙의 이벤트 큐까지 존재하고 더 나아가 이벤트 큐를 감시하는 모니터링 툴까지 존재할수 있다. 설계자에 따라 설계도의 복잡도가 기하급수적으로 증가할 수 있고 이는 SM을 수행 할시에도 문제로 작동한다.

2. 디버깅의 어려움 

동기적으로 서버에 로깅이 찍히는 것이 아닌 여러 서비스로부터 로깅이 발생하므로, 디버깅을 수행할시 어려움이 존재한다.