안녕하세요 발표하신 내용 정말 재밌게 감상하고 궁금한 점이 있어 질문드립니다 14:50 초의 PDL 관련하여 궁금한 점이 있는데 트랜잭션 아웃박스 패턴 대신 어떤 장점 때문에 PDL 을 사용하셨을까요 ? 출금취소 메시지 발행 실패에 대하여 트랜잭션아웃박스 패턴으로 payload 자체를 환전DB 변경과 동일 트랜잭션으로 묶어 outbox table에 저장해두고 배치를 통해 발행하는 방식으로 하면 적어도 환전 서버-> Service Message Broker 로의 메시지 유실에 대한 걱정은 없을 거 같은데(배치 지연 시간은 DLQ 도 있을 거 같아 동일하다고 보았습니다) 제 개인적인 생각으로는 PDL 방법으로 하면 환전 서버 -> PDL Message Broker 로의 메시지 발행 실패(유실) 및 DLQ -> 환전 브로커(서비스) 로의 발행 실패(유실) 에 대한 고려도 해야할 거 같아서 더 복잡해 보였는데(물론 실패에 대한 수동 처리를 하면 되겠지만) 이 부분을 해결하기 위한 별도의 설정 및 방법이 있으셨을까요 ??
저도 발표를 들으며 같은 생각이 들었네요. PDL Produce 까지 실패하는 것이 흔한 케이스는 아니기 때문에 이런 케이스는 뒤에 설명해주신 모니터링으로 인지해서 직접 수동 운영으로 해결하시는건지 궁금합니다..! 정답은 없겠지만 아웃박스 패턴 통해서 아웃박스 테이블을 배치에서 읽어서 시도한다면 위와 같은 복잡도는 조금 줄일 수 있지 않나 생각이 들었네요. 마지막으로 좋은 발표 해주셔서 너무 감사합니다!
안녕하세요, 발표에 관심 가져주시고 질문해주셔서 감사합니다. Q. 내부적으로 메시징 발행 재처리가 DL 중심으로 잡혀 있는지? A. 예상하신대로 토스뱅크는 모든 토픽에 대하여 기본적으로 PDL이 적용되어 있습니다. 따라서 추가적인 아웃박스 패턴 등을 적용하지 않았습니다. Q. DL 서버에서 메시지 발행에 실패하면 어떻게 되는지? A. DL 서버의 PDL 메시지 처리도 컨슈머로 동작하므로, 발표에서 설명드린 CDL을 이용하여 재처리할 수 있습니다. Q. PDL이 아웃박스 패턴보다 나은 점 A. PDL/CDL은 플랫폼 팀에서 제공하고 있어 서비스 개발자 입장에서 느끼는 장점을 말씀드려 보자면, 모든 서비스에서 일괄 적용하기 쉽다는 장점이 있습니다. 아웃박스 패턴은 서비스 변경과 아웃박스 데이터 저장을 트랜잭션으로 묶어 처리해야 하므로, 서비스 DB 내에 아웃박스 테이블이 존재해야합니다. 토스뱅크에서는 수백개의 MSA 서버가 독립된 스키마(db)를 바라보고 있고, 이 스키마들은 수십개의 분리된 물리 서버 위에 그룹핑되어 존재합니다. 또, 사용하는 DB 역시 Oracle, MySQL, Mongo 등으로 다양합니다. 따라서 모든 MSA에 일괄적으로 아웃박스 패턴을 적용하려면, DB종류, 물리서버, 스키마마다 아웃박스 테이블들을 만들어줘야하고, 테이블에서 메시지를 발행하는 어플리케이션도 각각 작성해야 합니다. 반면 PDL은 모든 서버에서 동일한 메시지 브로커를 바라볼 수 있기 때문에, 라이브러리 형태로 제공되어 일괄 적용하는데 편리한 점이 있습니다. Q. PDL 메시지 브로커도 고가용성이 보장되는지, 그렇다면 불필요한 인프라 비용이 생기는 것은 아닌지? A. PDL 메시지 브로커로 서버에서 로그를 남길때 사용하는 로그 Kafka 클러스터를 사용하고 있습니다. 즉 고가용성을 위한 세팅이 적용되어 있으며 평상시에도 항상 사용하고 있기 때문에, PDL 메시지가 발행되지 않더라도 메시지 브로커에 문제가 생기면 그 즉시 알게 됩니다. 답변 내용이 도움이 되셨길 바랍니다!
안녕하세요. 토스입니다. 현장 상황으로 부분적으로 세션 녹음 음향 고르지 못한 점 양해 부탁드립니다.
좋은 영상 감사합니다. 공부가 부족함을 많이 느끼고 가네요.. 추후 지금 다루는 기술에 경험과 판단력이 쌓인다면 꼭 공부하고 싶은 내용인 것 같습니다. 감사합니다.
안녕하세요 발표하신 내용 정말 재밌게 감상하고 궁금한 점이 있어 질문드립니다 14:50 초의 PDL 관련하여 궁금한 점이 있는데 트랜잭션 아웃박스 패턴 대신 어떤 장점 때문에 PDL 을 사용하셨을까요 ?
출금취소 메시지 발행 실패에 대하여 트랜잭션아웃박스 패턴으로 payload 자체를 환전DB 변경과 동일 트랜잭션으로 묶어 outbox table에 저장해두고 배치를 통해 발행하는 방식으로 하면 적어도 환전 서버-> Service Message Broker 로의 메시지 유실에 대한 걱정은 없을 거 같은데(배치 지연 시간은 DLQ 도 있을 거 같아 동일하다고 보았습니다) 제 개인적인 생각으로는 PDL 방법으로 하면 환전 서버 -> PDL Message Broker 로의 메시지 발행 실패(유실) 및 DLQ -> 환전 브로커(서비스) 로의 발행 실패(유실) 에 대한 고려도 해야할 거 같아서 더 복잡해 보였는데(물론 실패에 대한 수동 처리를 하면 되겠지만) 이 부분을 해결하기 위한 별도의 설정 및 방법이 있으셨을까요 ??
저도 발표를 들으며 같은 생각이 들었네요. PDL Produce 까지 실패하는 것이 흔한 케이스는 아니기 때문에 이런 케이스는 뒤에 설명해주신 모니터링으로 인지해서 직접 수동 운영으로 해결하시는건지 궁금합니다..!
정답은 없겠지만 아웃박스 패턴 통해서 아웃박스 테이블을 배치에서 읽어서 시도한다면 위와 같은 복잡도는 조금 줄일 수 있지 않나 생각이 들었네요.
마지막으로 좋은 발표 해주셔서 너무 감사합니다!
공감합니다. 개인적인 생각이지만 아마 내부적으로 메시징 발행 재처리에 대한 표준이 DL 중심으로 잡혀 있는 것이 아닐까요.
저도 궁금하네요 ㅎㅎ
추가로 PDL Message Broker을 더 고가용성으로 구현했는지도 궁금하네요. 인프라 비용과 신뢰성이 트레이드 오프인 상황이다보니
궁금궁금
안녕하세요, 발표에 관심 가져주시고 질문해주셔서 감사합니다.
Q. 내부적으로 메시징 발행 재처리가 DL 중심으로 잡혀 있는지?
A. 예상하신대로 토스뱅크는 모든 토픽에 대하여 기본적으로 PDL이 적용되어 있습니다. 따라서 추가적인 아웃박스 패턴 등을 적용하지 않았습니다.
Q. DL 서버에서 메시지 발행에 실패하면 어떻게 되는지?
A. DL 서버의 PDL 메시지 처리도 컨슈머로 동작하므로, 발표에서 설명드린 CDL을 이용하여 재처리할 수 있습니다.
Q. PDL이 아웃박스 패턴보다 나은 점
A. PDL/CDL은 플랫폼 팀에서 제공하고 있어 서비스 개발자 입장에서 느끼는 장점을 말씀드려 보자면, 모든 서비스에서 일괄 적용하기 쉽다는 장점이 있습니다. 아웃박스 패턴은 서비스 변경과 아웃박스 데이터 저장을 트랜잭션으로 묶어 처리해야 하므로, 서비스 DB 내에 아웃박스 테이블이 존재해야합니다. 토스뱅크에서는 수백개의 MSA 서버가 독립된 스키마(db)를 바라보고 있고, 이 스키마들은 수십개의 분리된 물리 서버 위에 그룹핑되어 존재합니다. 또, 사용하는 DB 역시 Oracle, MySQL, Mongo 등으로 다양합니다. 따라서 모든 MSA에 일괄적으로 아웃박스 패턴을 적용하려면, DB종류, 물리서버, 스키마마다 아웃박스 테이블들을 만들어줘야하고, 테이블에서 메시지를 발행하는 어플리케이션도 각각 작성해야 합니다. 반면 PDL은 모든 서버에서 동일한 메시지 브로커를 바라볼 수 있기 때문에, 라이브러리 형태로 제공되어 일괄 적용하는데 편리한 점이 있습니다.
Q. PDL 메시지 브로커도 고가용성이 보장되는지, 그렇다면 불필요한 인프라 비용이 생기는 것은 아닌지?
A. PDL 메시지 브로커로 서버에서 로그를 남길때 사용하는 로그 Kafka 클러스터를 사용하고 있습니다. 즉 고가용성을 위한 세팅이 적용되어 있으며 평상시에도 항상 사용하고 있기 때문에, PDL 메시지가 발행되지 않더라도 메시지 브로커에 문제가 생기면 그 즉시 알게 됩니다.
답변 내용이 도움이 되셨길 바랍니다!
너무 잘 생겼어요...
안녕하세요! 평소 토스 재밌게 시청 중인 구독자입니다. 농인들을 위해 자막을 제공하는 게 어떨까요? 감사합니다~