[서버개발캠프] 인증 서버 - 로그인 성능 테스트 : nGrinder

AWS RDS

 데이터베이스 구축을 위해 AWS에서 프리티어로 제공하는 RDS db.t2.micro 인스턴스를 사용했다. 해당 인스턴스의 최대 커넥션 수가 66이었고, 우리 서비스에서 데이터베이스에 접근하는 서비스 서버가 세 대였기 때문에 각 서버의 최대 커넥션 수를 20으로 지정했다. 이를 위해 HikariDataSource를 사용했다.

AWS db.t2.micro Max Connection

DatabaseConfig.java

@Configuration
@PropertySource("classpath:application.properties")
public class DatabaseConfig {

    @Bean
    @ConfigurationProperties(prefix = "spring.datasource.hikari")
    public HikariConfig hikariConfig() {
        return new HikariConfig();
    }

    @Bean
    public DataSource dataSource() {
        return new HikariDataSource(hikariConfig());
    }

	...

}

 

application.properties

spring.datasource.hikari.driver-class-name=com.mysql.cj.jdbc.Driver
spring.datasource.hikari.jdbc-url= //
spring.datasource.hikari.username= //
spring.datasource.hikari.password= //
spring.datasource.hikari.maximum-pool-size=20

 

로그인 성능 테스트

 nGrinder로 인증서버의 성능 테스트를 진행했다. nGrinder에서는 테스트를 위해 스크립트를 작성해야하는데, 따로 시나리오를 작성하지 않고 로그인 API에 대한 성능만 테스트를 진행했다.

 처음 테스트 할 때, Vuser를 99로 설정했는데 계속해서 오류가 발생했다. 이 부분에서 이유를 몰라 한참 헤매었다. 일단 서버에 요청이 제대로 들어가는지 확인하기 위해 로그를 찍어봤는데, 요청은 제대로 들어오는 상황이었다. Vuser를 1로두고 테스트를 하자 오류는 발생하지 않았는데, 6.5라는 귀여운 TPS가 나왔다...

 

 결국 서버 처리속도가 느려서 Vuser가 높으면 타임아웃이 발생해 계속해서 오류가 발생했다는 결론이 나왔다. 처음에는 사용자가 로그인 할 때마다 사용자 접근 시간을 업데이트하는 부분을 의심했지만, 원인은 전혀 예상하지 못한 곳에 있었다. 바로바로 PasswordEncorder!!!

 

BCrypt Password Encoder

 사용자의 비밀번호를 암호화하기 위해 Spring Security에서 제공하는 BCryptPasswordEncoder를 사용했는데, 역설적이게도 너무 강력한 암호화 덕분에 비밀번호 일치를 확인하는데 시간이 많이 걸렸던거였다.(사실은 EC2 t2.micro의 성능이 똥이기 때문...)

 BCrypt는 비밀번호 암호화를 위해 고안된 단방향 해쉬알고리즘이다. Spring Secrurity에서 제공하는 BCryptPassowrdEncoder는 내부적으로 랜덤 솔트를 생성해서 비밀번호를 암호화 시킨다.

 이 때 해쉬함수를 몇 번 돌리느냐에 따라 비밀번호의 암호화 강도가 결정되는데, 해당 인코더는 4~31사이 값으로 strength를 결정 할 수 있고, 디폴트는 10이다. 즉, strength가 10이라면 2^10번 BCrypt 해쉬함수를 돌려서 비밀번호를 암호화하는 것이다.

 문제는 BCrypt가 단방향 암호화 알고리즘이기 때문에, 비밀번호를 확인 할 때 마다 2^strength번 해쉬를 돌려야한다는 것이다. 이는 결국 서버의 성능, cpu 코어 수와 연관이 되는데, t2.micro는 하나의 cpu를 사용하기 때문에 비밀번호 확인하는 부분에서 병목 현상이 발생 했던 것으로 보인다.

 결국 비밀번호의 암호화와 로그인 속도의 트레이드 오프 문제인데, 권장 strength를 고민하던 중 Stack Exchange에서 다음과 같은 글을 발견했다. 요약하자면 어플리케이션에서 용납할 수 있는 성능 내에서, 최대의 strength를 지정해야 한다는 것이었다. 우리는 로그인 TPS 목표를 300으로 잡았었기 때문에 strength를 4로 두기로 결정했다.

https://security.stackexchange.com/a/3993

 

결과

 strength를 4로 했을 때 회원가입한 유저의 로그인 성능 테스트를 진행한 결과 TPS 247.3이라는 결과를 얻었다. 목표로 했던 300에 못미치지만 병목지점을 발견하고 해결했다는 점에서 뿌듯했다.