다중 WAS환경에서 발생한 세션 불일치 문제에 대한 방안을 고민하면서 여러 자료들을 찾아보았다.
서버에 저장한다고는 하는데, 어떠한 과정을 통해 서버에 세션을 저장하고 세션 불일치 문제를 어떠한 관점에서 접근해야 하는지 힌트를 얻기 위해 공부한 기록을 남긴다.
보통 서버에, 서버의 램에 세션 정보를 저장한다고 알고 있을텐데 application web server, 즉 was에도 저장한다.
그렇기에 디스패처서블릿이 요청을 전달할때 인터셉터 이후의 단계에서 세션정보를 얻어서 활용할 수 있는 것이다.
일단 서버라는 개념이 운영 인스턴스인지, was인지, 둘 다 인지는 개념을 더 찾아봐야겠으나 내가 보기엔 둘 다 맞고 가능할 것으로 보인다.
각설하고, 이러한 서버 혹은 was가(이후부터는 서버라는 단어로 일괄 작성) 다중화된다면 세션정보가 바뀌어도 다른 서버에 이를 반영할 수 없는 상황에서 세션 불일치 문제가 발생할 것이다.
현재 프로젝트의 경우 포트와 was가 다른 프로그램에서 세션정보가 공유되지 않아 발생하였다.
최초 요청을 진행한 서버에서만 세션 관리를 진행하며, 이에 따라 모든 요청은 하나의 서버에서만 관리하는 방식이다.
클라이언트의 세션정보 일관성이 없어지는 문제는 해결할 수 있겠지만, 모든 요청이 한 서버에서 관리되므로 그만큼 부담이 늘 것이다.
또한 프로젝트 환경 자체가 포트가 다를 수 밖에 없고 이에 따라 중개서버도 다를 수 밖에 없는 환경이므로 이 방법은 사용 불가능할 것으로 생각하였다.
여러 WAS 세션을 동일한 세션으로 관리하여, was가 달라져도 클라이언트 입장에서는 하나의 was를 바라보기 때문에 세션의 일관성을 확보할 수 있다.
그만큼 새기존 WAS에 새로운 서버의 IP/Port를 입력해서 클러스터링 해주는 작업이 필요하여 번거로워지고, 모든 stateful한 데이터를 각 was에 배포하는 방식으로 전달하므로 데이터 관리나 메모리 측면에서 그리 좋지 않은 선택이라는 생각이 든다.
특히나 sticky session과 동일한 이유로, 애초에 was를 다르게 운용하기 때문에 적용할 수 없는 방안이라 생각하였다.
난 이 방법을 사용하여 문제를 해결해보고자 하는데, 무엇보다 간편하고 별도의 성능이나 메모리 문제를 걱정하지 않아도 되며 스프링에서 이를 지원해주므로 방안을 구성하는데 공수가 많이 들지 않을 것이라 생각하였다.
일단 redis를 사용하는 환경은 제한되어 있으므로, 일단 스레드 로컬을 이용하여 다중 was환경에서 세션정보를 저장할 수 있는지 봐야겠다.
찾아보았을때는 동시성 제어의 일환이고, was가 달라지므로 스레드 자체가 달라지기에(구체적으로 말하면 스레드를 생성하는 웹컨테이너와 이에 대응하는 서블릿이 달라지기에)..적용할 수 있을지는 의문이지만 일단 한번 해봐야겠다. 개선방안을 적용한 과정은 추후 상세 기술할 예정이다.
세션 불일치 문제 접근 방향 - https://junghyungil.tistory.com/m/163
스레드 로컬을 활용한 세션정보 저장 - https://f-lab.kr/insight/thread-local-and-session-management-in-java-20241021
https://velog.io/@skygl/ThreadLocal
https://f-lab.kr/insight/was-session-management-with-tomcat-20240714