1. JWT를 이해하기 전에 Session이란 무엇인가

이 포스트는 데어 프로그래밍님의 유튜브 강의를 듣고 나서 정리한 글입니다.

 

클라이언트가 서버에 최초 접근한 경우

 

요청 헤더에 세션 ID를 들고 접근한 경우

 

그럼 이 세션만 있으면 계속 접근이 가능한가?

아니다. 세션이 날라가는 시점이 있다.

1. 서버에서 강제로 Session을 날린다.

2. 사용자가 브라우저를 종료할 때

3. Session 만료 시간이 됐을 때 (보통 30분으로 둔다)

 

세션 로그인 요청 / 인증 로직

1. 처음 로그인 요청을 합니다.
2. 사용자 ID, PW를 확인하여 사용자가 맞는지 확인합니다.
3. 세션ID를 생성합니다.
4. 사용자에게 응답 헤더에 세션ID를 담아서 응답합니다.
5. 세션ID를 웹 브라우저에 저장합니다.
6. 이제 세션ID를 헤더에 담아서 요청을 합니다.
7. 서버에서는 세션ID가 있으니, 세션 저장소에서 세션ID가 유효한지 확인을 합니다.
8. 검증이 됐다면 사용자 정보를 받아옵니다.
9. 응답

이 로직이 반복적으로 이뤄진다.

 

세션의 문제점

만약 우리의 서버가 동접자 수 최대 100명까지 처리할 수 있다고 가정해봅시다.

근데 평균 동접자 수가 300명이라면?

 

서버를 늘린다.

서버로 요청을 보냈는데 2 번째 서버는 지금 100명이 동접중이라 바쁘다. 그렇다면 다른 서버로 요청을 보내는데 이것을 바로 로드 밸런싱이라고 한다.

 

하지만, 또 문제가 있다.

만일, 처음 사용자가 2 번째 서버로 접근을 해서 세션ID를 발급 받았다고 가정을 해보자. 그런데 다시 사용자가 요청을 보냈는데 이번엔 로드 밸런싱 때문에 1 번째 서버로 요청을 보내게 된다면, 해당 서버에는 해당 사용자의 세션ID가 없어서 처음 온 사용자로 인식 될 것이다.

 

해결책으로는,

1. Sticky Session을 이용해 그 사용자가 갔던 서버로만 보내는 것이다.
2. 모든 서버에 세션이 생성 될 때마다 세션을 복제 시킨다.
3. DB를 세션 저장소로 사용한다. (DB에는 IO가 일어나기 때문에 속도가 엄청나게 저하된다. 세션은 메모리에 저장시키고 가져오기 때문에 훨씬 빠르다.) -> 메모리 서버를 이용한다! (주로 Redis를 이용한다.)
4. JWT를 사용하면 이 문제들을 해결 할 수 있다.