[Spring&AWS][5-3] 코드 개선하기

kiteB·2022년 3월 20일

JDBC Spring TIL

Spring-AWS

목록 보기

9/13

이 글은 책 「스프링 부트와 AWS로 혼자 구현하는 웹 서비스」를 공부하고 정리한 글입니다.

오늘은 지난 시간에 작성한 코드를 개선해보는 시간을 갖도록 하겠다.

[ 어노테이션 기반으로 개선하기 ]

1. 개선이 필요한 부분

IndexController에서 세션값을 가져오는 부분이 개선이 필요하다.

SessionUser user = (SessionUser) httpSession.getAttribute("user");

index 메소드 외에 다른 컨트롤러와 메소드에서 세션값이 필요하면 그때마다 직접 세션에서 값을 가져와야 한다. 이렇게 반복되는 작업을 줄이기 위해 이 부분을 메소드 인자로 세션값을 바로 받을 수 있도록 수정해보자.

2. 개선하기

✅ LoginUser

@LoginUser 어노테이션을 생성해보자!

config/auth/LoginUser.java

@Target(ElementType.PARAMETER)
@Retention(RetentionPolicy.RUNTIME)
public @interface LoginUser {
}

@Target(ElementType.PARAMETER)
- 이 어노테이션이 생성될 수 있는 위치를 지정한다.
- PARAMETER로 지정하면 메소드의 파라미터로 선언된 객체에서만 사용할 수 있다.
@interface
- 이 파일을 어노테이션 클래스로 지정한다.
- LoginUser라는 이름을 가진 어노테이션이 생성되었다고 보면 된다.

✅ LoginUserArgumentResolver

LoginUserArgumentResolver는 HandlerMethodArgumentResolver 인터페이스를 구현한 클래스이다. HandlerMethodArgumentResolver는 조건에 맞는 경우 메소드가 있다면 HandlerMethodArgumentResolver의 구현체가 지정한 값으로 해당 메소드의 파라미터로 넘기는 기능을 가지고 있다.

config/auth/LoginUserArgumentResolver.java

@RequiredArgsConstructor
@Component
public class LoginUserArgumentResolver implements HandlerMethodArgumentResolver {

    private final HttpSession httpSession;

    @Override
    public boolean supportsParameter(MethodParameter parameter) {
        boolean isLoginUserAnnotation = parameter.getParameterAnnotation(LoginUser.class) != null;
        boolean isUserClass = SessionUser.class.equals(parameter.getParameterType());
        return isLoginUserAnnotation && isUserClass;
    }

    @Override
    public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer, NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception {
        return httpSession.getAttribute("user");
    }
}

supportsParameter()
- 컨트롤러 메소드의 특정 파라미터를 지원하는지 판단한다.
- 여기서는 파라미터에 @LoginUser 어노테이션이 붙어 있고, 파라미터 클래스 타입이 SessionUser.class인 경우 true를 반환한다.
resolveArgument()
- 파라미터에 전달할 객체를 생성한다.
- 여기서는 세션에서 객체를 가져온다.

✅ WebConfig

이제 LoginUserArgumentResolver가 스프링에 인식될 수 있도록 WebMvcConfigurer에 추가해보자.

config/WebConfig.java

@RequiredArgsConstructor
@Configuration
public class WebConfig implements WebMvcConfigurer {

    private final LoginUserArgumentResolver loginUserArgumentResolver;

    @Override
    public void addArgumentResolvers(List<HandlerMethodArgumentResolver> argumentResolvers) {
        argumentResolvers.add(loginUserArgumentResolver);
    }
}

HandlerMethodArgumentResolver는 항상 WebMvcConfigurer의 addArgumentResolvers()를 통해 추가해야 한다. 다른 HandlerMethodArgumentResolver가 필요하다면 같은 방식으로 추가하면 된다.

✅ IndexController

모든 설정이 끝났으니 IndexController의 코드에서 반복되는 코드를 모두 @LoginUser로 개선해보자.

public class IndexController {

    private final PostService postService;
    
    @GetMapping("/")
    public String index(Model model, @LoginUser SessionUser user) {
        model.addAttribute("post", postService.findAllDesc());
        SessionUser user = (SessionUser) httpSession.getAttribute("user");
        
        if (user != null) {
            model.addAttribute("userName", user.getName());
        }
        return "index";
    }
}

@LoginUser SessionUser user
- 기존에 (User) httpSession.getAttribute("user")로 가져오던 세션 정보 값이 개선되었다.
- 이제는 어느 컨트롤러든지 @LoginUser만 사용하면 세션 정보를 가져올 수 있게 되었다.

✅ 실행 결과

정상적으로 동작하는 것을 확인하기 위해 Google Login을 해보았다.

로그인 성공!

[ 세션 저장소로 데이터베이스 사용하기 ]

1. 개선이 필요한 부분

1) 애플리케이션을 재실행하면 로그인이 풀리는 문제

세션이 내장 톰캣의 메모리에 저장되기 때문에 발생하는 것으로, 기본적으로 세션은 실행되는 WAS(Web Application Server)의 메모리에서 저장되고 호출된다. 메모리에 저장되다 보니 내장 톰캣처럼 애플리케이션 실행 시 실행되는 구조에서는 항상 초기화가 된다. 즉, 배포할 때마다 톰캣이 재시작된다.

2) 2대 이상의 서버에서 서비스하고 있다면 톰캣마다 세션 동기화 설정을 해야한다.

실제 현업에서는 다음의 3가지 중 하나를 선택한다.

톰캣 세션 사용
- 일반적으로 별다른 설정을 하지 않을 때 기본적으로 선택되는 방식이다.
- 이렇게 될 경우 톰캣(WAS)에 세션이 저장되기 때문에 2대 이상의 WAS가 구동되는 환경에서는 톰캣들 간의 세션 공유를 위한 추가 설정이 필요하다.
MySQL과 같은 데이터베이스를 세션 저장소로 사용한다.
- 여러 WAS 간의 공용 세션을 사용할 수 있는 가장 쉬운 방법이다.
- 많은 설정이 필요 없지만, 결국 로그인 요청마다 DB IO가 발생하여 성능상 이슈가 발생할 수 있다.
- 보통 로그인 요청이 많이 없는 백오피스, 사내 시스템 용도에서 사용한다.
Redis, Memcached와 같은 메모리 DB를 세션 저장소로 사용한다.
- B2C 서비스에서 가장 많이 사용하는 방식이다.
- 실제 서비스로 사용하기 위해서는 Embedded Redis와 같은 방식이 아닌 외부 메모리 서버가 필요하다.

여기서 두 번째 방식인 데이터베이스를 세션 저장소로 사용하는 방식을 선택할 것이다! 설정이 간단하고 사용자가 많은 서비스가 아니며 비용 절감을 위해서이다.

2. 개선하기

✅ spring-session-jdbc 등록

build.gradle에 다음 코드 추가하기

implementation 'org.springframework.session:spring-session-jdbc'

✅ h2-console

애플리케이션을 실행해서 로그인 테스트 한 뒤 h2-console로 접속해보면,

세션을 위한 테이블 2개(SPRING_SESSION, SPRING_SESSION_ATTRIBUTES)가 생성된 것을 볼 수 있다. JPA로 인해 세션 테이블이 자동 생성되었기 때문에 따로 할 작업은 없다.

로그인을 했기 때문에 한 개의 세션이 등록되어 있다.

📌 참고

로그인 테스트 시 다음과 같은 에러가 발생했다면

org.springframework.jdbc.BadSqlGrammarException: PreparedStatementCallback; bad SQL grammar [DELETE FROM SPRING_SESSION WHERE EXPIRY_TIME < ?]; nested exception is org.h2.jdbc.JdbcSQLSyntaxErrorException: Table "SPRING_SESSION" not found; SQL statement:
DELETE FROM SPRING_SESSION WHERE EXPIRY_TIME < ? [42102-200]

다음 코드를 추가해주면 된다.

spring.session.jdbc.initialize-schema=always

이렇게 세션 저장소를 데이터베이스로 교체하였다. 하지만 지금은 스프링을 재시작하면 세션이 풀린다. 이유는 H2 기반으로 스프링이 재실행될 때 H2도 재시작되기 때문이다. 이후 AWS로 배포하게 되면 AWS의 데이터베이스 서비스인 RDS를 사용하게 되니 세션이 풀리지 않는다.

다음 시간에는 네이버 로그인을 적용해보도록 하겠다.