API 제품 수명 주기 관리 쉽게 하기

현대 API는 내부 시스템과 제3자 모두가 소비하는 제품으로 설계, 구축, 운영되며, 이에 따라 유사하게 관리되어야 합니다. 많은 대기업들은 API를 전략적이고 중요한 구성 요소로 간주하며, 이를 위해 API 프로그램 전략을 수립하고 명확한 비즈니스 목표, 제약 조건, 리소스를 설정합니다. 전략이 수립되면 일상적인 전술적 접근은 주로 API 라이프사이클 관리에 초점을 맞춥니다.

전체 라이프사이클 API 관리(APIM)는 API의 전체 수명을 아우르며, 이는 계획 단계에서 시작하여 API가 폐기될 때까지 이어집니다. 라이프사이클 내의 많은 단계는 API 게이트웨이(API 관리 시스템의 주요 구성 요소)와 통합됩니다. 이 글에서는 3가지 주요 API 제품 라이프사이클 단계: _생성, 제어, 소비_를 살펴보고, 각 라이프사이클 단계에서 API 게이트웨이가 중요한 이유를 탐구합니다.

API 라이프사이클의 10가지 일반적인 단계

API 라이프사이클은 API의 진행 상황을 파악하고 성숙함에 따라 관리를 조정하는 데 도움이 되는 모델입니다. 일반적으로 API 라이프사이클 관리는 여러 단계로 나눌 수 있습니다:

구축 - API를 설계하고 구축합니다.
테스트 - 기능, 성능, 보안 기대치를 검증합니다.
게시 - 개발자에게 API를 공개합니다.
보안 - 보안 위험과 문제를 완화합니다.
관리 - API가 기능적이고 최신 상태이며 비즈니스 요구 사항을 충족하도록 유지 및 관리합니다.
온보딩 - 개발자가 공개된 API를 빠르게 학습하고 사용할 수 있도록 합니다. 예를 들어, OpenAPI 또는 AsyncAPI 문서를 제공하고 포털 및 샌드박스를 제공합니다.
분석 - 사용 현황을 이해하고 문제를 감지하기 위해 모니터링 데이터를 분석하고 관찰 가능성을 제공합니다.
홍보 - 개발자에게 API를 광고합니다. 예를 들어, API 마켓플레이스에 나열합니다.
수익화 - API 사용에 대한 요금을 청구하고 수익을 수집할 수 있도록 합니다. 이 부분은 다음 섹션에서 별도의 단계로 다룹니다.
폐기 - API의 사용 중단 및 제거를 지원합니다. 이는 비즈니스 우선순위 변경, 기술 변화, 보안 문제 등 다양한 이유로 발생합니다.

API 제품 라이프사이클 관리

제품 라이프사이클에는 일반적으로 _개발, 성장, 성숙, 쇠퇴_와 같은 네 가지 단계가 있으며, 이는 모든 제품이 시장 수요 관점에서 거치는 단계입니다. 이제 제품 라이프사이클 개념을 API에 적용하여 _생성, 게시, 실현, 유지, 폐기_의 5단계로 구성된 _API 제품 라이프사이클_을 도출할 수 있습니다. API 게이트웨이를 통합하여 전체 API 제품 라이프사이클을 관리함으로써 이 목록을 3가지 주요 단계로 더욱 좁힐 수 있습니다: 각각 생성, 제어, 소비입니다.

아래 다이어그램은 API 라이프사이클 관리가 API 게이트웨이 및 백엔드 서비스와 어떻게 통합되는지 보여줍니다:

API 라이프사이클 관리가 API 게이트웨이와 통합

이 3가지 단계를 각각 살펴보기 전에, 먼저 API 게이트웨이가 실제로 어떤 문제를 해결할 수 있는지 이해해 보겠습니다.

API 게이트웨이가 해결하는 주요 문제

API, 트래픭 관리 및 관련 기술을 다룰 때, 단기적인 구현과 장기적인 유지 관리 사이의 균형을 맞추어야 합니다. API와 관련된 여러 가지 교차 문제가 있으며, 이에는 _유지 관리성, 확장성, 보안, 관찰 가능성, 제품 라이프사이클 관리, 수익화_가 포함됩니다. API 게이트웨이는 이 모든 문제를 해결하는 데 도움을 줄 수 있습니다!

다음은 API 게이트웨이가 해결할 수 있는 주요 문제에 대한 개요입니다:

프론트엔드와 백엔드 사이에 어댑터/퍼사드를 사용하여 결합도를 줄입니다.
백엔드 서비스를 집계/변환하여 소비를 단순화합니다.
위협 탐지 및 완화를 통해 API의 과도한 사용 및 남용으로부터 보호합니다.
API가 어떻게 소비되고 있는지 이해합니다(관찰 가능성).
API를 제품으로 관리하며 API 라이프사이클 관리를 수행합니다.
계정 관리, 청구 및 결제를 통해 API를 수익화합니다.

API 생성 단계

API 생성 단계는 API 제품 라이프사이클 관리 프로세스의 첫 번째 단계로, 여기서 API를 설계, 오케스트레이션, 변환, 문서화, 테스트합니다. 이 단계에서는 Apache APISIX와 같은 현대적인 API 게이트웨이가 API를 처음부터 구축하거나 OpenAPI YAML/JSON 구조와 같은 다양한 소스에서 API 정의를 가져와 Route 및 Upstreams를 등록하는 데 도움이 될 수 있습니다.

기존 API의 정보를 결합하여 새로운 API를 공개하고 싶을 수 있습니다. API 게이트웨이의 응답 구성 기능을 통해 이를 달성할 수 있습니다. 또는 내부 및 외부 시스템을 새로운 API로 연결하는 경우, 이들이 XML/SOAP에서 JSON REST로 또는 그 반대로 다른 형식으로 통신할 수 있습니다. 기존 REST API가 있지만 새로운 GraphQL API를 구축 중일 수 있습니다. 예를 들어, Apache APISIX를 사용하면 GraphQL API를 REST API로 변환할 수 있습니다.

게시 전에 API 테스트를 완료하여 클라이언트 애플리케이션과의 API 계약을 충족하는지 확인하는 것이 중요합니다. 이러한 경우, API 게이트웨이를 사용하여 API 응답을 모의로 만들어 통합을 테스트할 수 있습니다.

API 제어 단계

제어 단계에서는 보안 정책을 적용하고, 배포, 관리, 모니터링, 확장합니다. 테스트 후, API를 보호하여 승인된 사용자와 애플리케이션만 API에 접근할 수 있도록 하고, 무단 접근 또는 남용을 방지합니다. 이는 입력 검증, OAuth, API 키와 같은 기술을 사용하고, API 게이트웨이를 통해 사용 제한 또는 할당량을 설정하는 것을 포함할 수 있습니다. 또한, API 메트릭, 추적, 로그를 모니터링하고 분석 데이터를 기반으로 API 성능을 최적화합니다.

동일한 단계에서, API 게이트웨이를 사용한 다양한 API 릴리스 전략을 활용하여 개발, 테스트, 스테이징, 프로덕션 환경에 API를 즉시 배포할 수 있습니다. 이는 설정 노력 없이 다운타임 없이 수행됩니다. API를 DevOps 도구와 통합하여 지속적 통합/지속적 개발(CI/CD) 모범 사례를 통해 배포 시간을 효율적으로 줄입니다.

이 단계에서는 시간이 지남에 따라 API에 대한 변경 사항을 관리하여 업데이트 또는 수정이 적절히 테스트되고 의도하지 않은 결과를 초래하지 않도록 합니다. 여러 API 버전을 추가하여 업데이트를 관리할 수 있습니다.

API 소비 단계

API 소비 단계에서는 API가 개발자 및 기타 외부 사용자가 발견할 수 있도록 제공됩니다. 이는 개발자가 공개된 API를 소비할 수 있도록 하고, OpenAPI 문서를 제공하며, 개발자가 통합을 테스트할 수 있는 샌드박스 환경을 제공하는 것을 포함합니다.

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를 제공하고, 요청 수를 줄이며, 보안 정책을 강제하는 것입니다.