Web/기타

세션 관리

이번 포스트에서는 Redis를 이용한 세션 관리에 대해 살펴보자.

scale up / scale out

인프라 업그레이드

열심히 프로젝트를 진행하고 결과물이 잘 서비스되는 것을 바라보는 것은 매우 흐믓한 일이다. 그러다 사이트 이용자가 점점 많아지다 보면 한 번 씩 렉이 걸리기도 하고 처리에 시간이 걸리는 모습을 보다보면 숨이 턱턱 막힌다.

이럴 때 우리는 인프라의 업그레이드를 고민하게 된다. 인프라를 업그레이드하는 방법은 scale up 과 scale out 방식 두 개로 나룰 수 있다.

scale up

scale up은 보다 좋은 사양으로 대체하는 것이다. 기존의 장비에 CPU도 좋은 걸로 바꾸고 램도 추가하고 HDD도 더 큰걸로 달아준다. 이 방법은 성능을 증가시킴에 따라 상대적으로 큰 비용이 들게 된다. 그리고 무한대로 성능을 높일 수도 없기 때문에 성능 확장에 한계가 있게 된다.

중요한 점은 한 대의 서버가 여전히 요청들을 받아들인다는 점이다. 사용자가 100만명으로 폭주할 때에 대비해서 서버를 준비해뒀는데 평소에는 동접자가 10명 정도라면 심각한 자원의 낭비일 것이다. 또한 그 서버가 망가지면 대박 난리다.

scale out

반면 scale out은 장비를 추가하는 형태이다. 하나의 장비가 처리하던 요청을 여러 장비가 나눠서 처리하는 형태이다. 필요하다면 서버를 빌려서 증설하면 되고 필요 없다면 반환하면 된다. 흔히 AWS등을 사용하다보면 설정에 따라 scale out이 아주 손쉽게 일어난다. 따라서 비용의 증가도 크게 부담스럽지 않다.

여러 대의 서버가 요청을 받아서 처리할 수 있기 때문에 로드밸런싱이 가능해지고 장애가 발생했을 때 다른 서버가 대신 처리해줄 수 있어서 장애에 대처하기도 용이하다.

scale out 된 multi server와 세션 관리의 문제

multi server와 로드 밸런싱(load balancing)

scale out 형태로 확장된 형태로 서버가 구성되면 load balancing에 신경써야 한다. load balancing은 말 그대로 특정 서버로 몰리는 load를 조절해서 모든 서버가 골로루 일하게 하고 장애에 대처하기 위한 기법이다.

load balancing에는 여러 방법이 있는데 가장 쉬운 방식이 Round Robin 방식이다. 이 방식은 사용자의 요청은 하나씩 순서대로 서버에 할당해서 처리하는 매우 간단한 방법이다. 그러다 보니 헛점도 많다.

만약 round robin 방식으로 load balancer가 동작한다면?

위와 같이 구성된 서버에서 round robin 방식으로 load balancer가 동작한다고 하자. writer를 하려면 login이 필요한 상황이다. 1번 요청을 1번 서버가 처리해서 session에 로그인 정보를 남겼을 때 다음 2번 요청은 2번 서버가 처리하게 되는데 2번 서버에는 login 정보가 없기 때문에 글 작성이 어려울 것이다.

load는 분산되었지만 매번 인증을 받아야 할것이다.

sticky session(끈적끈적한 세션)

round robin의 다음 버전은 sticky session 방식이다. 이 방식은 세션별로 서버를 고정해버리는 것이다. 따라서 한 사용자의 요청은 모두 한 서버에서만 처리한다. 아래의 그림은 1번 사용자의 요청은 2번이, 2번 사용자의 요청은 1번 서버가 전담하는 것을 보여준다.

이제 round robin의 문제점은 없어졌지만 만약 서비스 과정에서 1번 서버에 장애가 발생하면 2번 사용자의 모든 정보는 소실될 것이다. 또한 과도한 헤비 유저가 서버를 쥐어짜더라도 다른 쪽으로 load를 분산시킬 수 없으니 load balancing도 쉽지 않다.

session clustering

그래서 다음 방식으로 session clustering을 사용한다. 이 방식은 서버들마다 존재하는 session을 하나의 cluster로 묶어 준다.

이제 서버는 세션이 생성되면 이 정보를 다른 서버들에도 동기화 시켜서 저장한다. 따라서 1번 서버에 장애가 발생하더라도 모든 정보가 2번 서버에도 있기 때문에 문제없이 서비스가 가능하다. 하지만 이 과정에서 정보를 동기화 시키는데 누락이나 과도한 통신, 성능상 문제등이 발생할 수 있다. 만약 새로운 서버를 scale out 해서 추가하면 모든 세션 정보를 동기화 시켜줘야 하는 번거로움은 덤이다.

session server 운영

그래서 결국엔 세션 정보를 웹 서버가 아닌 별도의 세션 서버에서 관리하는 구조로 발전하게 되었다. 이제 세션은 중앙 집중적인 session server에서 관리되므로 서버들이 세션을 동기화 시킬 필요도 없고 새로 추가된 서버도 그냥 session server에 접근하면 기존의 세션을 다 사용할 수 있다.

이런 세션 서버로 많이 사용되는 것이 redis라는 메모리 기반의 database이다. redis는 remote dictionary server의 약자로 key-value의 구조로 데이터를 저장하는 녀석으로 구조가 간단하기 때문에 매우 빠른 속도를 자랑한다.

https://redis.io/

Redis

Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache, and message broker

redis.io

간단하게 spring boot에서 redis를 이용해서 세션을 관리해보자.

https://goodteacher.tistory.com/713

SpringBoot에서 Redis를 이용한 세션 관리

이번 포스트에서는 Redis를 이용해서 세션을 관리해보자. 내용은 다음의 글을 참조한다. https://docs.spring.io/spring-session/reference/guides/boot-redis.html Spring Session - Spring Boot :: Spring Session After adding the requi

goodteacher.tistory.com

JWT와 세션 out?

redis를 이용한 세션 관리는 많은 장점을 주지만 엄청난 트래픽이 발생하는 시대에는 버거움이 발생하기도 한다.

기본적으로 session의 동작은 클라이언트가 session id를 쿠키로 가지고 있다가 서버로 전송하고 서버는 session id를 확인해서 로그인된 사용자인지 확인한다. 여기에 한술 더 떠서 redis 같은 DB까지 개입을 하게 되니 아무래도 덕지적지 뭔가가 붙는 느낌이다. 더군다나 그럴리는 없겠지만 모든 redis server가 오류를 일으킨다면 인증은 완전히 불가능해진다.

그결과 JWT라는 방식이 고려된다.

https://goodteacher.tistory.com/97

JWT를 이용한 인증 처리 1

Vue 과정을 진행하면서 온전히 SPA로만 구현한 클라이언트를 위한 인증 처리의 필요성이 생겼고 이를 위해 JWT 사용법을 정리하고자 한다. Session Cookie vs JWT를 통한 인증의 차이 먼저 session cookie를