카드 서버가 메모리 릭*으로 서버가 강종되는 일이 빈번히 발생하였다. 카드 서버는 vert.x로 개발되어 있었는데 당시 회사에서 사용하고 있던 버전이 메모리 누수가 있던 버전이었다. 이에 머물고있는 개발자들에게 친숙한 프레임워크인 spring boot로 리뉴얼을 결정하였다.메모리 릭으로 인한 서버 강종이 가장 큰 문제였기 때문에 tps가 안정적인지를 검토하는 과정이 필요했다. 이에 jmeter를 사용했다. * vert.x 메모리 릭https://stackoverflow.com/questions/50407914/memory-leak-in-io-vertx-core-impl-eventloopcontext-in-java-application* event-driven(이벤트 드리븐)이란?더보기MSA(분산 아키텍처..
4/26 onlinecard test transaction queue 테스트a카드 10초 슬립 걸어놓고 b,c,d 카드로 요청했을 때 b,c,d는 정상적으로 진행된다. if(!Standard.isEmpty(request.getTestParam())) { try { logger.warn("10초 슬립 시작! cardno - {}", request.getCardNo()); Thread.sleep(10000); //10초 logger.warn("10초 슬립 끝! cardno - {}", request.getCardNo()); } catch (Exception e) { ..
4/5transactional 어노테이션을 사용하고 jmeter를 통한 부하테스트를 진행하였다.1트랜잭션(증액요청, 감액요청)을 총 20개의 카드번호로 구성하여 각각 100번씩 수행하게하였다. 즉 4000번의 request요청이 갔다.이 때 한 개의 카드에서 동시성 제어가 실패한 케이스가 발생했다. 확인해보니 잔액 300원을 동일하게 증감/차감 요청이 읽어가 sign값이 불일치했다. 이렇게 되면 고객은 sign값 불일치로 개발자가 db 보정을 하지 않는 한 서비스를 이용할 수 없게 된다.transactional 어노테이션을 사용하여 모두 커버가 되었다고 생각했으나 아니었던 것이다.의심되는 사항은 비동기 처리. (commit 됐다고 리턴 보냈는데- 사실 아직 커밋은 진행중이었으며, 다음 요청이 들어와 걔가..
카드 서버 리뉴얼 카드 서버가 vertex로 개발되어 있는데 메모리를 많이 잡아먹고 있다. 버텍스는 event driven 형식이 장점인데 event driven 형식으로 개발되어 있지 않기도 하고 메모리 릭으로 서버가 강종되는 일이 빈번하여 프레임웤을 spring boot으로 변경하여 재개발하기로 하였다. 메모리 릭이 가장 큰 문제였던만큼 tps가 안정적인지를 검토하는 과정이 필요했다. 이에 jmeter를 사용해 tps를 측정하기로 하였다. jmeter 설정값 https://kamang-it.tistory.com/399 카드 서버의 동시성 제어 spring boot의 connection pool ← 커넥션 풀의 설정에 미흡한 부분이 있어서 transactional 어노테이션이 동작하지 않는가?에 대해 ..