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

Karthik Krishnaswamy제품 마케팅 이사 | F5

일부 소비자 대상 API는 매우 널리 사용되어 Google Maps와 Stripe처럼 누구나 아는 이름이 되었습니다. 하지만 API 경제를 실질적으로 이끄는 원동력은 내부 API입니다.

내부 API(조직 내 클라이언트와 개발자에게만 공개되는 API를 의미)는 기업의 디지털 혁신을 뒷받침하는 핵심 축입니다. 내부 API 구축은 일반적으로 디지털 제품 및 서비스 개발의 첫 단계입니다. 실제로 IDC의 최근 설문 조사인 「API: 디지털 비즈니스의 성공과 실패를 가르는 결정적 요인」에 따르면, 애플리케이션과 제품의 내부 통합 지원은 기업의 API 개발 이니셔티브에서 가장 중요한 우선순위 중 하나입니다.

내부 API가 중요한 이유는 무엇일까요? 내부 API는 어떤 이점을 제공할까요? 그리고 무엇보다 내부 API를 관리하기 위한 최적의 아키텍처는 무엇일까요? 이 블로그에서는 이러한 질문을 살펴보고, 내부 API를 안전하게 대규모로 제공할 수 있도록 도와드립니다.

내부 API가 중요한 이유는 무엇인가요?

내부 API는 조직 내 서로 분리된 백엔드 시스템을 특정 사업 부문(LOB)의 다른 개발자들이 활용할 수 있도록 개방함으로써 데이터 사일로를 해소하고 시스템 간 연결을 구축합니다. 예를 들어, 제조업체의 마케팅 조직은 적절한 시장 세그먼트를 공략하고 매출을 극대화하기 위해 특정 제품과 모델의 할인 여부를 결정할 때 공급망 조직에서 사용하는 시스템의 정보를 확인해야 할 수 있습니다.

내부 API는 어떻게 사일로를 허물까요? 내부 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 게이트웨이는 호출을 인증하고 요청 속도를 제한하여 외부 공격자가 기업 방화벽을 뚫었을 때 발생할 수 있는 공격을 방지합니다.

마이크로서비스는 모놀리식 애플리케이션보다 서로 간의 통신이 더 빈번하며, 마이크로서비스 간에 대량의 ‘동서(East-West)’ 트래픽이 발생합니다. 따라서 높은 처리량(초당 요청 수)으로 요청을 처리하고 매우 빠르게 응답할 수 있는 고성능 게이트웨이를 선택하는 것이 매우 중요합니다. 클라이언트 요청 하나가 서로 다른 마이크로서비스에 대한 여러 API 호출을 유발하는 경우가 많으므로, 단 하나의 호출이라도 API 게이트웨이에서 지연되면 연쇄적인 영향을 일으켜 지연 시간이 크게 늘어날 수 있습니다.

호출을 기업 네트워크 외부의 클라우드를 통해 라우팅하지 마세요

전체 수명 주기 API 관리를 제공하는 1세대 클라우드 기반 솔루션이 있지만, 내부 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 게이트웨이의 배포 위치를 최대한 유연하게 선택할 수 있습니다. 온프레미스나 퍼블릭 클라우드에 배포할 수 있으며, 기업 네트워크가 클라우드까지 확장되어 있다면 여러 퍼블릭 클라우드에 걸쳐 배포할 수도 있습니다. API 트래픽을 처리하는 NGINX Plus API 게이트웨이를 기업 방화벽 뒤에 독립적으로 배포할 수 있으므로, 내부 API 호출을 기업 네트워크 외부의 클라우드를 통해 라우팅할 필요가 없습니다.

내부 API를 보유하고 계신가요? 아니면 내부 API를 개발할 계획이신가요? 내부 API를 클라우드를 통해 라우팅하고 계신가요? 아래 댓글을 통해 여러분의 이야기를 들려주세요. 지금 바로 NGINX Controller 30일 무료 평가판[NGINX Management Suite]을 시작하거나 사용 사례에 대해 논의하려면 문의해 주세요.

작성자 소개

Karthik Krishnaswamy제품 마케팅 이사 | F5

Karthik Krishnaswamy의 다른 블로그 게시물