API Gateway 배포 패턴
December 16, 2022
API는 애플리케이션을 구축하는 방식과 조직 내외부에서 데이터를 노출하는 방식을 변화시키고 있습니다. 또한, API의 성공은 그 무결성, 가용성, 성능에 달려 있습니다. Apache APISIX와 같은 API 게이트웨이를 통해 이러한 성공 지표를 달성할 수 있습니다.
API 게이트웨이의 배포와 관련하여 4가지 잘 알려진 패턴이 있습니다: 중앙 집중식 에지 게이트웨이, 2계층 게이트웨이, 마이크로게이트웨이, 사이드카. 이 글에서는 이러한 패턴을 살펴보고 비즈니스에 적합한 API 게이트웨이 배포 패턴을 선택하는 데 도움을 드리겠습니다.
API 게이트웨이란 무엇인가요?
API 게이트웨이는 시스템의 가장자리에 위치하여 소비자와 백엔드 서비스 집합 사이에 위치하며, 정의된 API 그룹에 대한 단일 진입점 역할을 하는 관리 도구입니다. 소비자는 최종 사용자 애플리케이션이나 장치(예: 단일 페이지 웹 애플리케이션 또는 모바일 앱), 다른 내부 시스템, 또는 제3자 애플리케이션이나 시스템일 수 있습니다.
API 게이트웨이 배포 구성 요소
API 게이트웨이는 두 가지 상위 수준의 기본 구성 요소로 구현됩니다: 제어 평면과 데이터 평면. 이러한 구성 요소는 일반적으로 함께 패키징되거나 별도로 배포될 수 있습니다. 제어 평면은 운영자가 게이트웨이와 상호 작용하고 경로, 정책, 필요한 원격 측정을 정의하는 곳입니다. 데이터 평면은 제어 평면에서 지정된 모든 작업이 발생하는 곳으로, 네트워크 패킷이 라우팅되고 정책이 적용되며 원격 측정이 방출됩니다. 예를 들어, APISIX는 다양한 생산 사용 사례에 대해 세 가지 다른 배포 모드 (전통적, 분리형, 독립형)를 제공합니다.
중앙 집중식 에지 게이트웨이
API 게이트웨이는 일반적으로 시스템의 가장자리에 배포되지만, 이 경우 "시스템"의 정의는 매우 유연할 수 있습니다. 스타트업과 많은 중소기업의 경우, API 게이트웨이는 종종 데이터 센터나 클라우드의 가장자리에 배포됩니다. 이러한 상황에서는 전체 백엔드 자산에 대한 정문 역할을 하는 단일 API 게이트웨이(고가용성을 위해 여러 인스턴스로 배포 및 실행)가 있을 수 있으며, API 게이트웨이는 모든 에지 기능을 제공합니다.
API 게이트웨이는 교차 요구 사항을 제공합니다. 예를 들어 _사용자 인증, 권한 부여, 요청 속도 제한, 캐싱, 타임아웃/재시도, 요청/응답 변환, 시스템 내 관측 가능성 구현을 지원하기 위한 메트릭, 로그 및 추적 데이터_를 제공할 수 있습니다.
또한, 많은 API 게이트웨이는 개발자가 API의 라이프사이클을 관리하고, API를 사용하는 개발자의 온보딩 및 관리(예: 개발자 포털 및 관련 계정 관리 및 액세스 제어 제공)를 지원하고, 기업 거버넌스를 제공하는 추가 기능을 제공합니다.
2계층 게이트웨이
대기업과 기업의 경우, API 게이트웨이는 일반적으로 여러 위치에 배포되며, 종종 데이터 센터 주변의 초기 에지 스택의 일부로 배포됩니다. 추가 게이트웨이는 각 제품, 사업 부문 또는 조직 부서의 일부로 배포될 수 있습니다. 이러한 맥락에서, 이러한 게이트웨이는 일반적으로 별도의 구현이며, 지리적 위치(필요한 거버넌스) 또는 인프라 기능(저전력 에지 컴퓨팅 리소스에서 실행)에 따라 다른 기능을 제공할 수 있습니다.
아래 다이어그램은 Apache APISIX API 게이트웨이가 공용 인터넷과 사설 네트워크의 비무장 지대 (DMZ) 사이에 위치하는 방식을 보여줍니다.
마이크로게이트웨이
마이크로게이트웨이는 마이크로서비스 간의 내부 통신을 위해 전적으로 설계되었습니다. 각 개별 마이크로게이트웨이는 다른 정책 집합과 보안 규칙을 가질 수 있으며, 여러 서비스에서 모니터링 및 메트릭을 집계해야 할 수 있습니다.
이 개념은 마이크로서비스를 관리하는 개별 팀이 서비스를 안전하게 노출하는 방법을 제어할 수 있는 기능(전용 게이트웨이)을 제공하는 것입니다. 동일한 개발자 팀이 마이크로서비스와 마이크로게이트웨이를 관리하고 유지보수하므로, 버그를 수정하고 업데이트를 제공하며 개선 사항을 독립적으로 수행하고, 다른 종속성과의 상호 작용을 최소화하면서 변경 사항을 빠르게 프로덕션에 푸시할 수 있으며, 배포 중인 다른 애플리케이션에 영향을 미치지 않습니다.
사이드카 API 게이트웨이
사이드카는 Kubernetes와 같은 독립적인 런타임에서 서비스에 연결된 컨테이너로 API 게이트웨이를 구현합니다. 사이드카는 오토바이에 부착된 사이드카와 유사한 패턴으로, 부모 애플리케이션(서비스 메시라고 불리는 소프트웨어 구성 요소)에 부착되어 애플리케이션을 위한 지원 기능을 제공합니다. 사이드카는 부모 애플리케이션과 동일한 라이프사이클을 공유하며, 부모와 함께 생성되고 폐기되며, 모니터링, 로깅, 구성 및 네트워킹 서비스와 같은 추가 기능을 제공합니다.
이 패턴을 채택하는 이점은 각 서비스 런타임이 자신의 API 게이트웨이를 최상의 방식으로 구성할 수 있다는 것입니다. API 게이트웨이 기능과 설정을 활성화하는 요구 사항은 서비스마다 다를 수 있기 때문입니다. 동시에, 공유 API 게이트웨이 인프라에서 문제가 발생하면 모든 서비스가 영향을 받지 않도록 관심사를 분리합니다. 예를 들어, Amesh는 Apache APISIX를 기반으로 한 또 다른 서비스 메시 솔루션입니다.
앞의 다이어그램은 각 서비스 엔드포인트로의 API 로드 밸런서 및 리소스 라우터 역할을 하는 인그레스를 보여줍니다. 서비스의 진입점은 서비스 엔드포인트 자체가 아니라 사이드카 API 게이트웨이입니다. 사이드카는 서비스 엔드포인트로 트래픽을 라우팅하는 것 외에도 API 게이트웨이가 제공하는 모든 기능을 수행할 수 있습니다.
결론
우리가 이해한 바와 같이, 모든 조건에 적합한 단일 배포 패턴은 없습니다. 때로는 시스템에서 하나 또는 여러 게이트웨이를 사용할 수 있습니다. 배포 선택은 비즈니스의 복잡성과 필요에 따라 달라집니다. 어떤 배포 패턴이 가장 적합한지 결정하는 데 도움이 필요하다면, 우리 커뮤니티 Slack 채널에 참여하여 전문가의 도움을 받아 결정할 수 있습니다.
관련 자료
➔ API 게이트웨이란 무엇이며, 클라우드 네이티브 시대에 왜 필수적인가?.
추천 콘텐츠
➔ 블로그 글 읽기: