전자카드 서버 동시성 제어

 

• 카드 서버 리뉴얼

카드 서버가 vertex로 개발되어 있는데 메모리를 많이 잡아먹고 있다. 버텍스는 event driven 형식이 장점인데 event driven 형식으로 개발되어 있지 않기도 하고 메모리 릭으로 서버가 강종되는 일이 빈번하여 프레임웤을 spring boot으로 변경하여 재개발하기로 하였다.

메모리 릭이 가장 큰 문제였던만큼 tps가 안정적인지를 검토하는 과정이 필요했다. 이에 jmeter를 사용해 tps를 측정하기로 하였다.

jmeter 설정값 https://kamang-it.tistory.com/399

 

• 카드 서버의 동시성 제어

spring boot의 connection pool ← 커넥션 풀의 설정에 미흡한 부분이 있어서 transactional 어노테이션이 동작하지 않는가?에 대해 생각해보았지만 커넥션 풀의 공유(토비의 스프링 vol.1 360p 8line 참고)는 .yml파일에서 수행하지 않는 것으로 보였다.

https://goddaehee.tistory.com/205

그렇다면 커넥션 풀의 공유는 어디에서 이루어지는가?에 대해 상단 블로그의 mapper class에 어노테이션 @Repositroy가 눈에 띄어 검색해보았고

Repository : jdbc connection등의 DB연동을 수행합니다. ← 이게 mapper의 annotation에 누락되어 transaction의 경계설정이 잡히지 않았고(토비의 스프링 vol.1 357p 참고) 그렇기에 commti 역시 진행되지 않았던 것.

https://u-it.tistory.com/entry/Service%EA%B3%84%EC%B8%B5%EA%B3%BC-Repository%EA%B3%84%EC%B8%B5%EC%97%90-%EB%8C%80%ED%95%9C-%EC%9D%B4%ED%95%B4

해당 annotation 추가하자 transactional(read_commited, requires_new) 동시성 제어가 원활히 작동하였다. (db에서 같은 칼럼을 동시에 select해와 각각 insert해버리는 일이 없어졌다.)

롤백을 위해서 전체 컨트롤러의 내용을 try catch문으로 설정하였는데(catch에 롤백을 넣고 try의 최하단 부분에 commit을 넣어두었다.) 이는 후에 하며 개선이 필요한 사항이다.

---

transactional 어노테이션을 사용하고 jmeter를 통한 부하테스트를 진행하였다.

1트랜잭션(증액요청, 감액요청)을 총 20개의 카드번호로 구성하여 각각 100번씩 수행하게하였다. 즉 4000번의 request요청이 갔다.

이 때 한 개의 카드에서 동시성 제어가 실패한 케이스가 발생했다. 확인해보니 잔액 300원을 동일하게 증감/차감 요청이 읽어가 sign값이 불일치했다. 이렇게 되면 고객은 sign값 불일치로 개발자가 db 보정을 하지 않는 한 서비스를 이용할 수 없게 된다.

transactional 어노테이션을 사용하여 모두 커버가 되었다고 생각했으나 아니었던 것이다.

의심되는 사항은 비동기 처리. (commit 됐다고 리턴 보냈는데- 사실 아직 커밋은 진행중이었으며, 다음 요청이 들어와 걔가 먼저 처리가 돼버려서 커밋 순서 역전)

이에 도움을 요청하니

1. 트랜잭션의 isolation 레벨이 exclusive 모드(serializalbe)인지
2. @.synchronized 어노테이션을 시도
3. mutex나 tryLock을 사용한 배타제어

등의 조언을 받았다.