요구사항 정의 및 설계는 다음 노션에 정리되어 있다.
-> Joon Bank Notion <-
개발이 진행됨에 따라 글은 실시간으로 업데이트될 예정이다.
💁♂️ 소개
은행의 기능을 구현해 볼 생각이다.
기능은 다음과 같은 핵심 기능만을 구현할 예정이다. ( 핵심 기능 구현 이후 서비스 기능들 추가 예정 )
- 입금/출금
- 송금
- 거래 내역 관리
- 계좌 관리 ( 계좌 등록, 삭제, 추가 )
- 관리자 페이지 ( 전체 입출금 및 송금 내역 조회 )
기능은 적되 보안성, 가용성, 확장성 측면을 중심으로 구현할 계획이다.
모놀리식으로 개발을 하되, 향후 MSA로 전환 가능성을 열어두고 그에 맞춰 개발을 할 계획이다.
고민과 해결
빈번한 하루 잔여 이체 한도 조회
일단, 하루 잔여 이체 한도 조회가 이루어지는 방식을 살펴보자.
계좌의 테이블에는 해당 계좌에 설정된 하루 이체한도에 대한 정보가 있을 것이다.
그리고 잔여이체 한도 조회를 위해서는 그날에 발생한 해당 계좌의 송금액의 합도 알아야 할 것이다.
두 정보를 바탕으로 하루 이체한도 - 하루 송금액을 계산해야 되는데 이게 문제가 송금 페이지를 들어갈 때마다 잔여 한도를 보여줘야 하기에 매번 조회하기에는 비용이 너무 크다. 서버의 부담을 낮추기 위해서 생각해 낸 방법이 바로..
Redis를 이용하는 것이였다.
내 계획은 그렇다.
Redis는 key: value로 계좌번호: 잔여 한도를 담고 있는다.
00시마다 Redis의 데이터를 전부 초기화시키고 사용자가 최초로 이체한도를 조회하는 상황이 발생 시에 하루 이체한도 - 하루 송금액 조회 연산을 진행하여 데이터를 새로 담는다. 이후 사용자가 송금할 때마다 Redis의 이체한도에서 송금액만큼만 제외시키고 이체 한도 조회 시에는 Redis에서 이체한도 정보를 바로 가져온다. (혹, 중간에 데이터가 날아가면 위의 연산을 다시 진행하여 데이터를 넣는다.)
즉, 메모리 DB와 key : value 형태로 빠르게 이체한도를 조회함으로서 이체한도 조회의 부담을 확 낮출 수 있었다.
그러면 HashMap을 쓰지 왜 Redis인가? 이거는 간단하다. HashMap은 서버 종속 데이터인데 내 설계 목표는 다중서버이기 때문에 공유 캐시 서버가 필요할 것이라 판단했고 해당 서버에 Redis를 올려서 사용할 예정이다.
Session vs JWT
서버의 부담은 있더라도 보안성 측면에서 좀 더 안정적인 Session을 사용하기로 했다.
가장 큰 이유는 세션은 개별적으로 컨트롤이 가능하여 부정 사용자가 식별되면 JWT와 달리 해당 사용자만 세션을 해제 시킬 수 있다.
근데 한 가지 의문점이 든 게 Session은 서버 메모리에 저장되어 관리가 되는데 로드밸런싱에서 세션 유지를 어떻게 할까?
몇 가지 방법이 존재하는데
먼저, Sticky Session이라는 방법이 있다.
이름처럼 세션이 생성된 서버에 들러붙어서 해당 서버로만 요청을 보내는 방법이다.
근데 해당 서버가 뻑나면? 세션도 같이 날아가 버리는 거다.
두 번째, 세션을 각 서버가 아닌 중앙 세션 관리 서버를 운용하는 방법이다.
Redis를 이용하여 세션만을 관리하는 서버를 따로 빼두어 각 서버가 Redis로부터 세션 관리를 하는 방법이다.
(MSA 전환 시에도 이 방법이 유용하게 사용될 거 같다.)
이러면 로드밸런서에 의해 서버가 바뀌어도 세션은 그대로 유지가 된다.
근데 이 경우 Redis 서버가 뻑나면 문제가 크다. 그래서 이를 해결하기 위해 Redis 서버를 클러스터링 하여 사용한다.
📌 Architecture
Cloud Architecture
Backend Architecture
