웹 아키텍처

https://www.educative.io/path/scalability-system-design

웹 아키텍처는 뭘까?

웹 서비스를 제공하기 위해 필요한 컴포넌트 (DB, Backend Server, load balancers, ...) 들의 협동조합이다.
이 중 client-server architecture는 2-tier, 3-tier, n-tier 모델이 취하는 웹의 기본 구조이다.
또한 client-server 구조는 request-response 모델로 동작한다.
이전 포스트에서 client-server 구조에 대해서만 간단히 정리 했는데 구체적으로 어떤 특징들을 가지고 있는지 알아보자.

client

• User Interface를 포함한다.
• presentation layer이다. 애플리케이션을 실제로 사용자가 보고, 느끼게 하는 계층이다.
• JavaScript, HTML, CSS 등으로 작성된다.
• 애플리케이션의 창문과도 같다.

두가지로 client를 구분한다.

• thin client -> User Interface만 가지고 있다. (비즈니스 로직 없음)
• thick client -> 다른말로 fat client라고도 한다. UI와 비즈니스 로직을 둘다 가지고 있다.

server

• client의 request을 수신한다. -> 요청 매개변수로 비드니스 로직을 실행한다. -> 결과를 response로 제공한다.
• 온라인으로 실행하는 서비스, 그리고 모든 컴포넌트(DB, cache, load balancser ...)들은 실행을 위한 서버가 필요하다.
• 특정 작업만을 수행하는 서버도 있다.
  • Proxy server
  • Mail server
  • File server
  • Virtual server
• 최근에는 UI도 별도의 서버에서 호스팅한다.

그렇다면 server와 client는 어떻게 통신할까?

HTTP라는 데이터 교환 규칙위에서 통신을 한다. 기본적으로 HTTP는 request-response model이다.
그리고 HTTP는 매번 독립적으로 실행된다. 그래서 이전 request에 대한 정보가 없다. 그러므로 무상태(state less)하다.

그런데 상태를 저장하지 않는다고 해서 모든 통신이 새로운 통신이라는 말은 아니다.

REST API는 뭔데..

웹 서비스를 구현하는 소프트웨어 설계 기법중 하나이다.
RESTful web services로 잘 알려진 그 기술이다.
REST 규칙을 잘 지키는 API 구현이라고도 할 수 있다.
그래서 REST API가 뭔데..

시스템에 진입하는 단일화된 문역할이다.
그리고 reponse를 캐싱도 한다.

client가 server에 특정 리소스를 요청할 때 하나의 규칙을 따르게 한다. 간단히 입사 지원서 포맷이라고 생각하면 된다.
인사담당자님은 포맷에 작성된 내용이 중요하지 내가 핸드폰으로 작성을 하든 태블릿으로 하든 노트북으로 하든 신경쓰지 않는다.
그냥 정해진 양식에 맞춰진 지원서가 도착했는지 안했는지만 본다.

이처럼 backend는 front에서 어떤 방식으로 데이터가 가공되고 조합되는지 신경쓰지 않을 수 있다. 약속된 형식의 데이터만 request에 담겨져 있기만 하면 된다.

backend는 해당 리소스에 접근할 권한이 있는 client가 요청했는지 여부만을 확인하고 인증된 사용자에 한하여 reponse를 준다.

기존에 jsp를 이용할 때는 비즈니스 로직 자체가 여러 layer에 분산 되어있었기 때문에 리팩토링이나 새로운 기능을 추가할 때 client의 코드또한 고려해야 했기 때문에 어려움이 있었다.

결과적으로 비즈니스 로직은 캡슐화가 될 수 있다. client와 server 서로가 어떤 방식으로 일처리를 하는지는 관심없고 원하는 데이터만 형식에 맞춰서 주고 받기만 하기 때문이다.