개발하며 내가 질의한 내용에 대한 답변들을 몇 가지 생각 나는대로 적어보겠음:
- Sparamin 개발중 access, refresh token을 배운 후 session에 대한 강의가 있었던터라 두가지 개념이 꽤 혼동됐음. 그래서 session으로 refresh token을 어떻게 구현하라는 소리인가 고민을 했음.
- 결국 둘의 가장 큰 차이는 session은 stateful하고 token은 stateless하다는 것임. 세션 기반 인증은 사용자의 인증 정보가 서버의 세션 저장소에 저장되고 브라우저는 세션 ID를 쿠키로 저장하여 서버에 전송함으로써 사용자를 인가함. 반면, 토큰 기반 인증은 사용자의 인증 정보를 클라이언트가 직접 들고 있으며, 토큰은 브라우저의 로컬스토리지에 저장되고 http authorization 헤더를 통해 서버에 전송됨.
- 세션 기반 인증은 세션 ID만 전송하면 되므로 트래픽이 적고 보안성이 높지만, 토큰 기반 인증은 더 많은 트래픽을 사용하며 보안 문제와 확장성 측면에서 유리함. 특히 토큰은 클라이언트가 저장하므로 서버의 부담이 줄어들고 수평 확장이 용이하다고 함.
- 그런고로,,, 보안이 중요한 금융사와 같은 회사들이 세션을 사용함. 튜터님 두 분께 물어봤을 때 두 분 다 토큰을 쓴다 하심.
- 그래서 뭐 굳이 세션으로 비슷한 느낌을 주고자 한다면 세션 시간을 연장할 수 있도록 구현하라 했으나 요구 조건에 맞추라는 주문이 있어 token으로 다시 개발을 하게 되었던 썰임.
- 스승님이 토큰이 나오게 된 백그라운드를 설명해주시며 풀어주신 썰도 재밌음:
- 스케일 아웃 = 서버를 하나 더 두는 거 // 스케일 인 = 서버 성능(CPU)을 높이는 것
- 최근 웹사이트에 따라 동시 접속이 많아져, 처리하기 위해 스케일 아웃이 주로 사용되고 있다 함. 여러 서버를 사용하여 트래픽을 분산시키고 높은 가용성을 제공한다는 것.
- 여기에 더하여 로드 밸런서가 트래픽을 분산시켜 서버 간의 부하를 고르게 분배하는 역할을 함 (라운드 로빙, 웨이트 기반 등 다양한 방식으로 서버에 트래픽을 전달하여 성능을 최적화하고 서버 간의 부하를 균형있게 유지해줌).
- 문제는, 로드 밸런서가 유저의 세션 정보를 담고있지 않은 서버에 분배했을 때 일어나는 인증 이슈 때문에 해당 문제점을 해결하는 기술도 나왔다고 함...지만 기억이 안남. 그리고 이런 문제점이 결국 토큰의 탄생에도 기여했다고 이해함.
- 또 하나의 해결 방법으로 레디스를 사용하는 것임. 레디스는 인메모리 데이터베이스로, 메모리 비용이 높다는 특징이 있음// 찾아보니 레디스는 주로 게임과 같이 빠른 응답이 필요한 부분에 활용되며, 메모리 비용이 높지만 그에 따른 성능 향상이 있다 함. 게임 데이터와 로그인 정보 등을 레디스에 저장하여 빠른 접근을 가능케 함.
- 결국,,, 세션의 경우 서버의 부담이 크고 확장성에 제약이 있어, stateless한 토큰 기반의 인증 방식이 더 선호되는 경향이 있다 함.
- 커넥션과 세션::
- 커넥션은 디비와 사용자 간의 물리적인 연결을 나타내는데, 세션은 이를 논리적으로 매핑하여 사용자와 디비 간의 상태를 유지함. 트랜잭션이 실행되면 해당 작업을 위한 카피본(커넥션)이 생성되고, 모든 작업이 성공하면 커밋하여 원본 데이터에 적용됨. 그러다 실패하면 롤백하여 해당 카피본이 사라지며 모든 작업이 취소되는 것.
- 그래서 10개의 동작을 하는 트랜잭션이 있다 하면, 커넥션이 10개가 생기는 것임. 이런 부하의 문제점을 해결하기 위해 커넥션 풀을 사용할 수 있는데 디비에 인서트되는 등의 작업이 발생할 때마다 매번 커넥션을 열고 닫는 비용을 줄일 수 있고, 지연 속도를 낮출 수 있음. 커넥션 풀 내 미리 만들어진 커넥션을 재사용함으로써 효율적인 디비 연결 관리가 가능하게 되는 것.
일단 맞게 썼는지 검증은 빠르면 주말이나 늦어도 내년 중엔 할 생각임. 노트 보고 기억나는대로 끄적여 봄...,,,;;;