개발자에게 필요한 API 거버넌스

이번 포스트에서는 적응형 거버넌스 (Adaptive Governance)가 무엇이고 필요한 이유와 모델 소개 및 구현 방법을 설명합니다. 오늘날의 기업은 일반적으로 둘 이상의 배포 환경에 걸쳐 API 및 Microservices를 구축 및 배포하는 전 세계적으로 분산된 팀으로 구성됩니다. 애플리케이션 전략 현황 보고서(State of Application Strategy Report)에 따르면 조직의 81%가 Public Cloud, Private Cloud, On-premise 및 Edge에 걸쳐 3개 이상의 환경에서 운영됩니다.

이러한 복잡한 멀티 클라우드 아키텍처의 안정성과 보안을 보장하는 것은 이러한 아키텍처의 유지 관리를 담당하는 Platform Ops 팀의 주요 과제입니다. 보고서에서 설문조사를 실시한 소프트웨어 엔지니어 리더에 따르면 가시성(45%)과 일관된 보안(44%)이 Platform Ops 팀이 직면한 멀티 클라우드 문제 목록의 1위를 차지했습니다.

오늘날 API와 Microservices의 수가 증가함에 따라 API 거버넌스는 기업 전반에 걸쳐 API 전략을 계획하고 구현하는 데 있어 가장 중요한 주제 중 하나가 되었습니다. 그럼 API 거버넌스란 무엇이며, API 전략에 왜 그렇게 중요한가요?

목차

1. API 거버넌스(Governance)란?
2. API 거버넌스가 필요한 이유
3. 관리해야 되는 API 유형
4. 사용할 수 있는 API 거버넌스 모델
5. 적응형 거버넌스(Adaptive Governance)를 사용하여 API 개발자의 역량 강화
6. NGINX를 사용하여 API 적응형 거버넌스 구현
6-1. 공유 인프라 제공
6-2. 팀에 에이전시 제공
6-3. 글로벌 정책과 로컬 제어의 균형
7. 요약

1. API 거버넌스(Governance)란?

가장 기본적인 수준에서 API 거버넌스에는 API가 검색 가능하고, 안정적이고, 관찰 가능하고, 안전하게 하기 위해 정책을 만들고 확인 및 유효성 검사를 실행하는 작업이 포함됩니다. 이는 최신 애플리케이션을 지원하는 복잡한 시스템 및 비즈니스 프로세스의 상태에 대한 가시성을 제공하며, 이를 통해 시간이 지남에 따라 API 인프라의 발전을 안내하는 데 사용할 수 있습니다.

2. API 거버넌스가 필요한 이유

API 거버넌스의 전략적 중요성은 아무리 강조해도 지나치지 않습니다. 즉, 조직의 전체 API 전략을 실현하는 수단입니다. 적절한 거버넌스 없이는 API의 설계, 운영 및 생산 전반에 걸쳐 일관성을 달성할 수 없습니다.

제대로 수행되지 않을 경우, 거버넌스는 종종 팀의 속도를 늦추는 부담스러운 요구 사항을 부과합니다. 그러나 API 거버넌스가 잘 이루어지면 작업이 줄어들고 승인이 간소화되며 조직의 여러 팀이 독립적으로 작동하면서 API 전략의 전반적인 목표를 달성할 수 있습니다.

3. 관리해야 되는 API 유형

API 전략의 일부로 효과적인 API 거버넌스 계획을 구축하는 것은 프로덕션에서 보유하고 있는 API 유형 및 API를 관리하는 데 필요한 도구, 정책 및 지침을 식별하는 것으로 시작됩니다. 오늘날 대부분의 엔터프라이즈 팀은 4가지 기본 유형의 API로 작업하고 있습니다.

  • External API – 데이터 및 기능과 셀프 서비스 통합이 가능하도록 외부 소비자 및 개발자에게 제공
  • Internal API – 내부 애플리케이션과 Microservices를 연결하는 데 사용되며 조직의 개발자만 사용할 수 있습니다.
  • Partner API – 파트너 조직의 개발자와 데이터 또는 애플리케이션에 대한 액세스를 권한을 공유하여 전략적 비즈니스 관계를 촉진합니다.
  • Third-Party API – 종종 지불을 처리하거나 데이터 또는 애플리케이션에 액세스할 수 있도록 타사 공급업체에서 서비스 사용

기업의 각 API 유형을 관리하여 액세스해야 하는 팀과 사용자가 안전하고 신뢰할 수 있게 액세스할 수 있도록 해야 합니다.

4. 사용할 수 있는 API 거버넌스 모델

API 거버넌스를 정의하고 적용하는 방법에는 여러 가지가 있습니다. NGINX에서는 일반적으로 고객이 다음 두 가지 모델 중 하나를 적용하는 것을 볼 수 있습니다.

  • 중앙 집중식(Centralized) – 중앙 팀이 변경 사항을 검토하고 승인합니다. 운영 규모에 따라 이 팀은 진행 속도를 늦추는 병목 현상이 될 수 있습니다.
  • 탈중앙화(Decentralized) – 개별 팀은 API를 구축 및 관리할 수 있는 자율성을 가집니다. 이로 인해 출시 시간이 줄어들지만 전반적인 보안과 신뢰성은 저하됩니다.

그러나 기업이 API를 처음 사용하면서 두 모델 모두 프로덕션에서 API의 수가 증가함에 따라 분해되기 시작합니다. 중앙 집중식 모델은 종종 다양한 검토와 승인이 필요한 일률적인 접근 방식을 구현하려고 합니다. 이로 인해 개발 팀의 작업 속도가 느려지고 마찰이 발생합니다. 개발자는 좌절감에 빠져 때때로 요구 사항(“Shadow IT”)을 해결하는 방법을 찾기도 합니다.

다른 모델인 분산형 거버넌스는 처음에는 API 개발자에게 잘 작동하지만 시간이 지남에 따라 복잡성이 증가합니다. API를 배포하는 여러 팀이 자주 통신하지 않는 한, 각 팀이 서로 다르게 설계되고 작동하며, 버전 변경으로 서비스 간에 운영 중단이 발생하고, 팀 및 서비스 간에 일관성이 없는 보안이 시행됩니다. API를 구축하는 팀의 경우, 중앙 집중식 모델과 마찬가지로 추가적인 작업과 복잡성으로 인해 결국 개발 속도가 느려집니다.

클라우드 네이티브 애플리케이션은 API를 사용하여 개별 Microservices가 서로 통신하고 응답을 요청의 소스로 다시 전달합니다. 기업들이 유연성과 민첩성을 위해 Microservices를 계속 수용함에 따라 API Sprawl은 사라지지 않을 것입니다. 대신, 이러한 복잡하고 끊임없이 변화하는 환경에서 API를 관리하기 위한 다른 접근 방식이 필요합니다.

5. 적응형 거버넌스(Adaptive Governance)를 사용하여 API 개발자의 역량 강화

다행히도, 더 좋은 방법이 있습니다. 적응형 거버넌스 는 API 개발자에게 권한을 부여하는 동시에 Platform Ops팀에게 기업 전체에서 API의 안정성과 보안을 보장하는 데 필요한 제어 권한을 부여하는 대안 모델을 제공합니다.

적응형 거버넌스의 핵심은 제어(일관성의 필요성)와 자율성(로컬 의사 결정을 내릴 수 있는 기능)의 균형을 유지하여 기업 전체에서 민첩성을 구현하는 것입니다. 실제로 적응형 거버넌스 모델은 여러 팀 간에 의사 결정을 분산하고 배포합니다.

Platform Ops팀은 공유 인프라(API Gateway 및 개발자 포털)를 관리하고 글로벌 정책을 설정하여 API 간의 일관성을 보장합니다. 그러나 API를 구축하는 팀은 서비스나 비즈니스 사업에 대한 주제 전문가 역할을 합니다. 개별 비즈니스 context에 대한 요구 사항을 충족하기 위해 API에 대한 로컬 정책(역할 기반 액세스 제어(RBAC), 서비스 속도 제한 등)을 설정하고 적용할 수 있는 권한이 있습니다.

적응형 거버넌스를 통해 각 팀 또는 비즈니스 사업는 조직의 공유 인프라를 사용하면서 Workflow를 정의하고 필요한 제어 수준의 균형을 맞출 수 있습니다.

6. NGINX를 사용하여 API 적응형 거버넌스 구현


API 전략을 계획하고 구현하기 시작할 때 다음과 같은 모범 사례에 따라 조직에서 적응형 거버넌스 를 구현하십시오.

NGINX Management Suite의 일부인 API Connectivity Manager를 사용하여 이러한 사용 사례를 달성하는 방법을 살펴보겠습니다.

6-1. 공유 인프라 제공

조직 전체의 팀이 API를 구축하고 있으며 인증 및 권한 부여, mTLS 암호화 등과 유사한 기능을 Microservices에 포함해야 합니다. 또한 내부 팀, 비즈니스 파트너 또는 외부 개발자와 같은 API 소비자가 문서 및 버전 관리를 사용할 수 있도록 해야 합니다.

팀이 자체 솔루션을 구축하도록 요구하는 대신 Platform Ops팀은 공유 인프라에 대한 액세스를 제공할 수 있습니다. API Connectivity Manager의 모든 작업과 마찬가지로 UI 또는 완전히 선언적인 REST API를 사용하여 몇 분 만에 이 기능을 설정할 수 있습니다. 이를 통해 API Connectivity Manager를 CI/CD Pipeline에 통합할 수 있습니다. 이 포스트에서는 UI를 사용하여 몇 가지 일반적인 Workflow를 보여 줍니다.

API Connectivity Manager는 인프라와 서비스라는 두 가지 유형의 Workspace를 지원합니다. 인프라 Workspace은 Platform Ops 팀에서 API Gateway 클러스터 및 개발자 포털 클러스터 형태로 공유 인프라를 온보딩(On-boarding)하고 관리하는 데 사용됩니다. 서비스 Workspace은 API 개발자가 API 및 문서를 게시하고 관리하는 데 사용합니다.

공유 인프라를 설정하려면 먼저 인프라 Workspace을 추가하십시오. 왼쪽 탐색 열에서 인프라를 클릭한 다음 탭의 오른쪽 상단 모서리에 있는 + 추가 버튼을 클릭합니다. Workspace에 이름을 지정합니다(여기서는 가상의 팀이 간단한 “Hello, World!” API를 Build하는 것입니다).

적응형 거버넌스 1

그림 1: 인프라 작업 공간 추가


다음으로 Workspace에 환경을 추가합니다. 환경에는 API Gateway 클러스터 및 개발자 포털 클러스터가 포함됩니다. Workspace 이름을 클릭한 다음 작업 열에서 … 아이콘을 클릭합니다. 드롭다운 메뉴에서 추가를 선택합니다.

그림 2와 같이 Create Environment 패널이 열립니다. 이름(및 선택적으로 설명) 필드를 입력하고 환경 유형(Production 또는 Non-Production)을 선택한 다음 추가할 인프라(API Gateway 클러스터, 개발자 포털 클러스터 또는 둘 다)에 대해 + 버튼을 클릭합니다. 환경 설정을 완료하려면 Create 버튼을 클릭합니다.

적응형 거버넌스 2

그림 2: 환경 및 온보드 인프라 생성


6-2. 팀에 에이전시 제공


비즈니스 사업, 지리적 지역 또는 기타 논리적 경계별로 팀을 논리적으로 분리하는 것은 의미가 있습니다. 그렇다고 해서 팀이 성공하는 데 필요한 도구에 대한 액세스 권한이 박탈되지는 않습니다. 공유 인프라에 액세스할 수 있다고 해서 팀이 글로벌 수준의 활동에 대해 걱정해야 하는 것은 아닙니다. 대신 고객이 자체 요구 사항을 정의하고 로드맵을 작성하며 Microservice를 구축하는 데 집중하도록 해야 합니다.

팀 구성을 지원하기 위해 Platform Ops 팀은 팀이 서비스 및 문서를 구성하고 운영할 수 있도록 서비스 Workspace을 제공할 수 있습니다. 이를 통해 논리적 경계를 형성되고 서비스 개발을 위한 개발, 테스트 및 Production과 같은 다양한 환경에 대한 액세스를 제공합니다. 이 프로세스는 이전 섹션에서 만든 인프라 Workspace을 만드는 것과 같습니다.

먼저 왼쪽 탐색 열에서 서비스를 클릭한 다음 탭의 오른쪽 상단 모서리에 있는  + Add  버튼을 클릭합니다. Workspace에 이름을 지정하고(여기는 “Hello, World” 서비스의 api-sentence) 필요에 따라 설명 및 연락처 정보를 선택적으로 제공합니다.

적응형 거버넌스 3

그림 3: 서비스 작업 공간 만들기

이 시점에서 API 개발자를 초대하여 작성한 Workspace에서 Proxy 및 문서 게시를 시작할 수 있습니다.

6-3. 글로벌 정책과 로컬 제어의 균형

적응형 거버넌스를 위해서는 글로벌 정책을 시행하는 것과 팀이 민첩성을 높이는 결정을 내릴 수 있도록 권한을 부여하는 것 사이에서 균형이 필요합니다. Platform Ops에서 시행하는 글로 설정을 정의하고 API 개발자가 사용하는 도구와 그들이 내릴 수 있는 결정을 정의하는 “guardrail”을 설정하여 책임을 명확하게 구분해야 합니다.

API Connectivity Manager는 API Proxy 수준에서 관리되는 글로벌 정책(공유 인프라에 적용)과 세분화된 제어 기능을 함께 제공합니다.

API Connectivity Manager에서 사용할 수 있는 글로벌 정책은 다음과 같습니다.

  • 오류 응답 형식 – API Gateway의 오류 코드 및 응답 구조 사용자 지정
  • 로그 형식 – 액세스 로깅을 활성화하고 로그 항목 형식을 사용자 정의합니다.
  • OpenID Connect – OpenID Connect 정책으로 API에 대한 보안 액세스
  • 응답 헤더 – 응답에 헤더 포함 또는 제외
  • Request Body Size – 수신 API Payload의 크기 제한
  • Inbound TLS – API 클라이언트와의 TLS 연결에 대한 정책 설정
  • Backend TLS – TLS로 Backend 서비스에 대한 연결 보호

API Connectivity Manager에서 사용할 수 있는 API Proxy 정책은 다음과 같습니다.

  • 허용되는 HTTP 메서드 – 사용할 수 있는 요청 메서드를 정의합니다(GET, POST, PUT 등).
  • Access Control – 다양한 인증 및 권한 부여 기술(API Key, HTTP 기본 인증, JSON Web Token)을 사용하여 API에 대한 안전한 액세스
  • Backend Health Check – 지속적인 상태 점검을 실행하여 Backend 서비스에 대한 요청 실패를 방지합니다.
  • CORS – 외부 도메인에서 클라이언트의 리소스에 대한 제어된 액세스 지원
  • Caching – 캐싱 정책을 해 API Proxy 성능 향상
  • Proxy Request Header – 선택 헤더를 Backend 서비스에 전달
  • 속도 제한(Rate Limiting) – 들어오는 요청을 제한하고 API Workload를 보호합니다.

다음 예제에서는 UI를 사용하여 API Gateway Proxy와 Backend 서비스 간의 통신을 보호하는 정책을 정의합니다.

왼쪽 탐색 열에서 Infrastructure를 클릭합니다. 편집하려는 API Gateway 클러스터가 포함된 환경의 이름을 클릭하면 해당 환경의 API Gateway 클러스터 및 개발자 포털 클러스터가 탭에 표시됩니다.

적응형 거버넌스 4

그림 4: API Gateway 클러스터 및 개발자 포털 클러스터에 대한 글로벌 정책 구성

정책을 적용할 API Gateway 클러스터 행에서 작업 열의 … 아이콘을 클릭하고 드롭다운 메뉴에서 고급 구성 편집을 선택합니다. 구성할 수 있는 모든 글로벌 정책 목록을 표시하려면 왼쪽 열에서 글로벌 정책을 클릭합니다.

Screenshot of Global Policies page in API Connectivity Manager UI

그림 5: API Gateway 클러스터에 대한 정책 구성

TLS Backend 정책을 적용하려면 행 오른쪽 끝에 있는 … 아이콘을 클릭하고 드롭다운 메뉴에서 Add Pollcy를 선택합니다. 요청된 정보를 입력하고 인증서를 업로드한 다음 Add를 클릭합니다. 그런 다음 Save and Submit 버튼을 클릭합니다. 이제부터 API Gateway 클러스터와 Backend 서비스 간의 트래픽은 TLS로 보호됩니다.

7. 요약

API 거버넌스를 계획하고 구현하는 것은 API 전략의 성공을 보장하는 중요한 단계입니다. 분산 모델을 지향하고 적응형 거버넌스 에 의존하여 다양한 팀과 API의 고유한 요구 사항을 해결함으로써 API와 클라우드 네이티브 환경을 매우 생산적으로 만드는 속도와 민첩성을 희생하지 않고도 일관된 거버넌스를 확장하고 적용할 수 있습니다.

API Connectivity Manager, API Gateway로 NGINX Plus 및 API 보호를 위한 NGINX App Protect를 직접 사용해 보려면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.