마이크로서비스아키텍쳐환경에서 개발하다보면.. 데이터정합성 어디까지 생각해야할까.. 고민하게 된다. 내지는 하나의 긴 트랜잭션을 들고 있는 경우에 정합성은 보장하지만 .. 이.. 넘나 긴 작업이 리소스를 다 잡아 먹기도 한다.
하나의 겁내 긴 트랜잭션 대신 선택할수있는 방법은 2phase commit방식을 쓰는것
- 트랜잭션완료 > 커밋 성공! .. 실패하면 롤백
- begin / commit / rollback
근데 나는.. 보통의 환경에서 오토커밋을 썼고,, nosql의 경우 없기도 한 프로코콜이다.
마틴파울러아저씨 이벤트드리븐아키텍쳐. 우선 키워드는
- 이벤트를 저장하는 것이 단일 연산이라 본질적으로 어토믹하다
- 이벤트 발행자체만 보장하는거지..
- 비지니스적 객체의 상태의 변화를 저장하고 > 변경되면 새 이벤트를 이벤트관리테이블에 추가
- 실패하면 이벤트관리테이블에 있는 최신=마지막 상태와 비교해서 다시 재처리
- 이벤트의 처리 상황을 저장하고 있고, 알수 있기 때문에 트래이스가 가능하다
- 실패한 이벤트의 경우, 한곳에 저장하면 실패한잡에 대한 트레이스도 쉬울거 같다.
그래서? 나는 선착순이벤트에 내가 이해한대로 한번 적용해봤다. 왜냐고 하면.. 이유는 아래와 같다.
당첨조건을 달성하면 > 축하푸쉬, 축하글작성, 이메일발송, 문자발송 , 채팅메시지전송 =축하작업들
- 이외 당춤축하관련 작업들이 늘어나게 되면? 전체흐름이 길어진다.
- 지금도 5가지나 되는 축하과정중 실패 처리는? 재처리 유무는?
이외 당첨 축하관련 작업들이 늘어나게 되면.. 비지니스 로직이 늘어남에 따라 전체 성공에 대한 흐름은 길어지겠지.. 이중에 하나가 실패하면 어쩔건지에 대한 로직도.. 마찬가지가 될거다....
여튼. 뚝 떼서.. 이벤트당첨의 축하작업들을 분리한다.
나는 이를 trigger_job 이라 칭하고, 각 job마다 번호를 매긴다.
문자발송:1
이멜발송:10
카톡같은 채팅전송 : 100
푸쉬
글작성
이벤트달성조건을 충족하게 되면, 이벤트관리테이블에 저장한다. 바우처코드값 전달+축하작업들을 위해 trigger_job에 진행해야 하는 값을 저장한다. 나의경우 111 = 문자발송 + 이멜발송 + 채팅전송 저장한다. 그리고 큐에 넣는다. (나의 경우 kestrel큐를 씀)
워커는 트리거잡이 0이 되면 된다. 각 작업수행이 성공하면 전체성공값 == 전체처리해야할값 111 을 다 성공하게 되면 각 job번호를 리턴해 뺴주면~ 최종적으로 0을 만들어 주면 된다.
- 결제의 과정처럼 주문>결제>배송>취소 등등의 과정이 복잡하지 않기 때문에
- 각 과정이 일련의 과정이 아니기 때문에
- job들이 독립적이기 때문에
- 실패한경우에 대한 처리나 모니터링도 trigger_job의 남아있는 값만 보면 알수있다.
- 실패한경우에 대한 테이블을 따로 둘까 고민하다.. trigger_job을 모니터링하는걸로..
적합한 사례였는지 모르겠지만. 위 작업을 개발함에 있어 이벤트드리븐아키텍쳐를 떠올린건
- 축하과정이 더 늘어나면?
- 각 과정에 실패된경우
- 어떤 job이 성공했고 실패했는지에 대한 기록은? = 트레이스
- 재처리는?
- 재처리 안해도 되는 잡은 어떻게?
event driven !!... 이벤트드리븐아키텍쳐에서 이벤트의 처리상황이 가장 중요한 정보다...
그래야 이벤트의 전달상황을 확인하고 조치할수 있으니까. 적어도 어떤 잡이 주로 실패 되는지..
이는 설계방식이고 큐는 그 중간에 필요한 도구.. 그냥.. 도구일뿐... 메시지큐 말고 뭘 떠올릴수 있는지는 생각안해봤다..
여튼.. 재밌었다. ㅋㅋㅋㅋㅋㅋ