동시성 문제는 이전 글에서 다루어 보았기에 이제 비관적 락을 프로젝트 코드에 적용하여 문제를 해결해보자. @PostMapping("/signup") @Operation(summary = "회원 가입", description = "회원 가입 처리 API(이메일 인증 후)") public ResponseEntity signup(@RequestBody SignInForm signInDto){ String encode = encoder.encode(signInDto.getPassword()); signInDto.setPassword(encode); SignInForm join = memberService.join(signInDto); return new ResponseEntity("User SignIn comp..
프로젝트 테스트를 진행하다 데이터가 중복되어 저장되거나 데이터에 결함이 발생하는 문제가 확인되었다. 이를 위해 우선 멀티 쓰레드 환경에서 동시성 문제에 대해 알아보고 이를 해결하는 방법을 순차적으로 알아보려 한다. 동시성 문제란 ? 어떤 두 사건이 같은 시간에 일어나는 것 우리의 웹 서버엔 동시에 여러 요청이 들어올 수 있으며 이로 인해 우리의 코드가 동시에 실행될 수 있다. 따라서, a가 자원X를 X+1로 바꾸고 확인하는 사이 b가 X를 또 1증가시키는 경우 a입장에선 X+1이 아닌 X+2가 조회될 수 있다는 뜻이다. 개념은 간단하니 넘어가고 실제로 문제가 발생하는 지 확인해보자. 우선, 현 프로젝트에서 그룹에 가입하는 경우 가입 전 현재 그룹에 속한 인원을 세어 해당 인원이 최대치 보다 작은 경우에만..
이제 nGrinder로 다시 부하를 걸어보자 VUser=50 캐시를 사용하기 전보다 아주 훌륭한 성적을 보였다. 전에는 1~2분만에 서버가 다운되었는데, 이번엔 서버가 다운되지는 않았다. (물론, CPU과열로 쓰로틀링이 되는 것 같긴 했다) 이제 Read하는 경우에 대한 테스트 및 성능 개선은 수행해보았으니 CUD가 섞인 요청도 해보려 한다. 시나리오 : 회원 가입 -> 로그인 -> (그룹장이) 가입 권유-> 받은 가입 권유 승낙 -> 그룹 게시물에 댓글 남기기 -> 해당 게시물 조회 5개의 POST요청과 1건의 GET요청으로 이루어진 시나리오이다. 대충, 생각해보면 POST요청 각각에 시간이 소요될 것이고 댓글 목록에 페이징을 적용하지 않았으니 아마 시간이 지나면 게시물을 조회하는 부분에서 큰 병목이 ..
마스터 슬레이브 구조를 적용하기 전, 근본적으로 커넥션 풀의 갯수를 좀 늘려보려 한다. 여기를 참고해서, 히카리에서 제공하는 풀 사이즈 대로 계산을 해보자 Tn * (Cm -1) +1 즉, 최대 쓰레드 수 * ( 하나의 쓰레드가 작업에 필요한 커넥션의 수 -1) +1 이 최적의 커넥션 풀 크기이다. 현재 그룹 정보 조회 API를 호출하게 되면 생기는 트랜잭션은 총 4개 이다. 해당 API가 그룹 서비스에서 가장 많은 로직이 포함 된 메소드를 사용하기에 우선 커넥션의 수를 4로하고 커넥션 풀의 크기를 계산해보면 10*3+1 =31이 된다. 이를 application.yml에 추가해보자. spring: datasource: hikari: maximum-pool-size: 40 VUser=50으로 한 테스트의..
이제, 프로젝트에서 실제 사용하는 시나리오별로 API를 하나 이상 호출하여 어떤 지점에서 병목이 발생할 지 확인해보려 한다. 1. 테스트 종류 Smoke Test : 최소한의 부하를 주어 이 부하를 견딜 수 있는 지 확인해보는 테스트 ( VUser 1~2) Load Test : 평소 트래픽과 최대 트래픽일 때 부하를 견딜 수 있는 지 확인하는 테스트 ( 점진적으로 VUser수를 늘려가며 이 최대치를 늘리는 것이 목표이다.) Stress Test : 스트레스 상황(최대 부하치에 해당하는 정도의 접속자가 발생한 상황) 에서 시스템이 안정적으로 운영되는지에 대한 테스트 (서비스가 빠르게 복구되는 지, 높은 스트레스 상황에서 안정적인 응답 속도를 보장하는 지 등등 에 대한 테스트 이다) 단순히 조회하는 API ..
이제, prometheus를 사용하는 grafana 그리고, (제대로 될 진 모르곘지만) pinpoint가 준비되었으니 nGrinder를 이용해서 부하 테스트를 수행할 준비를 해보자. 1. nGrinder설치 여기 에서 war를 다운해주자. (난 3.5.8을 사용했다.) release note에 Shows error message when running without tmpdir property 란 항목이 적혀있다. 그냥 받은 war를 실행하게 되면 이런 오류가 뜨며 실행이 되지 않는다. 에러 로그에서 처럼 로그를 기록할 디렉토리를 명시해줘야 실행이 된다는 뜻이다. java -Djava.io.tmpdir={로그를 기록할 디렉토리/파일명} -jar ngrinder-controller-3.5.8.war --..
지난번 포스트에서 오류는 핀포인트 에이전트와 스프링 부트 (즉, 스프링 6.0)간의 호환성 문제였다. (여기 (pinpoint issue) 참고) 핀포인트 버전을 2.5.2로 바꿔주고, java역시 최신 버전으로 변경해주니 이렇게 예쁜 문구만 보이고, 에러 로그들은 모두 사라졌다. 그래서, 기쁜 마음으로 API를 몇번 날려봤는데.. 딱 1개만 먹고 그 뒤로는 수집이 되지 않는다... 에이전트에서는 에러 로그가 하나도 남지 않았으니 이제, 에이전트 문제는 아닐거라 생각하고 있었다. 컬렉터와 웹을 보니 공통적으로 java.lang.IllegalArgumentException: Unable to canonicalize address localhost/:2181 because it's not resolvable..
1편에 이어 이제 핀포인트를 설치해보자. 참고로, 오픈소스 버전의 핀포인트는 무료이다. 1. Hbase 설치 메트릭들을 저장하는 DB이다. 현재는 2.x대 버전이 주로 쓰이지만 핀포인트에서 2.x를 쓰려면 모듈을 따로 설치해야 하기에 1.2.7을 설치하기로 했다. 여기 에서 옛 hbase들을 다운 받을 수 있다. 폴더 압축을 해제해준 후 (tar xzvf hbase-1.2.7-bin.tar.gz 로도 풀 수 있고, 그냥 더블클릭으로도 해제할 수 있다.) bin폴더로 이동한 다음 ./start-hbase.sh 를 입력하여 hbase를 실행해준다. 그 후, 아래 명령어로 hbase쉘에 들어가준다. ./hbase shell 쉘 내부에서 status를 쳐서 정상적으로 출력되는지 확인하거나 http://local..
