예를들어
사용자가 문서업로드하는 기능에서
Kt공인저장소 업로드하고
어마존 S3버킷업로드하고
네이버 객체스토리지 저장소 업로드한 다음
각 url이랑 정보 db에 저장한다고하면
Kt 성공 s3성공 , 네이버 실패
이러면 네이버 재시도한다음 그 마저도 탈락이면
업로드 성공한것들 다 삭제해야함?
외부 api많아지면 싹다 중간에 실패시 예외처리
사가로 돌려버려야하나?
사용자가 문서업로드하는 기능에서
Kt공인저장소 업로드하고
어마존 S3버킷업로드하고
네이버 객체스토리지 저장소 업로드한 다음
각 url이랑 정보 db에 저장한다고하면
Kt 성공 s3성공 , 네이버 실패
이러면 네이버 재시도한다음 그 마저도 탈락이면
업로드 성공한것들 다 삭제해야함?
외부 api많아지면 싹다 중간에 실패시 예외처리
사가로 돌려버려야하나?
https://youtu.be/xpwRTu47fqY?si=flcSHuGMsdc4S_ll
여기
좋은거 있다 - dc App
어 이거 면접때ㅋㅋ.. - dc App
따끈따끈한거네 굿
ㅇㅇ 복구해야지 그래서 외부 API 너무 많아지면 복잡도 높아지니까 event-driven으로 복잡도 낮출수도 있긴 함 아니면 Saga보다 2PC 쓰는게 쉬울수도 있음
Saga는 기본 난이도가 좀 있어서
실시간 아니면 이벤트 드리븐으로 하는게 편하긴 하지 - dc App
사가로 취소하는데 취소 요청마저 네트워크 에러로 실패할 가능성도있으니까 메세지브로커로 정합성 보장하고.. 메세지 브로커의 요청자체도 네트워킹에러였으면 실패할 가능성도 존재하니 배치로 이전상태 기록한뒤에 계속보내주는데 만약 메세지브로커 자체도 죽어버리면 PDL로 PDL메세지브로커와 다른 동작중인 DL서버로 취소 로직 위임해야하는거임?
Api하나 실패해서 보장해야하는게 개많네 그냥 몇번 재시도하다 슬랙으로 메세지 보내면 좋을텐데 너무 공수가 많이들어가는거아닌가 싶음
2pc로 구현하셈 그래서 진짜 중요하고 속도면에서 급한거 아니면 saga못쓸것같음 주니어기준 사가는 .. - dc App
시스템적으로 정합성 보장하려면 어쩔 수 없음 Retry, 2PC, Outbox pattern 같은거로 풀어야함 결국. 근데 단일 서버면 이벤트 발행하고 싶으면 굳이 kafka 같은거 쓰지 말고 application event 정도만 써도 되고 아니면 너가 말한대로 관리자가 직접 조치해도 됨. 트래픽 적으면 충분히 가능한 얘기임
근데 2PC자체도 트랜잭션 준비완료후 커밋과정에서 성공적인 전달을 완벽히 보장하진않잖음 그럴경우 어차피 메세지브로커로 위임하던 보상 트랜잭션을 통해 정합성을 보장해야할것같은데
감사함니당
어째서 2pc가 정합성을 보장안하는거에요? 결국 prepare 교환등 lock으로 완벽보장하는 개념아니에요? - dc App
ㄴ Prepare 단계에서 락이 걸려 있더라도, 트랜잭션이 커밋되거나 롤백되기 전까지는 트랜잭션이 완료되지 않은 상태고. 이 말은 락이 걸려 있다고 하더라도 네트워크 장애, 시스템 장애, Coordinator의 장애 등 외부 요인에 의해 트랜잭션이 정상적으로 종료되지 못할 가능성있잖음
대부분 2pc등 TTL을 걸어서 블로킹상태는 안걸리지않음? - dc App
정상종료되지 않으면 결국 lock상태겠지만 ttl로대부분 수습가능하지않나? - dc App
콜이 적으면 outbox 사용 콜 많으면 DB가 병목이라 API가 메세지만 던지고, 동시에 메세지가 멱등성이 있으면 됨
외부 서비스가 버전락이나 트랜잭션 지원 안하면 글로벌 락 걸고 락스텝 쓰는게 최선임