HTTP, Request & Response

앞서 REST API에 대해 간략하게 다루었다. 이번엔 웹의 본질인 '요청 및 반환' 에 대해 알아보고자 한다.

 

HTTP 상에서 요청 - 반환을 위해 기본적으로 REST API를 사용하고, 몇 가지 단점을 보완하기 위해 GraphQL도 사용한다. (단점 및 GraphQL은 추후에 다루도록 하겠다.)

 

먼저, 요청-반환의 주체는 2개로 구성된다 : 웹 브라우저와, 웹 서버가 있다.

HTTP

HTTP는 HyperText Transfer Protocol이다. 직역하면, 하이퍼텍스트를 전송하기 위한 프로토콜

WWW(World Wide Web)의 토대이며, 하이퍼텍스트 링크를 사용하여 웹 페이지를 로드하는 데 사용된다. OSI 7 Layers에서 애플리케이션 계층 프로토콜에 속하며, 네트워크 프로토콜 스택의 다른 계층 위에서 실행된다.

일반적으로 Client System에서 Server에 요청하고, Server에서 Response를 보내는 작업이 포함된다.

 

HTTP 요청?

 

HTTP 요청은 웹 브라우저와 같은 인터넷 통신 플랫폼에서 웹 사이트를 로드하는 데 필요한 정보를 요청하는 방법이다.

 

일반적으로 다음의 정보들이 포함된다.

- HTTP 버전 유형

 

- URL

 

- HTTP 메서드

: HTTP 동사라고도 불리는 HTTP 메서드는 HTTP 요청이 쿼리된 서버에서 기대하는 작업을 나타냄. GET, POST 등이 있다.

 

- HTTP 요청 헤더

: 키값 쌍에 저장된 텍스트 정보가 포함되며, 헤더는 모든 HTTP 요청에 포함된다.

 

- 본문

: 요청에서 전송되는 정보의 본문을 포함하는데, 본문에는 사용자 이름 및 비밀번호, 또는 양식에 입력된 기타 데이터와 같이 웹 서버에 제출되는 모든 데이터가 포함된다

 

웹 브라우저와 웹 서버의 요청-반환

일반적으로 우리가 보편적으로 생각하는 프론트엔드와 백엔드 사이의 데이터 및 웹 페이지를 교환하는 방식을 생각하면 되겠다. 주로 HTTP 방식을 사용한다.

 

웹 서버와 웹 서버의 요청-반환

웹 서버 간의 요청 및 반환은 웹 브라우저와 웹 서버 간의 상호작용과 매우 유사하게 작동한다. 일반적으로 HTTP 또는 HTTPS 프로토콜을 사용하여 이루어진다.

 

웹 서버와 웹 서버의 요청-반환은, 사례를 통해 조금 더 구체적으로 보도록 하자.

 

MSA(MicroService Architecture)를 사용하는 곳이라면, 각자 담당한 서비스를 갖는 수많은 서버거 있기 때문에, 서버간의 교환이 필요하다.

 

MSA에 관해서 간략하게만 짚고 가보자.

 

 

 

 

MSA 복잡한 애플리케이션을 작고 독립적으로 배포 가능한 서비스의 집합으로 분해하는 설계 접근 방식이다. 위의 그림이 MSA를 표현한 것이다.

 

MSA를 통해 애플리케이션을 설계하면, 각 서비스가 서로 독립적으로 작동할 수 있도록 설계되어, 느슨한 결합도(Loose Coupling)을 갖게 되고, 이를 통해 각 서비스를 독립적으로 배포할 수 있다는 장점이 생긴다.

 

다시 돌아와서

 

이처럼, MSA를 사용하는 곳이면 각자 담당한 수많은 서버가 존재하기 때문에, 서버간의 교환이 필요한 것이다. (= 웹 서버와 웹 서버간의 요청-반환 작업이 필요하다.)

 

Monolithic Architecture

 

 

MSA와 상반되는 아키텍처인 모놀리딕 아키텍처(Monolithic Architecture)이 존재한다. 모놀리딕은 애플리케이션이 단일 통합 단위로 구축된다. 즉, 하나의 서비스가 모든 서비스를 관장하는 형태이다.

 

모놀리딕 아키텍처는 실행 파일 또는 디렉토리가 한 개이기 때문에 배포가 쉽고, 개발하기가 쉬우며, 테스트가 단순하고, 디버깅이 간편하며, 중앙 집중식 Code base 및 Repository에서 하나의 API는 수많은 API가 MicroService에서 수행하는 것과 동일한 기능을 수행하는 경우가 있다는 등의 장점이 있다.

 

하지만, 모놀리딕 아키텍처는 한쪽 서비스에 문제가 생기면 모든 서버에 영향을 주게 되어, 기타 서비스들이 이용 불가능해질 수 있다는 단점이 존재한다. 이를 SPOF(Single Point of Failure)라고 한다. (단일 이슈가 전체로 퍼지는 것)

 

2009년, 넷플릭스는 IT 인프라를 Private Data Center에서 Public Cloud로 Migration하고, Monolithic Architecture를 MicroService Architecture로 교체하기로 결정하는데, 빠르게 비디오 스트리밍 서비스에 대한 수요를 해결하기 위함이었다.

현재 Netflix는 플랫폼의 개별 부분을 관리하고 지원하는 1,000개가 넘는 MicroService를 보유하고 있다.

 

그럼 MSA는 단점이 없는 아키텍처인가

 

아니다. 

 

여러 서비스 간의 통신과 데이터 일관성 유지가 복잡할 수 있기에, 분산 시스템이 복잡해질 수 있다는 점,

개발 및 운영 관리적인 측면에서 모놀리딕에 비해 어려울 수 있다는 점,

네트워크를 통한 서비스 간 호출은 로컬 호출보다 느릴 수 있으며, 성능에 영향을 줄 수 있다는 단점이 있다. (성능 오버헤드가 증가된다)

 

성능 오버헤드가 증가하는 원인으로 여러가지가 있지만, 그 중에서 HTTP 메서드 수가 증가하는 것이 하나의 원인으로 꼽힌다.

 

MSA에서 각 서비스는 자체적으로 독립된 API를 제공하므로, 시스템의 복잡성이 증가하고 여러 API 호출이 필요해진다.

 

이 문제를 해결하기 위해 API GW(Gateway)가 등장한다.

 

API Gateway

An API gateway accepts API requests from a client, processes them based on defined policies, directs them to the appropriate services, and combines the responses for a simplified user experience. Typically, it handles a request by invoking multiple microservices and aggregating the results. It can also translate between protocols in legacy deployments.

 

API 게이트웨이는 클라이언트의 API 요청을 수락하고, 정의된 정책에 따라 이를 처리하고, 적절한 서비스로 전달하고, 단순화된 사용자 경험을 위해 응답을 결합한다. 일반적으로 여러 마이크로서비스를 호출하고 결과를 집계하여 요청을 처리한다. 또한 레거시 배포의 프로토콜 간 변환도 가능하다.

 

(출처 : https://www.nginx.com/learn/api-gateway/)

 

 

 

API 게이트웨이 및 마이크로서비스 아키텍처

For microservices‑based applications, an API gateway acts as a single point of entry into the system. It sits in front of the microservices and simplifies both the client implementations and the microservices app by decoupling the complexity of an app from its clients.

In a microservices architecture, the API gateway is responsible for request routing, composition, and policy enforcement. It handles some requests by simply routing them to the appropriate backend service, and handles others by invoking multiple backend services and aggregating the results.

An API gateway might provide other capabilities for microservices such as authentication, authorization, monitoring, load balancing, and response handling, offloading implementation of non-functional requirements to the infrastructure layer and helping developers to focus on core business logic, speeding up app releases.

 

마이크로서비스 기반 애플리케이션의 경우 API 게이트웨이는 시스템에 대한 단일 진입점 역할을 한다. 이는 마이크로서비스 앞에 위치하며 클라이언트에서 앱의 복잡성을 분리하여 클라이언트 구현과 마이크로서비스 앱을 모두 단순화한다.

마이크로서비스 아키텍처에서 API 게이트웨이는 요청 라우팅, 구성 및 정책 시행을 담당한다. 일부 요청은 적절한 백엔드 서비스로 라우팅하여 처리하고, 다른 요청은 여러 백엔드 서비스를 호출하고 결과를 집계하여 처리한다.

API 게이트웨이는 인증, 권한 부여, 모니터링, 로드 밸런싱, 응답 처리와 같은 마이크로서비스를 위한 다른 기능을 제공하여 비기능적 요구 사항 구현을 인프라 계층으로 오프로드하고 개발자가 핵심 비즈니스 로직에 집중하여 앱 출시 속도를 높일 수 있도록 돕는다.

 

(출처 : https://www.nginx.com/learn/api-gateway/)