Stateless

Stateless

• 무상태의, 상태가 없는

 

JWT의 Stateless

• Session
  • 서버가 상태를 가지고 있음. (유저가 로그인을 했다는 정보)
  • 로그인 후 클라이언트에게 sessionId 주게 됨. (랜덤 문자열)
  • 클라이언트가 Session id를 가지고 서버에 요청을 보내면, 서버는 저장된 Session id(key)에 맞는 유저의 정보를 매칭시켜 유저 식별.
  • 로그아웃 : 클라이언트 또는 서버에서 sessionId 삭제
• JWT
  • Json Web Token - JSON 형식의 토큰
  • 클라이언트가 상태를 가지고 있음. (토큰)
  • 요청 시 헤더에 JWT를 포함시키고, 서버가 JWT를 파싱(디코드)해서 유저 식별 후 요청 처리.
  • Header, Payload, Signature 부분으로 나누어져 있음.
  • JWT에 포함된 데이터는 암호화된 것이 아니므로 민감한 정보를 넣으면 안됨.
    • Base64URL 인코딩을 사용하여 헤더, 페이로드, 서명을 직렬화함.
    • 그러나 인코딩은 데이터의 가독성을 낮추는 것일 뿐 데이터를 안전하게 보호하는 방법이 아님. 누구든지 쉽게 디코딩 가능.

 

➕ Base64 vs Base64URL

Base64는 인코딩시 +, /, = 포함. 특히 /는 URL과 파일 경로로 쓰이기 때문에 불필요한 에러가 발생할 수 있어 이 셋을 대체 및 제거한 Base64URL이 생김. Base64 특성상 인코딩 결과가 무조건 4의 배수로 나오며, 4의 배수가 안될 경우 =를 넣어 맞춰주는데 이를 패딩이라고 함. Base64URL에서는 그래서 삭제 가능.

 

 

Session에 비해 JWT 방식이 갖는 장점

1. 빠른 요청 속도
   1. 다른 동네 (서버) 갔다 오는 것은 꽤 무거운 작업
   2. 세션 사용 시 그 값을 해당 서버 자체의 캐시에 저장되는데 만약 서버 여러 개 사용한다면 클라이언트 요청이 다른 서버로 갔을 때 세션을 알 수 없음. 그래서 보통 외부 DB (Redis 등)에 세션 저장함.
   3. DB를 갔다 오지 않으므로 빠름. 서버 자체의 캐시를 사용하는 건 좋지 않다!
2. 무한한 확장성
   1. 다른 서버에서 JWT를 파싱할 수 있는 키를 갖고 있다면 DB 연결하지 않더라도 사용 가능
   2. 가능한 이유 : Stateless라는 특성 때문!!
   3. JWT가 상태(정보/데이터) 아님? stateful한 거 아님? → 여기서 stateless는 서버 관점.
3. 서버비가 저렴할 수도 있음
   1. 외부 DB 사용하지 않기 때문에.

JWT가 무조건 좋은 건 절대 아니다. 여러 보안적인 단점 등이 있기 때문…

 

서버의 Stateless

• 서버는 하나의 커다란 함수
• 동일한 서비스 서버들은 동일한 조건에서 동일한 요청을 한다면 동일한 응답을 줘야 한다.
• 서버는 상태를 가지면 안된다!
  • 이미지 저장하는 기능을 구현할 때 이미지를 서버에 저장 또는 채팅방 개발할 때 채팅방 기록을 서버에 HashMap으로 저장하면 다른 서버에서 해당 데이터에 접근하지 못하게 된다. (외부 DB에 저장해야 함) 서버는 항상 Stateless하게!!!
• 서버가 여러 개인 이유 : 가용성
  • 가용성?
    • 중단되지 않고 지속될 가능성
    • 서버 1대 → 장애 → 서비스 그대로 중단. ⇒ ‘가용성이 낮다’
    • 서버 여러 대 → 하나 장애 → 서비스 지속 ⇒ ‘가용성이 높다’
  • 가용성 100%를 보장하는 것은 불가능하므로 실제로는 고가용성(High Availability)을 목표로 한다.
    • 이를 위해 다중 서버, 데이터 복제, 로드 밸런싱, 이중화 등 다양한 방법 사용
  • 고가용성은 시스템이 최대한 오랜 시간 동안 중단 없이 운영될 수 있도록 보장하는 것. 이는 단순히 여러 대의 서버를 두는 것 뿐 아니라, 각 서버의 역할 분담, 장애 감지 및 자동 복구, 데이터의 지속적인 백업 및 복제 등을 포함.

 

로드 밸런싱 (Load Balancing)

• 서버는 트래픽의 양에 따라 유동적으로 늘거나 줄 수 있어야 한다. (Auto Scailing)
• 각 서버가 통신하기 위해서는 IP 주소를 알아야 한다. 그러나 서버가 유동적으로 생겨나는데 클라이언트는 서버의 IP 주소를 어떻게 알 수 있을까? 정답은 모른다.
• Load Balancer를 서버 앞에 둬서 알아서 트래픽을 분배해주고 클라이언트는 로드 밸런서만 보게 됨으로써 해결할 수 있다.
• 클라이언트는 로드 밸런서의 IP 주소만 알면 된다.
• Load Balancer를 Proxy Server 라고도 하는데, 여기서 프록시는 대리라는 뜻으로 뒤 서버들 대리해주는 서버라고 이해하면 된다.
• 실제 돌아가고 있는 서버들은 외부에 노출되지 않은 채 프록시가 대리로 받아주기 때문에 보안에 좋다는 장점이 있다.
• VPC (Virtual Private Cloud) : 가상 네트워크. 이 안에 있는 또 다른 소규모 네트워크 : Subnet
• Load Balancer : VPC. Public Subnet
• 실체 서버들 : Private Subnet