케이뱅크 이상거래탐지시스템 Singlestore DB 도입기

0. 들어가며

안녕하세요! 

보이스피싱, 해킹, 명의도용 등의 금융사기로부터 고객의 자산을 보호하기 위한 이상거래탐지 기술을 개발하고 운영하는 업무를 맡고 있는 데이터서비스팀 강은창입니다.

 

이번에 운영하는 시스템 중 하나인 '전기통신사기 의심계좌 모니터링 시스템'의 DBMS 교체를 추진하며 검토되었던 내용을 공유드리려고 합니다. 결론적으로는 Singlestore(구. memSQL)을 선정하여 도입하게 되었고, 해당 DB에 대해 관심이 있으신 분들을 위해 글을 작성하였습니다.

 

목차는 아래와 같습니다.

1. 시스템 소개

2. DB교체 배경

3. BMT 결과

4. 마무리

 

글 시작하도록 하겠습니다.

 

1. 시스템 소개

먼저, DB를 교체하려는 대상 시스템에 대해서 간단하게 소개드리겠습니다.

케이뱅크에서는 AMS(Anomaly Account Monitoring System)라는 이름의 전기통신사기 모니터링 시스템을 운영하고 있습니다.

통상적으로 '전기통신사기 FDS'라고 불리기도 하며, 전기통신사기 특별법(아래 링크)를 근거로 고객의 자산을 보이스피싱 등의 금융사기로부터 보호하기 위해 은행에서 필수적으로 구축하고 운영하는 시스템입니다.

 

링크: '전기통신금융사기 피해 방지 및 피해금 환급에 관한 특별법'
https://www.law.go.kr/lsInfoP.do?lsiSeq=218055&efYd=20201120#0000

전기통신금융사기 피해 방지 및 피해금 환급에 관한 특별법 | 국가법령정보센터 | 법령 > 본문

 

AMS 업무는 크게 아래의 3단계로 나눌 수 있습니다.

1) 수집 : 케이뱅크 발생하는 거래내역(스마트뱅킹, 입출금 및 ATM 거래내역 등)을 실시간으로 수집

2) 탐지 : 수집된 거래는 실시간으로 이상거래여부 탐지 -> 이상거래가 발생한 계좌는 즉시 입출금 정지

3) 분석 : 수집된 데이터들을 분석하여 이상거래 탐지룰 개발 및 배치 모니터링

 

아래는 업무 흐름도인데, 위 3단계의 업무를 아래와 같이 두개의 서버로 나누어 처리하고 있습니다.

 

AMS 업무 흐름도

각 서버는 아래와 같이 별도의 DB를 사용하고 있습니다.

 

 1) 탐지서버 : 실시간으로 초당 평균 200건(peak 2,000TPS)의 거래를 수집하고(Insert),

수집 된 각 거래는 당행이 운영하는 n개의 이상거래 탐지 룰에 맞는 거래인지 조회하는 쿼리를 수행(Select).
빠른 조회속도를 위해 인메모리DB를 사용하고 있으나, 저장용량 한계로 일정시간 지난 Data는 분석 서버 DB로 이관.

 

 2) 분석서버 : 이상거래 탐지에 필요한 feature 생성 및 거래내역을 분석하는 업무 수행.
현재까지 수집 된 xxx억 건의 Data에 대한 집계성 쿼리(배치)를 처리해야하는 업무를 주로 수행하며, 
탐지 서버의 인메모리DB의 저장용량한계를 보완하기위해 MariaDB를 도입하여 사용하고 있습니다.

 

2. DB교체 배경

크게 아래와 같은 사유로 해당 시스템의 DB교체에 대해서 검토를 시작하게 되었습니다.

  1) 동일한 데이터를 두 개의 DB를 통해 처리하며 관리적, 성능적 비용 발생
  2) 30분 이상 걸리는 Recovery time

 

여러 DB들을 검토하며, Singlestore라는 제품이 메모리와 디스크를 모두 사용할 수 있다는 점을 알게 되었고,

현재 우리가 추진하려는 인메모리DB와 MariaDB의 통합개선과 컨셉이 일치하여 기술검토를 진행 후
성능과 안정성을 검증하기 위한 BMT를 수행하였습니다.

 

3. BMT

BMT는 2022년 11월 진행되었으며, 3개의 DB제품에 대한 비교테스트로 진행 하였습니다.

(BMT : Bench Marking Test, 비교 대상 시스템을 표준적인 벤치마크 프로그램을 수행시켜 성능을 측정하는 것. 컴퓨터의 속도나 단위 시간당 일 처리량 등 수행속도를 비교하는 검사) 

  1) BMT 대상 
   당행표준 DB중 2종과 Singlestore, 총 3개의 DB 선정 
   - PostgreSQL
   - MySQL

   - Singlestore
  
  2) BMT 방안
   가. 테스트 방법
       - 부하1 : 데이터소스 -> Kafka-> DB
       - 부하2 : 데이터소스 -> JDBC -> DB 
       - 고가용성 : 데이터 부하 중 H/W, S/W 강제 Down
   
   나. 주요 테스트 항목
      - 최대처리 TPS
      - 집계쿼리 속도
      - 시스템 워크로드
      - 장애발생시 고가용성 및 Recovery time

   다. 참고사항
     - 테스트에 사용된 방법은 AMS 시스템에 특화되어 있기때문에 블로그에는 결과값을 추상화 하였습니다.
     - PostgreSQL과 MySQL은 당행 표준방식으로 인프라팀에서 구성하였으나, Singlestore는 사용경험이 없기 때문에 총판사에서 구성에 참여하였습니다. 따라서 Singlestore에 유리한 결과가 나올 수 있습니다.

  3) BMT 결과

BMT요약표

1) MySQL과 PostgreSQL는 널리 쓰이고 있는 DB인 만큼 전체적으로 준수한 성능을 보여주었으나, Singlestore는 인메모리(rowstore)지원으로 인한 결과인지 2~3배 이상 우수한 수치를 보여주었습니다.

2) Kafka를 이용한 부하테스트에서 Singlestore는 Kafkaconnect에 이슈가 있어서 전용 플러그인(Singlestore Pipeline)을 사용하였습니다.

3) 고가용성은 모든 DB가 좋은 결과를 보였는데, 특히 싱글스토어는 수 초내에 Recovery가 완료되는 점이 인상적이였습니다.

4) Singlestore는 데이터를 압축하여 저장할 수 있는데(속도와 trade-off 발생하는 것으로 보임), MariaDB 대비 최대 8배 정도 압축율을 확인하였습니다. 오래된 거래내역은 자주 사용되지 않기 때문에 이부분은 큰 장점으로 보여졌습니다.

 

5) Singlestore의 경우 MySQL 문법과 호환되지만, 서브쿼리 등 쿼리 제한사항이 있는 것이 확인되었습니다. 이부분은 향후 개선될수 있다고 하였지만, 마이그레이션 시 쿼리 수정이 필요할 것으로 보입니다.

 

4. 결론/요약

 1) 현재 인메모리DB와 디스크DB를 두 개 사용하고 있는 AMS시스템의 DB 통합 개선을 추진.
 2) Singlestore의 아키텍처가 우리의 개선방향과 일치.
 3) BMT를 수행해보니 일부 제약사항등이 확인되었으나, 뛰어난 성능과 Sharding지원에 대한 장점으로 AMS 교체 대상 DB로 선정.
 4) Singlestore를 도입하여 아래와 같이 아키텍처 변경.

 

AS-IS / TO-BE

5. 맺음말

인메모리DB와 디스크DB의 통합을 추진하며 처음에는 MySQL/PostgreSQL + Redis 등의 조합을 검토하였습니다. 그러던 중 Singlestore를 검토해보고 이름처럼 한 제품만으로 통합이 가능하다는 것을 알게되었습니다. BMT를 수행하며 일부 단점과 제약사항도 확인되었지만, AMS시스템에는 장점이 더 많은 제품라고 판단되어 도입을 결정하게 되었습니다. 실제 운영에서도 좋은 성능을 발휘하기를 기대하고 있으며, 기회가 되면 운영 후기도 공유드리도록 하겠습니다.

감사합니다.

 

 

케이뱅크와 함께 하고 싶다면 🚀