문제 발생
기존의 이메일을 인지하고 인증 코드를 보낼때 서버에서는 세션에 저장하여 이후 해당 이메일 인증 코드가 들어오면 세션의 값과 비교해서 이메일을 인증했다. 그렇게 진행을 했지만 MSA로 변경하고나서 문제가 발생했다. 더이상 세션을 통해 코드를 확인할 수 없다. 그 이유는 세션이 휘발성의 성격으로 인해 다음 요청에 세션이 비어있는 것이다.
모놀리식과 MSA의 세션 정책
- 모놀리식
- 모놀리식에서는 일반적으로 세션 저장소를 사용해서 세션을 관리한다. 이는 세션이 서버의 메모리나 외부 DB에 지속된다는 것인데 이는 클라이언트가 세션을 만들고 서버와 상호작용을 지속하고 있는 한 세션이 유지되고 있다
- MSA
- 서비스 간에 상태를 공유하는것을 피하기 위해 상태를 분리한다. 모두 독립적으로 실행되고 있으며 일반적으로 세션과 같은 상태를 저장하지 않고 그 대신 토큰을 사용하게 되는 것이다. 또한 MSA는 확장성과 유연성을 위해 서비스가 추가되거나 제거될 수 있다. 이로 인해 다른 인스턴스로 라우팅 될 수 있기에 세션의 휘발을 고려한다.
즉, 세션의 상태는 MSA로 서비스가 변경될때마다 초기화 되어버리는 것이다.
문제 해결
MSA의 환경은 당연하게도 멀티스레딩이 당연한 상황이다. 그렇다면 회원가입을 위해 이메일을 인증 받는 사람이 한명이 아니라는것 즉, 해당 요청이 이전의 요청자인지 확인 할 수 없다는 것이다. 때문에 Session의 ID값을 전달해서 알려주어야 하지만 이것이 저장된다면 위에서 말한것처럼 서버가 증설되는 부분에서 문제가 발생한다.
때문에 세션을 일일히 내부에 저장할 수 없기 때문에 해당 내용(인증 코드와 이메일)을 저장할 저장소가 필요했다
저장소
- 토큰 사용 : 클라이언트측에 토큰을 포함한 쿠키를 사용해서 클라이언트 측에서 상태를 유지하고 이를 통해 인증 및 인가를 처리할 수 있지만 이는 인증과 인가에 관련된 것이지 내가 하려는 것에 사용하기에는 적합하지 않다
- 외부 저장소 사용 : 세션에 들어갔던 데이터를 외부 저장소에 저장하고 관리하는 것이다. 이를 통해 여러 서비스 간에 상태를 공유하게 되는 것이다. 이는 앞서 로그아웃에서 진행했던 Redis를 활용하는 방식으로 진행할 수 있다.
결과적으로 Redis를 또 다시 사용하게 되었다. 아무래도 인증 코드와 이메일일 뿐이라서 Redis에서 데이터를 추출하기에 정말 적합한 상황이였다 이렇게 하면 각 서비스마다 세션을 공유할 필요가 없고 휘발적으로 사라질 걱정을 하지 않아도 된다. 또한 일을 처리하는 성능도 뛰어나기 때문에 방법을 변경했다.
느낀점
처음에는 굉장히 놀랐다. 세션의 데이터가 자연스럽게 지워졌기 때문에 아무리 MSA 방식으로 변경되었다 하더라도 해당 서비스가 증설되지 않았음에도 세션 자체가 스스로 데이터를 지울 줄은 몰랐기 때문이다. 하지만 이번 기능을 통해 세션에 대해 좀 더 알게되는 시간이였다.
또한 이번에도 결국 간단한 데이터 조회를 통한 해결을 할 수 있는 상황은 Redis를 사용하는것이 매우 현명한 선택이라는 것을 알게되었다.
추가적으로 해당 코드에 만료시간을 두어 회원가입을 진행하다가 그만 둔다면 redis에서는 해당 인증 코드를 또 지우는 것으로 진행했다.
'프로젝트 > 항해99 개인 프로젝트' 카테고리의 다른 글
🚢 재고 관리를 위한 동시성 제어 (Monolithic Architecture) (2) | 2024.04.27 |
---|---|
🚢 WishList가 장바구니? (Redis 의 Hash타입 사용) (0) | 2024.04.26 |
🚢 JPA 의 AttributeConverter (1) | 2024.04.26 |
🚢 로그아웃, RefreshToken?? Redis?? (feat. 비밀번호 변경) (1) | 2024.04.26 |
🚢 @Scheduled 을 이용한 배송 상태 자동 체크 (1) | 2024.04.21 |