토스뱅크 밋업
코어뱅킹 시스템 기술스택 교체하기
asis 코어뱅킹 계정계 구조
문제점
- 토스뱅크 기술스택과 맞지 않음.
- devon을 쓰고 있어서 기술지원에 의존성 존재
- 기술역량이 있으니 오픈소스가 유리하다고 판단
- 기술스택이 다른 채널계와 계정계
- devops의 운영이 어려움
- SRE의 트러블 슈팅의 어려움. (SRE는 간단히 얘기하면 it 인프라 작업 자동화하는 역할)
- 한 개발자가 채널계와 계정계를 둘다 다루기 어려움
해결 방법
- 코어뱅킹 계정계 기술스택을 채널계와 동일하도록 변경하기.
- 쿠버네티스 사용, no MDD(차세대 devon의 코딩없이 짜는 방식), Spring 사용하기 3가지를 중점적으로 해결
진행한 순서
1.로깅 시스템 개선(사전작업)
문제여부를 파악하기 위해 가장 중요하다고 판단.
개선방안
ELK 스택에 로깅하기.
로그백 사용에서 키바나로 모든 로그 조회하도록 수정.
(FileAppender에서 KafkaAppender로 변경하여 ELK에 로깅 성공)
추가 발생 문제
kafka로 stacktrace를 로깅하면 쪼개져서 보기 불편한 문제 발생
해결 방법
logger를 이용하는 방식으로 전부 수정했다.
문제를 빠르게 판단하
https://toss.tech/article/slash23-corebanking
다이내믹 스크래핑과무한 반복되는 전월세 대출 이동제 실행
전월세 대출
: 금융기관에서 대출받는 상품
체크리스트 입력 받는다. 그이유는 가심사결과 산출을 위해.
서류 제출
운영 검토 및 처리
:서류,주택,목적물,소득,보증 신청 등등
운영 수기 프로세스
직업에 따라, 소득 구분에 따라 받아야할 서류가 다름. 여러 케이스가 있음.
일일이 확인하고 전화하기가 매우 비효율.
소득관련 여러 서류를 하나하나보고 산출하면 휴먼에러 발생 리스크 존재.
그래서 자동화
주택 수 스크래핑
추가제출 필요서류 판단.
소득 산출
1. 케이스 정의 및 구현 (40개가 넘는다..) + 테스트 코드(270가지 이상)
2. 토스뱅크에는 직장인 밖에 없는데, 다양한 케이스를 어떻게 테스트할 수있었을까?
다이내믹 스크래핑
누구나 사업자,프리랜서,기혼,등이 될 수 있어야 한다는게 골조
사업자가 아니어도 사업자로 테스트할 수 있게끔 테스트한다.
ex / 근로/ 사업 소득.
-> 요거는 우리 결제 케이스를 여러개 나누어 놓은 다음에 하면 참 편하겠다는 생각?
if else로 구현한다면?
유지보수 어렵고 코드가 길어질 수 있음.
-> composition & strategy 패턴 사용
새로운 케이스가 추가되어야 한다면 구현체만 추가하는 방식
자동 운영 프로세스
LUMOS(자체 어드민)
서류 확인화면
LMS/알림 어떤 고객에게 어떤 알림이 갔는지 확인 가능.
전월세대출 이동제 실행(대환)
실행일에 대출을 실행하는 것은 매우 민감하다.
여러가지 금액이 합쳐져있는 상원 총액의 이체가 처리되어야 함.
특정 단계 실패 가능성/ 롤백/재시도 전략 수립 필요
ex 상환 조회 실패
if else?
depth가 깊고 side-effect
방법은?
진행상태 나열.
전략, 상태 state 패턴, saga 패턴
오케스트레이터(LCI서버)
보류상태에 빠지면 배치로 주기적으로 확인.
기술적 노력
6개월 만에 전월세대출 출시
strangler fig 패턴을 활용한 게정계 배치 프로그램 전환기
종합정보지원 : 계정계데이터로 여러개의 배치를 돌려 부도, 담보 데이터들을 생성.
그걸 기반으로 은행 운영방향 의사결정.
이 계정계 배치를 왜 채널계로 옮겨와야 할까요??
1. 두개의 환경 스택이 다르다.
옮겨와야 하는이유
1수정이 잦으나 수정이 어려움.
2. 한파일을 여러명 동시수정 어려움 ㅠ
3. 로컬 어플 띄우기 어려워 디버깅 어려움
4. MDD는 외부 라이브러리 못붙여서 테스트 어려움.
2- 속도가 느려지고 있음.
1. 급격히 많아진 데이터.(고려하지 못한 코드들)
2. 리소스확장 어려움.(비 쿠버네티스)
3. 튜닝x 비효율적 쿼리
2023년 1월 기준 18분, 23분
1년후 57분, 60분. 2~3배 늘어남.
-> 이관하자.
엄청 얽혀있는 164개 배치를 어떻게 잘 옮김?
-> 해결 방법 Stranger Fig Pattern을 이용하자.
점진적 대체, 병행운영, 리다이렉션
선행, 후행배치로 되어있음.
선행이 성공해야 후행이 돌아감.
하나를 떼서 채널계로 이관.
서로 다른 환경에 있는 배치간 선후행 조건을 어떻게 연결함?
-> 방법은 Airflow를 이용해서 polling하고 컨디션 발행하는 기능 존재
배치를 이관할때마다 추가로 할일이 많음. 배치 하나당 관리포인트가 두곳(배치, 에어플로우 코드)이 되었음
-> 툴을 꼭 써야됨?이라는 생각이 듬.
-> 채널계 배치에서 게정계 배치관리 솔루션 API직접 호출
-> 이관할때 배치코드만 작성하면됨 배치하나당 관리 포인트 1개.
검증은 어떻게?
기존배치와 새로운 배치가 만든 데이터 일치여부 검증
고려사항은?
1. 검증용 테이블이 따로 있어야 함(기존 테이블과 일치하는 형상)
2. validator는 모든 배치에서 재활용할 수 있어야 한다.(특정 배치에서 specific하면 안됨. 검증에서 제외할 필드 커스텀이 가능해야함.)
3. validator가 검증 끝내기 전까지는 후행 배치가 실행되서는 안됨.(후행배치가 데이터를 못건들도록)
4. 검증결과가 실패라도 후행 배치는 실행되어야 한다.(후행배치가 마비되고 그 뒤에도 연쇄적 마비됨.)
배치 수행구조?
배포는?
이슈 생기면 빠른 대처를 위해 배포 전략 필요
새벽이라 빠른 대응 어려움
-> holding 해놓는 배치를 단계 추가. 에러 생겨서 후행배치가 펜딩되면 홀딩을 풀어서 정상동작 하도록 하는 방법.
성능향상?
1. 슬로우쿼리 개선
반복 서브쿼리 -> WITH 절
비효율적 GROUP BY -> 데이터 저장
(1500만개 데이터에 대해 아무조건없는 GROUP BY ㅠ)
-> 57분에서 4분
2. 리소스 효율화
순차 처리 -> 병렬처리( 도메인 특성)
굳이 사용할 필요 없는 배치 삽입(ex : 스냅 작업 ) -> 대량 삽입
전세대출에서 대외기관 신용정보를 조회하는 방법
온라인 웹서비스
여신계정계심사 프로세스 설명
약관 동의
금리와 한도를 볼 수있는 프로세스.
전세대출 MSA전환 프로세스
신용정보조회
고객의 신용정보 확인가능. 다른 금융기관 연체여부 확인 가능.
N개의 기관에 N개의 서비스 이용.
왜 변화가 필요할까?
1.불필요한 호출. 폴링과정. 80회까지 MCI호출. 대외기관에 타임아웃 발생시 오류거래 찾기가 어려웠음.
2.심사에 불필요한 데이터(1회성 자료)가 많이 적재되고 있었음. 한개의 DB에.
락경합 발생. 그래서 기관별 테이블 나눴음.
기존 토스뱅크 신용정보조회 프로세스 개선 이유
어떻게 낭비를 줄일 수 있을까?
-> 레디스를 활용.
데이터를 KV형태로 저장. 인메모리 저장 방식. 램에 데이터를 저장해서 빠르게 읽고씀. 캐싱전략. 싱글스레드
(락경합 방지 가능)
레디스활용응답처리
->레디스를 활용해서 응답처리.
->카프카를 통해 폴링 극복.
전세대출 심사 MSA개선 방식?
1회성을 레디스에 저장하도록.
카프카를 통해 event driven 방식.
MSA 전세대출 심사서버 독립적으로 뺌.
fep 솔루션 -> fep-gateway 개발.
MSA 적용하고 달라진점??
- 능동적 대응 가능
- 전세대출 상품 로직만 관리가능. MSA는 단일책임원칙을 중요시하므로.
- DB리소스 절약.(1회성 레디스 활용) 하루 20만건, 연간 약 7300만건 데이터리소스 절약.
-속도 개선( 4초-> 3.3초. 39시간을 하루에 절약할 수 있었음)
-누구나 계정계 개발 가능.(MSA로 되어서)
-계정계 이슈가 발생해도 장애전파가 되지 않는다.
모놀리식은 장애가 전체로 전파됨.
앞으로 토스뱅크 여신
모든 금리산출 MSA 마이그레이션
신용정보 서버 생김.
토스뱅크 내외부 위험 탐지 모델
내부 위험
-> 로그 탐지 모델
외부 위험
-> 부정 바이어 탐지 모델
목표
토스뱅크 위험 상황 자동캐치.
내부 위험탐지 모델
auto-Encoder
인풋데이터와 아웃풋 데이터간 비교를 통해서 위험 탐지
로그데이터 도 동일하게 적용.
Rule과의 차별점?
+ 이상 여부에 대한 라벨이 없어도 학습 가능.(vs 지도학습 모델)
- 시계열 데이터의 순자적 특징 반영가능
- 주기성 및 추세이외 복잡한 패턴도 잡아낼 수 있음.
데이터 파이프라인.
문제1 방대한 용량
학습한 데이터 한번에 메모리 올릴 수 없음
-> 조금씩 나누어서 학습
문제2 카테고리 피쳐
one-hot encoding 사용시
시간 많은 소요
incremental learning 적용 어려움..
변수별 중요도 달라짐.
-> Embedding Layer
문제3 - 배치성 거래
다 이상거래로 탐지되는 경우.
-> custom Loss 이용
문제4 - 데이터 미입수
-> 1분 단위 더미 데이터 이용
외부 위험 탐지
위험요소?
1. 급격히 증가하는 부정 바이럴
2. 서비스, 상품 오정보
3. 장애및 취약점 내용 확산
초기에 파악하는게 필요했음
커뮤니티 정보 주기 수집
-> 더짧은 10분 주기로 자체 수집
바이럴 관련, 긍부정 확인
-> LLM 기반 모델 활용
댓글, 조회수, 공감수 여론 파악
-> DB 적재된 바이럴은 주기적 재수집 및 추적(배치)
내용 잘 선별하여 관련팀으로 보내준다면?
-> 부정바이럴을 사내 메신저 토한 전파
망분리 이슈 존재.
연구개발망
chatGPT를 통한 정확한 판단이 포인트.
더 정확한 판단을 위해.
기본적인 프롬포트 구조 구성.
앙상블을 통해 모니터링 결과 안전성을 올림.
1개의 바이럴을 5회 해서 평균이나 최빈값 파악
그래도 못찾으면 few 프롬포트
서비스 비용률 신경
토스뱅크 소셜 모니터링 룰
부정 바이럴 포착 시간 60분 -> 10분 내외 단축.지속 추적
긍부정 정확도 증가, 및 기능 추가
ML을 끼얹은 토스뱅크의 신용모형/전략 시스템
CSS : 내부 신용 평점 시스템
BSS : 다시 한번 신용 모형 점수 산출.(행동평점시스템)
ASS : 신용 평점 시스템.
한도금리,
신용모형/전략 시스템 자체 구축이유
1. python 모델 호환성 어려움.
2. 복잡한 전략 구현 어려움.
-> 한번에 모든 상품의 심사결과를 노출한다.
3. 타시스템 연동 어려움
Clin
배포방법
Rolling 3번만
blue green 한방에 옮겨버림. 모든 전략이 신버전
카나리아 배포 : 신버전의 인스턴스를 조금씩 퍼센트 늘려나가는 것(굉장히 유용.)
심사시스템에서는 카나리배포는 부적절했다.
심사기준이 통일되어야 해서.
-> 그래서 선택한건 shadow deploy 방식을 이용했음.
장점 : 쉐도우에서 모든 검증을 끝낼 수 있다. 검증이 끝나면 라이브 트래픽을 한번에 쉐도우로 보냄
+ 캐시방식으로 해결
라이브에서만 발생할 수 있는 에러를 쉐-디플로이를 쓰면 잡아낼 수 있음.
출처
- 사이트, 검색명 (날짜)