string(27) "/blog/?uid=193&mod=document"

HOME

ABOUT US

Blog

Blog

Blog

Event Driven Architecture (EDA)와 CDC

2021.09.30

20210930121434_id7n9eo.png




소프트웨어 산업과 관련 있는 사람들 특히 엔지니어나 개발자들에게 client-server 구조 혹은 request-driven 모델이란 용어는 비교적 익숙한 용어일 것이다. 아주 오래전부터 현재까지도 대부분의 서비스와 이를 위해 존재하는 시스템 소프트웨어 구현의 거대한 축을 구성하는 개념이기 때문이다. 전통적인 트랜잭션을 포함하여 비즈니스에서 유의미한 데이터의 대부분은 "이벤트(event)"로 발생한다. 그럼에도 불구하고 오랫동안 시스템은 client의 특정 요청을 받아들여 이에 대한 처리를 수행하고 그 결과를 응답으로 제공하는 ‘request-driven 모델’이 주를 이루었다.

"request driven"은 적시성(just-in-time)이라는 관점에서 굉장히 시스템 효율적인 방식이다. 그러나 최근의 데이터 환경은 대부분 클라우드, 빅데이터, AI 등의 용어들로 표현되는 massive 하고 scale 가변적이고 복합적인 데이터 처리 환경을 수반한다. 또한 15년 전 "빅데이터", 10년 전 "클라우드", 5년 전 "블록체인"에 이어 최근 유행하고 있는 "메타버스(Meta-verse)"는 IT업계는 물론 하나의 사회적 현상이자 서비스가 제공되는 플랫폼 생태계를 좌우할 큰 흐름이 되어가고 있다.

메타버스를 포함해서 이들 서비스와 플랫폼 생태계는 "데이터를 처리하는 시스템"의 관점뿐 아니라 "데이터가 생성되는 플랫폼"의 관점에서 보더라도 서로 독립적인 기능들이 정합성 있게 데이터를 주고받으며 상호작용하는 유기체적인 시스템으로 돌아가야 한다는 것을 가늠해 볼 수 있다. 이를 위해 시스템은, 자신이 처리해야 하는 ‘event’에 대해 독립적인 처리를 하는 loosely coupled된 다수의 컴포넌트들로 구성된다.

 

20210930121450_pfiy8yt.png



일반적으로 사용되는 ‘data’라는 용어 대신 왜 ‘event’란 개념적 용어를 사용하는 걸까?

많은 문서나 text에서 저마다의 용어와 문장으로 "event"에 대해 정의하고 있다. 시스템 소프트웨어에서 말하는 event는 과연 어떤

특성들을 갖고 있는지 살펴보도록 하자.





 

 

20210930121238_zxxdto8.png

 


 

먼저 ‘event는 시스템에 정의되어 있다"는 것은 실제로 시스템에 유입되는 data가 어떤 모양을 하고 있든 이를 처리하는 시스템은 자신이 알고 있는 모양으로 그 data를 인식한다는 의미이다.

‘event가 기 정의된 방식으로 처리된다는 것’은 시스템으로 유입된 event에 대한 처리 방식과 처리된 결과 data의 형태가 정의되어 있다는 것이다. 이렇게 시스템에서 처리되지 않는다면 event가 아니란 개념을 내포한다.

마지막으로 ‘event는 그 발생 주기나 시점을 이를 처리하는 시스템이 미리 알 수 없다’는 점에서 주기적으로 발생하는 routine과 다르다. 이러한 event 발생의 불특정성은 이를 처리하는 시스템의 아키텍처가 어떠해야 하는지를 말해준다.

이러한 특성을 갖는 event를 처리하는 시스템이 갖는 아키텍처가 바로 ‘event-driven architecture’이다. Event-driven architecture가 갖는 많은 특성들 중에서도 특히 자주 언급되는 것이 "loosely coupled"라는 특성이다.

"tightly coupled"와 반대가 되는 개념으로 loosely coupled system의 핵심은 decentralized되어 각각의 place(node)에서 처리될 수 있는 데이터, 즉 이벤트에 대한 정의가 된다. 그리고 이것은 asynchronous processing이라는 처리 방식과도 밀접하게 관련된다.

event의 lifecycle 이란 관점에서 event를 생산하고 소비하는 주체가 다르고 event를 생산하는 주체(producer)는 event를 소비하는 주체(consumer)에 대해 몰라도 되는 이 특징으로 인해 event-driven architecture를 지원하는 시스템은 최근의 시스템 구성에 필수적으로 고려되는 컴포넌트가 된다.

최근의 클라우드 플랫폼과 decentralized 분산 환경에서 빅데이터에 대한 처리를 수반하는 현대의 시스템은 처리 효율성을 높이기 위해 필수적으로 loosely coupled 쪽으로 중심 패러다임을 바꿔가고 있다. 최근 Kafka를 비롯한 asychronous processing system 아키텍처의 유행이 이를 반증하고 있다.

20210930121502_14acg28.png

 

현재 개발되어 사용되고 있는 CDC(Changed Data Capture) 제품은 “source DBMS의 transaction log를 실시간으로 읽어 target system에 반영 가능한 transaction 정보로 변환해 주는 시스템”으로 정의해도 될 만큼 특정 동작을 수행하는 소프트웨어이다. 즉 복제 (Capture)의 대상인 "Changed Data"가 transaction log로 기록되는 DBMS dependant 한 트랜잭션 정보로 한정된다는 것이다.

그러나 CDC에 의해 처리(복제) 된 데이터의 적용 및 반영(apply)은 다르다. DBMS를 포함하여 다양한 target 시스템의 input stream으로 변환이 가능하기 때문이다. 이러한 특징이 바로 CDC가 다양한 유형의 source data를 처리하지는 못하지만 실시간 분산 환경에 최적화된 시스템을 구성하기 위한 중요한 컴포넌트로 활용되는 이유이다.

CDC가 취급하는 log record는 기 정의된 format이 존재하며, source DBMS의 protocol에 의해 write 되나 CDC 입장에서 그 발생 시기나 주기를 특정할 수 없다. 따라서 이는 위에서 언급한 event의 특성을 상당 부분 그대로 갖는다는 것을 알 수 있다. 또한 그 처리에 있어 loosely coupled 컴포넌트로서의 역할뿐 아니라 분산 pipeline의 한 축으로서의 역할을 수행하는 데 활용이 가능하여 event-processing의 대부분의 layer에 활용될 수 있다.

event processing 시스템을 구성하는 layer들을 구분하면 다음과 같다.

· event generator

· event channel

· event processing engine

· event-driven downstream activity

CDC가 실시간으로 생성하는 transaction record는 그 자체로 다른 시스템에서 처리해야 할 event가 될 수 있다. 결국 CDC는 event generator로서 기능할 수 있는 컴포넌트이다.

해당 CDC 제품이 지원하는지에 따라 다르겠지만 DBMS뿐만 아니라 다른 유형의 데이터 처리 시스템으로 데이터를 분산하는 기능을 갖고 있다면 pipeline 구성을 위한 event channel로서도 활용이 가능할 것이다.

지금도 CDC는 ETL 작업을 실시간으로 최적화하기 위한 수단이라는 관점에서 그 활용도를 언급하는 경우가 많다. 그러나 진화해가는 CDC는 event-driven architecture로서 앞으로 구축될 수많은 시스템의 핵심 컴포넌트로 자리 잡아갈 것이 분명해 보인다.

20210930121238_513qbgs.png