CS

API GateWay

nanoh 2024. 4. 18. 08:59
728x90

1. API Gateway란?

  • 최근 많은 서비스들이 독립적인 기능을 수행하는 작은 단위의 서비스들로 구성된 마이크로 서비스 아키텍처(Micro Service Architecture) 형태로 구축되면서 서비스의 복잡도를 줄일 수 있게 되었고, 변경에 따른 영향을 최소화하면서 개발과 배포를 할 수 있다는 장점도 얻게 되었다.
    하지만 여기서 말하는 작은 단위의 서비스가 50개, 100개가 되었을 때, 이 많은 서비스들의 엔드포인트를 관리하는 데 있어서 어려움이 생기고, 또 각각의 서비스마다 공통적으로 들어가는 기능(ex 인증/인가, 로깅 등)들을 중복으로 개발해야 한다는 문제점이 발생한다.
    이러한 문제점을 해결하기 위해 등장한 것이 바로 API Gateway로 API Gateway는 아래 이미지와 같이 클라이언트와 각각의 서비스들 사이에 위치하는데,

)

클라이언트는 각 서비스의 엔드포인트 대신 **API Gateway로 요청을 보내게 되며, 요청을 받은 API Gateway는 설정에 따라 각 엔드포인트로 클라이언트를 대신하여 요청하고, 응답을 받으면 다시 클라이언트에게 전달하는 프록시(proxy) 역할**을 한다.

왜 API Gateway를 사용하지?

  • 인증, 속도 제한과 같은 기능으로 API 남용을 검사하는데 도움을 준다.
  • 개발자가 API가 사용되는 방법에 대한 다양한 시나리오를 찾는데 도움을 준다.
  • 수익을 창출하는 솔루션의 경우 백엔드 프로세스와 청구 시스템 간의 원활한 관계를 구성한다.
  • 마이크로 서비스 배포의 경우 다양한 애플리케이션에 대한 특성 요청을 구성한다.
  • 업데이트가 발생하는 경우에도 API 유지 관리, 업그레이드, 현대화에 필요한 모든 리소스를 확보하는데 도움이 된다.
  • API 게이트웨이는 API에 발생하는 모든 것을 관찰할 수 있으므로 여러 개의 API 처리에 도움을 준다.

2. API Gateway의 주요 기능

  1. 인증/인가 및 토큰 발급
  2. 공통 로직 처리
  3. 로드밸런싱
  4. 메디에이션 기능(Mediation)

2-1. 인증/인가 및 토큰 발급

  • 인증/인가의 경우, 각 서비스마다 공통으로 구현되어야 하는 필수적인 기능이다.
    각각의 서비스마다 인증/인가 처리를 구현하는 것은 매우 비효율적이기 때문에 API Gateway에서 이 처리를 하게 된다.
  • Spring인 경우 각각의 서비스에 Spring Security 의존성을 추가해 해당 기능을 구현 한다.
  • API 사용을 위한 토큰 발급 기능도 마찬가지 이유로 API Gateway에서 처리한다.
    실제로 토큰 발급 기능은 인증을 위한 서비스(= 인증 서버)를 하나 두고 처리되게 한다.

2-2. 공통 로직 처리

  • 인증/인가 외에도 여러 서비스에서 공통적으로 처리해야 할 기능들이 있다.
    공통되는 기능을 각각의 서비스마다 구현하는 것은 번거로울 일일뿐더러 코드 수정이 필요할 때, 각각의 서비스를 다 수정해야 하는 등, 유지보수 측면에서의 어려움도 존재한다.
    공통적으로 사용되는 로직의 경우 API Gateway에서 구현되는 것이 효율적이며, 개발 중복을 줄이는 것뿐만 아니라 표준 준수도 쉽다는 장점을 갖는다.

2-3. 로드밸런싱

  • 대용량 처리 서비스에 있어서 로드밸런싱은 필수적인 부분이다.
    기본적으로는 여러 개의 API 서버로 부하를 분산하는 기능이 주가 되겠지만, API 서버에 장애가 발생했을 때 이를 감지해서 로드밸런싱 리스트에서 빼고, 복구되었을 때 다시 로드밸런싱 리스트에 넣는 기능들이 필요하다.

2-4. 메디에이션 기능(Mediation)

  • 메디에이션이란 “중재” 또는 “조정”이라는 의미를 갖고
    메디에이션 기능 중에는 메세지 호출 변화(Message Exchange Pattern) 있다.
    메세지 호출 패턴은 동기(Sync), 비동기(Async)와 같은 API를 호출하는 메세지 패턴을 정의하는 것인데, API Gateway를 이용하면 아래와 같이 동기 호출을 비동기 호출로 바꿀 수도 있다.

  • 또한 클라이언트의 요청을 하위 서비스가 처리할 수 있도록 데이터 형식을 변형하거나, 하위 서비스의 응답 표준 포맷으로 데이터 형식을 변형하는 메세지 포맷 변환(Message format transformation) 기능도 있다.

  • 프로토콜 변환은 다양한 서비스나 클라이언트를 지원하게 되면 JSON이나 HTTP를 이용한 REST 기반의 통신을 많이 쓰지만 바이너리 기반의 경량 프로토콜을 사용하는 것 처럼 다양한 통신 프로토콜을 지원해야 하는 경우가 있다.
    이러헥 다양한 프로토콜을 지원하기 위해 새로운 서비스를 구현하는게 아닌 API Gateway에서 프로토콜 변환을 이용해 서비스를 호출 한다.

3. API Gateway의 문제점

  1. 안정성
  • API 호출에서 보안 관형을 구현하고 성능을 추적하는 것은 어렵다. 보다 다양한 작은 요청이 존재하므로 마이크로 서비스 생태계의 탭이 된다. 또한 내부와 외부 API에 대한 다양한 안전 관행을 생각해야 하며 보다 많은 작업을 의미한다.
  1. 지속 가능성과 신뢰성
  • API Gateway가 여러 요청을 결합하게 되므로 Gateway가 동작하지 않으면 전체 API 인프라가 붕괴된다.
  1. 복잡성을 유발하는 높은 수준의 종속성
  • 효과적인 작업을 위해서는 모든 마이크로 서비스를 추가해 API Gateway 업데이트를 유지 관리하는 것이 중요하다.
    단일 어플리케이션이 수백만 개의 마이크로 서비스로 교체하는 경우 많은 상황이 발생하며 업데이트 하는 과정이 끝나지 않는 작업으로 이어질 수 있다.
  • AUTH 서버
  • MSA 구성방식