Event-driven Architecture의 이해 (1)

Event-driven Architecture라는 말을 많이 들어봤을 것이다.

불리우는 형태는 다양한데, Architecture를 Service라는 단어로도 많이 사용하고, Programming이라고도 많이 사용한다.

보통 어디에 초점을 더 맞추어 얘기하느냐에 따라 약간씩 다르게 사용하는데, 체감상 시스템 내부 구조를 얘기할 때 Architecture라는 말이 더 자연스럽게 나오는 것 같다.

하지만 의미의 핵심은 Event-driven하다는 것에 있다. 그렇다면 이것은 도대체 뭘까?

Event-driven 이란?

서두에 말한 것과 같이, Event-driven 은 programming, Architecture 등과 연결되어 다양한 정의로 표현한다.

Event Driven 말 그대로 이벤트 중심 즉 어떠한 상태를 변경하는 사건을 기반으로 무언가 동작한다는 것이다.

잘 와닿지 않을 수 있는데, 이는 우리가 흔히 이야기하는 버튼 또는 마우스 클릭 등의 이벤트를 추가하고 무언가를 만들었을 때 Event-driven하다 라고 말하지 않기 때문이다.

보편적으로 여기에서 이야기하는 Event-driven은 버튼 흑은 클릭 등의 이벤트가 발생하는데에 초점이 맞춰져 있다기 보다, 버튼 혹은 클릭등의 이벤트가 발생했을 때 어떠한 상태변화가 일어났느냐에 초점이 맞춰져 있다.

쉽게 말해, 내가 회원가입 페이지에서 이메일 인증을 위한 인증확인 버튼을 만들었고 이는 이렇게 표현할 수 있다. /회원가입 에서 이메일 인증확인 버튼 클릭

상태에 기반하여 말해보자. 이메일 인증확인 요청이 사용자에게 발생함

이 두가지는 비슷하나 개념적으로는 완전히 다른데, 어디에서 어떤 버튼을 눌렀는지 모른다는 점이다. 그것보다 현재 어떤 상태인가에 초점이 맞춰져 있는 것이다.

우리가 앞으로 얘기할 Event에 대한 시야는 이런식으로 넓혀야 하는데, 이쯤에서 Event에 대한 개념을 다시 정의하자.

즉, 어떠한 상태가 변경되었을 때 (Event 발생) 이를 누군가 관찰하고 일을 수행한다. (Event 처리)

이 개념이 Event-driven의 시작점이라고 볼 수 있다.

Event-driven Architecture를 말할 때 우리는 종종 MSA와 비동기 프로그래밍을 많이 얘기하는데, 먼저 비동기 프로그래밍과 Event-driven Architecture는 무슨 연관성이 있는지 알아보자.

비동기 프로그래밍이란 철저하게 작업자 관점에서, 작업이 여러가지가 있을 경우 이를 어떠한 흐름으로 작업할 것이냐에 대한 방법이다.

말이 조금 어려웠는데, 쉽게 햄버거 재료 준비를 예시로 삼아보자.

대조되는 개념인 동기식 프로그래밍은 햄버거 재료를 준비할 때 이러한 작업 순서를 갖는다.

빵이 구워질 때까지 기다린다 -> 완료 후 패티를 데우고 마찬가지로 패티가 데워질 때 까지 기다린다 -> 양상추를 손질한다 -> 등등..

비동기식 프로그래밍은 이러한 작업 순서를 갖는다.

패티를 전자렌지에 넣는다 -> 데워지는 동안에 빵을 팬위에 올려둔다 -> 마찬가지로 데워지고 구워지는 동안에 양상추 손질을 한다 -> 등등..

이처럼 작업을 요청하고 이를 기다리는지 기다리지 않고 다른 일을 수행할 것인지에 대한 차이이다.

그렇다면 이것이 왜 Event-driven Architecture와 같이 얘기가 나오는 것일까

위의 그림이 우리가 보편적으로 얘기하는 Event-driven Architecture이다.

Topic Space는 즉 어떤 사건을 발생시키는 녀석이고, 약속된 사건이 발생하면 이를 관찰하던 관찰자가 이 사건에 대한 로직을 처리한다.

이것이 비동기 처리방식이 아닌 동기식 처리방식을 따른다면 어떠한 일이 벌어질까?

사진상의 여러 System에 사건이 할당되는 속도가 굉장히 느릴 것이다. 사건 처리 완료 후 다음 사건을 할당 할 것이기 때문에

이렇게 Event-driven Architecture의 구성을 이야기 할때 우리는 크게 4가지 구성요소를 이야기한다.

위에서 잠깐 이야기했는데, 이벤트는 넓은 범위의 어떤 사건이 발생되어 상태가 변경되었음을 일컫는다고 했다.

이 이벤트는 상태변경에 따른 어떠한 로직이 수행되어야 하는데, 이를 Consumer가 담당하는 것이다.

위에서 이메일로 예시를 들었으니 마저 들자면, 이메일 인증 요청은 수십명의 사용자가 요청할 수 있다.

Consumer는 이메일 인증을 어떠한 경로로 했는지 관심없고, 어떤 버튼을 눌렀는지도 관심이 없다. 즉 이메일 인증 요청을 한 상태에 대한 것만 관심이 있을 뿐이다.

여기서 알 수 있는 것은 Producer, Consumer는 서로 1:1도 아니고 서로의 존재조차 관심이 없다는 것이다.

이는 우리가 의존성이 낮다라고 표현할 수 있는데, Event-driven Architecture의 장점이기도 하다.

Event는 어떠한 사건에 따른 상태 변경을 의미한다.
Event-driven Architecture는 이러한 상태 변경을 처리하는 구조를 갖춘 소프트웨어 아키텍처 모델이다.
보편적인 Event-driven Architecture의 구성요소는 4가지로 이뤄져 있으며, 포스팅 내용과는 논외로 설계 복잡도가 올라감에 따라 여러 서비스 모니터링을 위한 추가적인 아키텍처가 들어갈 수 있다.

쓰다보니 내용이 길어져서 2편으로 나누어서 포스팅 해야할 것 같다.

다음 포스팅은 Event-driven Architecture의 장단점, 고려사항, 각종 패턴과 실제 프로그래밍을 어떻게 하는지에 대한 포스팅을 진행 할 예정이다.