API Gateway에 대한 이해와 기능

많은 서비스들이 독립적인 기능을 수행하는 작은 단위의 서비스들로 구성된 MSA로 구축하면서

서비스의 복잡도를 줄이고, 변경에 따른 영향을 최소화하고 작은 서비스별로 업무를 맡아 개발/배포를 하고 있다.

하지만 이 작은 서비스들이 무수히 많아진다면 각 서비스들의 엔드포인트를 관리하기 쉽지 않을 것이다.

또한 각 서비스마다 공통으로 들어가는 인증, 로깅같은 기능들을 중복으로 개발해야한다는 문제점도 있다.

이러한 문제점을 해결하기 위해 등장한 것이 바로 API Gateway이다.

 

출처 : https://www.msaschool.io/operation/architecture/architecture-one/

API Gateway는 위 이미지와 같이 클라이언트와 각각의 서비스들 사이에 위치하게 된다.

 

클라이언트는 각 서비스의 엔드포인트 대신 API Gateway로 요청을 보내고

요청을 받은 API Gateway는 라우팅 규칙에 따라 각 엔드포인트로 클라이언트를 대신하여 요청하고

응답을 받으면 다시 클라이언트에게 전달한다.

즉, 모든 API 요청이 단일 진입점인 API Gateway를 통과하여 적절한 서비스로 라우팅되고 응답받게 되는 것이다.

 

이제 API Gateway의 기능들이 뭔지 왜 필요한지를 하나씩 알아보자.

---

공통 로직 처리 기능

API Gateway는 단일 진입점 역할을 하기 때문에 모든 서비스에 공통으로 적용되는 기능을 처리할 수 있다.

API Gateway와 연결된 모든 서비스들이 공통적으로 인증 로직이 필요하다고 가정해보자.

각 서비스마다 공통된 인증 로직을 모두 구현하기에는 유지보수가 아주 극악이 될 수 있다.

API Gateway를 사용하면 클라이언트 인증 요청을 인증 로직이 구현된 인증 서비스에 전달하여 인증 관련 로직을 처리할 수 있다.

 

특정 API 요청마다 매번 인증 검증이 필요하다면 다음과 같이 공통된 인증 로직이 인증 서비스를 거쳐 처리될 것이다.

이 방법 말고도 인증에 대해서는 AWS의 API Gateway의 경우 Authorizer라는 기능으로

인증 프로세스를 직접 관리할 수 있다고 한다.

---

API 사용량 제한

API 남용이나 비용을 관리하기 위해 사용량을 제한할 수 있다.

제한 방식에는 초당/분당/시간당 최대 요청 수 제한하는 처리율 제한과

일일/주간/월간 총 요청 수 제한하는 할당량 제한 방식이 있다.

---

API 통합 기능

API Gateway 없이 직접 호출하는 경우 클라이언트는 다음과 같이

자신이 필요한 정보를 얻기 위해 각각의 서비스에 직접 API를 요청할 것이다.

아래는 상품 정보를 보기 위한 요청이다.

// 클라이언트가 각 서비스에 직접 API 요청
- 상품 정보: http://product-service.com/api/products/123
- 리뷰 정보: http://review-service.com/api/reviews?productId=123
- 재고 정보: http://inventory-service.com/api/inventory/123

 

API Gateway를 사용한다면 클라이언트는 상품 상세 정보 요청을 위한 API Gateway의 URL만 알면 된다.

GET <http://api.example.com/api/products/123/details>

그리고 API Gateway가 라우팅 규칙으로 내부 서비스들과 통신하여 통합된 응답을 반환할 수 있다.

하지만 API Gateway만으로 여러 서비스로 받은 응답을 통합해 클라이언트에게 제공할 수 없다.

필자는 경험해보지 못했지만 이 경우 서버리스인 Lambda를 추가해 데이터를 통합하여 응답할 수 있다고 한다.

AWS API Gateway의 경우 특정 API 요청에만 Lambda를 사용하도록 설정할 수 있다.

또한 엔드포인트별로 다른 통합 방식을 설정할 수도 있다.

 

이를 통해 다음과 같은 장점을 얻을 수 있다.

• 클라이언트는 내부 서비스들의 주소를 몰라도 됨
• 내부 서비스의 URL이 변경되어도 클라이언트는 영향 받지 않음
• 모든 API 요청이 단일 진입점을 통해 이루어짐

클라이언트는 한 번의 API 호출로 필요한 모든 정보를 받을 수 있고, 여러 서비스에 각각 요청할 필요가 없어져서 훨씬 효율적이다.

---

API 캐싱 기능

만약 위 처럼 API 통합 기능을 사용하는 상황일 경우 요청이 많으면 그만큼 Lambda 호출 비용이 잦고

여러 네트워크와 연결하기 때문에 지연도 발생할 수 있다.

특히 Lambda는 호출 시 마다 비용이 과금된다.

이 문제를 해결하기 위해 API를 캐싱할 수도 있다.

 

API Gateway는 클라이언트로 보낸 응답을 캐싱하고, 동일한 요청을 다시 받으면 캐시에 저장된 데이터를 보냄으로써

이 문제를 해결할 수 있고 더욱 빠른 응답이 가능하도록 할 수 있다.

---

메디에이션(Mediation) 기능

메디에이션은 API Gateway가 클라이언트와 서비스 사이에서 요청/응답을 변환하고 처리하는 기능이다.

이 기능은 다음과 같이 활용될 수 있다.

• 단순한 데이터 형식 변환
• 헤더 추가/수정
• 기본적인 프로토콜 변환 (HTTP, WebSocket, REST, SQS 같은 AWS 서비스)
• 파라미터 매핑

예를 들어 클라이언트와 통신은 REST API를 사용하고 내부 적으로는 API Gateway를 통해

gRPC 통신으로 더욱 빠른 응답이 가능하도록 할 수도 있을 것이다.

하지만 지원되지 않거나 복잡한 메디에이션이 필요한 경우 Lambda 사용하거나 별도의 서비스를 구현해야한다.

---

로드 밸런싱 기능

이미 위 설명에도 포함되는 말이지만 API Gateway는 기본적인 로드 밸런싱 기능을 제공한다.

하지만 ‘로드 밸런서’와는 차이가 있기 때문에 이를 비교하려 한다.

기본적인 로드 밸런싱 기능이란 ‘로드 밸런서’와 비교하면 좀더 쉽게 이해할 수 있다.

 

API Gateway의 로드 밸런싱

API 관리가 주 목적이다.

API 사용량을 제한할 수 있다.

단순히 API 요청이 들어오면 라우팅 규칙에 맞게 각 서비스에 요청을 보낸다.

서버의 상태를 고려하지 않는다.

 

로드 밸런서의 로드 밸런싱

트래픽 분산이 주 목적이다.

서버 상태를 지속적으로 헬스 체크하며 장애 서버를 감지하고 제외하며 트래픽을 동적으로 분배한다.