[Web]웹 서버: Monolithic과 MSA

Monolithic과 MSA, 그리고 그 전에

웹의 본질은 Request과 Response이며
Request와 Response의 주체는 Web Browser와 Web Server다.
주로 사용자가 웹 페이지를 요청할 때 발생한다.

Brower와 Server의 요청과 반환

웹 브라우저와 웹 서버의 요청과 반환은 우리가 흔히 아는 FE와 BE간의 소통이다.
FE와 BE사이의 데이터 또는 웹 페이지를 주고 받는다.

Server와 Server의 요청과 반환

웹 서버와 웹 서버간의 요청과 반환에 대한 대표적인 예시는 Open API이다.
브라우저와 서버의 통신은 사용자의 요청에 의해 발생하지만 서버와 서버간의 통신은 사용자의 요청이 아닌, 한 서버가 다른 서버에 데이터를 요청하거나 특정 작업을 요청하는 상황에서 발생한다.
Open API는 여러 웹 서비스가 자신의 데이터를 다른 서버와 공유하거나 외부 서비스에서 데이터를 받아올 수 있도록 만들어져있다.

Monolithic과 MSA

Monolithic과 MSA는 소프트웨어 시스템을 설계하고 배포하는 주요 방식이다.

Monolithic

Monolithic아키텍처는

• 애플리케이션이 하나의 커다란 코드베이스로 통합된 형태로
• 단일 웹 서버가 다수 서비스를 제공한다.

이런 아키텍처로 인해

• 한쪽 서비스에 문제가 발생하면 모든 서버에 영향을 주고
• 기타 서비스를들 모두 사용하지 못하는 문제가 발생할 수 있다.
• 애플리케이션의 모든 기능이 하나의 프로세스에서 실행되기 때문에, 한 부분에서 발생하는 오류가 전체 시스템에 영향을 미친다

이렇게 단일 이슈가 전체 이슈로 퍼지는 경우를 SPOF(Single Point of Failure 라고 한다.

Scale Out과 Scale Up

Scale Out과 Scale Up은 시스템의 성능을 향상시키기 위한 확장 방식으로,
둘 다 시스템을 확장하여 더 많은 트래픽을 처리하거나 더 많은 데이터를 관리할 수 있도록 하는 방법이다.

Scale Up

기존의 서버나 시스템의 성능을 강화하는 방식

• 더 강력한 하드웨어 추가(CPU, RAM, 디스크)
• 고성능 장비 도입(서버, 스토리지)

Scale Out

여러 대의 서버를 추가하여 시스템을 확장하는 방식

• 서버 추가
• 분산 처리 (여러 대의 서버에서 작업을 분산 처리)

Monolithic 아키텍처에서는
1. 애플리케이션이 하나의 코드베이스에 통합되어 있고,
2. 애플리케이션의 여러 기능이 강하게 결합되어 있다.
3. 애플리케이션 전체를 함께 배포하고 실행해야 하기 때문에

특정 부분을 확장(Scale Out)하거나, 최적화하는 것이 어렵다.

예를 들어, 애플리케이션의 특정 부분만 부하가 높아도 전체 애플리케이션을 복제해야하며 필요한 부분만 확장할 수 없다.

MSA(MicroService Architecture)

MSA 아키텍처는

• 다수의 웹 서버로 각각 개별 서비스를 제공하므로
• Monolithic의 문제점인 SPOF를 극복할 수 있다.

또한

• 하나의 서버는 하나의 서비스를 관장하여
• SRP(Single Responsibility Principle)을 준수하고
• 하나의 서버, 하나의 서비스 문제가 다른 서버 문제로 전파되지 않는다.

따라서

• 애플리케이션을 작은 독립된 서비스로 나누어 구성하는 방식을 취해
• 독립적인 배포가 가능하다.

API Gateway의 필요성

Monolithic의 문제점을 극복할 수 있는 MSA도 문제점을 가지고 있다.
MSA 클라이언트에서 서비스를 직접 호출할 때

• 각 서비스마다 인증/인가 등 공통 로직 구현의 번거로움
• 수많은 API 호출을 기록/관리하기가 어려움
• 클라이언트에서 여러 마이크로 서비스에 대한 번거로운 호출

이는 Mircroservice가 많아질 수록 문제점이 기하급수적으로 발생한다.

서비스가 많아지면서 수백개의 서버, 수백개의 API가 있을 때
어떤 서버의 어떤 API를 호출할건지에 대한 관리의 복잡성

이런 MSA의 문제점은 API Gateway로 해결할 수 있다.

API Gateway의 역할

• 모든 서버에 대한 모든 API를 중앙화하여 관리
  • 각 서버마다 어떤 API를 제공하는지 Swagger를 통한 버전관리를 한다(API 명세)
  • 어떤 서버의 API를 다른 어떤 서버가 사용하는가에 대한 것은 Consumer-Producer의 관점으로 볼 수 있다.
• 클라이언트의 요청을 적절한 서비스로 전달
  • 따라서 클라이언트는 여러 서비스의 엔드포인트를 알 필요가 없다
  • API Gateway의 단일 엔드포인트롤 통해 필요한 서비스 사용
• 로드밸런싱
• 인증/권한 부혀
  • 클라이언트 요청에 대해 API Gateway가 수행한다.