HttpSession과 Session Clustering (with Redis)

 

오늘은 HttpSession 으로 발생하는 문제들을 알아보고

그 대안들에 대해서 이야기 해볼 예정이다.

 

먼저 그전에 HttpSession를 알아야 한다.

 

1. HttpSession

 

우리가 밥먹듯이 사용하는 http 요청은 상태값이 존재하지 않는다.

 

요청은 완전히 독립적으로 이루어지고,

서버는 사용자가 보낸 요청에 대한 정보가 없다.

 

이건 다르게 말하면

클라이언트는 서버에 요청을 보낼 때 자신이 누군지를 알려줄 수 있는 정보를

요청할때 마다 보내줘야 한다는 것이다.

 

이 상황에서 보통 우리는 쿠키를 사용한다.

 

서버는 응답을 보내주면서 쿠키에 브라우저를 특정할 수 있는 값을 넣어서 보내주고,

그 이후에 클라이언트가 요청을 보낼때 해당 쿠키를 포함하여 보내주면

서버는 해당 클라이언트가 누군지 특정할 수 있다.

 

 

이런식으로 상태를 저장하지 않는 http 통신을 사용하면서,

요청을 보낸 사용자를 기억하는 상태를 유지하는 것을 세션이라고 부른다

 

스프링부트를 기준으로 설명하면,

스프링부트의 내장 서버인 Tomcat 서버가 세션을 관리한다. (JSESSIONID-쿠기 값)

 

Tomcat은 JSESSIONID을 바탕으로 세션을 관리하고, HttpSession 객체를 만들어준다

그래서 Springboot 컨트롤러 단에서 HttpSession을 다룰 수 있다.

 

---

 

2. 문제인식

 

우리는 보통 사용자가 많아져서 트래픽이 몰리게 되면 서버 개수를 늘리는데,

한가지 대안은 똑같은 기능을 하는 Springboot 서버를 여러개 만드는 것이다.

 

이 경우 아래 그림처럼, 로드 밸런싱을 통해서 부하 분산이 가능하다 (Scale Out 방식이라고 부름)

(서버 자원의 크기 자체를 키우는 방식 - Scale Up)

 

 

 

그런데 이경우 사용자가 A서버로 요청을 보냈다가 B서버로 요청을 보내면 세션이 유지 될까요?

 

불가능 합니다.

 

그래서 이를 해결하기 위한 대안책이 존재한다.

(Sticky Session, Session Clustering)

 

---

 

3. Sticky Session

 

Sticky Session은 클라이언트가 하나의 서버에만 고정적으로 요청을 보내는 방법이다.

 

로드밸런서를 통해 요청을 보낸 클라이언트를 기록하고,

해당 클라이언트가 요청을 다시 보낼 경우 똑같은 서버로 요청을 보내주는 것이다

 

 

 

그런데 이 방법 왠지 위험해보이지 않는가?

 

특정 사용자만 활발하게 활동한다면 특정 서버만 활발하게 사용될 것이고,

이는 결국 요청이 골고루 분산되지 않는다는 것이다.

 

 

위 그림 처럼 다른 서버들에 비해 B서버만 바쁘게 동작하니깐 

이는 결국 과부하로 이어지고

B서버가 다운되면, 세션도 사라지고 사용자 데이터는 사라지게 되는 것이다 (실제 서비스면 돈 증발)

 

 

---

 

4. Session Clustering

 

그래서 새로운 대안은 Session Clustering이다.

 

서버들이 하나의 저장소(DB)를 공유하고, 해당 저장소에 세션에 대한 정보를 저장하는 것이다.

이렇게 되면 요청이 어디로 가든간에 세션정보가 유지 될 수 있는 것이다!

 

 

외부 저장소에 세션정보를 저장하니깐

요청이 랜덤한 서버에 전달된다 하더라도 클라이언트 특정이 가능하다

 

외부 저장소를 사용하기 때문에 사용자 요청을 처리하는 서버를 자유롭게 추가하고 제거도 가능하다

서버를 제거하더라도 세션정보는 사라지지 않기 때문이다!

사용자의 트래픽에 따라 서버를 증설해주거나 줄여주면 된다는 것!

 

하지만, 사실 이렇게 되면 외부 저장소를 사용한다는 점에서

관리포인트가 하나 증가하는 것이고, 파일시스템 기반 데이터베이스를 사용하게 되면

어쩔 수 없이 지연이 발생하는데, 그래서 지연이 적은 인메모리 기반 데이터베이스를 사용하는 것이다 (Redis) 

 

---

 

5. Spring Session

 

우리는 스프링 개발자이지 않은가?

그리고 Redis를 사용한다? 그럼 Session Clustering은 이걸로 끝이다.

 

아래처럼 의존성을 추가해주고

//Redis 의존성
implementation 'org.springframework.boot:spring-boot-starter-data-redis'

//Redis Session을 사용하기 위한 의존성 
implementation 'org.springframework.session:spring-session-data-redis'

 

Spring Session은 Spring 의 하위 프로젝트 중 하나로, 사용자의 세션 정보를 다루는데 유용한 API를 제공한다.

 

위에서 JSESSIONID는 Tomcat서버가 관리한다고 했는데,

Redis session을 사용하게 되면, JSESSION은 사용하지 않게 되고

 SESSION이라는 새로운 쿠키를 Redis가 관리해준다.

 

 

 

 

Redis를 확인해보면 아래처럼 세션정보가 저장된 것을 알 수 있다.