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

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

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

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

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

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

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

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

거버넌스가 제대로 이루어지지 않으면, 팀의 속도를 늦추는 부담스러운 요구 사항이 부과되는 경우가 많습니다. 하지만 API 거버넌스를 제대로 구현하면 작업량이 줄어들고, 승인이 간소화되고, 조직 내 여러 팀이 API 전략의 전반적인 목표를 달성하는 동시에 독립적으로 기능할 수 있습니다.

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

API 전략의 일환으로 효과적인 API 거버넌스 계획을 구축하려면 먼저 프로덕션에 있는 API 유형과 이를 관리하는 데 필요한 도구, 정책 및 지침을 식별해야 합니다. 오늘날 대부분의 기업 팀은 4가지 주요 유형의 API를 사용하고 있습니다.

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

기업의 각 유형의 API는 보안과 신뢰성을 갖추고 이에 액세스해야 하는 팀과 사용자에게 접근이 가능하도록 관리되어야 합니다.

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

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

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

하지만 기업이 API 우선 여정을 진행함에 따라 프로덕션에서 사용되는 API 수가 늘어나면서 두 모델 모두 붕괴되기 시작합니다. 중앙집중형 모델은 종종 다양한 검토와 승인을 필요로 하는 단일화된 접근 방식을 구현하려고 합니다. 이로 인해 개발팀의 속도가 느려지고 마찰이 발생합니다. 좌절한 개발자들은 요구 사항을 해결할 방법(두려운 "섀도우 IT")을 찾아내는 경우도 있습니다.

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

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

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

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

적응형 거버넌스의 핵심은 기업 전체에 민첩성을 확보하기 위해 통제(일관성에 대한 필요성)와 자율성(현지에서 결정을 내릴 수 있는 능력)의 균형을 맞추는 것입니다. 실제로 적응형 거버넌스 모델은 의사 결정을 여러 팀으로 나누어 분산시킵니다.

플랫폼 운영 팀은 공유 인프라(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는 인프라와 서비스라는 두 가지 유형의 작업 공간을 지원합니다. 인프라 작업 공간은 플랫폼 운영 팀에서 API 게이트웨이 클러스터와 개발자 포털 클러스터의 형태로 공유 인프라를 온보딩하고 관리하는 데 사용됩니다. 서비스 작업 공간은 API 개발자가 API와 문서를 게시하고 관리하는 데 사용됩니다.

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

다음으로, 작업 공간에 환경을 추가합니다. 환경에는 API 게이트웨이 클러스터와 개발자 포털 클러스터가 포함됩니다. 작업 공간 이름을 클릭한 다음 작업 열의 ... 아이콘을 클릭하고 드롭다운 메뉴에서 추가를 선택합니다.

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

팀 에이전시 제공

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

팀을 정리하는 데 도움을 주기 위해 Platform Ops 팀은 팀이 서비스와 문서를 정리하고 운영할 수 있는 서비스 작업 공간을 제공할 수 있습니다. 이를 통해 논리적 경계가 생성되고 개발, 테스트, 프로덕션 등 다양한 환경에 대한 액세스가 제공되어 서비스를 개발할 수 있습니다. 이 과정은 이전 섹션 에서 만든 인프라 작업 공간을 만드는 것과 같습니다.

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

이 시점에서 API 개발자를 초대하여 자신이 만든 작업 공간에서 프록시와 문서를 게시할 수 있습니다. 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 클러스터 행에서 작업 열의 ... 아이콘을 클릭하고 드롭 다운 메뉴에서 고급 구성 편집을 선택합니다. 왼쪽 열에서 글로벌 정책을 클릭하면 구성할 수 있는 모든 글로벌 정책 목록이 표시됩니다.

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

요약

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

시작하기

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