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

API는 클라우드 기반 애플리케이션의 결합 조직이며, 애플리케이션의 구성 요소 마이크로서비스가 통신하는 수단입니다. 애플리케이션이 커지고 확장됨에 따라, 마이크로서비스와 API의 수도 늘어납니다. 대부분의 경우 이는 불가피한 결과이지만, 현대적 애플리케이션의 안정성, 확장성 및 보안을 보장해야 하는 플랫폼 운영 팀에게는 상당한 과제로 다가옵니다. 우리는 이 문제를 API 확산 이라고 부르고, 이전 블로그 게시물 에서 이에 관해 언급한 적이 있습니다.

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

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

API-First란 무엇인가?

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

API 우선으로 가는 길은 많지만 , 소프트웨어 개발에 대한 디자인 중심 접근 방식은 API 우선 여정을 시작하는 대부분 회사의 최종 목표입니다. 실제로 이 접근 방식에서는 API가 구현되기 전에 완전히 정의된다는 것을 의미합니다. 작업은 API가 어떻게 작동할지 설계하고 문서화하는 것으로 시작됩니다. 팀은 API 계약 이라고도 하는 결과 아티팩트를 활용하여 애플리케이션의 기능을 구현하는 방법을 알려줍니다.

O'Reilly에서 출간한 eBook 'API 아키텍처 마스터하기' 의 1장에서, 내구성과 유연성을 겸비한 API 중심 소프트웨어 개발 방식을 지원하는 설계 기법에 대해 알아보세요. 이 책은 NGINX를 기반으로 쓰여졌습니다.

조직을 위한 API-First의 가치

API 우선 전략은 애플리케이션 생태계가 모듈식이고 재사용 가능한 시스템으로 탄생할 수 있도록 보장하기 때문에 마이크로서비스 아키텍처에 이상적인 경우가 많습니다. API 우선 소프트웨어 개발 모델을 채택하면 개발자와 조직 모두에게 다음을 포함한 상당한 이점이 제공됩니다.

• 개발자 생산성 향상 – 개발팀은 병렬로 작업할 수 있으며, 애플리케이션 API에 의존하는 다른 마이크로서비스를 작업하는 팀에 영향을 주지 않고 백엔드 애플리케이션을 업데이트할 수 있습니다. 모든 팀이 확립된 API 계약을 참조할 수 있으므로 API 라이프사이클 전반에 걸쳐 협업이 더 쉬워지는 경우가 많습니다.
• 향상된 개발자 경험 – API 우선 설계는 API가 논리적이고 잘 문서화되어 있는지 확인하여 개발자 경험을 우선시합니다. 이는 개발자가 API와 상호 작용할 때 원활한 경험을 제공합니다. Platform Ops 팀이 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 스키마 - API에 사용되는 스키마 객체의 JSON 설명

REST API는 오늘날 프로덕션에서 사용되는 API의 대부분을 구성하며 OpenAPI 사양은 REST API에 대한 API 정의를 작성하는 표준 방식입니다. 주어진 API가 어떻게 기능하는지 설명하는 기계에서 읽을 수 있는 계약을 제공합니다. OpenAPI 사양은 NGINX를 포함한 다양한 API 관리 및 API 게이트웨이 도구에서 널리 지원됩니다. 이 블로그의 나머지 부분에서는 OpenAPI 사양을 사용하여 몇 가지 중요한 사용 사례를 달성하는 방법에 중점을 둡니다.

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

오픈 API: 3.0.0info:
버전: 1.0.0
제목: 식료품 목록 API
설명: OpenAPI 사양을 설명하는 예제 API

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

paths:
/list:
get:
description: 식료품 목록에 있는 물건 목록을 반환합니다.
응답:
        '200':
설명: 성공적으로 목록을 반환했습니다.
content:
schema:
type: array
items:
type: object
properties:
item_name:
type: string

OpenAPI 사양을 따르는 정의는 사람과 기계가 모두 읽을 수 있습니다. 즉, 각 API의 기능을 문서화하는 단일 진실 출처가 존재한다는 의미입니다. 이는 특히 많은 팀이 API를 구축하고 운영하는 조직에서 매우 중요합니다. 물론, 규모에 맞게 API를 관리, 통제 및 보호하려면 API 게이트웨이, 개발자 포털, 고급 보안 등 API 플랫폼의 나머지 도구도 OpenAPI 사양을 지원하는지 확인해야 합니다.

API 아키텍처 마스터링 의 1장에서 OpenAPI 사양을 사용하여 REST API를 설계하는 방법에 대해 자세히 알아보세요.

공통 API 사양 채택의 이점

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

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

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

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

NGINX는 대규모 API를 쉽게 운영하고 모니터링하고 관리하고 보호할 수 있는 가볍고 클라우드 기반 도구 세트를 제공합니다. 예를 들어, F5 NGINX Management Suite 의 일부인 API Connectivity Manager는 API 작업을 위한 단일 관리 평면을 제공합니다. 이를 사용하면 API 게이트웨이와 개발자 포털을 구성하고 관리할 수 있습니다. API 중심 도구이기 때문에 모든 기능에 REST API를 통해 접근할 수 있어 DevOps 팀이 CI/CD 자동화와 통합을 쉽게 수행할 수 있습니다.

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

• API 게이트웨이에 API 게시
• 개발자 포털에 대한 API 문서 생성
• API 엔드포인트를 보호하기 위해 긍정적 보안을 적용합니다.

API Gateway에 API 게시

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

OpenAPI 사양을 사용하여 API를 게시하는 방법에 대한 자세한 내용은 API 연결 관리자 설명서를 참조하세요.

개발자 포털을 위한 API 문서 생성

API 팀에게는 문서 유지 관리가 골치 아픈 일이 되는 경우가 많습니다. 하지만 개발자 포털의 오래된 문서도 API 확산의 주요 증상이다. API Connectivity Manager는 OpenAPI 사양을 사용하여 자동으로 문서를 생성하고 개발자 포털에 게시합니다. 이를 통해 API 개발자는 시간을 절약하고 API 사용자는 항상 필요한 정보를 찾을 수 있습니다. API 연결 관리자 사용자 인터페이스나 REST API를 통해 OpenAPI 사양 파일을 직접 업로드할 수 있습니다.

개발자 포털에 API 문서를 게시하는 방법에 대한 자세한 내용은 API 연결 관리자 설명서를 참조하세요.

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 아키텍처 마스터 링의 7장에서 API 게이트웨이에서 인증 및 권한 부여를 적용하는 방법을 알아보세요.

요약

API 우선 접근 방식을 사용하여 마이크로서비스와 애플리케이션을 구축하면 여러 면에서 조직에 도움이 될 수 있습니다. 팀을 OpenAPI 사양(또는 사람과 기계가 모두 읽을 수 있는 다른 공통 API 사양)에 맞춰 조정하면 팀 간 협업, 커뮤니케이션, 운영이 가능해집니다.

최신 애플리케이션은 복잡한 클라우드 기반 환경에서 작동합니다. API 중심 접근 방식으로 API를 운영하는 도구를 도입하는 것은 API 중심 전략을 실현하는 데 중요한 단계입니다. NGINX를 사용하면 OpenAPI 사양을 사용하여 분산된 팀과 환경에서 대규모 API를 관리할 수 있습니다.

API Connectivity Manager , API 게이트웨이인 NGINX Plus , API를 보호하기 위한 NGINX App Protect가 포함된 NGINX Management Suite의 30일 무료 평가판을 시작하세요.