Modern API 관리 플랫폼이 필요한 이유

NGINX는 종종 하나 이상의 Modern API 관리 프레임워크를 사용하는 고객들과 상호 작용합니다.
최근에 NGINX와 대화를 나눈 한 고객은 마지막으로 세는 도중에 5개나 되는 프레임워크를 사용하고 있었습니다.
이는 왜일까요? 이유는 다양할 수 있지만, NGINX가 계속해서 마주치는 상황 중 하나는 고객들이 자신들의 애플리케이션을 모놀리식 구조에서 더욱 마이크로서비스 기반의 구조로 전환하고 있습니다.
기존의 API 관리 프레임워크가 Modern API 에 대한 더 이상의 모든 요구사항을 충족시키지 못하고 있다는 것입니다.

목차

1. 소프트웨어 통합 아키텍처의 진화
 1-1. Modern API 개발
2. Modern API 관리 프레임워크가 아닌 기존 API 관리 프레임워크의 과제
 2-1. SaaS 기반 제품
3. Modern API 관리 프레임워크의 요구사항

1. 소프트웨어 통합 아키텍처의 진화

2000년대 초반에는 여러 프론트엔드 서비스를 메인프레임, 메시지 Queue, 데이터스토어와 같은 다양한 Backend 서비스에 연결할 수 있는 통합 Layer에 대한 요구가 증가하였습니다.
미들웨어 도구는 프로토콜과 메시지 변환을 통해 이러한 통합 문제를 해결하여 Backend 시스템에 연결하는 복잡성을 크게 줄였습니다.

이러한 미들웨어 도구들은 엔터프라이즈 서비스 버스(ESB)로 알려지게 되었고, 시간이 지남에 따라 인증, 권한 부여, 감사 기능 등 추가 기능을 제공하기 시작하였습니다.
내부 비즈니스 기능을 연결하고 통합하기 위한 API로, ESB 벤더들은 주로 SOAP 메시지 프로토콜과 XML 형식의 데이터를 사용하는 API를 만들었습니다.

시간이 지남에 따라 ESB는 많은 조직에서 중요한 인프라 컴포넌트가 되었고, 따라서 조직들은 일반적으로 ESB를 인프라에서 “애완동물”처럼 취급하게 되었습니다.

인터넷 트래픽이 기하급수적으로 증가하고 소비자들이 쇼핑, 인터넷 뱅킹, 소셜 미디어 등을 위해 모바일 기기를 사용하는 등 새로운 방식으로 서비스를 소비하기 시작하면서 조직들은 비즈니스 전략과 인프라 모델을 재고해야 했습니다.

상품 출시까지의 시간이 많은 조직에서 핵심 비즈니스 드라이버가 되었으며, 이는 비즈니스 부서가 새로운 제품과 서비스를 시장에 출시하는 더 민첩한 방법을 찾게 되는 계기가 되었습니다.
대기업이 소기업을 잡아먹는 것이 아니라, 빠른 회사가 느린 회사를 잡아먹는다는 말을 모두들 들어보셨을 거라고 확신합니다.

1-1. Modern API 개발

모바일 장치의 발전과 Modern API 웹 프레임워크의 채택으로 개발자들은 더 현대적인 웹 프레임워크를 채택하고 SOAP/XML API를 더 새롭고 경량화된 REST API와 JSON 형식의 Modern API 로 대체하기 시작했습니다.
API는 이제 NGINX의 디바이와 애플리케이션 간의 통신에 있어서 중요한 수단이 되었는데, 2019년에 아카마이가 발견한 바에 따르면 웹 트래픽의 83%가 API 호출이었습니다.

새로운 기술을 채택하는 조직에게 ESB가 점점 덜 중요해지자, ESB 벤더들은 유산적인 SOAP와 더 현대적인 REST 웹 서비스를 모두 제공하는 API 기능을 제공함으로써 시장 점유율을 유지하려고 노력했습니다.
이로 인해 ESB 벤더들에게는 빠른 승리가 있었지만, 시장은 여전히 마이크로서비스 시대로 빠르게 이동하고 있었습니다.

오늘날 시장에 존재하는 많은 API 관리 프레임워크는 ESB로서 시작되었습니다.
이들은 공용 클라우드가 주류가 되기 훨씬 전에 만들어졌으며, 마이크로서비스의 빠른 채택과 DevOps, CI/CD 도구 등의 방법론보다 먼저 나왔습니다.
간단히 말해서, 이는 이러한 프레임워크가 고객들이 분산형, 마이크로서비스 기반의 아키텍처를 구축하지 않았을 때 구현되었기 때문입니다.
이러한 아키텍처는 종종 공용 및 사설 클라우드 환경의 쿠버네티스 클러스터 내에서 실행됩니다.

2. Modern API 관리 프레임워크가 아닌 기존 API 관리 프레임워크의 과제

우리의 고객들이 현대적인 Modern API 애플리케이션 아키텍처를 채택함에 따라, 그들은 Modern API 가 아닌 전통적인 API 관리 프레임워크가 문제를 해결하기보다는 오히려 문제를 일으키고 있다는 것을 발견하고 있습니다.
최근에 NGINX에서는 인간 인지에 대한 연구와 고객들의 피드백을 바탕으로, API 호출이 30ms 이내에 처리되어야 소비자들이 여러분의 앱과 상호 작용할 때 요구하는 ‘실시간’ 성능을 제공할 수 있다고 결정했습니다.

많은 전통적인 API 프레임워크의 아키텍처는 unfortunately이 30ms 임계값 아래의 지연 시간을 달성하는 것을 어렵게 만듭니다.
특히, 전통적인 프레임워크는 일반적으로 API 호출을 데이터 플레인과 API Endpoint로 보내는 도중에 컨트롤 플레인을 통과시킵니다.
이는 지연 시간을 더하게 만들 뿐만 아니라, 밀접하게 연결된 Control Plane과 Data Plane이 API 호출을 처리하기 위해 항상 연결되어 있어야 한다는 것을 의미합니다.
또한, Control Plane은 종종 많은 부분으로 구성되어 있어, API를 관리하고, 모니터링하고, 분석하기 위해 제3자 모듈, 스크립트, 데이터베이스가 필요합니다.

전통적인 프레임워크는 특히 분산된 성격의 현대적인 애플리케이션, 즉 여러 물리적 위치나 클라우드 환경에 위치할 수 있는 마이크로서비스로 구성된 애플리케이션에 잘 맞지 않습니다.
예를 들어, 공용 및 사설 클라우드 환경에서 워크로드를 실행하는 클라우드 전략을 채택하였고 SaaS 기반 또는 자체 관리형 전통적인 API 관리 프레임워크를 사용하고 있습니다.
그렇게 되면 모든 API 트래픽이 인증되고 네트워크를 통해 밀접하게 연결된 Control Plane과 Data Plane을 통과하도록 라우팅되어야 하기 때문에 낮은 지연 시간을 달성하는 데 어려움을 겪을 것입니다.
이를 Trombon 현상이라고 불립니다.

2-1. SaaS 기반 제품

SaaS 기반 제공물은 일부 조직에게 또 다른 도전을 제기합니다.
만약 당신이 제로 트러스트 네트워크 보안 정책을 가지고 있다면, 아마도 API 관리 프레임워크와 API를 제공하는 백엔드 서비스 사이에 방화벽이 설치되어 있을 것입니다.
백엔드 서비스의 잠재적인 모든 변경은 방화벽의 변경을 요구합니다.
저는 기업 방화벽에서 자동 변경을 허용하는 많은 조직을 알지 못하므로, 이것은 민첩하려는 개발 팀에게 아주 큰 운영적 부담을 주게 됩니다.
또한 기업 전체의 보안 정책에 의해 계속 차단되고 늦어지는 것이 매우 불만스럽습니다.
기업 네트워크 외부의 클라우드를 통해 심지어 내부 API 호출도 라우팅하는 것은 특히 비효율적이며, API 성능 뿐만 아니라 전체 조직의 보안 자세에도 부정적인 영향을 미칩니다.

공용 클라우드의 성장으로 인한 명확한 결과 중 하나는 코드로서의 인프라의 채택과 애플리케이션에 가까운 인프라의 배치입니다.
비즈니스 부서나 DevOps 팀이 자신의 인프라를 운영하고 관리할 수 있는 분산된 인프라 소유권에 대한 명확한 추세가 있습니다.
이는 전통적인 API 관리 프레임워크에 문제를 일으키는데, 이들은 본질적으로 한 개의 중앙 팀이 운영하고 관리하도록 설계되었습니다. DevOps 팀은 자신들의 CI/CD 파이프라인의 일부로 테스트, 개발, 그리고 샌드박스 환경을 위한 자신들만의 게이트웨이를 배포조차 할 수 없습니다.
전통적인 프레임워크는 또한 도커와 같은 기술을 활용하는 것을 거의 불가능하게 만듭니다.

앞서 언급했듯이, 많은 전통적인 API 관리 프레임워크는 많은 부분으로 구성되어 있으며, 제3자 모듈, 스크립트, 데이터베이스에 의존하여 API를 관리하고, 모니터링하고, 분석합니다.
이는 문제 해결을 어렵게 만드는데, 이동하는 부분이 많기 때문이며, 또한 프레임워크 내부에 대한 가시성이 부족하기 때문입니다.
NGINX의 많은 고객들은 서비스 중단이 발생하거나 성능이 떨어질 때 시간을 많이 소비한다고 불평합니다.

이러한 전통적인 API 관리 프레임워크가 제기하는 마지막 도전은 비용입니다.
관리자당, API당, 게이트웨이당 그리고 이들의 조합을 포함한 다양한 비용 모델이 있습니다.
이들 모두에는 장단점이 있지만, 공통점은 다가오는 연도의 지출을 예측하는 것이 매우 어렵다는 것입니다.
API 호출당 요금을 부과하는 SaaS 기반 프레임워크의 경우, 고객들이 비정상적인 호출과 DDoS 공격 동안에도 요금을 지불해야 한다는 것을 깨닫고 심각한 충격을 받는 경우가 있습니다.

3. Modern API 관리 프레임워크의 요구사항

애플리케이션을 현대화하고 전통적인 API 관리 프레임워크와 관련된 문제에 직면한 조직들은 분명히 새로운 종류의 Modern API 관리 도구가 필요합니다.
이는 고객들이 필요하다고 말한 몇 가지 기능들입니다.

• 항상 연결을 필요로 하지 않는 분리된 Control Plane과 Data Plane. 이를 통해 고객들은 Data Plane(API Gateway)을 자신들의 애플리케이션에 더 가깝게 실행할 수 있습니다.
  또한 모든 API 호출이 더 이상 Control Plane을 통해 라우팅할 필요가 없기 때문에 지연 시간을 크게 줄일 수 있습니다.
  이는 서비스 간의 대량의 East-West(서비스 간) 트래픽이 있는 컨테이너화된 환경에서 특히 중요합니다.
• 멀티 클라우드를 위해 설계된 아키텍처. Microsoft Azure에서 실행되는 애플리케이션 A가 API를 통해 AWS에서 실행되는 애플리케이션 B와 통신하고, SaaS 기반의 전통적인 API 관리 시스템은 또 다른 클라우드나 사내에서 실행되고 있다고 가정해 봅시다.
  API 트래픽 흐름은 App A → SaaS → App B → SaaS → App A로, 불가피하게 상당한 양의 지연 시간이 발생합니다.
  분리된 아키텍처를 사용하면, 데이터 플레인을 각 애플리케이션 바로 옆에서 실행하고 트래픽 흐름을 App A → App B → App A로 만들 수 있습니다.
  API 트래픽이 그것을 통과하지 않기 때문에 Control Plane의 위치는 무관합니다.
  이 시나리오는 또한 SaaS 기반 API 관리 프레임워크와 App A 및 App B 사이에 방화벽이 있는 것이 부과하는 추가적인 운영 지연시간을 크게 줄입니다.

• 자체 서비스 API 배포 및 관리. 분리된 아키텍처를 사용하면, 각 비즈니스 부서 또는 DevOps팀은 자신의 API Gateway를 소유할 수 있고, NetOps 또는 SecOps 팀은 여전히 컨트롤 플레인의 보안 정책을 제어할 수 있습니다.
  이 요구사항은 조직들이 더 민첩한 개발 방법론으로 이동함에 따라 점점 더 인기를 얻고 있습니다.

NGINX는 고객들로부터 들은 이러한 요구사항을 기반으로 NGINX API 관리 솔루션인 NGINX Management Suite Instance Manager를 개발하였습니다.
여러분의 Modern API 관리 요구사항은 무엇인가요? NGINX STORE에 문의해서 NGINX Management Suite의 무료 30일 체험판을 시작하거나 여러분의 사용 사례에 대해 논의하기 위해 NGINX STORE에게 문의하세요.

아래 뉴스레터를 구독하고 NGINX와 NGINX STORE의 최신 정보들을 빠르게 전달 받아보세요.