MSA (Micro Service Architecture) 구조와 API Gateway 역할

 

많은 서비스들이 규모가 커질수록 배포, 장애, 확장성과 같은 문제들이 중요해지면서 모놀리식 구조에서 MSA로 전환을 고민하게 된다는 이야기들을 많이 들어보셨을거에요. 이 과정에서 자연스럽게 2개의 구조에서 차이점과 왜 이런 구조가 나오게 되었는지에 대해서 이해가 필요합니다. 

 

최근 MSA 구조에 대한 이해가 필요하게 되면서 구조에 대한 정의와 핵심 요소인 API Gateway에 대해서 알아보겠습니다. 

 

모놀로식 vs MSA

 

기본적인 모놀리식 아키텍처란 여러 도메인의 서비스를 하나의 아키텍처에 구성해둔 것으로 모든 기능이 하나의 어플리케이션으로 구성된 아키텍처를 이야기합니다. 이와 반대로 MSA는 작은 단위의 서비스들 여러 개가 함께 동작하는 서비스로 여러 개의 서버를 이야기합니다. 

 

아래는 GPT와 함께 두 개의 구조를 장단점을 비교해보았습니다. 

 

구분	모놀리식	MSA
구조	하나의 애플리케이션	여러 개의 서비스
배포	전체 배포	서비스별 배포
장애 영향	전체 장애	부분 장애
확장	전체 확장	필요한 서비스만
운영 난이도	낮음	높음
초반 개발	빠름	느림
대규모 트래픽	불리	유리

 

 

 

특히 MSA가 가지는 장점은 하나의 서비스의 장애가 전체 서비스에 영향을 주지 않아서 직접적인 연관이 없는 다른 서비스의 경우는 장애의 영향을 받지 않는다는 점입니다. 또한 특정 서비스가 트래픽이 많아지면 스케일 아웃을 통해 확장성을 높일 수 있습니다.하지만 서비스 간 통신이 복잡하고, 운영 난이도가 상승하며 인증, 로깅, 모니터링이 분산되게 되어 시스템의 관리포인트가 많아진다는 단점을 가지게 됩니다.

 

MSA (Micro Service  Architecture) 구조

 

어플리케이션의 서비스 단위들을 '마이크로 서비스'라고 부릅니다. 또한 각 서비스는 자신마다의 DB를 가지고 REST, gRPC, Message Queue(Kafka, RabbitMQ 등)으로 통신하며 다른 서비스와 강하게 엮이지 않고 독립적인 구조를 가질 수 있습니다.

또한 각 서비스는 독립적으로 배포, 확장, 운영이 될 수 있습니다. 

 

[Client]
↓
[API Gateway]
↓
[회원 서비스]
[주문 서비스]
[결제 서비스]
[배송 서비스]

 

Client (클라이언트) 

: 웹 브라우저, 모바일 앱, 외부 시스템(API 호출)과 같은 서비스를 사용한 주체를 이야기합니다. MSA 구조에서 클라이언트는 개별의 서비스가 아닌 API Gateway만을 호출합니다. 따라서 클라이언트는 각각의 서비스에 대한 주소를 알 필요가 없습니다.

 

API Gateway 

: MSA의 단일 진입점(Single Entry Point) 역할을 하며 어떤 서비스로 보낼지 결정하는 요청 라우팅 처리, 인증/인가 처리, 로깅, 모니터링 등의 공통 로직을 처리하고 요청 제한(Rate Limit), 장애 제어를 하는 주요 역할을 하게 됩니다. 

 

마이크로 서비스

: 기능 별로 분리된 서비스로 도메인 별로 서비스를 의미합니다. 각 서비스는 독립적인 코드 베이스, 배포, 단일 책임 원칙을 가지는 특징들을 가지게 됩니다. 

: 각 서비스들은 서로 협력해야 하기 때문에 REST API, gRPC와 같은 동기 통신이나 Message Queue를 활용하여 사용하는 경우가 많았습니다. 

 

API Gateway가 반드시 필요한 이유

MSA에서는 기능 별로 서비스가 분리되면서 자연스럽게 서비스의 개수도 함께 증가하게 됩니다. 이 때 API Gateway가 없게 된다면 클라이언트는 여러 서비스와 직접적으로 통신해야 하는 구조가 됩니다. 이때 이 구조는 서비스가 늘어나면 늘어날수록 여러 문제들을 발생시킬 수 있습니다. 따라서 선택 사항이 아니라, 분산된 서비스를 하나의 시스템처럼 동작하게 만들어주는 핵심적인 구성 요소라고 볼 수 있습니다. 

 

항목	효과
구조	단일 진입점 확보
보안	외부 노출 최소화
유지보수	공통 로직 중앙화
확장성	서비스 독립성 강화
안정성	장애 전파 방지

 

 

1. 클라이언트가 모든 서비스에 대한 정보를 알아야 하게 되어 무거워짐

  - API Gateway가 없는 경우에 클라이언트는 어떤 서비스들이 존재하는지, 각각 서비스의 주소, 인증 방식, 요청 형식을 모두 알고 있어야 하여 서비스가 무거워 지게 됩니다.

  - 백엔드 서비스 구조의 변경이 필요하게 되면 클라이언트의 수정이 필요하게 되면서 유지보수가 어려워집니다.

 

2. 공통 로직이 모든 서비스에서 중복되게 됨

  - 인증/인가, 로깅, 요청 검증, 요청 제한(Rate Limit)과 같은 모든 서비스에서 필요한 기능들을 각 서비스에 구현하면서 코드 중복 증가, 특정 정책 변경 시 모든 서비스 수정 등을 하면서 유지보수가 복잡하게 될 수 있습니다.

  - 각 서비스들은 비즈니스 로직에만 집중할 수 있게 되어 인증 정책을 한 곳에서 관리 할 수 있고, 서비스 코드의 복잡도를 크게 줄여 줄 수 있게 됩니다. 

 

3. 외부에 모든 서비스가 직접 노출되게 되어 보안 관리가 어려워짐

  - 모든 서비스들이 클라이언트에게 직접적으로 노출되면, 공격 지점이 증가되고 인증 정책에 대한 통일이 어려워지게 됨으로 문제가 발생되게 됩니다. 이 때 API Gateway를 사용하면 외부에 노출되는 지점을 하나로 제한할 수 있게 되면서 보안에 대한 관리를 좀 더 쉽게 할 수 있습니다. 

 

API Gateway가 장애 포인트(SPOF)가 되는 이유

API Gateway 장애는 서비스에 치명적일 수 있습니다.

 

절대 장애가 나선 안돼...

 

 

 

MSA에서 API Gateway는 모든 요청이 지나가게 되는 단일 진입점이 되기 때문에 구조적으로 편리 할 수 있지만, 장애가 나면 전체 서비스가 멈춘 것처럼 보일 수 있는 장애 지점이 되게 됩니다. 모든 요청 트래픽이 Gateway를 거치기 때문에 부하가 집중되게 됩니다.  

 

또한 라우팅 이외에도 위에서 정의한 공통 기능(인증/인가, 요청 제한 등)을 맡게 되기 때문에 기능이 늘어 날 수록 처리 시간이 늘어나고 장애 원인 분석이 어려워질수 있습니다. 또한 공통 기능에 대한 오류들은 곧 전체 장애로 이어 질 수 있기 때문에 대비가 필요합니다. 따라서 다중화, 타임아웃, 서킷 브레이커, 재시도 제어 등 다양한 장치로 장애 전파를 끊고 안정성을 확보하는 것이 중요합니다.