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 gateway 설계 패턴이 지향하는 다음 진화 형태입니다. GraphQL이 아키텍처의 중심 또는 필수 요소는 아니지만 게이트웨이 액터 패턴을 개선시키는 기능이 있습니다.
요약
API 관리 생태계는 API 게이트웨이 모놀리스 관리에서 벗어나 보다 현대적인 시스템 설계 접근 방식으로 전환되어야 합니다. 이를 통해 보다 민첩하고 효과적인 API 관리 생태계를 구축할 수 있습니다.
API gateway sprawl (스프롤) – 분산 모놀리스 관리
API 경제 내에서 이미 까다로운 과제인 API 스프롤은 API 게이트웨이 스프롤로 이어지며, 다양한 API 게이트웨이 공급업체 기술과 API 게이트웨이를 관리하는 독선적인 팀으로 인해 API 관리는 통제할 수 없는 상황이 되었습니다. 우리는 API 아키텍처의 변곡점에 있는데, API 호출의 진입점 역할을 하는 전용 소프트웨어 레이어인 레거시 API 게이트웨이(API-GW)가 새로운 API 생태계의 규모와 복잡성을 관리하기에는 더 이상 충분하지 않기 때문입니다.
그림 1은 API Sprawl 관리에서 API Gateway Sprawl 관리로의 전환 방법을 보여줍니다.
위의 설계 패턴은 중앙에서 관리되는 제어 평면을 나타내며, API 게이트웨이는 그림 2에 나온 대로 분산 데이터 평면을 형성합니다.
API 게이트웨이는 현대적인 소프트웨어 아키텍처의 필수 구성 요소이며 API에 대한 중앙 제어 및 보안 지점을 제공합니다. 그러나 API 게이트웨이가 제공하는 기능의 수가 증가함에 따라 점점 더 복잡해지고 관리하기 어려워졌습니다. 대부분의 경우, 이러한 게이트웨이는 단일 패키지에 다양한 기능이 함께 묶여 있는 모놀리식 시스템으로 진화했습니다.
여러 게이트웨이를 관리하는 것이 분산 설계로 보일 수 있지만 현실은 진정한 분산에 미치지 못한다는 것입니다. 이는 게이트웨이가 여전히 긴밀하게 결합되어 분리하기 어려운 리소스와 구성을 공유하기 때문입니다. 그 결과, 많은 기업이 분산 모놀리스와 이로 인해 발생하는 모든 문제를 관리해야 합니다.
레거시 API Gateway 아키텍처
그림 3은 기존 API Gateway의 아키텍처를 보여줍니다. 클라이언트에서 생성된 API 요청은 먼저 공유 네트워크 또는 전용 네트워크를 통해 전송되고 API Gateway에 도달하기 전에 방화벽을 통과합니다. 그 다음, 리버스 프록시 역할을 하는 API Gateway가 트래픽을 API 워크로드로 전달합니다.
API 게이트웨이가 기업 전체에 배포되거나 API 워크로드가 지역, 영역, 여러 클라우드 또는 엣지 간에 운영적으로 이동하면서 API 스프롤과 경쟁할 때 레거시 API-GW는 API 관리의 걸림돌이 됩니다. 엔터프라이즈 관리 및 제어의 단일 지점 없이 여러 팀에서 여러 API-GW를 스핀업합니다. 개별 또는 API 서비스 그룹이 다른 인프라(클라우드 또는 기타)로 이동하는 경우, 운영팀은 등록, 검색, 인증, 네트워킹, 보안, 거버넌스 위험 및 규정 준수(GRC) 정책 등 API 관리의 모든 측면을 마이그레이션할 수 있는 방법을 가지고 있어야 합니다.
따라서 그림 3에 나온 아키텍처는 시간이 지나면 분산 모놀리스 관리(그림 2) 문제가 발생하기 때문에 장기적으로 확장성 또는 실용성이 떨어집니다.
API 게이트웨이 혼잡 지점을 만드는 문제는 두 가지로, (1) API 게이트웨이 공급업체의 무질서한 확산, (2) 기업이 많은 위치에서 많은 애플리케이션을 실행하는 경우 필요에 따른 규모 확장으로 인한 문제입니다.
- API 게이트웨이 공급업체의 무질서한 확산: API 게이트웨이 공급업체의 무질서한 확산을 처리하는 것은 인간이 해결해야 할 과제입니다. 모든 팀이 단일 API 게이트웨이 공급업체를 채택하도록 설득하는 것은 어려울 수 있으며 새로운 공급업체로 마이그레이션하는 것은 번거로운 작업이 될 수 있습니다. 그 결과, 조직은 여러 게이트웨이 공급업체를 관리하기 위해 시간과 리소스를 소모하게 됩니다. 이 문제를 해결할 수는 있지만 현실적으로 완전히 실현 가능하지 않을 수 있습니다.
- 애플리케이션 규모 확장: 애플리케이션 규모 확장은 애플리케이션이 단일 위치 내에서 더 많은 사용자를 지원해야 하거나 여러 위치에 배포해야 하는 경우 문제가 됩니다. 이를 위해서는 애플리케이션이 수평 또는 수직으로 확장되어야 합니다. 그러나 애플리케이션이 확장되면 API 게이트웨이도 확장되어야 하며, 경우에 따라서는 현재 아키텍처 패턴에 기반한 규모 확장을 지원하기 위해 여러 위치에 배포해야 합니다. 이로 인해 API 게이트웨이 관리가 운영상 복잡해질 수 있습니다.
해결책: 분산 게이트웨이 액터 패턴
그림 4는 API 게이트웨이 스프롤을 해결하기 위한 분산 게이트웨이 액터의 패턴을 설명합니다. 분산 패턴 자체가 새로운 것은 아니지만, 이 백서에서는 API 게이트웨이의 컨텍스트 내에서 이를 공식화합니다. 클라이언트가 API 요청을 시작하면 분산 게이트웨이 액터는 일시적이며 가능한 한 클라이언트에 가까운 곳에서 온디맨드로 인스턴스화됩니다. API 요청을 게이트웨이 액터에서 간소화된 API 게이트웨이로 전송하는 것은 API 전송 계층의 책임이 되며, 이 게이트웨이는 요청을 적절한 API 워크로드로 라우팅합니다. 분산된 액터에서 GraphQL 지원을 사용하는 것은 이 패턴이 작동하기 위한 필수 요구 사항이라기보다 세부 사항이지만, 서비스 오케스트레이션과 같은 기능을 지원할 수 있게 해줍니다. 따라서 새로운 서비스 오케스트레이션 레이어를 만드는 대신 GraphQL이 해당 지원을 제공할 수 있습니다.
명확히 하자면, 트래픽 패턴은 오른쪽에서 왼쪽으로 진행됩니다. 즉, 그림 5와 같이 클라이언트는 오른쪽에 있고 API 요청은 해당 클라이언트에서 시작됩니다.
게이트웨이 액터를 사용하여 기업 내부 및 기업 전반에서 API를 관리하기 위해 API 게이트웨이에 대한 과도한 의존성을 대체하거나 줄이는 새로운 배포 패턴이 등장하고 있습니다. GraphQL이 아키텍처에 반드시 필요한 것은 아니지만, 게이트웨이 액터가 GraphQL을 지원하는 데 적합한 수단이기 때문에 도입은 시의적절합니다.
게이트웨이 액터를 잠재적인 솔루션으로 더 깊이 이해하려면 API 인프라, 특히 API 게이트웨이의 현재 상태를 면밀히 검토해야 합니다. 이는 API 인프라의 운영 및 확장 문제에 중대한 영향을 미치는 것이 게이트웨이 스프롤이라고 판단했기 때문입니다.
API 게이트웨이를 더욱 잘 이해하려면 먼저 최신 API 관리 인프라의 다양한 구성 요소를 검토해야 합니다.
그림 6은 API 관리에 필수적인 다양한 기능과 구성 요소에 대한 포괄적인 시각적 표현을 제공합니다. 백엔드 서비스로 트래픽을 라우팅하고 관리하는 데 필요한 API 게이트웨이 외에도 몇 가지 다른 중요한 인프라 구성 요소가 있습니다. 여기에는 인증, 속도 제한, 캐싱 및 서비스 메시 등에 대한 솔루션이 포함될 수 있습니다. 이러한 기능을 통합함으로써 조직은 API를 제어하고 보안을 강화하며 성능을 최적화할 수 있습니다.
API 게이트웨이의 일반적으로 인정되는 익숙한 기능에 대해 살펴보겠습니다.
- 라우팅: 요청의 경로 또는 내용에 따라 적절한 백엔드 서비스로 요청을 라우팅합니다.
- 인증 및 승인: 요청을 단일 유입 지점으로 인증하고 승인된 클라이언트만 백엔드 서비스에 액세스할 수 있도록 합니다.
- 속도 제한: 클라이언트가 기본 API에 대한 요청을 할 수 있는 속도를 제한하여 과도한 사용을 방지하고 백엔드 서비스를 과부하로부터 보호합니다.
- 캐싱: 기본 API로부터의 응답을 캐싱하여 백엔드 서비스에 대한 요청 수를 줄이고 성능을 향상시킵니다.
- 프로토콜 변환: HTTP 및 WebSockets 등의 여러 프로토콜 간에 변환할 수 있으므로 클라이언트가 서로 다른 프로토콜을 사용하여 기본 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 Gateway Sprawl (스프롤)
API Gateway Sprawl (스프롤)은 독립적인 여러 API 게이트웨이가 조직 내에서 확산되는 것을 의미합니다. 서로 다른 팀이나 사업부는 종종 자체 API를 생성하며, 이러한 서로 다른 API를 처리하기 위해 여러 독립적인 API 게이트웨이를 만들 수 있습니다. 또한 팀마다 서로 다른 유형의 API를 처리하기 위해 서로 다른 공급업체 또는 솔루션의 API 게이트웨이를 사용할 수도 있습니다.
이로 인해 여러 API 게이트웨이가 배포되며 이러한 게이트웨이는 모두 다양한 기능 세트를 갖추고 있습니다.
API 게이트웨이 스프롤은 다음과 같은 몇 가지 추가적인 과제를 야기합니다.
- API 게이트웨이 관리 규모 확장: 여러 개의 독립적인 API 게이트웨이가 있으면 특히 기본 API 및 클라이언트의 수가 증가함에 따라 게이트웨이를 관리하고 유지 관리하는 것이 어려워질 수 있습니다.
- east-west 트래픽의 비효율성: 여러 게이트웨이로 인해 요청이 여러 게이트웨이를 통과해야 하므로 지연 시간이 늘어나고 성능이 저하될 수 있습니다.
- 보안 정책의 통일성: 여러 게이트웨이를 관리하는 것은 어려울 수 있으며 일관성 없는 보안 정책으로 이어질 수 있으므로 민감한 데이터를 보호하고 액세스를 제어하기가 더 어려워집니다.
- 표준화된 거버넌스: 여러 게이트웨이를 사용하면 모든 API가 제대로 관리되고 표준 및 모범 사례를 준수하는지 확인하기 어려울 수 있습니다.
- 비용 증가: 게이트웨이가 여러 개인 경우 인프라, 개발 리소스 및 유지 관리 비용이 증가할 수 있습니다.
- 통합 문제 증폭: 게이트웨이가 여러 개이면 다른 데이터베이스, 데이터 웨어하우스 및 데이터 분석 도구와 같은 다른 시스템 및 기술과 통합하기가 더 어려워집니다.
기업은 API 관리 및 거버넌스를 중앙화하고 단일 유형의 API 게이트웨이를 사용하기 위해 노력해야 합니다. 이렇게 하면 위의 API 게이트웨이 스프롤 문제를 완화할 수 있지만, API 게이트웨이에 대한 균질화된 전략은 절대 간단하지 않습니다.
기업에서 API Gateway (게이트웨이) 표준화 과제
기업이 유기적으로 또는 인수를 통해 성장함에 따라 API 게이트웨이 기술 또는 공급업체를 선택하는 와중에 특정 사업부(BU)에 연계된 내부 팀이 서로 대립하게 됩니다. 여기에는 다음과 같은 이유가 포함됩니다.
- 기술: 팀이나 사업부마다 기술 스택이 서로 다르거나 선호하는 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가 매우 가볍고 일시적이므로 모든 엣지 컴퓨팅에서 인스턴스화될 수 있도록 구현하는 것입니다.
API 전송은 게이트웨이 액터와 API 게이트웨이 사이의 네트워크 구축이 포함되기 때문에 인프라의 중요한 구성 요소입니다. 필요한 인프라 유형은 공급업체 또는 기업에 따라 달라지며 매우 다양할 수 있습니다. 예를 들어, 대규모 퍼블릭 클라우드는 자체 백본을 사용하여 API 전송을 실행할 수 있습니다. 또 다른 구현으로는 기업 데이터 센터 내의 기존 고대역폭 및 낮은 지연 시간의 네트워크를 기반으로 계층화된 낮은 지연 시간의 메시징 버스를 들 수 있습니다.
API 게이트웨이 기능
다시 말하지만, API 게이트웨이는 기본적으로 리버스 프록시로, 주요 기능은 HTTP 트래픽을 적절한 API 워크로드로 라우팅하는 것입니다. 이 접근 방식은 로컬 온프레미스 네트워크 내에서 또는 가용 영역 내의 가상 프라이빗 클라우드(VPC) 내에서와 같이 모든 API가 코로케이션되는 곳에 적합합니다. 그러나 API의 수가 확대되거나 하이브리드 인프라 전체에서 이동하거나 모바일화됨에 따라 API 게이트웨이 설계에서 이러한 접근 방식은 비효율적이고 작동이 복잡하며 비용이 많이 들게 됩니다.
그림 6에 설명된 모든 기능을 분류하는 방법에 대한 다른 견해가 있을 수 있지만, API 관리 인프라는 신중하게 오케스트레이션해야 하는 많은 구성 요소가 복잡하게 배포되었다는 데 동의할 수 있습니다.
그림 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 분석, 사용량 보고, 오류율 모니터링, 경보 및 이벤트, 모니터링 및 로깅 통합은 여러 마이크로서비스에서 데이터를 수집하고 집계할 수 있는 엣지 게이트웨이에서 처리할 수 있습니다.
게이트웨이 액터 – GraphQL 후보
오늘날 API 게이트웨이가 지원하는 중요한 기능은 서비스 구성 및 오케스트레이션입니다. 이로 인해 다소 복잡해질 수 있지만, 이 기능이 단순화된 API 게이트웨이에서 지원되지 않는다면 문제가 될 수 있습니다. 우리는 GraphQL이 기존 API에 대한 일종의 미들웨어 역할을 하는 서비스 구성에 대한 흥미로운 접근 방식이 될 수 있다고 생각합니다.
모든 API의 가시성으로 인해 API 게이트웨이는 서비스 구성을 수행하기 위한 논리적 장소가 되므로 개발자는 게이트웨이 뒤의 API를 결합하여 서비스 구성 레이어에서 보다 쉽게 결합될 수 있는 새로운 서비스를 작성하지 않고도 비즈니스 로직을 개선할 수 있습니다.
GraphQL의 서비스 구성은 클라이언트가 사용할 수 있는 데이터의 형태를 정의하는 강력하게 유형화된 스키마를 사용하여 수행할 수 있습니다. 클라이언트는 이 스키마를 사용하여 어떤 서비스 또는 소스가 데이터를 제공하는지에 관계없이 필요한 정확한 데이터를 지정하는 쿼리를 작성할 수 있습니다. 쿼리를 데이터 소스에 매핑하는 기능인 Resolver는 적절한 서비스 또는 소스에서 데이터를 가져오는 데 사용됩니다. 그러나 GraphQL이 더 나은 보안을 약속하지만, 이는 코드를 작성하는 개발자의 역량에 달려있습니다.
기타 기능
그림 6: API 관리 및 인프라 기능에서 설명하지 않은 기능이 아직 남아 있습니다. 이러한 나머지 기능은 개별 관리 및 운영 또는 데이터 플레인 기능으로 전환할 수 있는 후보입니다.
우리는 특정 구현 또는 공급업체 기술을 제안하지 않기 위해 의도적으로 "액터"라는 용어를 사용하기로 결정했습니다. 게이트웨이 액터의 구현은 방법, 기능, 작업자, 스레드 및 프로세스를 기반으로 하며 VM, 컨테이너, 서버리스 또는 공급업체별 기타 접근 방식을 기반으로 하는 인프라를 사용하여 구현될 수 있습니다.
구성 요소의 기능 및 동작
분산 게이트웨이 액터(DGA) 아키텍처를 사용한 접근 방식은 API 게이트웨이 기능을 단순화하고 다른 인라인 기능을 엣지 또는 컨트롤 플레인으로 이동시킵니다.
컨트롤 플레인
API 게이트웨이 기능과는 별개로, DGA 아키텍처는 모놀리식 API 게이트웨이 내에서 구현되기보다는 논리적으로 중앙 관리되는 구성 요소로 컨트롤 플레인에서 더 잘 작동할 수 있는 기능을 식별하는 것이 권장됩니다. 이미 존재하는 API 인프라의 관리 및 제어의 경우 이러한 추가 기능을 포함하도록 확장 및 확대할 수 있습니다.
간소화된 API 게이트웨이
API 게이트웨이의 간소화는 모든 API 게이트웨이 공급업체가 공통 구성 매개변수 세트를 통해 관리할 수 있는 표준 핵심 기능 세트를 도출하기 위한 연습이 됩니다.
이러한 전환을 원하는 기업은 기존 배포를 방해하지 않고 대대적인 작업 없이도 한 번에 한 애플리케이션씩 DGA 아키텍처를 배포할 수 있습니다.
분산 게이트웨이 액터
DGA의 중요한 측면은 각 게이트웨이 액터가 API 세션(즉, 하나의 API 호출을 하는 한 클라이언트) 동안만 일시적으로 인스턴스화된다는 것입니다.
분산 게이트웨이 액터는 기존 API 게이트웨이보다 더 유연하고 확장성이 뛰어나며 경제적일 수 있습니다. 게이트웨이 액터를 사용하면 서로 다른 공급업체의 여러 모놀리식 API 게이트웨이를 사용하여 API 트래픽을 집계하고 처리하는 대신 개발자가 네트워크 엣지에 더 가까운 각 API에 대해 개별 게이트웨이 인스턴스를 지정하고 배포할 수 있습니다. API 자체에서 특정 요구 사항에 대한 더 큰 제어 및 맞춤형 기능을 제공할 수 있습니다.
또한 이 새로운 접근 방식은 개발자가 대규모 중앙 집중식 게이트웨이 관리의 오버헤드에 대한 걱정 없이 증가된 트래픽을 처리하는 데 필요한 게이트웨이 액터 인스턴스를 쉽게 스핀업할 수 있기 때문에 확장성을 높일 수 있습니다.
게이트웨이 액터는 기술적 이점 외에도 기업이 사용하는 임시 게이트웨이 액터 인스턴스에 대해서만 비용을 지불할 수 있도록 하여 기존 API 게이트웨이보다 높은 비용 절감 효과를 제공합니다. 이 배포 모델은 추가 수익 모델을 위한 기회를 제공할 수 있습니다.
게이트웨이 액터 배치
DGA는 API 전송 레이어를 활용함으로써 본질적으로 API 게이트웨이에서 API 유입 위치를 분리합니다. DGA는 엣지, 즉 API 호출을 수행하는 클라이언트에 더 가깝게 이동할 수 있습니다. API는 DGA에서 종료된 다음에도 어떻게든 전송될 수 있습니다. 이는 클라이언트 트래픽이 API 게이트웨이에 위상적으로 인접하여 유입되는 그림 3: 레거시 API 게이트웨이 아키텍처와는 다릅니다.
결론
우리가 원한 것은, 서로 다른 공급업체가 설명한 것과 유사한 목표를 달성하기 위해 이러한 구성 요소를 구축하기 위한 지적 재산을 자체적으로 보유할 수 있기 때문에 공급업체 및 배포 애그노스틱 접근법을 제안하는 것이었습니다.
이 문서에서는 API 스프롤, Edge 2.0 아키텍처, API 경제 및 GraphQL에 대해 연구한 여러 분기의 학습 내용을 요약했습니다. 여론은 아직 레거시 API 인프라에 대해 배제하고 있지만 우리는 새로운 접근 방식이 필요하다고 생각합니다.
전 세계의 모든 개별 장치 또는 엔터티 내에서 가치를 실현하겠다는 약속만으로도 새로운 접근 방식을 모색할 수 있는 충분한 이유가 됩니다. 분산된 것처럼 보이지만 들여다 보면 모놀리식이기 때문에 현재의 레거시 API 인프라에서 벗어나야 합니다.
우리는 새로운 API 경제의 잠재력을 최대한 발휘하기 위한 공급업체 애그노스틱 방법으로 분산 GraphQL 기반 게이트웨이 액터 접근법을 제안합니다.