영상 잘 봤습니다. 두 가지 질문이 있는데요. 하나는 타은행 (eg. 카뱅)에 의해 대외기관 트래픽이 몰리면서 토뱅에게 할당 가능한 캐파가 줄어드는 경우에 대한 추가 대처가 필요한지, 가능한지요? 또 대기열을 만드는 것 같은 대응을 넘어 근본적으로 몰려드는 트래픽을 분산시킬 방법도 고민해 보셨을 것 같은데요 (eg. 대출 재개 첫날엔 전체 pot 중 일부만 사용하되, 대출금리를 다음날 대비 0.1%p 높게 해줘서 소비자들이 자기선택을 하게 한다든지..) 어떤 비지니스/기술적 옵션들이 있으셨는지 궁금합니다.
안녕하세요! 질문 남겨주셔서 감사합니다. 1. 대외기관에 문제가 발생했을 때는 가변적인 thread-pool을 이용해 줄어든 캐파에 맞게 조정을 진행합니다. 그런데 해당 대외기관에 허용가능한 tps를 줄이기만 하면 고객의 심사 대기는 지속해서 증가하므로 대체할 수 있는 대외기관으로 확률적으로 고객을 우회시킵니다. (half_open) 만약 대체할 수 있는 대외기관이 아니라면 심사 대기열의 상태에 따라서 (심사결과를 받기까지 N분이상 지연 및 실패율 N% 이상 증가) 전체 대기열이 동작하게 됩니다. 2. 기술적으로는 대기열과 동일하지만 실제로 고객이 느끼는 경험은 다른 온라인 쇼핑몰이나 게임사이트의 대기열과는 조금 다릅니다. 대기열에 걸리게 되면 바로 대기열에 진입하고 실시간으로 심사를 받을 수 있는 순번이 되었을 때 고객에게 푸시를 보내서 입장권을 발급하는 방식으로 진행됩니다. 그래서 고객은 입장 되기까지 화면을 보면서 기다리는 것은 아니고 푸시를 받은 순간부터 심사와 실행이 할 수 있기 때문에 트래픽 분산에 효율적이라고 생각했습니다. 혹시 더 궁금하신점이 있다면 언제든지 알려주세요!
@@bank7121 답변 감사합니다. 1. 네, 이 부분은 영상에서 충분히 설명해 주셔서 이해가 바로 됩니다. 단, 제가 궁금한건 결국 대외기관이 토스 외에도 타 은행들이 함께 이용하는 경우 (만약 전용 파이프라인이 있다면 죄송) 타 은행의 작업요청량에 따라 토스의 가용량이 달라질 수 있지 않는지, 그 부분은 어떻게 대응하고 계신지였습니다. 즉, 경쟁사가 트래픽 다 잡아먹으면 어찌되는지.. 2. 이것도 대기의 경험을 개선하시고 하는 부분보다는 대기 자체를 없앨 수 있는 보다 앞단에서의 문제 해결 시도가 있었는지? 그땐 어떤 roadblock이 있었는지 였습니다. ㅎㅎ
@@jwvirus 추가 질문 감사합니다! 1. 대외기관이 연동된 회사에 qos를 제공하기 위해서 노력하고 있는 것으로 알고 있습니다. 영상에 나오는 주요 대외기관과는 전용선으로 연동해서 사용하고 있습니다. 경쟁사가 트래픽을 100% 잡아먹게 되는 상황을 확정할 수는 없습니다만 대외기관이 일정량의 트래픽을 보장할 수 있도록 요청하고 있으며 만약의 사태에 대비해 영상에서 설명해 드린 방식으로 대응하고 있습니다. 2. 상품을 오픈할 때 대기 자체를 줄이기 위해서 segment 단위로 고객군을 나눠서 오픈하거나 사전 신청을 받아 오픈하게 됩니다. 대기열이 생기는 경험은 최대한 지양하려고 노력하고 있습니다. 다만 대출 상품 같은 경우 예측하기 어려운 외부 이벤트 요소들이 많아 내부적으로는 영상에 설명해 드린 방식으로 기술적으로 준비해두고 있다고 봐주시면 감사하겠습니다.
안녕하세요 취직준비하는 신입 개발자입니다. 영상 중 궁금한 점이 있어 댓글답니다. monolithic으로 구성된 서버는 신규 피처 개발에 따른 영향도 분석에 많은 시간을 소요하게 되며, 신규 피처는 코어뱅킹 시스템 내에 새로운 영향도 분석의 대상이 되는 악숙환의 구조를 가지게 된다. 라는 대목이 경험과 지식이 적어 잘 상상이 가지 않았습니다. 신규 기능이나 기존 기능의 수정 정도는 테스트코드로 정상적으로 돌아가는가를 확인해볼 수 있을 것 같다고 생각했습니다. 그래서 영향도를 분석하는 이유가 조금 궁금했습니다. 또한 스키마의 수정이 어느정도 빈번하게 발생하는지, 그 규모가 어느정돈지 힌트라도 듣고 싶었습니다. 스키마가 변하면 관련 코드들이 전부 영향을 받아 실제 코드뿐만 아니라 테스트코드들도 전부 수정이 필요할 수도 있을 것 같은데, 이런 문제를 어떻게 해결하는지 조금 듣고 싶었습니다. 질문 읽어주셔서 감사합니다. 영상 너무 잘봤습니다. 멋있어요. 행복하세요.
감사합니다.
설명 진짜 깔끔하게 잘하시네요. 역시 토스인가
영상 잘 봤습니다. 두 가지 질문이 있는데요. 하나는 타은행 (eg. 카뱅)에 의해 대외기관 트래픽이 몰리면서 토뱅에게 할당 가능한 캐파가 줄어드는 경우에 대한 추가 대처가 필요한지, 가능한지요? 또 대기열을 만드는 것 같은 대응을 넘어 근본적으로 몰려드는 트래픽을 분산시킬 방법도 고민해 보셨을 것 같은데요 (eg. 대출 재개 첫날엔 전체 pot 중 일부만 사용하되, 대출금리를 다음날 대비 0.1%p 높게 해줘서 소비자들이 자기선택을 하게 한다든지..) 어떤 비지니스/기술적 옵션들이 있으셨는지 궁금합니다.
안녕하세요! 질문 남겨주셔서 감사합니다.
1. 대외기관에 문제가 발생했을 때는 가변적인 thread-pool을 이용해 줄어든 캐파에 맞게 조정을 진행합니다. 그런데 해당 대외기관에 허용가능한 tps를 줄이기만 하면 고객의 심사 대기는 지속해서 증가하므로 대체할 수 있는 대외기관으로 확률적으로 고객을 우회시킵니다. (half_open) 만약 대체할 수 있는 대외기관이 아니라면 심사 대기열의 상태에 따라서 (심사결과를 받기까지 N분이상 지연 및 실패율 N% 이상 증가) 전체 대기열이 동작하게 됩니다.
2. 기술적으로는 대기열과 동일하지만 실제로 고객이 느끼는 경험은 다른 온라인 쇼핑몰이나 게임사이트의 대기열과는 조금 다릅니다. 대기열에 걸리게 되면 바로 대기열에 진입하고 실시간으로 심사를 받을 수 있는 순번이 되었을 때 고객에게 푸시를 보내서 입장권을 발급하는 방식으로 진행됩니다. 그래서 고객은 입장 되기까지 화면을 보면서 기다리는 것은 아니고 푸시를 받은 순간부터 심사와 실행이 할 수 있기 때문에 트래픽 분산에 효율적이라고 생각했습니다.
혹시 더 궁금하신점이 있다면 언제든지 알려주세요!
@@bank7121 답변 감사합니다.
1. 네, 이 부분은 영상에서 충분히 설명해 주셔서 이해가 바로 됩니다. 단, 제가 궁금한건 결국 대외기관이 토스 외에도 타 은행들이 함께 이용하는 경우 (만약 전용 파이프라인이 있다면 죄송) 타 은행의 작업요청량에 따라 토스의 가용량이 달라질 수 있지 않는지, 그 부분은 어떻게 대응하고 계신지였습니다. 즉, 경쟁사가 트래픽 다 잡아먹으면 어찌되는지..
2. 이것도 대기의 경험을 개선하시고 하는 부분보다는 대기 자체를 없앨 수 있는 보다 앞단에서의 문제 해결 시도가 있었는지? 그땐 어떤 roadblock이 있었는지 였습니다. ㅎㅎ
@@jwvirus
추가 질문 감사합니다!
1. 대외기관이 연동된 회사에 qos를 제공하기 위해서 노력하고 있는 것으로 알고 있습니다. 영상에 나오는 주요 대외기관과는 전용선으로 연동해서 사용하고 있습니다. 경쟁사가 트래픽을 100% 잡아먹게 되는 상황을 확정할 수는 없습니다만 대외기관이 일정량의 트래픽을 보장할 수 있도록 요청하고 있으며 만약의 사태에 대비해 영상에서 설명해 드린 방식으로 대응하고 있습니다.
2. 상품을 오픈할 때 대기 자체를 줄이기 위해서 segment 단위로 고객군을 나눠서 오픈하거나 사전 신청을 받아 오픈하게 됩니다. 대기열이 생기는 경험은 최대한 지양하려고 노력하고 있습니다. 다만 대출 상품 같은 경우 예측하기 어려운 외부 이벤트 요소들이 많아 내부적으로는 영상에 설명해 드린 방식으로 기술적으로 준비해두고 있다고 봐주시면 감사하겠습니다.
@@bank7121 와 정말 친절한 답변 감사드립니다. 많이 배웠습니다!
안녕하세요 취직준비하는 신입 개발자입니다.
영상 중 궁금한 점이 있어 댓글답니다.
monolithic으로 구성된 서버는 신규 피처 개발에 따른 영향도 분석에 많은 시간을 소요하게 되며, 신규 피처는 코어뱅킹 시스템 내에 새로운 영향도 분석의 대상이 되는 악숙환의 구조를 가지게 된다.
라는 대목이 경험과 지식이 적어 잘 상상이 가지 않았습니다.
신규 기능이나 기존 기능의 수정 정도는 테스트코드로 정상적으로 돌아가는가를 확인해볼 수 있을 것 같다고 생각했습니다.
그래서 영향도를 분석하는 이유가 조금 궁금했습니다.
또한 스키마의 수정이 어느정도 빈번하게 발생하는지, 그 규모가 어느정돈지 힌트라도 듣고 싶었습니다.
스키마가 변하면 관련 코드들이 전부 영향을 받아 실제 코드뿐만 아니라 테스트코드들도 전부 수정이 필요할 수도 있을 것 같은데, 이런 문제를 어떻게 해결하는지 조금 듣고 싶었습니다.
질문 읽어주셔서 감사합니다.
영상 너무 잘봤습니다. 멋있어요.
행복하세요.