내부 API 관리를 위한 모범 사례

일부 소비자 대상 API는 너무 널리 퍼져서 가정의 이름이 되었습니다. Google Maps와 Stripe를 생각해 보세요. 하지만 내부 API가 API 경제의 진정한 원동력입니다.

내부 API(조직 내의 클라이언트와 개발자에게만 공개되는 API를 의미)는 기업의 디지털 혁신 노력에 있어 핵심 요소입니다. 내부 API를 구축하는 것은 일반적으로 디지털 제품과 서비스 개발의 첫 단계입니다. 실제로 IDC의 최근 조사인 API - 디지털 비즈니스의 성공과 실패를 결정하는 요인 에 따르면 애플리케이션과 제품의 내부 통합을 지원하는 것은 기업의 API 개발 이니셔티브에서 최우선 과제 중 하나입니다.

내부 API가 중요한 이유는 무엇입니까? 내부 API의 이점은 무엇인가요? 그리고 가장 중요한 것은 이를 관리하기 위한 최적의 아키텍처는 무엇인가? 이 블로그에서는 이러한 질문에 답하여 안전하고 대규모로 내부 API를 제공하는 데 도움을 드립니다.

내부 API가 중요한 이유는 무엇입니까?

내부 API는 사업부(LOB) 내 다른 개발자가 조직의 분산된 백엔드 시스템을 사용할 수 있도록 개방하여 데이터 사일로를 해제하고 브리지를 구축합니다. 예를 들어, 제조업체의 마케팅 조직은 적절한 시장 세그먼트를 타겟팅하고 수익을 극대화하기 위해 특정 제품과 모델의 가격을 할인할지 여부를 결정하기 위해 공급망 조직에서 사용하는 시스템에 대한 가시성이 필요할 수 있습니다.

내부 API는 어떻게 사일로를 분해하나요? HTML이나 JSON과 같은 표준 형식을 사용하여 데이터 교환을 지원하는 공통 인터페이스를 제공합니다. API를 구축하는 것뿐만 아니라 사용하는 것도 쉽고 빠릅니다. 이를 데이터 저장소에서 정보를 검색하기 위해 독점적인 데이터베이스 커넥터와 난해한 데이터 교환 프로토콜을 사용하는 것과 비교해보세요. API는 마찰을 줄임으로써 생산성을 크게 향상시킵니다. 이러한 API는 외부 개발자와 제3자에게 공개되지 않습니다. 내부 API 트래픽은 조직 내부, 즉 회사 방화벽 내부에 있습니다.

내부 API의 이점

내부 API는 제품 출시 시간을 단축하고 소프트웨어 개발에 소요되는 시간과 비용을 줄여줍니다. 자세히 혜택을 살펴보겠습니다.

운영 효율성

내부 API는 비즈니스의 다양한 부분을 연결하기 위한 쉽게 사용할 수 있는 추상화 계층을 제공하고, 변화하는 요구 사항에 적응할 수 있는 유연성을 제공합니다. 각 LOB의 애플리케이션에 대해 사일로화된 기술 스택을 만드는 대신, 조직 전체의 개발자는 공통된 내부 API 풀을 활용하여 데이터에 액세스할 수 있습니다. 이를 통해 중복을 제거하고 소프트웨어 개발 시간을 단축하여 개발자와 IT 생산성을 향상할 수 있습니다.

기록 시스템 개발

내부 API는 조직 내 주요 데이터 요소에 대한 권위 있는 소스 역할을 하는 기록 시스템의 개발을 촉진합니다. 데이터 무결성을 보장하려면 주어진 정보에 대한 기록 시스템은 반드시 하나여야 합니다. 각 LOB에 자체 데이터가 있거나 약간이라도 다른 버전이 있는 경우 불일치와 혼란이 발생합니다. 내부 API는 이 단일 진실 소스에 접근하는 효율적인 메커니즘입니다.

비용 절감

효율성은 비용 절감으로 이어집니다. 각 LOB 내에서 많은 사용자 정의가 필요한 독점 플랫폼을 구축할 필요가 없습니다. 기본적으로 포인트 도구인 값비싼 커넥터와 통합을 구축하거나 구매할 필요도 없습니다.

예를 들어, 에스토니아 연방 정부는 모든 정부 기관을 원활하게 연결하는 데이터 교환 플랫폼인 X‑Road를 운영합니다. 에스토니아 국민은 운전면허증을 소지할 필요조차 없습니다. 운전면허증 정보는 인구등록부와 차량등록부에서 빠르게 검색할 수 있기 때문입니다. 두 데이터 저장소가 별개로 운영되고 있음에도 불구하고요. 세계은행 보고서는 X-Road가 정보 접근을 보다 쉽게 만들어 에스토니아 정부와 국민이 단 한 해(2014년)에 280만 인시를 절약했다고 보수적으로 추산했습니다.

내부 API 관리를 위한 가이드라인

내부 API를 관리하기 위한 몇 가지 모범 사례를 살펴보겠습니다.

API 관리 도구 사용

내부 및 외부 API를 효율적으로 정의, 게시, 보호, 모니터링 및 분석하려면 API 관리 솔루션이 필요합니다. 또한 내부 개발자가 게시된 API에 대해 빠르게 알아볼 수 있는 개발자 포털도 필요합니다.

고성능 보장

마이크로서비스는 점점 인기를 얻고 있는 소프트웨어 개발에 대한 새로운 아키텍처적 접근 방식입니다. 많은 기업이 이 프레임워크를 사용하여 기존 내부 애플리케이션을 재설계하거나 새로운 애플리케이션을 구축하고 있습니다. 마이크로서비스 아키텍처에서 API는 클라이언트와 마이크로서비스 기반 애플리케이션 간, 그리고 애플리케이션을 구성하는 마이크로서비스 간 통신 수단입니다. API 클라이언트가 백엔드 애플리케이션에 리소스를 요청하면 API 게이트웨이는 트래픽을 적절한 마이크로서비스로 라우팅합니다. API 게이트웨이는 호출을 인증하고 속도 제한을 적용하여 외부 공격자가 회사 방화벽을 뚫을 경우 발생할 수 있는 공격을 방지합니다.

마이크로서비스는 모놀리식 애플리케이션보다 "대화가 더 많으며", 마이크로서비스 간에 "동서" 트래픽 볼륨이 높습니다. 따라서 높은 처리량(초당 요청 수)으로 처리하고 매우 빠르게 응답을 전달할 수 있는 고성능 게이트웨이를 선택하는 것이 매우 중요합니다. 클라이언트 요청은 종종 여러 마이크로서비스에 대한 여러 API 호출을 생성하므로 API 게이트웨이에서 하나의 호출에 대한 지연이 발생하면 잠재적으로 연쇄 효과가 발생하여 매우 긴 대기 시간이 발생할 수 있습니다.

회사 네트워크 외부의 클라우드를 통해 통화를 라우팅하지 마십시오.

전체 수명 주기 API 관리를 제공하는 1세대 클라우드 기반 솔루션이 있기는 하지만, 이러한 솔루션은 내부 API를 처리하는 데 적합하지 않습니다. 해당 아키텍처는 데이터 플레인(API 트래픽을 처리하는 API 게이트웨이)과 제어 플레인(API 관리 기능을 수행하는 API 게이트웨이)을 긴밀하게 결합하므로 런타임에 모든 내부 API 호출은 API 관리 솔루션의 클라우드를 통해 라우팅되어야 합니다. 이러한 방법에는 두 가지 단점이 있습니다.

• 지연 시간 증가 – 내부 API 호출을 처리하기 위해 클라우드로 이동하는 과정이 복잡하고 필연적으로 성능이 저하됩니다.
• 기업의 제로 트러스트 정책을 위반합니다. 내부 API 호출은 클라우드로 라우팅되어야 하므로 방화벽에 구멍을 뚫어야 합니다. 이로 인해 기업 네트워크가 공격과 침해에 노출되고 불필요한 복잡성이 발생합니다.

보안상의 이유로, 내부 API 트래픽은 회사 방화벽 뒤에 유지되어야 하므로 외부 클라우드로 호출을 라우팅할 수 없습니다. 이는 자체 프라이빗 클라우드 환경에서 애플리케이션과 API를 호스팅하는 기업에도 해당됩니다.

NGINX가 어떻게 도움이 될 수 있나요?

NGINX는 여러 가지 방법으로 내부 API를 관리하는 데 도움을 줍니다.

• NGINX는 성능이 뛰어나기로 유명합니다. 독립적인 기술 연구 분석가인 GigaOm에 따르면, NGINX는 초당 30,000개가 넘는 요청이 있어도 API 호출을 30ms 이내에 처리할 수 있습니다. 블로그 에서 벤치마킹 결과에 대해 자세히 알아보세요. 우리는 실시간 API를 제공하기 위한 자세한 지침과 함께 참조 아키텍처를 공개했습니다.
• NGINX와 NGINX Plus는 마이크로서비스를 개발하기 위한 인프라인 컨테이너를 위해 설계되었습니다. 약 2MB 크기의 NGINX와 NGINX Plus는 지원되는 Linux 서버(베어메탈, 클라우드 또는 가상)에서 실행되거나 Kubernetes 및 기타 플랫폼이 조정하는 Docker 컨테이너에서 직접 실행됩니다.

• NGINX API 관리 솔루션의 혁신적인 아키텍처는 확장성을 염두에 두고 설계되었습니다. NGINX는 API 게이트웨이(NGINX Plus)와 API 관리 소프트웨어(NGINX Controller [현재 F5 NGINX Management Suite] )를 분리하여 분산 API 관리를 지원합니다. 두 가지 사이에 런타임 종속성이 없으므로 추가 스크립팅, 데이터베이스 호출 또는 기타 제어 평면 논리와 같은 불필요한 오버헤드 없이 API 트래픽이 처리됩니다.

  분리된 아키텍처는 Controller [NGINX Management Suite] 와 NGINX Plus API 게이트웨이를 배포하는 위치에 있어 최대한의 유연성을 제공합니다. 회사 네트워크가 클라우드까지 확장되는 경우 온프레미스, 퍼블릭 클라우드 또는 여러 퍼블릭 클라우드에 배포할 수 있습니다. NGINX Plus API 게이트웨이는 API 트래픽을 처리하고 이를 회사 방화벽 뒤에 독립적으로 배포할 수 있으므로, 내부 API 호출을 회사 네트워크 외부의 클라우드를 통해 라우팅할 필요가 없습니다.

내부 API가 있나요? 아니면 내부 API를 개발할 계획이 있나요? 내부 API를 클라우드를 통해 라우팅하고 있나요? 아래에 댓글로 여러분의 의견을 들려주세요. 지금 당장 NGINX Controller [NGINX Management Suite] 의 무료 30일 체험판을 시작하거나, 사용 사례에 대해 논의하기 위해 저희에게 연락하세요 .