카드서버 리뉴얼 - 1

 

3/29

onlinecard transactional

 

• 카드 서버 리뉴얼

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

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

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

 

infinite 체크하면 duration에 적힌 시간 동안 요청을 무한 반복한다.

https://m.blog.naver.com/jooh21020/221983660521

 

• 카드 서버의 동시성 제어

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을 넣어두었다.) 이는 후에 하며 개선이 필요한 사항이다.