적응형 거버넌스는 API 개발자에게 필요한 자율성을 제공합니다.

오늘날의 기업은 종종 API와 마이크로서비스를 빌드하고 배포하는 전 세계적으로 분산된 팀으로 구성되어 있으며, 일반적으로 두 개 이상의 배포 환경에 걸쳐 있습니다. F5의 애플리케이션 전략 보고서 에 따르면 , 조직의 81%가 퍼블릭 클라우드, 프라이빗 클라우드, 온프레미스, 엣지에 걸쳐 세 개 이상의 환경에서 운영됩니다.

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

오늘날 API와 마이크로서비스의 수가 증가함에 따라 API 거버넌스는 기업 전체 API 전략을 계획하고 구현하는 데 가장 중요한 주제 중 하나가 되고 있습니다. 하지만 API 거버넌스란 무엇이고, API 전략에 왜 그렇게 중요한가요?

API 거버넌스란 무엇인가요?

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

API 거버넌스가 필요한 이유는 무엇입니까?

API 거버넌스의 전략적 중요성은 과소평가할 수 없습니다. 이는 조직의 전반적인 API 전략을 실현하는 수단입니다. 적절한 거버넌스 없이는 API의 설계, 운영 및 제품화 전반에 걸쳐 일관성을 달성할 수 없습니다.

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

어떤 유형의 API를 관리해야 합니까?

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

• 외부 API  – 데이터 및 기능을 통한 셀프 서비스 통합을 가능하게 하기 위해 외부 소비자 및 개발자에게 제공됨
• 내부 API  – 내부 애플리케이션과 마이크로서비스를 연결하는 데 사용되며 조직의 개발자만 사용할 수 있습니다.
• 파트너 API  – 파트너 조직의 개발자와 데이터 또는 애플리케이션에 대한 액세스를 공유하여 전략적 비즈니스 관계를 촉진합니다.
• 타사 API  – 서비스로서 타사 공급업체에서 소비되며, 주로 결제 처리나 데이터 또는 애플리케이션에 대한 액세스 활성화를 위해 사용됩니다.

기업의 각 유형의 API는 보안, 신뢰성, API에 액세스해야 하는 팀과 사용자에게 접근 가능한지 확인하기 위해 관리되어야 합니다.

어떤 API 거버넌스 모델을 사용할 수 있나요?

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

• 중앙 집중화  - 중앙 팀이 변경 사항을 검토하고 승인합니다. 운영 규모에 따라 이 팀은 진행을 늦추는 병목 현상이 될 수 있습니다.
• 분산화  - 개별 팀은 API를 구축하고 관리할 수 있는 자율권을 가지고 있습니다. 이로 인해 출시 시간이 늘어나지만 전반적인 보안과 안정성이 희생됩니다.

그러나 회사가 API 우선 여정을 진행하면서 프로덕션에서 API 수가 늘어나면서 두 모델 모두 무너지기 시작합니다. 중앙 집중형 모델은 종종 다양한 검토와 승인이 필요한 일괄적 접근 방식을 구현하려고 합니다. 이는 개발팀의 속도를 늦추고 마찰을 일으킵니다. 좌절한 개발자는 때로는 요구 사항을 해결할 방법을 찾기도 합니다(두려운 "섀도우 IT").

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

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

API 개발자에게 권한을 부여하기 위해 적응형 거버넌스를 활용하세요

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

적응형 거버넌스의 핵심은 기업 전체에 민첩성을 제공하기 위해 통제(일관성에 대한 필요성)와 자율성(지역적 의사 결정 능력)의 균형을 맞추는 것입니다. 실제로 적응형 거버넌스 모델은 의사 결정을 팀 간에 분리하고 분산합니다.

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

적응형 거버넌스를 통해 각 팀이나 사업부는 조직의 공유 인프라를 활용하면서도 자체 워크플로를 정의하고 필요한 통제 수준을 균형 있게 조절할 수 있습니다.

NGINX를 사용하여 API에 대한 적응형 거버넌스 구현

API 전략을 계획하고 구현하기 시작할 때 조직에서 적응형 거버넌스를 구현하기 위해 다음 모범 사례를 따르세요.

• 공유 인프라 제공  – API 프록시 및 문서 게시를 위한 API 게이트웨이 및 개발자 포털에 대한 액세스 권한을 팀에 제공
• 팀에 에이전시 제공  – 팀이 공유 작업 공간 내에서 API의 수명 주기를 온보딩하고 관리할 수 있도록 지원
• 로컬 제어를 통한 글로벌 정책 균형 조정  – 팀에 서비스에 대한 세부적인 제어를 제공하는 동시에 공유 인프라 전반에 글로벌 정책을 설정합니다.

F5 NGINX Management Suite의 일부인 API Connectivity Manager를 사용하여 이러한 사용 사례를 어떻게 달성할 수 있는지 살펴보겠습니다 .

공유 인프라 제공

조직 전반의 팀은 API를 구축하고 있으며, 마이크로서비스에 인증 및 권한 부여, mTLS 암호화 등 유사한 기능을 포함해야 합니다. 또한 API 소비자, 즉 내부 팀, 비즈니스 파트너 또는 외부 개발자에게 문서 및 버전 관리를 제공해야 합니다.

Platform Ops 팀은 팀에서 자체 솔루션을 구축하도록 요구하는 대신 공유 인프라에 대한 액세스를 제공할 수 있습니다. API Connectivity Manager의 모든 작업과 마찬가지로 UI나 완전히 선언적인 REST API를 사용하여 몇 분 안에 이를 설정할 수 있으며, 이를 통해 API Connectivity Manager를 CI/CD 파이프라인에 통합할 수 있습니다. 이 게시물에서는 UI를 사용하여 몇 가지 일반적인 워크플로를 설명합니다.

API Connectivity Manager는 인프라와 서비스의 두 가지 유형의 작업 공간을 지원합니다. 인프라 작업 공간은 Platform Ops 팀이 API Gateway Clusters 및 Developer Portal Clusters 형태로 공유 인프라를 온보딩하고 관리하는 데 사용합니다. 서비스 작업 공간은 API 개발자가 API 및 문서를 게시하고 관리하는 데 사용합니다.

공유 인프라를 설정하려면 먼저 인프라 작업 공간을 추가합니다. 왼쪽 탐색 열에서 인프라를 클릭한 다음 탭의 오른쪽 상단 모서리에 있는  + 추가  버튼을 클릭합니다. 작업 공간에 이름을 지정합니다(여기서는 team-sentence 입니다  . 간단한 "Hello, World!" API를 구축하는 가상의 팀입니다).

다음으로, Workspace에 환경을 추가합니다. 환경에는 API Gateway 클러스터와 Developer Portal 클러스터가 포함됩니다. Workspace 이름을 클릭한 다음 Actions 열 에서 … 아이콘을 클릭 하고 드롭다운 메뉴에서 Add를 선택합니다.

그림 2와 같이 환경 만들기 패널이 열립니다. 이름(선택 사항으로 설명) 필드에 입력하고 환경 유형 ( 프로덕션 또는 비프로덕션)을 선택한 다음 추가하려는 인프라(API Gateway 클러스터, 개발자 포털 클러스터 또는 둘 다)에 대한 + 추가 버튼을 클릭합니다.  만들기  버튼을 클릭하여 환경 설정을 완료합니다. 자세한 지침은 API Connectivity Manager 설명서를 참조하세요 .

팀 에이전시 제공

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

팀이 조직화되도록 돕기 위해 Platform Ops 팀은 팀이 서비스와 문서를 조직하고 운영할 수 있는 서비스 작업 공간을 제공할 수 있습니다. 이는 논리적 경계를 만들고 서비스를 개발하기 위해 개발, 테스트, 프로덕션과 같은 다양한 환경에 대한 액세스를 제공합니다. 이 프로세스는 이전 섹션 에서 만든 인프라 작업 공간을 만드는 것과 같습니다 .

먼저, 왼쪽 탐색 열에서 서비스를 클릭한 다음 탭의 오른쪽 상단 모서리에 있는  + 추가  버튼을 클릭합니다. 작업 공간에 이름을 지정하고(여기서는 "Hello, World" 서비스에 대한 api-sentence ), 선택적으로 설명과 연락처 정보를 제공합니다.

이 시점에서 API 개발자를 초대하여 해당 개발자를 위해 만든 Workspace에서 프록시와 문서를 게시하도록 할 수 있습니다. API 프록시와 문서를 게시하는 방법에 대한 전체 지침은 API Connectivity Manager 설명서를 참조하세요 .

세계 정책과 지역 통제의 균형

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

API Connectivity Manager는 공유 인프라에 적용되는 글로벌 정책과 API 프록시 수준에서 관리되는 세부적인 제어를 함께 제공합니다.

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

• 오류 응답 형식  – API 게이트웨이의 오류 코드 및 응답 구조 사용자 지정
• 로그 형식  - 액세스 로깅을 활성화하고 로그 항목 형식을 사용자 정의합니다.
• OpenID Connect  – OpenID Connect 정책을 사용하여 API에 대한 보안 액세스
• 응답 헤더  - 응답에 헤더 포함 또는 제외
• 요청 본문 크기  – 수신 API 페이로드 크기 제한
• 인바운드 TLS  – API 클라이언트와의 TLS 연결에 대한 정책 설정
• 백엔드 TLS  – TLS를 사용하여 백엔드 서비스에 대한 연결 보안

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

• 허용된 HTTP 메서드  – 사용할 수 있는 요청 메서드 정의( GET, POST, PUT, 등)
• 액세스 제어  – 다양한 인증 및 권한 부여 기술(API 키, HTTP 기본 인증, JSON 웹 토큰)을 사용하여 API에 대한 보안 액세스
• 백엔드 상태 점검  – 백엔드 서비스에 대한 요청 실패를 방지하기 위해 지속적인 상태 점검을 실행합니다.
• CORS  – 외부 도메인의 클라이언트가 리소스에 대한 제어된 액세스를 활성화합니다.
• 캐싱  – 캐싱 정책으로 API 프록시 성능 개선
• 프록시 요청 헤더  - 백엔드 서비스에 선택 헤더 전달
• 속도 제한  – 들어오는 요청 제한 및 API 작업 부하 보호

다음 예에서는 UI를 사용하여 API Gateway 프록시와 백엔드 서비스 간의 통신을 보호하는 정책을 정의합니다.

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

정책을 적용하려는 API Gateway Cluster 행에서 Actions 열의 … 아이콘을 클릭하고 드롭다운 메뉴에서 Edit Advanced Configuration을 선택합니다 . 왼쪽 열에서 Global Policies를 클릭하여 구성할 수 있는 모든 글로벌 정책 목록을 표시합니다.

TLS 백엔드 정책을 적용하려면 행의 오른쪽 끝에 있는 … 아이콘을 클릭 하고 드롭다운 메뉴에서 정책 추가를 선택합니다. 요청된 정보를 입력하고 인증서를 업로드한 다음 추가를 클릭합니다. 그런 다음  저장 및 제출  버튼을 클릭합니다 . 이제부터 API Gateway 클러스터와 백엔드 서비스 간의 트래픽은 TLS로 보호됩니다. 전체 지침은 API Connectivity Manager 설명서를 참조하세요 .

요약

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