토스가 마이데이터 과부하를 해결한 방법

핀테크 서비스를 쓴다면, 아니 토스를 쓴다면 대체로 마이데이터 서비스를 이용하고 있다. 마이데이터는 흩어진 사용자의 신용정보를 한 곳에 모아놓은 것을 말한다. 토스 홈 화면에 있는 소비내역, 금융자산, 계좌잔액, 거래내역, 신용점수 올리기, 대출 등의 서비스도 마이데이터를 이용한 경우다.

마이데이터 활용 서비스가 점점 늘어나면서 핀테크 서버에 들어오는 트래픽 양도 늘어나고 있다. 토스의 경우 지금까지 마이데이터로 인해 7만 트랜잭션처리시스템(TPS)이 발생했다. 이렇게 많은 부하가 생길 경우 장애가 생길 수 있어 대응은 필수적이다.

신윤재 토스 서버 엔지니어는 지난 12일 삼성동 코엑스 그랜드볼룸에서 열린 토스의 개발자 컨퍼런스 ‘슬래시24’에서 대규모 사용자 기반의 마이데이터 서비스를 안정적으로 운영하는 방안을 소개했다.

현재 토스뱅크는 마이데이터 서비스를 위해 은행, 카드, 증권, 보험 등 7개 업권과 애플리케이션프로그래밍인터페이스(API)를 주고 받고 있다. 이렇게 많은 곳과 API를 주고 받을 경우 장애가 발생할 수 있으며, 나아가 다른 서비스에 안 좋은 영향을 미칠 수 있다.

은행에서 사용자의 계좌잔액 API를 불러오기 위해선 여러 번의 인증 과정과 자산 정보를 가져와야 한다. 이때 API를 불러오는 소요 시간은 제공기관의 응답 속도에 따라 달라진다. 현재 마이데이터의 공식스펙에 따라, 이 시간이 20초로 규정되어 있지만, 여러 API를 순차적으로 호출해야 하는 만큼, 마이데이터 서버 응답 시간이 점차 늘어나는 경향을 보이고 있다.

예를 들어, 사용자가 자산 등록 요청을 하면, 인증기관은 사용자가 실제로 인증을 했는지 여부를 확인한다. 확인이 되면 자산 정보를 가져오기 위한 토큰 발급이 요청되고, 이를 통해 자산 목록을 가져오고, 또 다시 잔액, 거래내역 등의 상세정보를 가져 온다. 이때 토큰 발급에 28초, 자산 목록 불러오기까지 25초, 상세정보를 가져오는데 24초가 걸린다고 가정하면, 총 77초라는 시간이 소요된다.

신 엔지니어는 “1분이 넘는 시간을 기다리는 유저는 사실상 없다”며 “다만, 늦은 응답이라도 오는 것이 중요하다”고 강조했다. 이어 “당장 성공화면을 볼 수 없지만 사용자가 화면을 이탈하더라도 API 연결에 성공에 이후 사용자가 토스 앱에 들어오면 연결된 자산을 확인할 수 있다”고 덧붙였다.

그러나 이때 토스 입장에선 인프라 점유 시간이 길어지는 문제가 생긴다. 이때 필요한 네트워크 홉은 토스의 다른 서비스들이 공용으로 사용하는 리소스로, 토스의 트래픽에 문제가 생길 수 있다. 특히 마이데이터 서버는 다른 서버에 비해 트래픽이 많은 편이다. 문제를 해결하기 위한 방안 중 하나로, 토스는 클라이언트와 서버를 연결하고 실시간으로 통신이 가능하도록 하는 ‘웹소켓(Websocket)’ 기술을 선택했다.

신 엔지니어는 웹소켓 방식에 대해 “대용량 트래픽이 발생하는 서버에 잦은 폴링(일정 주기로 서버와 응답을 주고 받는 방식)으로 부하를 주기보다 효율적”이라고 설명했다.

신 엔지니어는 기존 시스템에 웹소켓을 적용한 사례를 소개했다. 토스는 자산 등록 요청이 들어오면 API를 얼리리턴(조건과 맞지 않는 결과를 일찍 반환하는 일)한 뒤, 공용 리소스를 즉시 해제했다. 이때 클라이언트는 웹소켓으로부터 서버의 푸시를 기다린다.

토스는 비동기적으로 자산 등록 과정을 처리하고, 완료된 기관이 생길 때마다 푸시를 한다. 최종적으로 모든 기관의 자산 등록이 완료될 때 클라이언트가 한 번에 알게 된다. 그 결과, 기존에 3300ms 걸리던 시간을 56배 개선한 58ms로 단축할 수 있었다는 것이 토스의 설명이다.

아울러, 토스는 일주일 동안 발생하는 API 호출을 균일하게 했다. 주로 월급날이나 증권 거래가 많은 시간대 등 사용자 호출이 많은 날은 배치 호출 수를 낮췄다. 반대로, 사용자 호출이 적은 날은 배치 호출의 수를 늘렸다. 이렇게 되면 일주일 간 발생하는 호출 총량은 같지만, 특정일에 과도한 호출이 발생하지 않도록 해 장애를 방지할 수 있다는 것이 토스 측의 설명이다.

신 엔지니어는 “일주일 간 발생하는 배치 호출을 균일하게 나눠 제공기관의 동시 처리 수를 최소화했다”며 “이를 통해 장애 발생 가능성을 낮추고, 시스템 안정성을 높일 수 있었다”고 밝혔다.

글. 바이라인네트워크

<홍하나 기자>0626hhn@byline.network