#1 타행 이체 기능 성능 개선기, 프로젝트 소개

---

목차

1. 프로젝트 소개

2. 프로젝트 개선 그래프

3. 트래픽의 개략적인 측정

4. 서버 인프라 구성

5. 문서화

---

✍️ 프로젝트 소개

 카카오 뱅크, 토스 뱅크, 케이 뱅크 등 은행 도메인의 돈통을 구현하는 프로젝트 입니다. 은행에서는 이자 적립, 예약 이체 등 여러 기능들이 있지만, 현 프로젝트에선 대용량의 트래픽이 발생하는 상황에서 '이체' 기능을 잘 수행할 수 있는 백엔드 개발을 중시했습니다.

 

 데이터 정합성, 속도와 사용자 경험을 생각하며 이체 기능을 설계하고 구현했습니다. 서버에 장애가 일어나는 상황을 생각하며 데이터 정합성을 고려했고, 속도 관련 이슈를 해결하기 위해 nGrinder와 APM을 이용하여 객관적인 근거를 찾았습니다. 해결 방법을 찾을 때는 사용자 경험을 고려하며 기획과 Engineering의 trade off를 고려했었습니다.

 

 프로젝트를 하며 주기적으로 저의 현 상태를 팀원과 공유하는 것을 의식적으로 행했습니다. 비록 코드를 작성한 사람은 저 한명이지만, f-lab 오프라인 공간에서 매일 보는 4년차 개발자 habi에게 매일 '제가 무엇을 했는지, 어디에서 막혀있는지, 이전에 말해준 피드백에 대해 어디까지 고민해 봤는지'을 공유했습니다. 문제 해결 결과 만이 아닌 현재 저의 상태를 공유하여 마치 팀과 함께 일하는 느낌을 살리려고 노력했습니다.

 

https://github.com/michaelkimm/bank

GitHub - michaelkimm/bank: 돈통 및 이체 서비스

  

✍️ 프로젝트 개선 그래프

 사용자가 이체 기능을 사용할 때 중요하게 생각하는 이체 요청 완료 시간(Mean Test Time), 이체 처리 완료 시간(이체 출금 <-> 입금 시간 차)를 중점하여 테스트를 진행했습니다. 각 테스트에서 고려한 요소들은 다음 이어지는 글들에서 보실 수 있습니다.

<그림1. 이체 완료 소요 시간 성능 개선 그래프>

 

<그림2. TPS 성능 개선 그래프>

 

<그림3. MTT 성능 개선 그래프>

 

 

✍️ 트래픽의 개략적인 측정

 이체는 돈을 주고 받는 행위이기 때문에 이와 비슷한 도메인에는 결제가 있었습니다. 목표 트래픽(TPS)을 설정하기 위해선 Active User 수가 필요했기에 결제와 송금 서비스의 회사의 MAU를 조사해봤습니다.

 

<그림4. 트래블월렛 트래픽 추이>

회사	MAU
트래블 월렛	24000
페이 히어	3889
센트비	5822

	MAU	DAU
총계	33711	1124
평균	11237	375

 

 시리즈 A-C의 스타트업 중 결제 혹은 송금 서비스를 하고 있는 기업엔 트래블 월렛, 페이 히어, 센트비가 있었습니다. 저는 nGrinder를 이용한 성능 테스트에 사용될 VUser가 필요했기에 Active User를 산출할 최소의 근거인 DAU가 필요했습니다. 이에 각 기업의 앱 런칭 첫 달 MAU를 www.innoforest.co.kr에서 얻었습니다. DAU는 유저들이 매 일 일정하게 접속했다고 가정하여 DAU = MAU / 30으로 산출했습니다.세 앱의 평균 DAU는 375였습니다. 본 프로젝트는 학습에 중점을 맞췄기에 DAU 목표치를 이보다 적은 100으로 설정했습니다.

 

<그림5. 사용자 수를 통한 부하량 계산>

 

 TPS를 구하기 위해서 DAU 다음으로 평균 응답 시간이 필요했습니다. Little's Law에서의 (그림5 참조) 'TPS = Number of Active Users / 평균 응답 시간' 식에서 근거를 찾았습니다. 평균 응답 시간은 0.8s로 설정했습니다. web.dev에 의하면 0.8초 이내의 평균 응답 시간이 사용자에게 좋은 경험을 줄 수 있는 시간이었기 때문입니다. Active User(VUser)가 100명이고 0.8초의 MTT(Mean Test Time)일 때 TPS는 120이 됩니다. 이에 현 테스트는 TPS 120을 목표하여 시작했습니다.

 

 

✍️ 서버 인프라 구성

프로젝트를 하며 구축하게 된 인프라 구성입니다. Elastic apm을 왜 도입하게 됐는지, 당행과 타행 구조의 테스트 환경을 어떻게 구축했고 어떤 이슈가 있었는지 앞으로 이어질 글에서 설명 드릴 것입니다.

<그림6. 인프라 구조도>

 

✍️ 문서화

 문제 상황, 접근 방법과 해결 과정 및 결과를 문서화 했습니다. 이를 바탕하여 Habi(4년차 개발자)와 매일 스크럼할 때 시각적인 자료로도 활용하여 커뮤니케이션에 도움이 됐었습니다.

<그림7. 문제 상황 및 접근 방법과 해결 과정>

 

<그림8. 테스트 결과 및 결과>

<그림9. 스케줄러 전략>

 

해당 프로젝트는 네이버 클라우드를 활용하여 진행했습니다.