API Gateway
하나의 큰 서비스는 수십~수백개의 작은 서비스로 나뉘어지며(MSA), 만약 클라이언트에서 서비스를 직접 호출하는 형태라면 다음과 같은 문제점이 생길 수 있다.
- 각각의 서비스마다 인증/인가 등 공통된 로직을 구현해야하는 번거로움이 있다.
- 수많은 API 호출을 기록하고 관리하기가 어렵다.
- 클라이언트에서 여러 마이크로 서비스에 대한 번거로운 호출을 해야 한다.
- 내부의 비즈니스 로직이 드러나게 되어 보안에 취약해 진다.
특히 이러한 문제점들은 마이크로 서비스의 갯수가 많아질 수록 기하급수적으로 늘어나게 될 것이다.
어느 규모 이상의 마이크로 서비스 기반 어플리케이션에는 API Gateway를 도입하는 것이 효율적라고 한다.
API Gateway란?
API Gateway는 API 서버 앞 단에서 모든 API 서버들의 엔드포인트를 단일화 해주는 또다른 서버이다. API에 대한 인증과 인가 기능을 가지고 있으며, 메세지의 내용에 따라 어플리케이션 내부에 있는 마이크로 서비스로 라우팅하는 역할을 담당한다.
API Gateway는 REST/JSON 기반으로 보다 가볍게 설계된 것이 특징이다.
API Gateway의 특징
-
인증서 관리나, 인증, SSL, 프로토콜 변환과 같은 기능들은 API Gateway에서한다.
마이크로 서비스 아키텍처(MSA)에서 각각의 서비스에 API 호출에 대한 인증 및 인가를 하는 것은, 같은 소스코드를 서비스 인스턴스들마다 심어주어야 한다는 것을 의미한다.
-> 이러한 경우, 소스의 중복이 심하여 유지 관리가 어려운 것은 물론, 로깅 및 모니터링을 관리하는 것도 매우 어려워지는데, API Gateway는 이러한 불편함을 해소하고자 인증 관련 부분을 직접 관리한다. -
요청 절차의 단순화
API Gateway는 여러 클라이언트의 요청을 단일 클라이언트의 요청으로 대체 가능하도록 한다. 따라서 클라이언트와 백엔드 간의 API 통신량을 줄여주어 대기시간을 줄이고 효율성을 높여 준다.
- 라우팅 및 로드밸런싱
API Gateway는 클라이언트로 부터 접수된 메세지에 따라, API 호출을 적절한 서비스에 라우팅 할 수 있는 기능이 있다. 또한, 서비스 인스턴스들에 대한 부하 분산을 할 수 있다.
-
서비스 오케스트레이션
오케스크레이션은 여러개의 마이크로 서비스를 묶어 새로운 서비스를 만드는 개념인데, 이는 API Gateway에 과도한 부담을 줄 수 있어 높은 기술 이해가 필요한 부분이긴 하다...!
-
서비스 디스커버리
각 서비스를 호출하기 위해서는 IP와 포트를 알고 있어야 하는데, 클라우드는 동적인 환경이기 때문에 서비스의 위치를 찾는 것이 어렵다. API Gateway는 이러한 서비스 디스커버리를 구현할 수 있다.
-> 클라우드에서 인스턴스는 동적으로 할당되기 때문에 IP주소나 포트 정보가 정해지지 않은 데다가 오토스케일링도 일어나고 중지되고 복구되면서 네트워크 위치가 계속해서 바뀐다. 따라서 클라이언트나 API 게이트웨이가 호출할 서비스를 찾는 매커니즘이 필요하고 이를 서비스 디스커버리(Service Discovery)라고 한다. 이러한 로직을 구현하는 쪽에 따라서 두 가지 방식으로 나뉜다.
- 클라이언트 사이드 디스커버리 패턴(Client-Side Discovery Pattern): 서비스 인스턴스의 네트워크 위치를 찾고 로드밸런싱하는 역할을 클라이언트가 담당
- 서버 사이드 디스커버리 패턴(Server-Side Discovery Pattern): ELB(AWS Elastic Load Balancer)가 서버 사이드 서비스 디스커버리 패턴의 좋은 예다. ELB는 일반적으로 인터넷에서 들어오는 외부 트래픽을 로드밸런싱하는 데 사용되고, VPC(Virtual Private Cloud)에서 내부 트래픽을 처리할 때 사용되기도 한다. 클라이언트에서 DNS 이름을 이용해 ELB로 요청(HTTP 또는 TCP)을 보내면 ELB는 등록된 EC2(Elastic Compute Cloud) 인스턴스나 ECS(EC2 Container Service) 컨테이너 사이에서 부하를 분산 한다. 여기서 서비스 레지스트리 역할도 ELB가 한다.
API Gateway 주의점
- API Gateway의 Scale-out 적용이 유연하게 일어나지 않을 경우, API Gateway가 병목지점이 되어 어플리케이션의 성능저하가 일어날 수 있다.
- API Gateway라는 추가적인 계층이 만들어지는 것이기 때문에, 그만큼 네트워크 latency가 증가하게 된다.
추가로 알아둘 것
canary
API Gateway에서 사용되는 canary는 API의 새 버전을 테스트 목적으로 배포하고 같은 단계에서의 정상 작동을 위해 기본 버전은 프로덕션 릴리스로 배포하는 소프트웨어 개발 전략으로, canary는 테스트 버전을 의미한다고 볼 수 있다.
Canary 릴리스 배포에서 전체 API 트래픽은 사전 구성된 비율로 프로덕션 릴리스와 Canary 릴리스로 임의로 분할 된다. 일반적으로 Canary 릴리스에는 API 트래픽 중 작은 백분율이 주어지며, 프로덕션 릴리스가 나머지를 한다. 이 때, 업데이트된 API 기능은 Canary를 통하는 API 트래픽에만 보인다.
-> 테스트 범위 또는 성능을 최적화하기 위해 Canary 트래픽 백분율을 조정할 수 있다.
Canary 트래픽을 적은 수준으로 유지하고 선택이 임의로 이루어지면 대부분의 사용자는 새 버전의 잠재적 버그로 인한 부정적 영향을 받지 않으며, 단일 사용자가 부정적 영향을 계속 받는 경우는 없다고 한다~!
테스트 지표가 요구 사항을 통과한 후에는 Canary 릴리스를 프로덕션 릴리스로 승격하고 배포에서 Canary를 비활성화할 수 있다. 이렇게 하면 새 기능을 프로덕션 단계에서 사용할 수 있다.
참고
1) 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-nvk2kf0zb
2) https://futurecreator.github.io/2018/10/18/service-discovery-in-microservices/
