클라이언트 - 서버 아키텍쳐
추상적인 수준에서 소프트웨어를 클라이언트 측과 서버 측의 두 부분으로 나누는 소프트웨어 설계 아키텍쳐이다.
클라이언트 : 사용자 컴퓨터에서 사용자와 상호 작용을 처리하는 UI를 제공
서버 : 클라이언트로부터 요청을 수신하고 적절한 데이터를 응답
소프트웨어의 역할을 두 개로 나눴기 때문에 서버는 비즈니스 로직과 데이터들에, 클라이언트는 사용자에게 UI를 제공하는 것에 집중 할 수 있고, 서버는 UI를 신경 안써도 되고, 클라이언트는 복잡한 데이터를 건드릴 필요가 없게 된다.
클라이언트와 서버로 나눴기 때문에 서로 통신을 해야하는데 여기에 필요한 것이 통신 프로토콜이고 Statefull, Stateless로 나뉜다.
Statefull Service
클라이언트가 서버에 요청을 보내면 서버에서는 세션의 상태에 기반하여 응답을 한다.
서버가 로그인한 상태를 유지하거나, 장바구니를 유지해주는 것과 같은 예시가 있다.
Statefull Protocol에는 TCP, HTP, Telent 등이 있다.
Stateless Service
클라이언트가 서버에 요청을 보내고 서버는 응답을 한다.
클라이언트에서 서버로의 모든 요청은 이전 요청에 대한 지식에 의존해서는 안된다.
세션 관리는 안하는게 기본이지만 필요한 경우는 클라이언트가 하거나 필요에 따라 DB가 한다.
Stateless Protocol에는 HTTP, UDP 등이 있다.
Scale Out(수평적 확장)
서버가 세션을 처리하면 서버의 수를 늘려 부하를 줄이는 Scale Out에 많은 비용이 든다.
하지만 그림 처럼 세션 처리를 DB에 맡기면 서버의 수를 여러개 늘려도 서버는 응답만 하기 때문에 Scale Out이 용이하다.
REST API의 세션 관리는 어떻게 ?
요즘 많이 보이는 REST API 에서 REST는 Represent State Transfer의 약자로 Roy Fielding의 논문에서 확장 가능한 대규모 클라이언트 - 서버 시스템을 구축하기 위한 이상적인 소프트웨어 아키텍쳐라고 설명한다.
확장을 위해 Stateless가 제약 조건 인데 로그인과 같은 상태를 위해 세션을 사용하면 Statefull 하게 되므로
세션관리를 세션 서버 or DB, JWT, OAuth2.0을 통해 처리하고 리소스 서버는 응답만 하는 방식으로 Stateless를 유지한다.
관련 포스트
참조
https://www.baeldung.com/cs/rest-sessions
https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
Architectural Styles and the Design of Network-based Software Architectures
UNIVERSITY OF CALIFORNIA, IRVINE Architectural Styles and the Design of Network-based Software Architectures DISSERTATION submitted in partial satisfaction of the requirements for the degree of DOCTOR OF PHILOSOPHY in Information and Computer Science by Ro
www.ics.uci.edu
