24.07.05 23:16 작성
·
81
0
해당 클래스의 주된 내용은 동시 로그인 제한으로 이해를 했습니다.
그런데 설명을 해주시는 부분에 있어서
set-cookie 부분에서 부터 이해가 잘 되지 않네요.
먼저 설명 부분에 있어서
set-cookie로 session id를 보내고
갑자기 결제가 필요한 유료 api에 접근을 요청하고
redis의 캐시에서 해당 유저가 프리미엄 등급임을 확인하고
유료 api 요청을 처리한다 하셨는데
동시 로그인 제한이라면 pc나 모바일 등 여러 장비에서 접속하는 session의 처리를 의미하는거라 생각이 됩니다.
그리고 redis의 캐시로 프리미엄 등급을 확인한다는것도 이해가 되지 않는게 해당 데이터는 캐시로 다뤄질 데이터가 아니지 않나요?
초반 설명하셨던 동시 로그인 제한이란 소주제의 목적이
다이어그램을 통해 설명한 내용과 다른것 같습니다.
혹시 제가 이해한게 잘못된 것인지 알고 싶습니다.
n(로그인 세션)
답변 1
0
2024. 07. 05. 23:35
안녕하세요. 해당 강의의 주된 내용은 redis를 이용해서 사용자의 로그인 세션을 관리하는 방법을 알아보는 것입니다. 로그인 세션이라고 하면 어떤 사용자가 활동적으로 시스템을 이용하는 기간의 임시 데이터 정도로 이해할 수 있는데요.
특정 사용자의 활성화된 세션을 생성하기 위해서는 최초에 사용자를 식별할 수 있는 id, pw 등을 받아서 먼저 사용자를 식별해야 합니다. 이 때 보통 데이터베이스를 조회해서 사용자 데이터를 확인하는데요. 예제에서는 사용자마다 등급이 있다고 가정했고, 해당 사용자가 preminum 등급이라는 정보를 세션 Hash에 함께 저장하였습니다. 이렇게 세션 생성시 사용자 등급까지 한 번에 캐싱하는 이유는 이후 세션을 이용한 요청마다 추가로 사용자의 등급을 조회하는 과정을 생략하기 위함입니다.
이런 식으로 캐시를 이용해서 세션을 관리하면 동시 로그인 제한 같은 기능까지 구현 가능한데요. 계정 별로 생성할 수 있는 세션의 개수를 제한하여 활성화 된 세션이 특정 개수를 넘을 경우 이전에 생성된 세션을 삭제하는 식의 로직을 추가해주시면 됩니다.
2024. 07. 06. 00:19
네, 맞습니다,
세션 수 제한은 프리미엄 여부와는 무관할 수도 있습니다. 무료 등급에서도 계정마다 동시 접속을 제한할 수도 있습니다.
프리미엄 상태가 빈번하게 바뀌는 것이 아니라면 캐시로 관리하는 것도 큰 문제가 되지 않을 수도 있습니다. 약간의 데이터 불일치를 감수하는 대신 성능을 우선하는 설계입니다. 예를 들어서, 프리미엄 상태가 이미 만료됐지만 사용자에게 프리미엄 기능을 조금 더 제공하는 것이 크게 문제가 되지 않는다면 이런 설계가 충분히 합리적인 선택일 수도 있습니다. 만약에 이런 상태를 완벽하게 통제해야한다면 요청마다 source of truth에 해당하는 데이터를 조회하면 됩니다.
2024. 07. 06. 00:09
말씀하신 내용대로라면,
database의 사용자 정보 중 자주 사용되는 정보를 캐시하는데 그 중 프리미엄 여부에 대한 정보가 포함되어 있다.
세션의 수 제한은 이러한 유료 결제 여부를 먼저 확인하고 이후 처리를 해야 하는 부분이다.
사용자의 프리미엄 여부를 db의 hit가 아닌 캐시를 사용하는 유효함을 가질 수 있다.
이 내용이 해당 강의의 내용이 맞을까요?