Microservices 구축을 위한 API-First 접근 방식의 이점

이번 포스트는 API‑First 전략으로 Microservices를 구축할 때 얻는 이점과 NGINX가 이를 지원하는 방법과 통합 시 얻는 이점을 설명합니다.

API는 클라우드 네이티브 애플리케이션의 연결 조직으로, 애플리케이션의 구성 요소 Microservices가 통신하는 수단입니다. 애플리케이션이 성장하고 확장됨에 따라 Microservices와 API의 수도 증가합니다. 이는 대부분의 경우 피할 수 없는 결과이지만 최신 애플리케이션의 안정성, 확장성 및 보안을 담당하는 Platform Ops팀에게 중요한 과제를 안겨줍니다. 우리는 이 문제를 API sprawl이라고 부릅니다.

API 무분별한 확산을 해결하기 위한 첫 번째 시도로, 조직은 자동화된 API 검색 및 수정을 위한 도구를 구현하여 하향식(top-down) 접근 방식을 사용하려고 할 수 있습니다. 이는 단기적으로는 효과적이지만 API 및 Microservices 구축 및 운영을 담당하는 팀에 과도한 부담을 주는 경우가 많습니다. 보안 및 규정 준수 문제를 해결하기 위해 기존 Microservices 및 API를 재작업하거나 필요한 승인을 얻기 위해 힘든 검토 프로세스를 거쳐야 합니다. 이것이 많은 대규모 소프트웨어 조직이 개발자에게 필요한 자율성을 제공하기 위해 적응형 거버넌스를 사용하는 분산형 접근 방식을 채택하는 이유입니다.

목차

1. API-First 란?
2. API-First 의 이점
3. 공통 API 사양 채택이 도움이 되는 방법
4. 공통 API 사양 채택의 이점
5. NGINX가 API‑First 소프트웨어 개발을 지원하는 방법
 5-1. API Gateway에 API 게시
5-2. 개발자 포털용 API 문서 생성
5-3. Positive 보안을 적용하여 API Endpoint 보호
6. 요약

1. API‑First 란?

API는 수십 년 동안 존재해 왔습니다. 그러나 그것들은 더 이상 단순히 “애플리케이션 프로그래밍 인터페이스”가 아닙니다. 핵심 API는 개발자 인터페이스입니다. 모든 사용자 인터페이스와 마찬가지로 API에는 계획, 디자인 및 테스트가 필요합니다. API‑First 는 API를 운영하고 사용하는 모든팀에서 연결성과 단순성의 중요성을 인식하고 우선순위를 지정하는 것입니다. 거의 항상 개발자인 API 소비자들을 위한 통신, 재사용 가능성 및 기능을 우선시합니다.

API‑First 으로 가는 경로는 다양하지만 소프트웨어 개발에 대한 설계 주도 접근 방식은 API-First 여정을 시작하는 대부분의 회사의 최종 목표입니다. 실제로 이 접근 방식은 구현 전에 API가 완전히 정의됨을 의미합니다. 작업은 API가 작동하는 방식을 설계하고 문서화하는 것으로 시작됩니다. 팀은 종종 API 계약이라고 하는 결과 아티팩트(artifact)에 의존하여 애플리케이션의 기능을 구현하는 방법을 알려줍니다.

2. API‑First 의 이점

API‑First 전략은 애플리케이션 에코 시스템이 모듈식 및 재사용 가능한 시스템으로 시작되도록 보장하기 때문에 Microservices 아키텍처에 이상적인 경우가 많습니다. API‑First 소프트웨어 개발 모델을 채택하면 개발자와 조직 모두에게 다음과 같은 상당한 이점을 제공할 수 있습니다:

  • 개발자 생산성 향상 – 개발팀은 애플리케이션의 API에 의존하는 다른 마이크로서비스에서 작업하는 팀에 영향을 미치지 않고 Backend 애플리케이션을 업데이트할 수 있도록 병렬로 작업할 수 있습니다. 모든 팀이 설정된 API 계약(contract)을 참조할 수 있기 때문에 API Lifecycle 전반에 걸쳐 협업이 더 용이한 경우가 많습니다.
  • 개발자 경험 향상 – API‑First 설계는 API가 논리적이고 잘 문서화되도록 보장하여 개발자 경험을 우선시합니다. 이는 개발자가 API와 상호 작용할 때 원활한 경험을 제공합니다.
  • 일관된 거버넌스 및 보안 – 클라우드 및 플랫폼 설계자는 API 설계 단계에서 보안 및 거버넌스 규칙을 통합하여 일관된 방식으로 API 에코 시스템을 구성할 수 있습니다. 이렇게 하면 소프트웨어 프로세스에서 후반부에 문제가 발견될 때 필요한 비용이 많이 드는 검토 작업을 피할 수 있습니다.
  • 소프트웨어 품질 향상 – API를 먼저 설계하면 API를 Production에 배포할 준비가 되기 훨씬 전에 개발 프로세스 초기에 보안 및 규정 준수 요구 사항을 충족할 수 있습니다. 운영, 품질 및 보안 엔지니어링팀이 개발팀과 직접 협력하여 설계 단계에서 품질 및 보안 표준을 충족할 수 있도록 보장하는 시간을 단축할 수 있습니다.
  • 출시 시간 단축 – 더 적은 종속성과 서비스 간 통신을 위한 일관된 프레임워크를 통해 서로 다른 팀이 훨씬 더 효율적으로 서비스를 구축하고 개선할 수 있습니다. 일관되고 기계가 읽을 수 있는 API 사양은 개발자와 Platform Ops팀이 더 잘 협력하는 데 도움이 되는 하나의 도구입니다.

전반적으로 API‑First 접근 방식을 채택하면 기업이 보다 유연하고 확장을 용이하게 하며 안전한 Microservices 아키텍처를 구축하는 데 도움이 될 수 있습니다.

3. 공통 API 사양 채택이 도움이 되는 방법

일반적인 엔터프라이즈 Microservices 및 API 환경에는 Platform Ops팀이 매일 추적할 수 있는 것보다 더 많은 구성 요소가 있습니다. 시스템이 읽을 수 있는 표준 API 사양을 수용하고 채택하면 팀이 현재 환경에서 작동하는 API를 이해하고 모니터링하고 결정을 내리는 데 도움이 됩니다.

공통 API 사양을 채택하면 API 설계 단계에서 이해관계자와의 협업을 개선하는 데에도 도움이 될 수 있습니다. API 계약을 생성하고 이를 표준 사양으로 공식화하면 모든 이해관계자가 API 작동 방식에 대해 동일한 페이지에 있도록 할 수 있습니다. 또한 팀 간에 재사용 가능한 정의 및 기능을 더 쉽게 공유할 수 있습니다.

현재 세 가지 일반적인 API 사양이 있으며, 각 사양은 대부분의 API 유형을 지원합니다:

  • OpenAPI – 모든 Web API 및 Webhook에 대한 JSON 또는 YAML 설명
  • AsyncAPI – 이벤트 기반 API의 JSON 또는 YAML 설명
  • JSON Schema – API에 사용되는 스키마 객체의 JSON 설명

REST API는 현재 Production API의 대부분을 차지하며 OpenAPI 사양은 REST API에 대한 API 정의를 작성하는 표준 방법입니다. 주어진 API가 작동하는 방식을 설명하는 기계 판독 가능 계약을 제공합니다. OpenAPI 사양은 NGINX를 비롯한 다양한 API 관리 및 API Gateway 도구로 광범위하게 지원됩니다. 이 포스트의 나머지 부분에서는 OpenAPI 사양을 사용하여 몇 가지 중요한 사용 사례를 달성하는 방법에 중점을 둘 것입니다.

OpenAPI 사양은 API를 JSON 또는 YAML로 정의하기 위한 Open Source 형식입니다. 다음의 간단한 API 예제에서 볼 수 있듯이 광범위한 API 특성을 포함할 수 있습니다. 여기서 간단한 HTTP GET 요청은 가상 식료품 목록의 항목 목록을 반환합니다.

openapi: 3.0.0
info:
  version: 1.0.0
  title: Grocery List API
  description: An example API to illustrate the OpenAPI Specification

servers:
url: https://api.example.io/v1

paths:
  /list:
    get:
      description: Returns a list of stuff on your grocery list             
      responses:
        '200':
          description: Successfully returned a list
          content:
            schema:
              type: array
              items:
                type: object
                properties:
                   item_name:
                      type: string

OpenAPI 사양을 따르는 정의는 사람과 기계 모두 읽을 수 있습니다. 즉, 각 API가 어떻게 작동하는지 문서화하는 단일 정보 소스가 있으며, 이는 API를 구축하고 운영하는 많은 팀이 있는 조직에서 특히 중요합니다. 물론 API를 대규모로 관리, 제어 및 보호하려면 API 플랫폼의 나머지 도구(API Gateway, 개발자 포털 및 고급 보안)도 OpenAPI 사양을 지원하는지 확인해야 합니다.

4. 공통 API 사양 채택의 이점

OpenAPI 사양과 같은 공통 API 사양을 사용하면 다음과 같은 몇 가지 이점이 있습니다:

  • 상호 운용성(Interoperability) 향상 – 기계가 읽을 수 있는 공통 사양은 서로 다른 시스템과 클라이언트가 API 계약을 소비하고 사용할 수 있음을 의미합니다. 이를 통해 Platform Ops팀은 복잡한 아키텍처를 보다 쉽게 통합, 관리 및 모니터링할 수 있습니다.
  • 일관된 문서화 – API 계약은 Endpoint, 요청 및 응답 형식, 기타 관련 세부 정보를 포함하여 표준 형식으로 문서화됩니다. 많은 시스템이 계약을 사용하여 포괄적인 문서를 생성할 수 있으며, 명확성을 제공하고 개발자가 API를 사용하는 방법을 더 쉽게 이해할 수 있도록 합니다.
  • 더 좋은 테스트 – API 사양을 사용하여 테스트를 자동으로 생성하고 실행하면 API 구현이 계약을 준수하고 예상대로 작동하는지 확인할 수 있습니다. 이는 API가 Production에 게시되기 전에 API 관련 문제를 식별하는 데 도움이 될 수 있습니다.
  • 보안 향상 – 고급 보안 도구는 OpenAPI 사양을 사용하여 API 트래픽 및 사용자 행동을 분석할 수 있습니다. API 요청이 API Endpoint에서 지원하는 메서드, Endpoint 및 매개변수를 준수하는지 확인하여 긍정적인 보안을 적용할 수 있습니다. 부적합 트래픽은 기본적으로 차단되어 Microservices 가 처리해야 하는 호출 수를 줄입니다.
  • 점진적 발전 – API 사양은 기계 및 사람이 읽을 수 있는 형식으로 변경 사항을 문서화하고 전달하는 명확하고 표준적인 방법을 제공함으로써 시간이 지남에 따라 API 계약 및 애플리케이션 자체의 발전을 촉진하는 데 도움이 될 수 있습니다. 이는 적절한 버전 관리 관행과 결합되면 API 변경이 API 소비자에게 미치는 영향을 최소화하고 API가 이전 버전과 호환되도록 하는 데 도움이 됩니다.

전반적으로 공통 API 사양을 사용하면 API의 상호 운용성, 문서화, 테스트, 보안 및 점진적 발전을 개선하는 데 도움이 될 수 있습니다.

5. NGINX가 API‑First 소프트웨어 개발을 지원하는 방법

NGINX는 규모에 맞게 API를 쉽게 운영, 모니터링, 관리 및 보호할 수 있는 경량의 클라우드 네이티브 도구 세트를 제공합니다. 예를 들어 NGINX Management Suite의 일부인 API Connectivity Manager는 API 작업을 위한 단일 Management Plane을 제공합니다. 이를 통해 API Gateway 및 개발자 포털을 구성하고 관리할 수 있습니다. API-First 도구로서 REST API를 통해 모든 기능에 액세스할 수 있으므로 DevOps팀이 CI/CD 자동화 및 통합을 쉽게 수행할 수 있습니다.

OpenAPI 사양을 사용하면 NGINX 제품을 사용하여 다음을 수행할 수 있습니다:

  • API Gateway에 API 게시
  • 개발자 포털용 API 문서 생성
  • Positive 보안을 적용하여 API Endpoint 보호
Diagram showing how API Connectivity Manager leverages an OpenAPI Specification for three uses: publishing the API to an API gateway, publishing documentation at the developer portal, and setting security policies on a WAF

OpenAPI 사양을 사용하여 API Gateway에 API를 게시하고 개발자 포털에 문서를 게시하고 CI/CD Pipelin 또는 사용자 인터페이스를 통해 WAF에 대한 보안 정책을 설정합니다.

5-1. API Gateway에 API 게시

API Connectivity Manager는 OpenAPI 사양을 사용하여 API 게시 및 관리를 간소화합니다. API 개발자는 NGINX Management Suite 사용자 인터페이스 또는 완전한 선언적 REST API를 사용하여 API Gateway에 API를 게시할 수 있습니다. API는 API Gateway 가 들어오는 API 요청을 Backend Microservices로 보내는 데 필요한 모든 수신, Backend 및 라우팅 구성을 포함하는 API Proxy로 Gateway에 추가됩니다. REST API를 사용하여 Ansible과 같은 도구로 간단한 CI/CD 자동화 스크립트를 생성하여 API를 코드로 배포하고 관리할 수 있습니다.

5-2. 개발자 포털용 API 문서 생성

문서를 유지 관리하는 것은 종종 API팀에게 골칫거리입니다. 그러나 개발자 포털의 오래된 문서는 API 확산의 주요 증상이기도 합니다. API Connectivity Manager는 OpenAPI 사양을 사용하여 문서를 자동으로 생성하고 개발자 포털에 게시함으로써 API 개발자의 시간을 절약하고 API 소비자가 항상 필요한 것을 찾을 수 있도록 합니다. 또한 API Connectivity Manager 사용자 인터페이스 또는 REST API를 통해 직접 OpenAPI 사양 파일을 업로드할 수 있습니다.

5-3. Positive 보안을 적용하여 API Endpoint 보호

또한 OpenAPI 사양을 사용하여 NGINX Plus API Gateway에 대한 API 요청이 API가 지원하는 내용을 준수하는지 확인할 수 있습니다. Positive 보안(허용되는 항목을 정의하고 다른 모든 항목을 차단하는 보안 모델)을 적용하면 악의적인 요청이 Backend 서비스에서 잠재적인 취약성을 탐색하는 것을 방지할 수 있습니다.

6. 요약

Microservices 및 애플리케이션 구축에 대한 API API‑First 방식은 조직에 여러 가지 이점을 줄 수 있습니다. OpenAPI 사양(또는 사람과 기계가 모두 읽을 수 있는 또 다른 공통 API 사양)을 중심으로 팀을 조정하면 팀 간의 협업, 커뮤니케이션 및 운영이 가능해집니다.

Modern 애플리케이션은 복잡한 클라우드 네이티브 환경에서 작동합니다. API 운영에 대한 API 우선 접근 방식을 지원하는 도구를 채택하는 것은 API‑First 전략을 실현하기 위한 중요한 단계입니다. NGINX를 사용하면 OpenAPI 사양을 사용하여 분산된 팀과 환경 전체에서 API를 대규모로 관리할 수 있습니다.

NGINX Plus와 함께 API Gateway를 테스트 및 사용해 보려면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.