2021.09.02 로그인 세션을 파일에서 Redis로 이관

2021.09.02 로그인 세션을 파일에서 Redis로 이관

운영중인 메인 서비스는 세션을 사용하는데, 로드밸런서 stricky 옵션을 줘서 각 인스턴스 내부에서 파일로 관리중이었다. 신규 서비스에서 메인 서비스의 세션에 접근해야해서, 각 인스턴스에서 관리중인 로그인 세션을 하나의 Redis에서 붙도록 인프라 작업으르 진행했다.

위와 같은 목적으로 파일로 관리중인 세션 정보를 Redis로 옮긴 거였는데, 막상 작업하고 나니까 전체적으로 페이지 응답속도가 2~4배 빨라졌다;;

평균 응답이 0.3~0.4초 소요됐는데 이제는 0.1~0.2초 정도로 줄어들었다.

기분좋아!! 짜릿해!! 의도한 바는 아니지만 완전 빨라졌어!!

어쨌든 Redis를 사용해본 적 없는 뉴비라서 처음 노드 구성부터 용량까지 하나의 선택마다 고민이 많이 됐다.

노드 구성

노드 구성에는 고민이 많았는데, AWS ElastiCache에서 좋은 기능들을 제공하고 있었다. 일단 싱글 노드로 구성하되 복제본을 하나 갖고 있는다면 노드가 죽어도 빠르게 복구가 가능해보인다.

일관성(Consistency) : 모든 노드가 같은 순간에 같은 데이터를 볼 수 있다. 싱글노드로 구축한다! 단 한 명의 로그인도 실패없이 성공을 보장한다. 대신 일부 노드가 죽으면, 그 노드에 저장된 사용자들의 로그인 정보는 날아가기 때문에 다시 로그인해야함.

: 모든 노드가 같은 순간에 같은 데이터를 볼 수 있다. 가용성(Availability): 모든 요청이 성공 또는 실패 결과를 반환할 수 있다. 클러스터를 구축하고 샤딩한다! 가끔 몇 명의 로그인을 실패할 수 있다 (몇명일지 모름) 하지만 일부 노드가 죽어도, 모든 사용자의 로그인에 영향을 받지 않는다

모든 요청이 성공 또는 실패 결과를 반환할 수 있다.

클러스터 구성안

용량 산정

특정일 기준 사용자수 x에 대해 운영서버의 세션파일 용량은 약 48MB였다.

이번년도 최대 사용자수가 b일때, 이를 비례해서 계산했을 때 150MB 정도가 예상된다.

세밀하게 용량 산정하려고 노력했었는데, AWS 기본적으로 제공하는 최소 사양도 4GB였다ㅋㅋㅋ

테스트

개발서버에서 로그인이 유지되는지?

세션 만료 (5분으로 줄여서 테스트해봄)

from http://prohannah.tistory.com/181 by ccl(A) rewrite - 2021-10-16 19:00:49