[MSA] API Gateway

API Gateway의 필요성

MSA는 큰 서비스를 잘게 쪼개어 개발/운영 하는 아키텍처입니다. 하나의 큰 서비스는 수십~수백개의 작은 서비스로 나뉘어지며, 만약 이를 클라이언트에서 서비스를 직접 호출하는 형태라면 다음과 같은 문제점이 생길 수 있습니다.

• 각각의 서비스마다 인증/인가 등 공통된 로직을 구현해야하는 번거로움이 있습니다.
• 수많은 API 호출을 기록하고 관리하기가 어렵습니다.
• 클라이언트에서 여러 마이크로 서비스에 대한 번거로운 호출을 해야합니다.
• 내부의 비즈니스 로직이 드러나게 되어 보안에 취약해집니다.

특히 이러한 문제점들은 마이크로 서비스의 갯수가 많아질 수록 기하급수적으로 늘어나게 될 것입니다.

어느 규모 이상의 마이크로 서비스 기반 어플리케이션에는 API Gateway를 도입하는 것이 효율적입니다.

API Gateway는 API 서버 앞단에서 모든 API 서버들의 엔드포인트를 단일화 해주는 또다른 서버입니다. API에 대한 인증과 인가 기능을 가지고 있으며, 메세지의 내용에 따라 어플리케이션 내부에 있는 마이크로 서비스로 라우팅하는 역할을 담당합니다.

 

API Gateway의 시작은 SOA의 핵심 인프라라고 할 수 있는 ESB(Enterprise Service Bus)에서 시작되었습니다. 따라서 API Gateway의 많은 부분들이 ESB로 부터 승계되었습니다.
ESB가 SOAP/XML 기반의 무거운 기능을 가졌다면, API Gateway는 REST/JSON 기반으로 보다 가볍게 설계된 것이 특징입니다.

2. 요청 절차의 단순화

여러 마이크로서비스를 대상으로하는 기능을 이용하려 할 때, 만약 API Gateway가 없다면 클라이언트에서 여러 서비스들에 대해 요청을 진행해야 했을 겁니다.
하지만, API Gateway는 여러 클라이언트의 요청을 단일 클라이언트의 요청으로 대체 가능하도록 합니다. 따라서 클라이언트와 백엔드 간의 API 통신량을 줄여주어 대기시간을 줄이고 효율성을 높여줄 수 있습니다.

 

3. 라우팅 및 로드밸런싱

API Gateway는 클라이언트로 부터 접수된 메세지에 따라, API 호출을 적절한 서비스에 라우팅 할 수 있는 기능이 있습니다. 또한, 서비스 인스턴스들에 대한 부하분산을 할 수 있습니다.

 

4. 서비스 오케스트레이션

오케스크레이션은 여러개의 마이크로 서비스를 묶어 새로운 서비스를 만드는 개념입니다. 오케스트레이션 로직을 과도하게 넣는 것은, API Gateway의 부담을 늘리는 것으로, 성능 저하를 일으킬 수 있어, MSA와 API Gateway에 대한 높은 수준의 기술적 이해를 바탕으로 이루어져야 합니다.

 

5. 서비스 디스커버리

API Gateway는 각 서비스를 호출하기위해, 서비스마다의 IP주소와 포트번호를 알고 있어야 합니다. legacy 환경에서는 고정적인 IP주소를 가지고 있기 때문에 크게 문제될 것이 없지만, 클라우드 환경에서는 동적인 환경에서 배포되기 때문에 서비스의 위치를 찾는 것이 어렵습니다.

이러한 서비스의 위치(IP 주소와 포트번호)를 찾는 것을 "Service Discovery"라 하며, API Gateway에서는 서버사이드나, 클라이언트 사이드를 기준으로 하여 서비스 디스커버리를 구현할 수 있습니다.

 

API Gateway 적용시 고려해야 할 사항

1. API Gateway 적용의 가장 큰 단점은 API Gateway를 내부 마이크로서비스와 결합한다는 것입니다. 이러한 결합은 기존 SOA에서의 ESB(Enterprise Service Bus)에서 발생했던 문제점이 다시 발생할 수 있습니다.
2. API Gateway의 Scale-out 적용이 유연하게 일어나지 않을 경우, API Gateway가 병목지점이 되어 어플리케이션의 성능저하가 일어날 수 있습니다.
3. API Gateway라는 추가적인 계층이 만들어지는 것이기 때문에, 그만큼 네트워크 latency가 증가하게 됩니다.

2000년대 후반, 많은 SOA 프로젝트가 실패한 이유로 SOA의 핵심적인 요소 중 하나인 ESB가 꼽히는 경우를 많이 볼 수 있었습니다. 그 이유는 다음과 같습니다.
첫 번째로, 당시 ESB 내부 처리 로직을 XML을 기반으로 하였는데, XML의 파싱은 오버헤드가 큰 작업이었습니다.
두 번째로, ESB는 가벼운 연산 뿐만 아니라, 과도한 Orchestration 등 무거운 로직을 가지고 있었습니다. 특히 ESB를 Gateway로의 특성이 아닌 시스템을 통합하기 위한 역할로 많이 구현하였기 때문에 많은 실패 사례가 발생하였습니다.

 

참조 사이트 : https://velog.io/@tedigom/MSA-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-3API-Gateway-nvk2kf0zbj