웹사이트 로그인의 역사

첫 번째 로그인

브라우저에서 email과 password를 가지고 로그인 요청을 백엔드로 보낸다면 백엔드는 해당 유저가 존재하는지 DB를 확인하고 있다면 session에 저장을 한다. session에 저장할 때 특정 id를 부여하는데, 브라우저에 response로 넘겨준다. 

 

이렇게 보내진 id는 해당 유저가 누구인지 식별할 때 사용된다. 

하지만 유저의 정보를 백엔드 서버에서 받기 때문에 한번에 여러명의 정보를 받으면 session의 한계가 존재하기 때문에 문제가 발생한다. 

 

이것을 해결하기 위해서 백엔드 서버의 성능상 한계가 있기 때문에 scale-up을 통해 컴퓨터 성능을 올려주었다. 

scale-up
→ 컴퓨터 성능(cpu, memory 등)을 올려주는 작업

두 번째 로그인 

백엔드 컴퓨터의 성능을 오려주었지만 더 많은 유저의 접속이 동시 다발적으로 발생하면 결국 서버의 부하가 발생한다. 

그래서 백엔드 컴퓨터를 복사하는 방법인 scale-out으로 해결해주려고 한다. 

 

이 방법은 유저의 정보가 담기는 백엔드 컴퓨터를 여러대의 컴퓨터로 구성하여 백엔드 서버의 부하를 분산시켜주는 방식이다. 

하지만 이 방법에서도 문제가 있었는데, 백엔드 컴퓨터를 복사할 때 세션까지는 복사가 안되기 때문에 기존 로그인 정보를 가지고 있던 백엔드 컴퓨터가 아니면 로그인 정보가 없어지게 된다. 

 

또한 백엔드 컴퓨터는 복사할 수 있겠지만 DB는 하나이기 때문에 DB로 부하가 몰리는 병목현상이 발생한다.

scale-out
→ 똑같은 성능의 컴퓨터를 추가하는 방법

세 번째 로그인 

sacle-out을 통해서 세션 복사를 하지 못하는 문제점을 보안하는 방법이자, DB의 병목현상을 해소하기 위한 방법으로 

사용자의 로그인 정볼르 DB에 저장하기 시작했다. 

 

하지만 이는 백엔드 서버의 부하가 DB로 옮겨진 것이기 때문에 DB의 부하가 발생하게 된다. 

그렇다고 DB를 복사하자니, 비용 문제가 발생하기 때문에 비효율적이었다.  

 

이러한 문제를 데이터를 쪼개면서 해결하게 되었다. 

데이터를 쪼개는 방법 
→ 수직으로 쪼개는 수직파티셔닝
→ 수편으로 쪼개는 수평파티셔닝 ( 샤딩 )

 

위 방법으로 문제를 해결했지만, 컴퓨터를 껏다 켜도 날아가지 않기 때문에 너무 많은 데이터들이 Disk에 저장된다. 

따라서 안전하지만 느린 방법인데, 이것을 Redis라는 메모리에 임시 데이터베이스를 만드는 방법으로 해결했다. 

 

메모리에 데이터를 저장하기 떄문에 디스크보다 빠른 성능을 가지게 된다. 

네 번째 로그인

굳이 로그인 정보를 서버나 DB에 저장해야할 필요가 있을까? 에 대한 의문으로 JWT 토큰이 발생했다. 

JWT 토큰은 유저 정보를 담은 객체를 문자열로 만들어 암호화한 후 암호화된 키 ( AccessToken )를 브라우저에게 전달한다. 

 

받아온 암호화 키를 브라우저의 저장소에 저장시켜두었다가 유저의 정보가 필요한 API를 사용할 때, 백엔드에서 키를 복호화하여 사용자를 식별 후 접근이 가능하도록 한다. 

 

JWT 토큰은 발급 받아온 서버에서 정상 발급을 했다는 것을 증명하는 signature를 가지고 있기 때문에 사용자의 정보를 DB를 열어보지 않고 식별할 수 있게 되었다.