[Spring boot] [JWT] Spring security와 Redis를 기반으로 한 인증 구현(1) - 회원가입과 Docker를 이용한 Redis
SpringBoot-JWT Auth
현재 진행 중인 마감할인 서비스가 sprint2로 들어섬에 따라 서버를 파이어베이스에서 독자 서버로 옮길 일이 생겼다. 이와 더불어 기존 MVP앱에 로그인 기능을 추가하기로 해서 개발을 진행해보았다. 우리는 소셜 로그인을 채택했고, 따로 아이디와 비밀번호를 입력받지 않는다. 우리는 iOS, AOS 모바일 앱만을 지원하고 있으므로 소셜 로그인의 경우 클라이언트단에서 처리를 한다. 사실상 백엔드는 소셜로그인 처리가 아닌, jwt token인증을 진행하는 것이다. 나는 개발에 들어갈 때 소셜로그인이라는 개념이 사소하고, 모바일과의 협업은 처음이라 이런 플로우를 알아내는 데 시간이 꽤 걸렸다. 혹시나 나처럼 플로우부터 헤매고 계신 분이 있다면 이 글이 도움이 되기를 바란다. 그럼 지금부터 그 플로우를 하나씩 살펴보도록 하자.
회원가입의 Flow
ppt로 만들고 캡쳐를 해서 빨간 줄이 보이는데 양해 바란다. 첫 문단에서 설명했듯, 소셜로그인 처리는 사실상 클라이언트단에서 처리가 된다. 회원가입 시점에서 이 과정을 설명하자면, 사용자가 소셜 로그인을 진행하면 소셜 플랫폼에서 첫 로그인임을 감지, 정보 제공 동의화면으로 이동시킨다. 사용자가 정보 제공을 동의하면 위 다이어그램의 2번 플로우부터 진행이 되는 것이다.
그럼 백엔드는 무엇을 하느냐? 바로 JWT 토큰 생성과 반환이다. JWT가 무엇인지는 이 글을 참조하기 바란다. JWT형태의 access token과 refresh token을 생성하고 사용할 것인데, access token은 매 접근마다, refresh token은 access token의 만료 시 재갱신에 사용된다. 사용자가 최종적으로 우리 서비스에서 요청한 회원정보까지 입력을 해서 최종적으로 회원가입 요청을 했을 때, 해당 정보를 DB에 저장하고 이 토큰들을 생성하여 반환해주면 되는 것이다. 이때 Redis가 등장한다.
Redis?
Redis는 key, value 구조의 비정형 데이터를 저장, 관리하기 위한 오픈 소스 기반 NoSQL(비관계형 데이터베이스)이다. 인메모리 데이터 구조를 가졌다.
이때 눈여겨볼 것이 인메모리 데이터 구조라는 점이다. 디스크에 저장되는 것이 아니라 메모리에 저장이된다는 것은, 접근이 빠르다는 말이다. 이런 특징이 필요한 이유는 조금 뒤에 기술하겠다.
그래서 이걸 어떻게 사용하느냐고? 바로 refresh token의 저장이다. 대개 access token은 만료기간을 대략 몇 시간 단위로 설정하고, refresh token은 주 단위로 설정을 한다. access token이 만료되었을 때 클라이언트에서는 가지고 있던 refresh token을 서버에 보내 access token 갱신을 요청할 것이다. 그때 만약 refresh token이 메모리가 아닌 디스크에 저장돼있다면? 몇 명의 유저밖에 없는 상황은 모르겠으나 서비스 규모의 확장을 고려한다면 길게는 몇 초 이상이 소비될 것이다. 이는 꽤 부정적인 경험일 것이다.
이를 해결하기 위해 많은 곳에서 token의 저장에 인메모리 저장 방식을 채택하는 것이다(token 뿐만 아니라 채팅 등 빠른 로드가 필요한 경우에 쓰인다고 한다.). key(refresh token):value(user pk) 형태로 저장해두고 후에 refresh token을 받아 해당 token의 value인 user pk를 이용하여 access token을 갱신하는 것이다.
또한 Redis는 single thread를 사용하므로 context-switch 비용의 완화, thread간 자원 공유 문제에서의 자유로움 등의 이점도 존재한다. 하지만 이 single threaded 방식 때문에 생기는 문제점도 존재한다. 시간 복잡도가 O(N)인 전체 데이터 탐색을 수반하는 명령어는 주의하도록 해야한다. 그동안 다른 일처리를 하지 못하기 때문이다. 이 문제들에 대해서는 후에 개발을 진행하며 고민하기로 했다.
나는 이참에 Redis를 Docker에 올려서 돌려보기로 했다. 나중에 서버를 배포할 때 어떤 일이 벌어질지 모르기 때문이기도 했고, Redis 서버를 로컬에서 독립시키고 싶었기 때문이다(물론 실제로 사용해보고도 싶었다.).
Docker?
Docker는 소프트웨어를 컨테이너라는 표준화된 유닛으로 패키징하며, 이 컨테이너에는 라이브러리, 시스템 도구, 코드, 런타임 등 소프트웨어를 실행하는 데 필요한 모든 것이 포함되어 있다.
내가 원하는 환경에 맞게 컨테이너를 패키징할 수 있다는 점이 정말 큰 이점인 것 같다. 다른 환경에 독립적이란 것 말이다. 확장성, 유연성, 이식성도 우수하니 사용에 친숙해지면 좋을 것 같았다.
정리
인증 과정 구현 첫 글은 회원가입의 플로우와 그에 쓰인 기술들에 대한 간략한 설명이 다였다. 다음 글은 Mac 기준 Docker의 설치, 실행 및 Redis 이미지 다운로드와 컨테이너 등록, 이용에 대해 써볼 예정이다.
