스프링 시큐리티 Bcrypt 연산 이슈

테스트 환경 & 성능 이슈 발생
생각해본 원인
실제 원인
리뷰

테스트 환경 & 성능 이슈 발생

테스트 환경
테스트 툴 : Jmeter
서버 : AWS ec2의 t2.micro

성능 이슈 발생
다른 api요청들에 비해 로그인, 회원가입쪽만 유독 낮은 tps 발생

---

생각해본 원인

테스트는 로컬 환경에서 실시함
고려해야 하는 문제는 배포 환경에 비해 높은 성능의
컴퓨터에서 돌아가고 있는 서버에서의 테스트임

가상 원인 1 : JPA로 작성된 쿼리문의 성능 문제
시도해본 방법 : JPA로 작성된 쿼리문 대신 JPQL로 대체해서 테스트
결과 : 성능상의 차이는 거의 없고 오히려 간단한 쿼리문이라 그런지 JPQL보다 일반 JPA성능이 조금 우세함

가상 원인 2 : 시큐리티 form 로그인 성능 문제
시도해본 방법 : Security Config에서 form로그인 부분 주석처리 후 컨트롤러에게 위임 후 반대로도 테스트
결과 : 아무런 성능차이가 없음

가상 원인 3 : JwtUtil 코드의 성능 문제
시도해본 방법 : 토큰을 인코딩, 디코딩하는 과정에서 성능상 이슈가 발생하지 않을까 싶어 로컬 환경에서 인코딩 디코딩 과정 생략
결과 : 성능 차이 없음, 인코딩, 디코딩 과정은 성능에 영향을 끼치지 않음

결과적으로 아무런 문제점을 찾지 못함, 배포 환경에 비해 매우 좋은 로컬 환경에서 돌아가는 것도 간과할 수 없음

---

실제 원인

실제 원인은 직접 테스트하면서 찾은 것이 아닌 구글링을 통해 찾음
스택 오버 플로우
레딧 커뮤니티
위 두개의 사이트에서 얻을 수 있는 정보는 Bcrypt의 salt round에서 이슈가 발생 할 수 있다는 점임

Bcrypt는 비밀번호를 암호화할때 사용한 인코더인데 이때 salt round 는 비밀번호를 몇번에 암호화 작업을 돌릴 것 인지에 대한 수치인데 1씩 증가할때마다 2배의 연산 처리 시간 즉 n^2의 시간복잡도를 가짐

스프링에서 Bcrypt encoder를 등록할때 따로 인자로 숫자를 지정하지 않는다면 10이 default 세팅으로 들어가게 되고 실제로 이 값을 최소값으로 넣을 수 있는 4로 내렸을때 실제로 tps가 올라가는 것을 확인함

기존 Bcrypt가 10인 경우

Iteration	No. of Transactions	Average	90% Line	95% Line	99% Line	Min(ms)	Max(ms)	Error%	Throughput(request/second)
5-1	1000	16218	15958	45038	45890	37	46931	49.1	19.9

Bcrypt를 4로 낮춘 경우

Iteration	No. of Transactions	Average	90% Line	95% Line	99% Line	Min(ms)	Max(ms)	Error%	Throughput(request/second)
5-1	1000	25	31	35	45	19	91	0	99.8

CPU사용량 또한 Bcrypt가 10인 경우 점유율이 계속 90% 이상을 유지하면서 오류도 동반했는데
4로 낮춘 경우 CPU사용량은 50% 이상을 올라가지 않고 안정적으로 데이터를 처리하는 것을 확인 할 수 있었다.

리뷰

로컬환경에서 Bcrypt 의 sal round를 바꿔가며 진행을 하였을 경우 크게 차이를 보여주지 않았었다.
t2.micro라는 극단적으로 좋지 않은 환경에서 확실하게 체감 가능한 부분 이였다.
하지만 Bcrypt의 sal round를 낮추게 된다면 무차별 brute force(무차별 비밀번호 대입) 공격에 취약해 진다는 단점이 존재한다.
결론적으로 근본적인 해결책이 될 수 없는 해결 방법이다.
문제를 해결해 보기 위해 swap 메모리를 적용 시켜 보았지만 부하가 있는 상황에서 swap 메모리를 사용하지 않았다.
단순 연산이 많아져서 CPU의 점유율을 많이 잡아먹는 현상이지 램을 많이 잡아먹는 현상이 아닌 것 같다.
차선책으로는 ec2 인스턴스의 유형을 업그레이드 할 필요가 있어 보인다.