event driven architecture 적용하기에 앞서서 고민 사항.

Question

안녕하세요, 3년차 백엔드 개발을 하고 있는 1인입니다.최근 event driven architecture를 학습하고 있는데요!일반적으로 비동기로 이벤트를 처리하는 것이 일반적인 것 같은데 현재 회사 백엔드 로직의 많은 부분이 rest한 crud api들로 이루져있는데 이런 api들은 일반적으로 유저가 응답을 기다리고 있고 내부적으로 일부 비동기처리를 하더라도 전체적인 흐름자체는 동기적으로 처리가 되어야 한다고 생각하는데요.그러면 비동기 처리를 해도 무방한 일부로직에 대해서만 event driven architecture 기반의 로직을 적용하는 것이 크게 메리트가 있을까 하는 생각이 듭니다.event driven architecture를 도입하는 것이 전체적인 구조에 도입한다는 것을 전제로 한다면 저는 아래의 두가지 방식 중 하나로 도입을 하는 것이 아닐까라는 생각이 들었습니다.방식 1. 동기 처리가 필요한 로직들을 동기로 이벤트 처리, 비동기로 처리가 가능한 로직들은 비동기로 이벤트 처리.방식 2. 실제로 동기 처리가 되어야하는 로직들이더라도 비동기로 처리. (결국 처리가 될 것이고 유저가 인지하지 못할 정도의 딜레이는 괜찮다고 생각하는 차원으로 봤을 때)추가로 이벤트를 발행해 처리하면 이벤트를 발행하는 쪽과 수신하는 쪽의 트랜잭션을 어떻게 묶어서 처리 할 것인지에 대한 고민과 이에 대한 추가적인 안전장치의 로직들( 보상 트랜잭션, 아웃박스 테이블)이나 모니터링 환경 구성, 대응 로직 등이 구현되어야하는데 이에 대한 부담감도 커서 기존의 설계 방식에서 event driven architecture를 도입해야될 명확한 이유를 아직 얻지 못한 상황입니다.위에 내용은 아직 event driven architecture에 경험이 없이 도입하면 어떨까 하는 사람의 생각이 담긴 내용인데 이 중 맞는 것과 틀린 것, 또 선배님들의 event driven architecture를 도입했던 경험이나 이 아키텍처에 대한 의견이 궁금합니다.

집킨 · Answer

k-msa말고 근사msa일때나 eda가 의미가 있죠Eda의 근본부터 공부해보면 서비스가 마이크로하고 그 서비스를 담당하는 팀이 분리되어 있을때 데이터(eda에선 이벤트라고 하죠)를 단일 진실 공급원으로 취급할지가 핵심요소입니다서비스가 분리되고 팀이 분리됐을때를 가정하고 생각하셔야 합니다지금 질문글에 언급한 내용들은 eda로 할수있는 것들이고, 중요한건 이벤트 스키마 설계,배포관리 이론부터 시작해야 점점 와닿을겁니다Building Event Driven Microservices 라는 책 한번 읽어보시면 좋을것같습니다 번역서도 있어요

wharup · Answer

이벤트 드리븐은 특정 케이스 보다는 이벤트를 사용하는 모든 곳에 붙이는 경우가 있습니다.예를 들어 Spring의 Application Event를 사용하는 것도 그렇게 부를 수 있으니까요. 따라서 케이스 별로 필요할 때 적용하는게 좋습니다. 그래서 EDA가 널리 퍼져도 REST API가 없어지진 않을거에요.

yeori · Answer

event driven architecture 라는 거창한 이름은 다 잊고 문제 해결에만 집중하면 좋습니다.그러니까, 지금 내가 겪고 있는 문제를 해결하려면 요청을 비동기적으로 처리하고 실패 시 retry를 하고, 관련 통계 및 입증 데이터까지 잡아내야 할 필요성 등등..예전에 모 기관에서 데이터를 긁어오는 기능을 넣는데, 문제는 응답 시간 편차가 너무 컸습니다.요청 100개 날리면 10개는 1초 이상 걸리고, 더 속터지는 건 무려 30초 넘게 응답이 안와서 타임아웃으로 소켓이 끊기는 사례가 결코 적지 않았다는 거...딱 봐도 이거 얘기해본들 절대 단시간에 수정될 문제가 아니고, 버리면 안되는 데이터이기 때문에, 2초까지 기다렸다가 연결 끊고 실패 횟수를 기록했습니다.요청을 다음과 같이 설계함uid - 식별키group_id - 작업 그룹starttime - 최초 시작 시간endtime - 성공 또는 실패 시간job_type - 작업의 종류req_spec - 요청 보낼 때 필요한 정보payload - 작업 결과(job_type의 결과)cur_retry - 작업 완료까지 시도한 횟수max_retry - 최대 시도 횟수(5로 줬음)status - RDY, RUN, RTY, END그리고 데이터 처리 엔티티를 네 개로 나눕니다.1번은 주기적으로 요청을 전부 밀어넣음.2번은 타임아웃 2초짜리 요청 보내고 결과를 업데이트함.3번은 성공한 요청을 꺼내서 분류하고 처리함.4번은 재시도 초과한 요청을 꺼내서 json으로 결과 요약(차트 그리거나 pdf로 뽑을 때..)요즘은 통제 밖의 외부 시스템에서 데이터를 가져오는 경우가 아주 많고, 시간 초과 뿐만 아니라 데이터 검증같은 자잘한 작업을 쉽게 붙일 수 있어야 합니다.요청을 동기적으로 처리하는 게 제일 좋습니다.문제는 그게 안되는 상황을 자주 경험하니까 이벤트무시기 아키텍처같은게 나옵니다.

event driven architecture 적용하기에 앞서서 고민 사항.

3개의 답변

기술 목록