로그인
sessionId
백엔드 메모리 세션에 로그인 정보를 저장 후 sessionId 를 브라우저에 전달했다. 이 sessionId 를 통해 로그인 한 유저와 글을 작성/결제 등등 에 대한 정보를 일치 시킬 수 있다.
scale up
요청을 메모리(RAM)에 저장되므로 이용자가 늘어날 수록 필요한 메모리 양이 증가한다. 이를 해결 하기 위해 디스크나 메모리를 늘리는 것을 scale up 이라고 부른다.
scale out
컴퓨터를 늘려 요청을 분산시켜 부하 문제를 해결하는 것을 scale out 이라고 한다. 하지만 이런 식으로 요청을 처리할 경우 요청이 저장된 컴퓨터가 다르기 때문에(로그인 정보와 상품 등록 정보가 저장된 컴퓨터가 달라 정보를 비교할 수가 없게 된다) 로그인 정보를 불러올 수 없게 된다.
stateful
사용자의 세션 정보를 가지고 있는 상태
stateless
사용자의 세션 정보를 가지고 있지 않는 상태
scale out 을 하기 위해선 stateless 가 돼야한다.
tokenId
stateless 상태의 백엔드를 scale out시키고 로그인 정보를 DB에 저장하게 되면서 tokenId 로 바뀌었다. 하지만 결국 DB로 부하가 몰리기 때문에 완벽한 해결책은 되지 못한다. DB를 늘리는 것도 효율적인 방법은 아니다.
Partioning
데이터가 저장된 테이블을 나누어 각기 다른 DB에 담아서 부하를 피해준다.
수직 파티셔닝 : 로그인 정보와 결제 정보 나눠서 저장
수평 파티셔닝(샤딩) : 1~100, 101~200, ...
하지만 결국 영구저장공간인 디스크에 저장한다는 것은 저장 속도도 드리고 데이터를 찾아오는 속도도 느릴 수 밖에 없다. 이걸 디스크를 긁는다고 말한다 한다.
로그인 저장 방식
Redis
메모리 기반 DB로 redis에 저장하면서 디스크 저장 문제를 해결할 수 있다.
JWT
아이디를 제외한 로그인 정보를 객체로 만들어서 암호화 시켜준 뒤 암호화 된 내용을 tokenId로 사용한다. 데이터를 DB에 저장하지 않고 정보가 필요한 경우 복호화(원래대로 되돌림) 시켜서 사용한다.
JSON Web Token 으로 객체를 암호화 시킨 토큰
(JavaScript Object Notation)
iat는 로그인 한 시간이고 exp 는 토큰이 유지되는 기간
JWT는 signature가 있기 때문에 조작은 불가능하지만 누구든지 내용을 열어볼 수 있어 중요한 정보는 저장해서는 안 된다.
암호화
양방향 암호화
암호화 할 수 있고 복호화(원상복귀) 할 수 있는 암호화
단방향 암호화(Hash)
암호화만 가능하고 복호화 할 수 없는 암호화
rainbow table
단방향 암호화 상태의 데이터를 복호화 했을 경우가 담긴 데이터. 이를 막기 위해 해시를 여러번씩 반복하기도 한다. 하지만 완벽한 보안은 없다.
인증과 인가
Authentication(인증)
이메일과 비밀번호를 주고 accessToken을 받아오는 것. 한 번만 이루어짐
Authorization(인가)
받은 토큰을 가지고 상품을 등록하거나, 결제 하거나, 내 정보를 받아오는 요청을 할 때 accessToken을 넘겨주는 것. 매번 해야한다.
백엔드에서 토큰을 가져갈 때 replace("Bearer", "") 해서 토큰만 가져간다. Bearer 는 별다른 기능이 없는 문자열이지만 어떤 내용인지 알려주기 위해 관례상 붙여준다. Bearer는 accessToken 을 넘겨 준다는 의미.
