분산 게이트웨이 액터: 진화하는 API 관리

Rajesh Narayanan 작성

검토 및 기여: Ian Smith, Sam Bisbee, Andrew Stiefel, Lori MacVittie, Mike Wiley 외.

F5 CTO실의 견해

F5의 CTO 오피스 팀은 지난 1년여 동안 API 관련 기술 분야를 탐구해 왔습니다. 이번 최신 백서는 끊임없이 진화하는 API 생태계를 이해하기 위한 노력의 연장선입니다.

앞서 자세히 설명한 API 난립 관리의 어려움은 API 게이트웨이 난립이라는 문제로 이어질 것이며, 이러한 문제를 해결하는 데 기존의 접근 방식만으로는 충분하지 않을 것입니다. GraphQL과 같은 그래프 기술은 API와 관련된 복잡성을 완화하는 데 큰 가능성을 지니고 있지만, 문제는 연결성, 보안, 라우팅을 넘어서기 때문에 이는 해결책의 일부일 뿐입니다. 시스템 및 애플리케이션 확장에 관한 약 30년간의 전문성을 바탕으로 한 올바른 접근 방식은 GraphQL을 활용하되 전적으로 의존하지 않는 연합형이 아닌 분산형 아키텍처에 기반합니다.

이 백서에서는 API 게이트웨이 난립 문제를 해결하기 위한 분산 아키텍처 접근 방식을 살펴봅니다.

초록

디지털 경제는 API를 기반으로 구동되며, 이로써 API 주도형 경제가 실현될 것입니다. API 스프롤 백서에 이어, 저희는 API 스프롤의 영향을 제거하거나 완화하는 방법을 파악하고자 했습니다. GraphQL은 API 스프롤의 파급 효과를 줄일 수 있는 유망한 기술로 보였지만, 개발자가 기존 API 코드베이스의 상당 부분을 다시 작성해야 하는 부담이 있습니다. 그러나 최근에는 GraphQL을 효과적인 게이트웨이 액터로 활용할 수 있다는 관점이 부상하고 있습니다. 게이트웨이 액터는 클라이언트 가까이에서 생성되어 API 요청을 시작하는 함수 또는 프로세스입니다. 이 게이트웨이 액터는 API 요청을 종단하는 최초의 API 게이트웨이 역할을 합니다. 또한 일시적으로 존재하다가 요청 처리를 완료한 후 폐기될 수도 있습니다.

개발자와 운영 팀이 API 게이트웨이보다 API 관리를 우선시한다는 점 외에도, API 확산으로 인해 API 게이트웨이 확산 문제가 발생한다는 사실도 확인했습니다. 개발자의 주된 관심사는 API가 적시에 올바르게 작동하도록 하는 것입니다. 반면 운영 팀은 검색, 보안, 사용성, 액세스 제어 등의 측면에 더 중점을 둡니다. 오늘날 API 게이트웨이는 API 인프라의 핵심 구성 요소이므로, API가 확산될수록 API 게이트웨이 배포도 늘어나 결국 API 게이트웨이 확산으로 이어진다는 점이 분명해졌습니다.

향후 API 아키텍처는 API의 난립을 수용하는 동시에 배포와 운영을 간소화하는 방향으로 발전해야 합니다. 여기서 제안하는 아키텍처는 API 게이트웨이 디자인 패턴이 나아가야 할 다음 단계입니다. GraphQL이 이 아키텍처의 핵심이거나 필수 요소는 아니지만, 게이트웨이 액터 패턴을 강화할 수 있습니다.

요약

API 관리 생태계는 API 게이트웨이 모놀리스를 관리하는 방식에서 벗어나 보다 현대적인 시스템 설계 접근 방식으로 전환해야 합니다. 이를 통해 더욱 민첩하고 효과적인 API 관리 생태계를 구축할 수 있습니다.

“새롭게 부상하는 API 생태계의 규모와 복잡성을 더 이상 기존 API 게이트웨이만으로 관리하기 어려워지면서, API 아키텍처는 전환점에 서 있습니다.”

API 게이트웨이 난립 – 분산형 모놀리스 관리

이미 API 경제에서 과제로 떠오른 API 난립은 API 게이트웨이 난립으로도 이어집니다. 이는 다양한 API 게이트웨이 공급업체의 기술과 각자의 방식을 고수하는 API 게이트웨이 관리 팀으로 인해 API 관리가 통제 불가능해진 상황을 의미합니다. API 호출의 진입점 역할을 하는 전용 소프트웨어 계층인 기존 API 게이트웨이(API-GW)만으로는 새롭게 부상하는 API 생태계의 규모와 복잡성을 더 이상 감당할 수 없게 되면서, API 아키텍처는 전환점에 도달했습니다.

그림 1은 API 난립 관리에서 API 게이트웨이 난립 관리로 어떻게 전환되었는지를 보여줍니다.

그림 1: API 난립에서 API 게이트웨이 난립으로

위의 설계 패턴은 중앙 집중식 제어 플레인을 나타내며, 그림 2와 같이 API 게이트웨이가 분산형 데이터 플레인을 구성합니다.

API 게이트웨이는 현대적인 소프트웨어 아키텍처의 필수 구성 요소로, API를 중앙에서 제어하고 보호할 수 있게 해줍니다. 하지만 API 게이트웨이가 제공하는 기능이 늘어나면서 점점 더 복잡해지고 관리하기도 어려워졌습니다. 많은 경우 이러한 게이트웨이는 광범위한 기능이 하나의 패키지에 통합된 모놀리식 시스템으로 발전했습니다.

그림 2: 분산 모놀리스 관리

여러 게이트웨이를 관리하는 방식은 분산 설계처럼 보일 수 있지만, 실제로는 진정한 분산 구조에 미치지 못합니다. 게이트웨이들이 여전히 긴밀하게 결합되어 있어 분리하기 어려운 리소스와 구성을 공유하기 때문입니다. 그 결과 많은 기업이 분산형 모놀리스와 그로 인해 발생하는 모든 문제를 관리하게 됩니다.

레거시 API 게이트웨이 아키텍처

그림 3은 기존 API 게이트웨이의 아키텍처를 보여줍니다. 클라이언트에서 시작된 API 요청은 먼저 공유 또는 전용 네트워크를 통해 전송되고, 방화벽을 거쳐 API 게이트웨이에 도달합니다. 그런 다음 역방향 프록시 역할을 하는 API 게이트웨이가 트래픽을 API 워크로드로 전달합니다.

그림 3: 기존 API 게이트웨이 아키텍처

레거시 API-GW는 API 게이트웨이가 전사적으로 배포되거나, API가 난립하는 상황에서 API 워크로드가 운영상 여러 리전, 영역, 멀티 클라우드 또는 엣지로 이동할 때 API 관리의 병목 지점이 됩니다. 여러 팀이 전사 차원의 단일 관리 및 통제 지점 없이 각자 여러 API-GW를 구축합니다. 개별 API 서비스 또는 API 서비스 그룹이 다른 인프라(클라우드 또는 기타 환경)로 이동하는 경우, 운영팀은 등록, 검색, 인증, 네트워킹, 보안, 거버넌스·위험·규정 준수(GRC) 정책 등 API 관리의 모든 요소를 이전할 수 있는 방법을 갖추어야 합니다.

따라서 그림 3에 제시된 아키텍처는 시간이 지남에 따라 분산형 모놀리스를 관리해야 하는 상황(그림 2)으로 이어지므로, 장기적으로 확장 가능하지도 실용적이지도 않습니다.

API 게이트웨이 병목 지점을 만드는 문제는 두 가지입니다. (1) API 게이트웨이 공급업체의 난립, (2) 기업이 더 많은 애플리케이션을 더 다양한 환경에서 운영하게 됨에 따라 확장해야 하는 문제입니다.

API 게이트웨이 공급업체의 난립: API 게이트웨이 공급업체의 난립에 대처하는 것은 사람과 조직 차원의 과제입니다. 모든 팀이 단일 API 게이트웨이 공급업체를 채택하도록 설득하기가 어려울 수 있고, 새로운 공급업체로 마이그레이션하는 작업도 번거로울 수 있기 때문입니다. 그 결과 조직은 여러 게이트웨이 공급업체를 관리하는 데 시간과 리소스를 투입하게 됩니다. 이 문제를 해결할 수는 있지만, 현실적으로 완전히 해결하기는 어려울 수 있습니다.
애플리케이션 확장: 단일 위치에서 더 많은 사용자를 지원하거나 여러 위치에 배포해야 하는 경우 애플리케이션 확장이 문제가 될 수 있습니다. 이를 위해서는 애플리케이션을 수평 또는 수직으로 확장해야 합니다. 그러나 애플리케이션이 확장됨에 따라 API 게이트웨이도 함께 확장해야 하며, 경우에 따라 현재 아키텍처 패턴에 따른 확장을 지원하기 위해 여러 위치에 배포해야 합니다. 이로 인해 API 게이트웨이의 운영 관리가 복잡해질 수 있습니다.

솔루션: 분산 게이트웨이 액터 패턴

그림 4는 API 게이트웨이의 무분별한 확산 문제를 해결하기 위한 분산 게이트웨이 액터 패턴을 보여줍니다. 분산 패턴 자체는 새로운 것이 아니지만, 이 백서에서는 이를 API 게이트웨이의 맥락에서 공식화합니다. 클라이언트가 API 요청을 시작하면, 수명이 짧은 분산 게이트웨이 액터가 가능한 한 클라이언트와 가까운 위치에 필요에 따라 인스턴스화됩니다. API 전송 계층은 게이트웨이 액터에서 간소화된 API 게이트웨이로 API 요청을 전송하고, 이 게이트웨이는 요청을 적절한 API 워크로드로 라우팅합니다. 분산 액터의 GraphQL 지원은 이 패턴의 작동에 필수적인 요건이라기보다 구현상의 세부 사항에 가깝지만, 서비스 오케스트레이션과 같은 기능을 지원할 수 있게 해줍니다. 따라서 새로운 서비스 오케스트레이션 계층을 만드는 대신 GraphQL을 통해 해당 기능을 제공할 수 있습니다.

그림 4: GraphQL 기반 분산 게이트웨이 액터

명확히 설명하자면, 트래픽은 오른쪽에서 왼쪽으로 흐릅니다. 즉, 클라이언트는 오른쪽에 있으며, 그림 5와 같이 API 요청은 클라이언트에서 시작됩니다.

그림 5: 트래픽은 클라이언트(오른쪽)에서 API 워크로드(왼쪽)로 흐릅니다

기업 내부 및 기업 간 API를 관리할 때 API 게이트웨이에 지나치게 의존하는 방식을 대체하거나 줄이기 위해 게이트웨이 액터를 활용하는 새로운 배포 패턴이 부상하고 있습니다. GraphQL이 이 아키텍처에 반드시 필요한 것은 아니지만, 게이트웨이 액터가 GraphQL을 지원하기에 적합한 수단이라는 점에서 이를 도입하기에 시의적절합니다.

“기업 내부 및 기업 간 API를 관리할 때 API 게이트웨이에 지나치게 의존하는 방식을 대체하거나 줄이기 위해 게이트웨이 액터를 활용하는 새로운 배포 패턴이 부상하고 있습니다. ”

API 관리에서 API 게이트웨이의 역할

API 게이트웨이를 더 잘 이해하려면 먼저 최신 API 관리 인프라를 구성하는 다양한 요소를 살펴보는 것이 중요합니다.

API 관리 인프라 및 기능

그림 6은 API 관리에 필수적인 다양한 기능과 구성 요소를 종합적으로 시각화하여 보여줍니다. 백엔드 서비스로 향하는 트래픽을 라우팅하고 관리하는 데 필요한 API 게이트웨이 외에도 여러 가지 중요한 인프라 구성 요소가 있습니다. 여기에는 인증, 속도 제한, 캐싱, 서비스 메시 등을 위한 솔루션이 포함될 수 있습니다. 조직은 이러한 기능을 도입함으로써 API에 대한 제어력을 확보하고 보안을 강화하며 성능을 최적화할 수 있습니다.

그림 6: API 관리 및 인프라 기능

API 게이트웨이 공통 기능

API 게이트웨이에서 일반적으로 잘 알려진 기능을 살펴보겠습니다:

라우팅: 요청의 경로나 콘텐츠를 기준으로 적절한 백엔드 서비스로 요청을 전달합니다.
인증 및 권한 부여: 단일 진입점에서 요청을 인증하고 권한을 부여하여, 권한이 있는 클라이언트만 백엔드 서비스에 액세스할 수 있도록 합니다.
요청 속도 제한: 클라이언트가 기본 API에 요청할 수 있는 속도를 제한하여 과도한 사용을 방지하고 백엔드 서비스가 과부하되지 않도록 보호합니다.
캐싱: 기본 API의 응답을 캐싱하여 백엔드 서비스에 필요한 요청 수를 줄이고 성능을 향상합니다.
프로토콜 변환: HTTP와 WebSocket 등 서로 다른 프로토콜 간에 변환하여 클라이언트가 다양한 프로토콜을 통해 기본 API에 액세스할 수 있도록 합니다.
부하 분산: 요청을 여러 백엔드 서비스에 분산하여 확장성과 안정성을 향상합니다.
보안: 암호화 및 복호화와 같은 보안 작업을 처리하여 데이터가 안전하게 전송되도록 합니다.
분석 및 모니터링: 사용량 지표와 오류 정보를 추적하고 보고하여 시스템이 어떻게 사용되고 있는지 파악할 수 있도록 하며, 성능 병목 현상과 오류를 식별하는 데 도움을 줍니다.
버전 관리: 기본 API의 버전을 관리하여 클라이언트가 필요에 따라 서로 다른 API 버전에 액세스할 수 있도록 합니다.
서비스 검색: 사용 가능한 백엔드 서비스를 검색하고 요청을 해당 서비스로 동적으로 라우팅하여 더욱 동적이고 유연하게 서비스를 검색할 수 있도록 합니다.

맥락: API 게이트웨이 집중 조명

API 관리 인프라의 기능을 분석한 결과, API 게이트웨이의 역할을 더 깊이 이해하고 현재의 모놀리식 API 게이트웨이 설계를 대체할 방안을 모색할 필요가 있음을 확인했습니다.

API 수가 증가하면서 이미 API 난립과 API 게이트웨이 난립이 발생하고 있으며, 점점 더 많은 클라이언트가 모바일화되거나 고도로 분산되고 있습니다. 또한 엣지를 비롯한 모든 곳에서 컴퓨팅 인프라를 사용할 수 있게 되었습니다. 따라서 API 생태계의 민첩성, 유연성, 확장성, 성능 및 보안을 향상할 수 있는 접근 방식이 필요합니다.

이 새로운 접근 방식에는 진정한 분산 아키텍처의 이점을 최대한 활용할 수 있는 간결한 설계가 필요합니다.

API 게이트웨이

API 게이트웨이의 기능과 범위를 더 자세히 분석하여 그 미묘한 특성과 한계를 살펴봅니다.

API 게이트웨이는 오늘날 API 관리 인프라의 핵심 구성 요소입니다. 기본적으로 API 게이트웨이는 리버스 프록시로서 클라이언트와 백엔드 서비스 사이에서 중개자 역할을 하며, 수신 요청에 대해 다양한 작업을 수행합니다. 예를 들어 게이트웨이는 요청을 적절한 백엔드 서비스로 전달하기 전에 인증, 속도 제한, 요청 라우팅, 보안 정책 적용, 모니터링, 버전 관리 등의 작업을 수행할 수 있습니다. 백엔드 서비스가 요청을 처리하고 응답을 반환하면 API 게이트웨이는 해당 응답을 클라이언트에 다시 전달하기 전에 캐싱, 프로토콜 변환, 응답 처리 등의 작업을 수행할 수 있습니다.

API 수가 증가함에 따라 API 게이트웨이는 기본적인 라우팅을 넘어 다양한 새로운 기능을 포함하도록 발전하면서 사실상 모놀리식 시스템이 되었습니다. 이제 이러한 게이트웨이는 성능을 개선하고 백엔드 서비스의 부담을 줄이기 위해 인증 및 요청 속도 제한과 같은 작업을 관리합니다. 그러나 이렇게 기능이 강화되었음에도 API 게이트웨이는 여전히 백엔드 서비스에 접근하는 단일 지점이므로 고도로 분산된 환경에서는 문제가 발생할 수 있습니다.

특히 클라우드, 하이브리드 멀티클라우드 및 엣지 인프라가 부상하면서 API 게이트웨이 방식으로 민첩성, 보안 및 관리 용이성을 유지하기가 더욱 어려워졌습니다. 클라이언트, 디바이스 및 애플리케이션 워크로드가 광범위한 위치에 분산될 수 있으므로 API 게이트웨이는 필요한 수준의 엣지 친화적 아키텍처를 제공하는 데 적합하지 않을 수 있습니다.

API 게이트웨이의 과제

API 게이트웨이는 광범위한 작업을 처리하고 여러 시스템과 통합해야 하므로 일반적으로 배포 및 관리가 어렵습니다. API 게이트웨이 관리는 복잡할 수 있지만, API의 가용성, 보안 및 확장성을 보장하는 데 반드시 필요한 작업입니다. 기업은 API 게이트웨이를 더욱 효과적으로 관리하고 모니터링하기 위해 API 관리 플랫폼과 같은 전문 도구를 사용하는 경향이 있습니다.

아래 목록이 모든 요소를 망라하는 것은 아니지만, API 게이트웨이의 복잡성을 높이는 몇 가지 요소는 다음과 같습니다:

구성 관리: API 게이트웨이에는 라우팅 규칙, 속도 제한, 보안 설정 등 관리하고 유지해야 하는 다양한 구성 옵션과 설정이 있는 경우가 많습니다. 특히 기반 API와 클라이언트 수가 늘어날수록 이러한 설정을 관리하는 작업은 복잡하고 많은 시간이 소요될 수 있습니다.
다른 시스템과의 통합: 게이트웨이는 인증 및 권한 부여 시스템, 로드 밸런서, 데이터베이스 등 다양한 시스템과 통합되어야 합니다. 특히 기반 시스템 간의 통합이 원활하지 않거나 API 게이트웨이가 여러 프로토콜 또는 데이터 형식을 처리해야 하는 경우에는 통합이 복잡해질 수 있습니다. 기업이 여러 공급업체의 API 게이트웨이를 복수로 배포한 경우에는 이러한 문제가 더욱 심각해집니다.
확장성 및 가용성: API 게이트웨이는 대량의 요청을 처리하고 고가용성을 보장할 수 있어야 합니다. 특히 수많은 백엔드 서비스와 클라이언트를 다루는 경우에는 이를 관리하기가 복잡할 수 있습니다.
보안: API 보안의 핵심 구성 요소인 보안 API 게이트웨이는 민감한 데이터를 보호하고 액세스를 제어할 수 있도록 구성하고 관리해야 합니다. 이는 복잡할 수 있으며 지속적인 모니터링과 관리가 필요합니다.
버전 관리: 기반 API와 클라이언트 수가 증가함에 따라 API의 여러 버전을 관리하고 클라이언트가 올바른 버전에 액세스하도록 보장하는 일이 점점 더 어려워질 수 있습니다.
모니터링 및 문제 해결: API 게이트웨이는 대량의 데이터를 수집하고 생성할 수 있습니다. 대규모 기업에서는 게이트웨이가 여러 위치에 분산될 수 있어 애플리케이션의 전반적인 상태에 영향을 미치는 이벤트 간의 연관성을 파악하고 문제를 해결하기가 어렵습니다.

API 게이트웨이 난립

API 게이트웨이 난립은 조직 내에 여러 개의 독립적인 API 게이트웨이가 확산되는 현상을 의미합니다. 서로 다른 팀이나 사업부가 자체 API를 만드는 경우가 많으며, 이로 인해 각기 다른 API를 처리하기 위한 여러 개의 독립적인 API 게이트웨이가 생성될 수 있습니다. 또한 팀마다 서로 다른 유형의 API를 처리하기 위해 각기 다른 공급업체의 API 게이트웨이나 솔루션을 사용할 수도 있습니다.

이로 인해 서로 다른 기능을 갖춘 여러 API 게이트웨이가 배포됩니다.

API 게이트웨이의 난립은 다음과 같은 몇 가지 추가적인 문제를 야기합니다:

API 게이트웨이 관리 확장: 독립적인 API 게이트웨이가 여러 개 있으면 게이트웨이를 관리하고 유지하기가 어려워질 수 있으며, 특히 기반 API와 클라이언트 수가 증가할수록 더욱 그렇습니다.
동서 트래픽의 비효율성: 게이트웨이가 여러 개이면 요청이 여러 게이트웨이를 거쳐야 할 수 있으므로 지연 시간이 늘어나고 성능이 저하될 수 있습니다.
보안 정책의 일관성: 여러 게이트웨이를 관리하기는 어려울 수 있으며 보안 정책이 일관되지 않게 적용될 수 있습니다. 이로 인해 민감한 데이터를 보호하고 액세스를 통제하기가 더 어려워집니다.
표준화된 거버넌스: 게이트웨이가 여러 개이면 모든 API가 적절하게 관리되고 표준 및 모범 사례를 준수하도록 보장하기 어려울 수 있습니다.
비용 증가: 여러 게이트웨이를 운영하면 인프라, 개발 리소스 및 유지 관리 비용이 증가할 수 있습니다.
가중되는 통합 문제: 게이트웨이가 여러 개이면 다른 데이터베이스, 데이터 웨어하우스, 데이터 분석 도구와 같은 다른 시스템 및 기술과 통합하기가 더 어려워집니다.

기업은 API 관리 및 거버넌스를 중앙 집중화하고 단일 유형의 API 게이트웨이를 사용하기 위해 노력해야 합니다. 이렇게 하면 앞서 언급한 API 게이트웨이 난립 문제를 완화할 수 있지만, API 게이트웨이를 단일화하는 전략은 결코 간단하지 않습니다.

기업 내 API 게이트웨이 표준화의 과제

기업이 자체적으로 성장하거나 인수를 통해 확장됨에 따라, 특정 사업부(BU)에 속한 내부 팀들은 API 게이트웨이 기술이나 공급업체를 선정하는 과정에서 서로 의견이 충돌할 수 있습니다. 그 이유는 다음과 같습니다:

기술: 팀이나 사업부마다 사용하는 기술 스택이 다르거나 선호하는 API 게이트웨이 솔루션이 달라 단일 유형의 게이트웨이로 표준화하기가 어렵습니다.
레거시 시스템: 일부 팀은 다른 유형의 API 게이트웨이를 사용하여 구축한 기존 시스템을 보유하고 있으며, 특히 해당 시스템이 아직 사용 중인 경우 이를 새로운 게이트웨이로 교체하기가 어렵습니다.
사용자 지정: 일부 팀은 특정 요구 사항을 충족하기 위해 기존 API 게이트웨이를 사용자 지정하며, 이러한 사용자 지정 사항을 새 게이트웨이에 동일하게 적용하기 어려울 수 있습니다.
교체 비용: 기존 API 게이트웨이를 새로운 표준 게이트웨이로 교체하려면 개발과 유지 관리 측면에서 모두 많은 비용이 들 수 있습니다.
개발자 교육: 팀마다 전문성 수준이 다르므로 다른 공급업체의 새로운 게이트웨이 기술을 익히거나 관련 교육을 받아야 할 수 있으며, 이 과정에는 많은 시간과 비용이 들 수 있습니다.
제한된 리소스: 조직은 변경에 투입할 개발자, 예산, 시간이 제한되어 있어 새로운 게이트웨이를 구현하기가 어렵습니다.
애플리케이션 종속성: 팀이나 사업부마다 기존 게이트웨이에 대한 종속성이 서로 다릅니다. 예를 들어 특정 시스템과 연동되어 있거나 기타 맞춤형 통합이 적용되어 있어 새로운 게이트웨이로 전환하기가 어렵습니다.
타사 솔루션: 게이트웨이와 통합되는 타사 솔루션을 사용하는 팀은 해당 타사 솔루션을 지원하지 않는 새로운 솔루션으로 마이그레이션하기 어렵습니다.

따라서 기존 애플리케이션을 담당하는 팀이 이미 확고한 방식과 견해를 갖추고 있다면, 서비스 중단을 초래하지 않기 위해 다른 배포 패턴으로 전환하려 하지 않을 것입니다.

따라서 기존 API 인프라의 여러 한계를 고려하는 동시에 API 게이트웨이의 난립을 주요 고려 사항 중 하나로 다루는 새로운 접근 방식이 필요하다는 결론을 내릴 수 있습니다.

설계 시 고려 사항

다음은 전체 목록은 아니지만, 솔루션을 구축할 때 반영해야 한다고 판단되는 몇 가지 주요 설계 고려 사항을 요약한 것입니다:

현재 배포 환경과의 공존: 조직이 끊임없이 변화하는 기술 환경에 발맞추고자 노력함에 따라, 기업에서 다양한 API 게이트웨이 배포 환경을 운영하는 것은 흔한 일이 되었습니다. 기존 API 인프라를 전면 교체하는 방식은 핵심 비즈니스 운영에 차질을 줄 수 있으므로 현실적이지 않습니다. 따라서 모든 신규 배포는 현재 배포된 아키텍처와 공존할 수 있도록 설계해야 합니다.
API 게이트웨이 기능 표준화: 기업의 API 전략에서 가장 중요한 목표는 API 게이트웨이 기능을 표준화하는 것이어야 합니다. 다양한 API와 사업부별로 서로 다른 요구 사항으로 인해 이는 쉽지 않은 과제일 수 있습니다. 그럼에도 이러한 표준화는 조직의 디지털 혁신을 뒷받침할 수 있는 안정적이고 안전한 인프라를 구축하는 데 필수적입니다.
엣지 배포 활용: 엣지 인프라는 API 수를 기하급수적으로 늘릴 잠재력이 있을 뿐만 아니라, 기업이 게이트웨이 액터를 엣지에 더 가깝게 배치할 기회도 제공합니다. API 생성에 사용되는 동일한 인프라를 분산형 게이트웨이 액터 생성에도 활용할 수 있기 때문입니다. 따라서 솔루션은 API 요청을 시작하는 클라이언트와 엣지 인프라 간의 근접성을 최대한 활용해야 합니다.
전송 방식에 구애받지 않음: 분산 게이트웨이 액터 아키텍처를 구현할 때 중요하게 고려해야 할 사항은 특정 전송 메커니즘에 종속되지 않아야 한다는 것입니다. 기업이 기존 IP 네트워크, 오버레이 네트워크, VPN 또는 저지연 메시징 인프라 중 무엇을 사용하든 솔루션은 전송 메커니즘에 구애받지 않아야 합니다. 이를 통해 유연성을 높이고 기업이 구체적인 필요와 요구 사항에 가장 적합한 전송 메커니즘을 선택할 수 있습니다.
GraphQL 지원: GraphQL은 기존 REST API에 비해 많은 장점이 있어 API 개발에서 점점 더 널리 사용되고 있습니다. 주요 장점 중 하나는 데이터에 세분화된 방식으로 접근할 수 있어 클라이언트가 한 번의 요청으로 필요한 데이터를 정확히 지정할 수 있다는 점입니다. 또한 GraphQL은 여러 서비스의 데이터를 집계하는 과정을 간소화할 수 있으므로 서비스 조합과 오케스트레이션에 적합한 아키텍처입니다. 이를 통해 네트워크 오버헤드를 줄이고 성능을 향상할 수 있으며, 특히 하나의 요청을 처리하기 위해 여러 API 서비스를 사용하는 분산 시스템에서 효과적입니다. 마지막으로 GraphQL은 강력한 형식의 스키마와 쿼리 언어를 통해 API 검색 가능성을 높이고 클라이언트 개발을 더욱 용이하게 할 수 있습니다.
보안은 기본 전제입니다: 가장 중요한 설계 목표는 기업의 API 보안 태세를 한층 강화하는 것이어야 합니다. 이 솔루션은 API 요청 인증 및 권한 부여, 액세스 제어 구현, 크로스 사이트 스크립팅(XSS) 및 SQL 인젝션 공격과 같은 일반적인 보안 위협 방지 등의 일부 기능을 포괄할 수 있습니다. 어떠한 경우에도 새로운 솔루션이 기존 위협 모델을 약화하거나 공격 표면이 달라질 정도로 크게 변경해서는 안 됩니다. 보안을 설계 목표의 최우선 순위로 삼아, 아키텍처는 API 통신에 더욱 안전한 환경을 제공하고 데이터 유출 및 기타 보안 사고의 위험을 줄여야 합니다.

이러한 설계 고려 사항을 바탕으로 구체적인 요구 사항을 도출할 수 있으며, 당사는 이를 분산 게이트웨이 액터(DGA) 솔루션에 반영했습니다.

분산 게이트웨이 액터

이제 API 게이트웨이를 충분히 살펴보았으므로, 분산 게이트웨이 액터 솔루션을 설명할 수 있습니다.

분산 게이트웨이 액터 설계

분산 게이트웨이 액터(DGA) 디자인 패턴은 엣지 컴퓨팅과 클라이언트 가까이에서 사용할 수 있는 컴퓨팅 환경에서 영감을 얻었습니다. 이 아이디어의 핵심은 각 게이트웨이 액터를 클라이언트와 최대한 가까운 곳에 초분산 배치하고, 트랜잭션이 진행되는 동안에만 존재하게 한 뒤 트랜잭션이 끝나면 제거하는 것입니다.

“분산 게이트웨이 액터(DGA) 디자인 패턴은 엣지 컴퓨팅과 클라이언트 가까이에서 사용할 수 있는 컴퓨팅 환경에서 영감을 얻었습니다.”

가정

이 솔루션의 기반이 되는 몇 가지 가정은 다음과 같습니다.

엣지 컴퓨팅이 더욱 보편화되면서 이제 클라이언트와 지리적으로 더 가까운 곳에서 사용할 수 있는 컴퓨팅 리소스를 찾을 수 있게 되었습니다. 게이트웨이 액터는 이러한 엣지 컴퓨팅 노드에 인스턴스화할 수 있습니다. DGA를 매우 가볍고 일시적으로 구현하여 어떤 엣지 컴퓨팅 환경에서도 인스턴스화할 수 있도록 하는 것이 목표입니다.

API 전송은 게이트웨이 액터와 API 게이트웨이 간의 네트워크 구축을 수반하므로 인프라의 핵심 구성 요소입니다. 필요한 인프라 유형은 공급업체나 기업에 따라 달라질 수 있습니다. 예를 들어 대규모 퍼블릭 클라우드는 자체 백본을 사용하여 API 전송을 운영할 수 있습니다. 또 다른 구현 방식으로는 기업 데이터 센터 내의 기존 고대역폭·저지연 네트워크 위에 저지연 메시징 버스를 계층화할 수 있습니다.

API 게이트웨이 기능

다시 말해, API 게이트웨이는 기본적으로 HTTP 트래픽을 적절한 API 워크로드로 라우팅하는 것을 주된 기능으로 하는 리버스 프록시입니다. 이 접근 방식은 모든 API가 로컬 온프레미스 네트워크나 가용 영역 내의 가상 프라이빗 클라우드(VPC)처럼 동일한 위치에 배치된 경우에는 적합합니다. 하지만 API 수가 늘어나거나, API가 하이브리드 인프라 전반으로 분산되거나, 단순히 이동성을 갖게 되면 이러한 API 게이트웨이 설계 방식은 비효율적이고 운영이 복잡하며 비용도 많이 듭니다.

그림 6에 설명된 모든 기능을 분류하는 방법에 대해서는 다양한 견해가 있을 수 있지만, API 관리 인프라가 세심하게 조율해야 하는 여러 구성 요소로 이루어진 복잡한 배포 환경이 되었다는 점에는 동의할 수 있습니다.

그림 7: GraphQ 기반 분산 게이트웨이 구성 요소

그림 7은 그림 6에 제시된 API 관리의 다양한 특징과 기능을 분산 게이트웨이 액터 아키텍처에 매핑합니다. 이 매핑은 각 특징과 기능이 DGA 접근 방식에 어떻게 부합하는지를 시각적으로 보여 주며, API 관리 구성 요소가 아키텍처 내에 원활하게 통합되어 있음을 강조합니다.

중앙 집중식 기능

위에 나열된 기능 대부분에는 논리적으로 중앙 집중화할 수 있는 관리 구성 요소가 포함되어 있습니다. 우리의 목표는 관리 플레인을 재설계하는 것이 아니라, 가능하다면 특정 기능을 제거하는 것입니다.

핵심 API 게이트웨이 기능

이러한 기능은 데이터 플레인 기능이므로 API에 구현하고 애플리케이션 워크로드와 함께 배치하는 것이 가장 좋습니다. API 게이트웨이는 모든 외부 트래픽의 진입점 역할을 하는 현대적인 마이크로서비스 아키텍처의 핵심 구성 요소입니다. API 게이트웨이의 핵심 기능은 라우팅, 부하 분산, 동적 라우팅, 상태 확인, 재시도 및 대체 처리로 분류할 수 있습니다.

API 게이트웨이는 들어오는 요청을 적절한 마이크로서비스로 전달하고, 여러 인스턴스에 트래픽을 분산하며, 동적 라우팅을 지원하고, 마이크로서비스와 해당 인스턴스의 상태를 모니터링하며, 실패한 요청을 재시도하고, 마이크로서비스를 사용할 수 없거나 장애가 발생한 경우 대체 응답을 제공합니다. 인증, 권한 부여, 속도 제한, 캐싱, 로깅과 같은 기타 기능은 시스템의 구체적인 요구 사항에 따라 엣지에 분산하거나 중앙 집중식 기능으로 구현할 수 있습니다.

이러한 모듈식 접근 방식은 더욱 유연하고 최적화된 아키텍처를 구현할 수 있게 하며, 엔터프라이즈 API 인프라를 간소화하고 현대화하며 확장하기 위한 권장 사항의 핵심입니다.

통합형

공급업체들은 API 게이트웨이와 API 관리를 API 게이트웨이 기능의 일부로 잘못 혼동하는 경우가 많지만, 실제로는 별도로 다뤄야 하는 서로 다른 두 가지 기능입니다. API 게이트웨이는 클라이언트의 요청을 백엔드 서비스로 라우팅하는 역할을 하는 반면, API 관리는 액세스 제어, 요청 속도 제한, 분석, 개발자 포털 관리 등 더 광범위한 기능을 포괄합니다.

“일부 공급업체는 API 게이트웨이와 API 관리 기능을 하나의 제품으로 제공하기도 하지만, 두 기능의 차이점을 이해하고 각각의 구체적인 요구 사항에 따라 별도로 평가하는 것이 중요합니다.”

일부 공급업체는 API 게이트웨이와 API 관리 기능을 하나의 제품으로 제공하기도 하지만, 이러한 기능 간의 차이를 이해하고 각각의 구체적인 요구 사항에 따라 별도로 평가하는 것이 중요합니다. 이러한 기능을 결합하면 혼란을 초래할 수 있으며 조직의 API 인프라가 지닌 유연성과 확장성을 제한할 가능성이 있습니다. 이는 API 게이트웨이 기능의 분산에 대한 당사의 입장을 이해하는 데에도 매우 중요합니다.

게이트웨이 액터 – 인라인 기능

여기에 나열된 기능은 데이터 경로에 인라인으로 배치되어야 하는 핵심 기능입니다. 분산 게이트웨이 패턴에서는 API 게이트웨이의 일부 인라인 기능도 분산됩니다. 이러한 기능에는 액세스 제어, 속도 제한, 요청 검증, API 분석, 사용량 보고, 오류율 모니터링, 경고 및 이벤트 처리, 인증 통합, 서드 파티 통합, 모니터링 및 로깅 통합, 엣지 캐싱, 압축이 포함됩니다.

이러한 기능을 분산 게이트웨이 패턴으로 전환하면 다음과 같은 이점이 있습니다:

API 게이트웨이 부하 감소: 중앙 집중식 API 게이트웨이의 부하를 줄이고 시스템의 성능과 확장성을 개선하는 데 도움이 됩니다.
응답 시간 단축: 이러한 기능을 클라이언트와 더 가까운 위치에 배포하여 응답 시간을 단축하고 지연 시간을 줄일 수 있습니다. 데이터와 기능을 캐싱하면 엣지에서 호스팅되는 API 게이트웨이가 수신 요청에 신속하게 응답할 수 있습니다.

예를 들어 액세스 제어, 속도 제한, 요청 검증은 클라이언트와 더 가까운 위치에 배포된 엣지 게이트웨이 액터가 처리할 수 있습니다. 이를 통해 중앙 집중식 API 게이트웨이가 처리해야 하는 요청 수를 줄여 성능과 확장성을 향상할 수 있습니다. 마찬가지로 API 분석, 사용량 보고, 오류율 모니터링, 알림 및 이벤트 처리, 모니터링 및 로깅 통합도 엣지 게이트웨이가 담당할 수 있으며, 여러 마이크로서비스의 데이터를 수집하고 집계할 수 있습니다.

게이트웨이 액터 – GraphQL 후보

오늘날 API 게이트웨이가 지원하는 중요한 기능 중 하나는 서비스 구성 및 오케스트레이션입니다. 이 기능은 상당히 복잡해질 수 있지만, 간소화된 API 게이트웨이에서 지원되지 않는다면 문제가 될 수 있습니다. 저희는 GraphQL이 기존 API의 일종의 미들웨어 역할을 하면서 서비스 구성을 구현하는 흥미로운 접근 방식이 될 수 있다고 생각합니다.

API 게이트웨이는 모든 API를 파악할 수 있으므로 서비스 컴포지션을 수행하기에 적합한 위치가 됩니다. 이를 통해 개발자는 새로운 서비스를 작성할 필요 없이 게이트웨이 뒤에 있는 API를 결합하여 비즈니스 로직을 강화할 수 있으며, 이러한 API는 서비스 컴포지션 계층에서 더욱 쉽게 조합할 수 있습니다.

GraphQL에서는 클라이언트가 사용할 수 있는 데이터의 구조를 정의하는 강력한 형식의 스키마를 통해 서비스 컴포지션을 구현할 수 있습니다. 클라이언트는 데이터가 어떤 서비스나 소스에서 제공되는지와 관계없이 이 스키마를 사용하여 필요한 데이터를 정확히 지정하는 쿼리를 구성할 수 있습니다. 쿼리를 데이터 소스에 매핑하는 함수인 리졸버는 적절한 서비스나 소스에서 데이터를 가져오는 데 사용됩니다. 하지만 GraphQL이 더 나은 보안을 제공한다고 해도, 실제 보안 수준은 코드를 작성하는 개발자의 역량에 달려 있습니다.

기타 기능 및 함수

아직 강조되지 않은 몇 가지 기능이 그림 6: API 관리 및 인프라 기능에 남아 있습니다. 이러한 나머지 기능은 개별 관리 및 운영 기능이나 데이터 플레인 기능으로 이전할 수 있습니다.

특정 구현 방식이나 공급업체 기술을 암시하지 않기 위해 의도적으로 ‘액터’라는 용어를 사용합니다. 게이트웨이 액터는 메서드, 함수, 워커, 스레드 및 프로세스를 기반으로 구현할 수 있으며, VM, 컨테이너, 서버리스 또는 공급업체별 기타 접근 방식을 기반으로 하는 인프라를 사용할 수 있습니다.

컴포넌트의 기능 및 동작

분산 게이트웨이 액터(DGA) 아키텍처에서 채택한 접근 방식은 API 게이트웨이 기능을 간소화하고, 기타 인라인 기능을 엣지 또는 제어 플레인으로 이동합니다.

제어 플레인

API 게이트웨이 기능 외에도 DGA 아키텍처에서는 모놀리식 API 게이트웨이 내에 구현하기보다 논리적으로 중앙 집중화된 구성 요소인 컨트롤 플레인에서 더 효과적으로 제공할 수 있는 기능을 식별할 것을 권장합니다. 기존 API 인프라의 관리 및 제어 기능을 확장하여 이러한 추가 기능을 포함할 수 있습니다.

간소화된 API 게이트웨이

따라서 API 게이트웨이를 간소화하려면 모든 API 게이트웨이 공급업체가 공통 구성 매개변수 집합을 통해 관리할 수 있는 표준 핵심 기능 집합을 도출해야 합니다.

이러한 전환을 추진하려는 기업은 기존 배포 환경에 영향을 주거나 전면적인 교체 작업을 수행할 필요 없이 애플리케이션별로 DGA 아키텍처를 단계적으로 도입할 수 있습니다.

분산 게이트웨이 액터

DGA의 중요한 특징 중 하나는 각 게이트웨이 액터가 일시적이며, API 세션이 지속되는 동안에만 인스턴스화된다는 점입니다(즉, 한 클라이언트가 한 번의 API 호출을 수행하는 동안).

분산 게이트웨이 액터는 기존 API 게이트웨이보다 더 유연하고 확장성이 뛰어나며 비용 효율적일 수 있습니다. 여러 공급업체의 모놀리식 API 게이트웨이에 의존해 API 트래픽을 집계하고 처리하는 대신, 게이트웨이 액터를 사용하면 개발자가 각 API에 맞는 개별 게이트웨이 인스턴스를 지정하고 네트워크 에지에 더 가깝게 배포할 수 있습니다. 이를 통해 API 자체의 구체적인 요구 사항에 맞춰 더 세밀하게 제어하고 사용자 지정할 수 있습니다.

이 새로운 접근 방식은 확장성도 한층 높여 줍니다. 개발자는 대규모 중앙 집중식 게이트웨이를 관리하는 데 따르는 부담을 걱정할 필요 없이, 트래픽 증가에 대응해 필요에 따라 게이트웨이 액터 인스턴스를 손쉽게 가동할 수 있습니다.

게이트웨이 액터는 기술적 이점뿐만 아니라, 기업이 실제로 사용하는 임시 게이트웨이 액터 인스턴스에 대해서만 비용을 지불할 수 있게 해 기존 API 게이트웨이보다 비용을 절감할 수 있습니다. 이러한 배포 모델은 새로운 수익 모델을 창출할 기회도 열어줄 수 있습니다.

“게이트웨이 액터는 기술적 이점뿐만 아니라, 기업이 실제로 사용하는 임시 게이트웨이 액터 인스턴스에 대해서만 비용을 지불할 수 있도록 하여 기존 API 게이트웨이보다 비용을 절감할 수 있게 해줍니다. ”

게이트웨이 액터 배치

API 전송 계층을 활용하면 DGA는 API 인그레스 위치를 API 게이트웨이와 사실상 분리할 수 있습니다. DGA를 에지, 즉 API를 호출하는 클라이언트와 더 가까운 위치로 이동할 수 있습니다. API는 DGA에서 종단된 후 어떤 방식으로든 전송될 수 있습니다. 이는 그림 3: 레거시 API 게이트웨이 아키텍처에서 클라이언트 트래픽이 API 게이트웨이와 토폴로지상 인접한 위치로 유입되는 것과는 다릅니다.

결론

따라서 당사의 의도는 특정 공급업체나 배포 방식에 종속되지 않는 접근 방식을 제안하는 것이었습니다. 공급업체마다 앞서 설명한 것과 유사한 목표를 달성하기 위해 이러한 구성 요소를 구축하는 고유한 지식재산권을 보유할 수 있기 때문입니다.

이 백서에서는 여러 분기에 걸쳐 API 난립, Edge 2.0 아키텍처와 API 경제(https://www.f5.com/company/blog/inverting-the-api-is-the-digital-transformation-that-enterprises-need-to-participate-and-compete-in-an-api-economy), 그리고 GraphQL을 연구하며 얻은 교훈을 요약했습니다. 기존 API 인프라에 대해서는 아직 결론이 나지 않았지만, 새로운 접근 방식이 필요하다고 생각합니다.

전 세계의 모든 개별 디바이스나 개체에 내재된 가치를 실현할 수 있다는 가능성만으로도 새로운 접근 방식을 모색할 충분한 이유가 됩니다. 현재의 레거시 API 인프라는 겉보기에는 분산형이지만 내부적으로는 모놀리식 구조이므로, 이제는 여기에서 벗어나야 합니다.

새롭게 부상하는 API 경제의 잠재력을 최대한 끌어낼 수 있는 벤더 중립적 방안으로 분산형 GraphQL 기반 게이트웨이 액터 접근 방식을 제안합니다.

보고서 다운로드