내부 API 관리 모범 사례

일부 소비자 대면 API는 너무 널리 퍼져서 Google Maps 및 Stripe와 같이 누구나 아는 이름이 되었지만 내부 API 는 API 경제의 진정한 강자입니다.

내부 API(즉, 조직 내의 고객과 개발자에게만 노출되는 API)는 기업의 디지털 혁신 노력의 핵심 요소입니다.
내부 API를 구축하는 것은 일반적으로 디지털 제품 및 서비스 개발의 첫 번째 단계입니다.
실제로 IDC의 최근 설문 조사인 APIs – Digital Business의 성패를 결정하는 에이전트에 따르면
애플리케이션과 제품의 내부 통합을 지원하는 것이 기업의 API 개발 이니셔티브의 최우선 과제 중 하나라고 합니다.

내부 API가 중요한 이유는 무엇입니까? 내부 API의 이점은 무엇입니까? 그리고 가장 중요한 것은 관리하기에 가장 적합한 아키텍처는 무엇일까요?
해당 포스트는 내부 API를 안전하고 규모에 맞게 제공하는 데 도움이 되는 이러한 질문을 해결합니다.

목차

1. 내부 API가 중요한 이유는 무엇일까요?
2. 내부 API의 이점
 2-1. 운영 효율성
 2-2. 기록 시스템 개발
 2-3. 비용 절감
3. 내부 API 관리 지침
 3-1. API 관리 도구 사용
 3-2. 고성능 보장
 3-3. 회사 네트워크 외부의 클라우드를 통해 Call을 라우팅하지 마십시오
4. NGINX가 내부 API 관리에 어떻게 도움이 될까요?

1. 내부 API 가 중요한 이유는 무엇일까요?

내부 API는 비즈니스 라인(Line Of Business) 내의 다른 개발자가 사용할 수 있도록 조직의 개별 백엔드 시스템을 열어 데이터 사일로를 잠금 해제하고 브리지를 구축합니다.
예를 들어, 제조업체의 마케팅 조직은 올바른 시장 부문을 목표로 하고 수익을 극대화하기 위해 특정 제품 및 모델을 할인할지 여부를 결정하기 위해 공급망 조직에서 사용하는 시스템에 대한 가시성이 필요할 수 있습니다.

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

2. 내부 API 의 이점

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

2-1. 운영 효율성

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

2-2. 기록 시스템 개발

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

2-3. 비용 절감

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

예를 들어, 에스토니아 연방 정부는 모든 정부 기관을 원활하게 연결하는 데이터 교환 플랫폼인 X‑Road를 운영합니다. 에스토니아 시민은 운전면허증을 휴대할 필요조차 없습니다.
두 개의 데이터 저장소가 분리되어 있어도 인구 등록부와 차량 등록부에서 정보를 신속하게 검색할 수 있기 때문입니다.
World Bank의 이 보고서 는 X-Road가 정보에 더 쉽게 액세스할 수 있게 함으로써 에스토니아 정부와 시민들이 1년(2014년)에 280만 인시를 절약했다고 ​​보수적으로 추정했습니다.

3. 내부 API 관리 지침

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

3-1. API 관리 도구 사용

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

3-2. 고성능 보장

마이크로서비스는 관심을 끌고 있는 소프트웨어 개발에 대한 새로운 아키텍처 접근 방식입니다.
많은 기업이 기존 내부 애플리케이션을 재설계하거나 이 프레임워크를 사용하여 새 애플리케이션을 구축하고 있습니다. 마이크로서비스 아키텍처에서 API는 클라이언트와 마이크로서비스 기반 애플리케이션 간 그리고 애플리케이션을 구성하는 마이크로서비스 간 통신 수단입니다.

API 클라이언트가 백엔드 애플리케이션에서 리소스를 요청하면 API 게이트웨이가 트래픽을 적절한 마이크로서비스로 라우팅합니다.
또한 API 게이트웨이는 호출을 인증하고 속도 제한(Rate Limit)을 적용하여 외부 행위자가 회사 방화벽을 위반하는 경우 발생할 수 있는 공격을 방지합니다.

마이크로서비스는 모놀리식 애플리케이션보다 “더 수다스럽”고 마이크로서비스 간에 “East-West” 트래픽이 많습니다. 따라서 높은 처리량(초당 요청 수)으로 처리하고 응답을 매우 빠르게 전달할 수 있는 고성능 게이트웨이를 선택하는 것이 매우 중요합니다.
클라이언트 요청은 종종 서로 다른 마이크로 서비스에 대한 여러 API 호출을 생성하므로 하나의 호출에 대한 게이트웨이의 지연으로 인해 잠재적으로 계단식 효과가 발생하여 대기 시간이 매우 길어질 수 있습니다.

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

전체 수명 주기 관리를 제공하는 1세대 클라우드 기반 솔루션이 있지만 내부 API 처리에는 적합하지 않습니다.
그들의 아키텍처는 Data Plane과 Control Plane을 긴밀하게 결합하기 때문에 런타임에 모든 내부 API 호출은 API 관리 솔루션의 클라우드를 통해 라우팅되어야 합니다.
여기에는 두 가지 단점이 있습니다.

• 대기 시간 추가 – 내부 API 호출을 처리하기 위해 클라우드로 홉(hop)하는 것은 우회적이며 불가피하게 성능을 저하시킵니다.
• 기업 제로 트러스트 정책 위반 – 내부 API 호출은 클라우드로 라우팅되어야 하므로 방화벽에 구멍을 뚫어야 합니다.
  이로 인해 회사 네트워크가 공격과 위반에 노출되고 불필요한 복잡성이 발생합니다.

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

4. NGINX 내부 API 관리에 어떻게 도움이 될까요?

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 Controller [현재 NGINX Management Suite] ) 에서 API 게이트웨이(NGINX Plus)를 분리하여 분산 API 관리를 지원합니다.
  둘 사이에 런타임 종속성이 없으므로 추가 스크립팅, 데이터베이스 호출 또는 기타 컨트롤 플레인 로직과 같은 불필요한 오버헤드 없이 API 트래픽이 처리됩니다.
  분리된 아키텍처는 컨트롤러 [NGINX Management Suite] 및 NGINX Plus API 게이트웨이 를 배포하는 위치에서 최대의 유연성을 제공합니다.
  기업 네트워크가 클라우드로 확장되는 경우 온프레미스, 퍼블릭 클라우드 또는 여러 퍼블릭 클라우드에 배포할 수 있습니다. 내부 API 호출은 API 트래픽을 처리하는 NGINX Plus API 게이트웨이를 회사 방화벽 뒤에 독립적으로 배포할 수 있으므로 회사 네트워크 외부의 클라우드를 통해 라우팅할 필요가 없습니다.

내부 API가 있습니까? 아니면 내부 API를 개발할 계획입니까? 클라우드를 통해 내부 API를 라우팅하고 있습니까? 아래 의견에서 귀하의 의견을 듣고 싶습니다.
그 동안 [NGINX Management Suite] 의 30일 무료 평가판을 시작하거나 당사에 연락하여 사용 사례에 대해 논의하십시오.