마이크로서비스 구축을 위한 API 우선 접근 방식의 이점

Andrew Stiefel

API는 클라우드 네이티브 애플리케이션을 연결하는 조직으로, 애플리케이션을 구성하는 마이크로서비스가 서로 통신하는 수단입니다. 애플리케이션이 성장하고 확장됨에 따라 마이크로서비스와 API의 수도 늘어납니다. 이는 대부분의 경우 피할 수 없는 결과이지만, 최신 애플리케이션의 안정성, 확장성 및 보안을 보장하는 플랫폼 운영 팀에는 중대한 과제를 안겨 줍니다. 우리는 이 문제를 API 스프롤이라고 부르며, 이전 블로그 게시물에서 이에 대해 다룬 바 있습니다.

API 스프롤 문제를 해결하기 위한 첫 번째 시도로, 조직은 API를 자동으로 검색하고 문제를 해결하는 도구를 도입하는 하향식 접근 방식을 택할 수 있습니다. 이 방식은 단기적으로는 효과적이지만, API와 마이크로서비스를 구축하고 운영하는 팀에 과도한 부담을 주는 경우가 많습니다. 이들 팀은 보안 및 규정 준수 문제를 해결하기 위해 기존 마이크로서비스와 API를 재작업하거나, 필요한 승인을 받기 위해 까다로운 검토 절차를 거쳐야 합니다. 이러한 이유로 많은 대규모 소프트웨어 조직은 적응형 거버넌스를 활용하여 개발자에게 필요한 자율성을 부여하는 분산형 접근 방식을 채택합니다.

마지막 순간에 안전장치를 마련하기보다는 문제에 상향식으로 접근하는 것이 장기적으로 더 효과적입니다. 다양한 마이크로서비스와 애플리케이션을 위한 API를 구축하고 운영하는 팀이 가장 먼저 참여하며, 대개 조직의 소프트웨어 개발에 API 우선 접근 방식을 도입하는 것부터 시작합니다.

API 우선이란 무엇인가요?

API는 수십 년 전부터 존재해 왔습니다. 하지만 이제 API는 단순한 ‘애플리케이션 프로그래밍 인터페이스’가 아닙니다. 본질적으로 API는 개발자를 위한 인터페이스입니다. 다른 사용자 인터페이스와 마찬가지로 API에도 기획, 설계, 테스트가 필요합니다. API 우선 접근 방식은 API를 운영하고 사용하는 모든 팀에서 연결성과 단순성의 중요성을 인식하고 이를 우선시하는 것입니다. 또한 거의 항상 개발자인 API 사용자를 위해 소통, 재사용성, 기능성을 우선시합니다.

API 우선 접근 방식으로 나아가는 길은 다양하지만, API 우선 여정을 시작하는 대부분의 기업이 궁극적으로 지향하는 것은 설계 주도형 소프트웨어 개발 방식입니다. 실제로 이 방식에서는 구현에 앞서 API를 완전히 정의합니다. 먼저 API가 어떻게 작동할지 설계하고 문서화합니다. 팀은 그 결과물인 API 계약을 바탕으로 애플리케이션의 기능을 구현합니다.

내구성과 유연성을 모두 갖춘 API 우선 소프트웨어 개발 접근 방식을 지원하는 설계 기법을 O’Reilly 전자책 Mastering API Architecture의 1장에서 살펴보세요. NGINX에서 무료로 제공합니다.

조직을 위한 API 우선 접근 방식의 가치

API 우선 전략은 애플리케이션 생태계가 처음부터 모듈식의 재사용 가능한 시스템으로 구축되도록 보장하므로 마이크로서비스 아키텍처에 적합한 경우가 많습니다. API 우선 소프트웨어 개발 모델을 도입하면 개발자와 조직 모두 다음과 같은 상당한 이점을 얻을 수 있습니다:

• 개발자 생산성 향상 – 개발 팀은 병렬로 작업할 수 있으며, 애플리케이션의 API에 의존하는 다른 마이크로서비스 담당 팀에 영향을 주지 않고 백엔드 애플리케이션을 업데이트할 수 있습니다. 또한 모든 팀이 확립된 API 계약을 참조할 수 있으므로 API 수명 주기 전반에 걸쳐 협업이 한층 수월해집니다.
• 향상된 개발자 경험 – API 우선 설계는 API가 논리적이고 문서화가 잘 되어 있도록 함으로써 개발자 경험을 우선시합니다. 이를 통해 개발자는 API와 상호 작용할 때 원활한 경험을 누릴 수 있습니다. 플랫폼 운영 팀이 API 개발자 경험을 고려하는 것이 왜 중요한지 알아보세요<.htmla>.
• 일관된 거버넌스 및 보안 – 클라우드 및 플랫폼 아키텍트는 API 설계 단계에서 보안 및 거버넌스 규칙을 적용하여 API 에코시스템을 일관된 방식으로 구성할 수 있습니다. 이를 통해 소프트웨어 개발 프로세스 후반에 문제가 발견될 경우 필요한 비용이 많이 드는 검토를 방지할 수 있습니다.
• 소프트웨어 품질 향상 – API를 우선 설계하면 API를 프로덕션에 배포할 준비가 되기 훨씬 전인 개발 프로세스 초기 단계에서 보안 및 규정 준수 요구 사항을 충족할 수 있습니다. 프로덕션 환경에서 보안 결함을 수정해야 할 필요성이 줄어들기 때문에 운영, 품질 및 보안 엔지니어링 팀은 개발 팀과 직접 협력하여 설계 단계에서 품질 및 보안 표준을 충족하는 데 더 많은 시간을 할애할 수 있습니다.
• 시장 출시 기간 단축 – 종속성을 줄이고 서비스 간 통신에 일관된 프레임워크를 적용하면 여러 팀이 훨씬 더 효율적으로 서비스를 구축하고 개선할 수 있습니다. 일관된 기계 판독형 API 사양은 개발자와 플랫폼 운영 팀이 더 원활하게 협업하도록 지원하는 도구 중 하나입니다.

전반적으로 API 우선 접근 방식을 도입하면 기업이 더욱 유연하고 확장 가능하며 안전한 마이크로서비스 아키텍처를 구축하는 데 도움이 될 수 있습니다.

공통 API 사양을 도입하면 어떤 도움이 되는가

일반적인 엔터프라이즈 마이크로서비스 및 API 환경에는 플랫폼 운영 팀이 일상적으로 모두 파악하기 어려울 만큼 많은 구성 요소가 존재합니다. 표준화된 기계 판독형 API 명세를 도입하고 활용하면 팀에서 현재 환경 내에 운영 중인 API를 파악하고 모니터링하며 관련 의사 결정을 내리는 데 도움이 됩니다.

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

현재 널리 사용되는 API 명세는 세 가지이며, 각각 대부분의 API 유형을 지원합니다:

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

오늘날 프로덕션 환경에서 사용되는 API의 대부분은 REST API이며, OpenAPI Specification은 REST API의 API 정의를 작성하는 표준 방식입니다. 이는 특정 API의 작동 방식을 설명하는 머신 리더블 계약을 제공합니다. OpenAPI Specification은 NGINX를 비롯한 다양한 API 관리 및 API 게이트웨이 도구에서 폭넓게 지원됩니다. 이 블로그의 나머지 부분에서는 OpenAPI Specification을 사용해 몇 가지 중요한 사용 사례를 구현하는 방법을 중점적으로 살펴보겠습니다.

OpenAPI 사양은 JSON 또는 YAML로 API를 정의하기 위한 오픈 소스 형식입니다. 다음의 간단한 API 예시와 같이 다양한 API 특성을 포함할 수 있습니다. 여기서는 간단한 HTTP GET 요청이 가상의 장보기 목록에 있는 항목들을 반환합니다.

openapi: 3.0.0info:
  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 게이트웨이, 개발자 포털, 고급 보안 기능)도 OpenAPI 사양을 지원하는지 확인해야 합니다.

OpenAPI 사양을 사용하여 REST API를 설계하는 방법을 자세히 알아보려면 Mastering API Architecture 1장을 참조하세요.

공통 API 명세 도입의 이점

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

• 향상된 상호 운용성 – 공통된 기계 판독 가능 사양을 사용하면 서로 다른 시스템과 클라이언트가 API 계약을 활용할 수 있습니다. 따라서 플랫폼 운영 팀이 복잡한 아키텍처를 더 쉽게 통합, 관리 및 모니터링할 수 있습니다.
• 일관된 문서화 – API 계약은 엔드포인트, 요청 및 응답 형식, 기타 관련 세부 정보를 포함하는 표준 형식으로 문서화됩니다. 다양한 시스템에서 이 계약을 사용해 포괄적인 문서를 생성할 수 있으므로 내용이 명확해지고 개발자가 API 사용 방법을 더 쉽게 이해할 수 있습니다.
• 향상된 테스트 – API 사양을 사용하면 테스트를 자동으로 생성하고 실행할 수 있으므로, API 구현이 계약을 준수하고 예상대로 작동하는지 확인하는 데 도움이 됩니다. 이를 통해 API를 프로덕션 환경에 배포하기 전에 문제를 파악할 수 있습니다.
• 보안 강화 – 고급 보안 도구는 OpenAPI 사양을 사용하여 API 트래픽과 사용자 행동을 분석할 수 있습니다. 또한 API 요청이 API 엔드포인트에서 지원하는 메서드, 엔드포인트 및 매개변수를 준수하는지 확인하여 포지티브 보안<.htmla>을 적용할 수 있습니다. 규정을 준수하지 않는 트래픽은 기본적으로 차단되므로 마이크로서비스가 처리해야 하는 호출 수가 줄어듭니다.
• 더욱 용이한 발전 – API 사양은 변경 사항을 기계와 사람이 모두 읽을 수 있는 형식으로 문서화하고 전달하는 명확하고 표준화된 방법을 제공하여 시간이 지남에 따라 API 계약과 애플리케이션 자체가 발전할 수 있도록 지원합니다. 적절한 버전 관리 방식과 함께 사용하면 API 변경이 API 소비자에게 미치는 영향을 최소화하고 API의 이전 버전과의 호환성을 유지하는 데 도움이 됩니다.

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

NGINX가 API 우선 소프트웨어 개발을 지원하는 방법

NGINX는 대규모 API를 손쉽게 운영, 모니터링, 관리 및 보호할 수 있는 경량 클라우드 네이티브 도구 세트를 제공합니다. 예를 들어, API Connectivity Manager는 F5 NGINX Management Suite의 일부로, API 운영을 위한 단일 관리 영역을 제공합니다. 이를 통해 API 게이트웨이와 개발자 포털을 구성하고 관리할 수 있습니다. 이 도구 자체도 API 우선 방식으로 설계되어 모든 기능에 REST API를 통해 액세스할 수 있으므로 DevOps 팀이 CI/CD 자동화와 통합을 손쉽게 수행할 수 있습니다.

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

• API 게이트웨이에 API 게시
• 개발자 포털용 API 문서 생성
• API 엔드포인트를 보호하기 위해 포지티브 보안 적용

OpenAPI 사양을 사용하여 API를 API 게이트웨이에 게시하고 개발자 포털에 문서를 게시하며, CI/CD 파이프라인 또는 사용자 인터페이스를 통해 WAF의 보안 정책을 설정합니다.

API 게이트웨이에 API 게시

API Connectivity Manager는 OpenAPI 사양을 사용하여 API 게시 및 관리를 간소화합니다. API 개발자는 NGINX Management Suite 사용자 인터페이스 또는 완전한 선언형 REST API를 사용하여 API를 API 게이트웨이에 게시할 수 있습니다. API는 API 프록시 형태로 게이트웨이에 추가되며, 이 프록시에는 수신 API 요청을 백엔드 마이크로서비스로 전달하는 데 필요한 모든 인그레스, 백엔드 및 라우팅 구성이 포함됩니다. Ansible과 같은 도구로 간단한 CI/CD 자동화 스크립트를 작성하면 REST API를 사용하여 API를 코드로 배포하고 관리할 수 있습니다.

OpenAPI 사양을 사용하여 API를 게시하는 방법에 대한 전체 지침은 API Connectivity Manager 설명서를 참조하세요.

개발자 포털용 API 문서 생성

문서를 유지 관리하는 일은 API 팀에게 골칫거리가 되는 경우가 많습니다. 하지만 개발자 포털의 오래된 문서 역시 API 난립을 보여 주는 주요 징후입니다. API Connectivity Manager는 OpenAPI Specification을 사용하여 문서를 자동으로 생성하고 개발자 포털에 게시함으로써 API 개발자의 시간을 절약하고 API 사용자가 필요한 정보를 언제든지 찾을 수 있도록 합니다. OpenAPI Specification 파일은 API Connectivity Manager 사용자 인터페이스 또는 REST API를 통해 직접 업로드할 수 있습니다.

개발자 포털에 API 문서를 게시하는 방법에 대한 전체 지침은 API Connectivity Manager 설명서를 참조하세요.

API 엔드포인트 보호를 위한 포지티브 보안 적용

OpenAPI 사양을 사용하여 NGINX Plus API 게이트웨이에 대한 API 요청이 해당 API에서 지원하는 범위를 준수하는지 확인할 수도 있습니다. 포지티브 보안(허용되는 항목을 정의하고 그 외의 모든 항목을 차단하는 보안 모델)을 적용하면 악의적인 요청이 잠재적인 취약점을 찾기 위해 백엔드 서비스를 탐색하는 것을 방지할 수 있습니다.

이 글을 작성하는 현재, API Connectivity Manager를 사용하여 NGINX App Protect WAF를 구성할 수는 없지만, 이 기능은 2023년 후반에 제공될 예정입니다. 그러나 Instance Manager(또 다른 NGINX Management Suite 모듈)와 OpenAPI 사양을 사용하여 WAF용 사용자 지정 정책을 작성할 수 있습니다. 자세한 내용은 NGINX App Protect WAF 및 Instance Manager 설명서를 참조하세요.

API 보안 및 위협 모델링과 API 게이트웨이에서 인증 및 권한 부여를 적용하는 방법에 대한 자세한 내용은 Mastering API Architecture 7장을 참조하세요.

요약

마이크로서비스와 애플리케이션을 구축할 때 API 우선 접근 방식을 채택하면 조직에 다양한 이점을 제공할 수 있습니다. OpenAPI 사양(또는 사람과 기계가 모두 읽을 수 있는 다른 공통 API 사양)을 중심으로 팀 간의 방향성을 일치시키면 여러 팀에 걸친 협업, 커뮤니케이션 및 운영을 원활하게 할 수 있습니다.

최신 애플리케이션은 복잡한 클라우드 네이티브 환경에서 운영됩니다. API 운영에 API 우선 접근 방식을 적용할 수 있는 도구를 도입하는 것은 API 우선 전략을 실현하기 위한 핵심 단계입니다. NGINX를 사용하면 OpenAPI Specification을 기반으로 분산된 팀과 환경 전반에서 API를 대규모로 관리할 수 있습니다.

Start a NGINX Management Suite 30일 무료 체험을 시작하세요. 무료 체험에는 API Connectivity Manager, API 게이트웨이로 사용할 수 있는 NGINX Plus 및 API 보안을 위한 NGINX App Protect가 포함됩니다.

작성자 소개

Andrew Stiefel

Andrew Stiefel의 다른 블로그 게시물