APISIX가 Tencent BlueKing의 API Gateway 업그레이드를 주도하다

이 사례 연구는 Tencent IEG(Interactive Entertainment Group)의 BlueKing PaaS 플랫폼 기술 이사인 Lei Zhu가 공유한 내용입니다.

BlueKing 소개

BlueKing은 Tencent IEG(Interactive Entertainment Group) 내부에서 개발된 통합 연구 및 운영 PaaS로, 여러 비즈니스 유닛과 내부 플랫폼을 서비스합니다. 그 역할은 회사의 프로젝트에 CI(지속적 통합), CD(지속적 제공), CO(지속적 운영) 단계에서 전 생애 주기 서비스를 제공하는 것입니다.

개요

도전 과제

• 낮은 성능: 높은 동시성 조건과 라우팅 알고리즘에서의 낮은 성능으로 인해 라우팅 매칭 및 전달 속도가 느림
• 엄청난 DB 부하: 라우팅 정책이 MySQL에 저장되어 있어, 많은 검색 요청으로 인해 데이터베이스에 부하가 걸림
• 높은 비용: Redis가 다양한 시나리오에서 널리 사용되어 높은 오버헤드 비용 발생
• 불충분한 격리: 물리적 격리를 달성할 수 없음; 장기 연결이 불안정함
• 단일 프로토콜 지원: HTTP 프로토콜만 지원
• 동적 라우팅 미지원: 카나리 릴리스에 불친절하며, 시나리오 기반 조합 및 캡슐화 불가능
• 서비스 발견 기능 부족: 마이크로서비스 아키텍처에 불친절함

목표

• 플랫폼 기능을 독립적인 마이크로서비스로 전환하고, 마이크로서비스 변환을 통해 PaaS 아키텍처 형성
• 로우코드 기술을 사용하여 SaaS를 효율적으로 개발하여 PaaS 플랫폼의 마이크로서비스 기능 활용
• 다양한 SaaS를 통해 다양한 서비스 시나리오에 유연하게 대응

결과

• K8s의 CRD 사용자 정의 리소스를 사용하여 게이트웨이의 통합 운영 및 확장 실현
• APISIX 통합을 통해 더 풍부한 기능 제공: 리소스 관리, 버전 릴리스, 자동 문서화, 권한 관리, 관찰 가능성, 모니터링 및 보안 보호
• 서비스 발견 시나리오 지원 비용 절감을 위한 통합 개발자 인터페이스 및 규정 제공

게임의 다양성과 복잡성으로 인해 BlueKing API 게이트웨이가 필요

Tencent 내부에는 수천 개의 게임이 있을 수 있습니다. 일부 자체 개발 게임을 제외하고 나머지는 대행사에 속합니다. 게임은 언어, 의존하는 저장소, 아키텍처 스타일 등이 다르기 때문에 BlueKing은 자체 API 게이트웨이를 개발했습니다.

이러한 복잡한 비즈니스 시나리오와 많은 이기종 아키텍처를 고려할 때, BlueKing은 내부 플랫폼으로서 API 게이트웨이를 변환하여 PaaS 아키텍처를 개발하고, 로우코드 기술을 사용하여 SaaS를 효율적으로 개발하여 PaaS의 마이크로서비스 기능을 활용하며, 다양한 SaaS를 통해 서비스 시나리오를 처리해야 합니다.

BlueKing의 아키텍처를 추상화하면 다음과 같은 API 다이어그램을 얻을 수 있습니다.

• 한편으로, BlueKing은 복잡한 플랫폼으로, 통합 게이트웨이에 대한 복잡한 요구 사항이 있습니다. 플랫폼의 API를 호출하는 프록시 역할 외에도, BlueKing은 서비스 발견, 인증 및 인가, 동적 라우팅, 카나리 릴리스, 속도 제한 등과 같은 더 많은 게이트웨이 기능을 요구합니다.

• 다른 한편으로, 클라우드 네이티브 기술의 발전으로 많은 내부 SaaS와 플랫폼이 이제 K8s 클러스터에 배포됩니다. 이 시나리오는 통합 트래픽 게이트웨이 또는 API 게이트웨이를 통해 외부 호출 요청의 통합 트래픽 제어와 같은 새로운 요구 사항을 제기합니다.

동시에, 일부 내부 비즈니스 시스템은 BlueKing 플랫폼의 컨테이너 관리 또는 모니터링과 같은 인프라 기능을 사용합니다. 이들도 모든 호출 트래픽을 관리하기 위해 통합 서비스 게이트웨이가 필요합니다.

내부 비즈니스 요구 사항의 발전에 따라 BlueKing의 API 게이트웨이는 점점 더 다양한 시나리오를 지원해야 합니다.

BlueKing API 게이트웨이 1.0

BlueKing API 게이트웨이 1.0은 플랫폼의 호출자(다양한 SaaS 및 프로세스 엔진 포함)가 API 게이트웨이를 직접 호출하여 게이트웨이를 통해 프로토콜 변환 및 권한 검증을 완료할 수 있도록 하는 것을 목표로 했습니다.

아키텍처도 상대적으로 간단했으며, 서버 측과 관리 측 두 부분으로 나뉘었습니다. 플랫폼은 관리 측에 접근하여 플랫폼의 API 리소스 주소 및 해당 권한을 구성하고, 최종적으로 API 게이트웨이에 서비스를 등록해야 했습니다.

몇 년이 지나면서 요청이 증가하고 시나리오가 복잡해짐에 따라 BlueKing API 게이트웨이 1.0의 단점이 점점 드러나기 시작했습니다. 예를 들어:

• 프레임워크 성능 저하: Django 프레임워크를 구현에 선택했습니다. 높은 동시성 시나리오에서의 성능이 평균적이며, 대량의 요청을 처리할 때 성능이 저하됩니다.

• 라우팅 구현 성능 평균: API 라우팅에 사용된 알고리즘의 성능이 낮아, 라우트 매칭 및 전달 속도에 영향을 미칩니다.

• 데이터베이스 부하: 모든 라우팅 정책이 MySQL에 저장되어 있습니다. 규칙이 많을 때 많은 검색 요청이 발생하여 데이터베이스에 큰 부하가 걸립니다.

• 높은 네트워크 비용: Redis가 다양한 시나리오에서 많이 사용되어 네트워크 오버헤드 비용이 너무 높습니다.

BlueKing API 게이트웨이 2.0

위의 문제를 해결하기 위해 BlueKing은 1.0 버전을 기반으로 반복하여 2.0 버전을 설계하고 구현했습니다. 이전 버전과 비교하여 2.0 버전의 가장 큰 변화는 Golang으로 게이트웨이 프레임워크와 전달 계층을 재구현한 것입니다. Golang은 Python보다 대규모 동시 요청 처리에 더 많은 장점이 있기 때문입니다.

다른 최적화 변경 사항도 이루어졌습니다. 예를 들어, 더 효율적인 라우팅 구현이 메모리에서 유지되었고, 중간 계층에 메모리 기반 캐시가 도입되어 Redis에 대한 의존도를 줄였습니다. 새로운 아키텍처는 또한 여러 버전과 환경의 게이트웨이에 대한 생명주기 관리를 추가하고, 개발자가 플러그인을 통해 게이트웨이 기능을 확장할 수 있도록 확장 플러그인 메커니즘을 도입했습니다.

전반적으로, BlueKing API 게이트웨이 2.0은 성능 문제와 1.0 버전에서 직면한 대부분의 문제를 해결했습니다. 그러나 시간이 지나면서 새로운 문제가 점점 드러나기 시작했습니다.

• 불충분한 격리: 실제 물리적 격리를 달성할 수 없음; 릴리스 프로세스가 장기 연결을 끊게 함

• 단일 프로토콜 지원: HTTP만 지원하며, 실제 시나리오에서 비 HTTP 프로토콜에 대한 요구가 증가함

• 동적 라우팅 규칙 미지원: 조건에 따라 매칭되는 동적 라우팅 규칙을 지원하지 않음; 카나리 릴리스 시나리오에 충분히 친절하지 않음; 시나리오 기반 조합 및 캡슐화 불가능

• 서비스 발견 기능 부족: 자동 서비스 발견 기능이 부족하여 마이크로서비스 아키텍처에 불친절함

BlueKing API 게이트웨이 기술 선택에서 APISIX가 두각을 나타냄

회사 내에는 API 게이트웨이를 사용해야 하는 많은 제품 시스템이 있습니다. 게이트웨이에 대한 다양한 요구 사항을 동일한 게이트웨이 세트에 통합하는 것은 매우 어렵습니다.

따라서, 우리는 분산 게이트웨이를 설계하는 아이디어를 갖게 되었습니다. 즉, 큰 게이트웨이를 여러 마이크로 게이트웨이로 분할하여, 다른 시스템의 게이트웨이 요구 사항의 차이를 균형 있게 조정하는 것입니다." Zhu는 말했습니다.

분산 게이트웨이 아키텍처의 구성 요소는 주로 두 가지 범주로 나뉩니다: 관리 측과 마이크로 게이트웨이 인스턴스.

관리 측은 각 마이크로 게이트웨이를 통합 관리 및 제어하며, 각 게이트웨이의 관리자가 게이트웨이를 구성하고 관리합니다. 마이크로 게이트웨이 인스턴스는 독립적으로 배포된 개별 게이트웨이 서비스로, 각 특정 서비스 그룹의 접근 트래픽을 담당하고 관리 측의 설정에 따라 관련 접근 제어를 수행합니다. 모든 마이크로 게이트웨이 인스턴스는 동일한 관리 측에 의해 제어됩니다.

"마이크로 게이트웨이의 기술 선택에 있어, 우리는 시장에서 인기 있는 여러 오픈소스 게이트웨이를 참고했습니다. 예를 들어 Kong과 Tyk 등이 있습니다. 인기도, 기술 스택, 프로토콜 지원 등을 비교한 후, 우리는 최종적으로 APISIX를 마이크로 게이트웨이의 가장 중요한 백엔드 기술로 선택했습니다." Zhu는 말했습니다.

Zhu는 BlueKing이 APISIX를 선택한 이유는 NGINX + Lua 기반으로 구현되었기 때문에 Golang 기반 게이트웨이에 비해 전반적인 성능이 우수하기 때문이라고 말했습니다. 또한, APISIX는 확장성이 뛰어나며, 다중 프로그래밍 언어 플러그인을 통해 기능 확장을 지원합니다. 많은 전형적인 사용 사례가 있었습니다.

또한, 뛰어난 호환성 덕분에 APISIX는 BlueKing의 요구에 맞게 사용자 정의할 수 있습니다. 예를 들어, APISIX를 기반으로 BlueKing은 내부 요구 사항에 따라 APISIX의 제어 면을 사용자 정의했습니다.

APISIX 기반 BlueKing API 게이트웨이 3.0

클라우드 네이티브 환경에서 K8s는 가장 중요한 기본 구성 요소로 주목받고 있습니다. 전체 마이크로 게이트웨이가 클라우드 네이티브 환경을 위해 설계되었기 때문에, 3.0 버전은 K8s를 기반으로 새로운 아키텍처 설계를 갖추고 있습니다.

핵심 부분은 K8s의 CRD 사용자 정의 리소스를 사용하여 API 게이트웨이의 전체 운영 및 확장을 실현하는 것입니다.

위 그림과 같이, 게이트웨이는 BkGatewayStage(게이트웨이 환경), BkGatewayService(백엔드 서비스) 등과 같은 K8s CRD 리소스 세트를 도입했습니다. 이러한 CRD를 통해 BlueKing은 각 마이크로 게이트웨이 인스턴스의 구체적인 동작을 제어할 수 있습니다.

그림의 여러 "Operators"는 이 아키텍처의 핵심 부분입니다. 위쪽은 Plugin Operators 서비스로, 일련의 플러그인 연산자를 포함합니다. 예를 들어, 서비스 발견을 담당하는 Operator는 서비스 발견 센터에 등록된 백엔드 서비스의 주소를 K8s 클러스터에 기록합니다.

중앙의 핵심 Operator는 모든 게이트웨이 관련 CRD 리소스를 모니터링합니다. 리소스 조정자는 게이트웨이 구성을 APISIX 마이크로 게이트웨이 인스턴스가 이해할 수 있는 형식으로 변환하여 마이크로 게이트웨이의 전 생애 주기 관리를 실현합니다.

이 마이크로 게이트웨이 세트는 두 가지 배포 유형으로 나뉩니다:

• 공유 게이트웨이: 기본 유형으로, 플랫폼에 배포되며 API 접근 주소는 플랫폼에서 통합 생성 및 관리됩니다.

• 전용 게이트웨이: 사용자가 "마이크로 게이트웨이" 인스턴스를 배포하고, 플랫폼에 접근한 후 "전용 게이트웨이"가 됩니다. API 접근 주소는 수동으로 관리되며, 트래�크는 "전용 게이트웨이"에서 백엔드 서비스로 직접 흐릅니다.

통합 관리 측은 하나만 있으며, 다중 환경 관리 및 접근 제어와 같은 기능은 모든 게이트웨이에 공유됩니다. 그러나 관리하는 다양한 유형의 마이크로 게이트웨이 인스턴스 간에는 지원되는 기능 세트가 서로 다릅니다.

공유 게이트웨이 인스턴스를 예로 들면, 지원하는 기능 세트는 상대적으로 기본적이며, 주로 통합 로그인 인증, 속도 제한, 다중 프로토콜 지원 등이 포함됩니다. 그러나 독립적인 전용 게이트웨이 인스턴스는 고유한 개인화 기능을 갖추고 있습니다. 전용 게이트웨이와 비즈니스가 동일한 클러스터에 속하기 때문에, 동적 라우팅, 사용자 정의 서비스 발견 등을 빠르게 실현할 수 있으며, APISIX의 강력한 확장성을 활용하여 더 많은 기능을 사용자 정의할 수 있습니다.

위의 아키텍처와 모드를 기반으로, BlueKing API 게이트웨이 3.0은 APISIX의 지원으로 더 풍부한 기능을 제공합니다. 예를 들어, 리소스 관리, 버전 릴리스, 자동 문서화, SDK, 권한 관리, 관찰 가능성, 모니터링 및 경고, 보안 보호 등이 있습니다.

APISIX를 사용한 BlueKing 게이트웨이 3.0의 실제 시나리오

Tencent 내부에는 서비스 발견, 통합 인증, 동적 라우팅, 클라이언트 라이선스 관리와 같은 네 가지 전형적인 실제 시나리오가 있습니다.

서비스 발견

서비스 발견은 마이크로서비스 아키텍처에서 필요한 기본 기능입니다. 내부적으로는 사용자 정의 리소스 CRD를 통해 구현할 수 있습니다. 유효한 서비스 발견 YAML 정의는 아래 그림의 오른쪽 코드와 같습니다.

위의 CRD 리소스가 K8s 클러스터에 기록되면, 서비스 발견 관련 컨트롤러의 관련 작업이 트리거됩니다. 이후, 조정자는 해당 서비스 발견 구성을 캡처하고 서비스 발견과 관련된 프로그램 객체를 생성합니다.

그런 다음 조정자는 Watcher 및 Lister와 같은 내장 서비스 발견 인터페이스를 통해 서비스 발견 센터의 관련 주소 정보를 읽고, 얻은 주소를 CRD 리소스 BkGatewayEndpoints를 통해 K8s 클러스터에 다시 기록합니다.

오른쪽의 핵심 Operator가 이러한 엔드포인트를 APISIX에 해당하는 업스트림에 동기화하면, 완전한 서비스 발견 프로세스가 완료됩니다.

개발을 용이하게 하기 위해, BlueKing은 일반적인 서비스 발견 프레임워크를 구현하여 통합 개발 인터페이스와 규정을 제공하며, 이를 통해 다른 유형의 서비스 발견 시나리오를 저비용으로 지원할 수 있습니다.

통합 인증

통합 인증 부분은 상대적으로 간단합니다. 일상적인 실무에서, 브라우저, 플랫폼, 개별 사용자로부터의 요청이 있습니다. APISIX를 기반으로, BlueKing은 BK-Auth라는 인증 플러그인을 사용자 정의하여 통합 인증을 실현했습니다.

구체적인 구현 프로세스는 위 그림과 같습니다. 요청 후, 플러그인은 헤더에서 관련 자격 증명 정보를 읽고, BK-Auth 인증 서비스를 호출하여 자격 증명을 검증하고 해당 SaaS 정보를 읽습니다. 그런 다음 플러그인은 백엔드와 약속된 개인 키를 사용하여 JWT 토큰을 발행하고 요청 헤더에 기록한 후, APISIX 변수에 기록합니다.

통합 인증 외에도, 내부 프로젝트에는 더 복잡한 인증 시나리오도 있습니다. 주요 기능은 SaaS가 플랫폼의 특정 리소스를 호출할 때 SaaS가 권한이 있는지 여부를 판단하는 것입니다. 통합 리소스 인증도 Golang을 통해 APISIX 플러그인으로 구현되었으며, 아래 그림과 같습니다.

클라이언트 요청은 먼저 인증 링크를 통해 SaaS 애플리케이션 정보를 가져올 수 있으며, ext-plugin을 통과할 때 RPC 기반 인증 플러그인과 상호 작용합니다. 이때, 인증 플러그인은 관리 측에서 전체 및 증분 메커니즘을 통해 동기화된 캐시에서 인증 관련 데이터를 직접 조회한 후 인증을 완료합니다.

동적 라우팅

전형적인 동적 라우팅 응용 시나리오는 BlueKing의 컨테이너 관리 플랫폼에서 나옵니다. BlueKing 컨테이너 플랫폼은 많은 K8s 클러스터를 관리하며, 일부는 서비스 클러스터이고 일부는 데이터 클러스터입니다.

사용자로서, 이러한 클러스터의 APIServers에 요청해야 하는 경우가 많습니다. 사용자 요청이 마이크로 게이트웨이에 들어가면, 게이트웨이는 요청 경로를 기반으로 어떤 클러스터의 APIServer로 전달할지 결정합니다.

요청이 들어오면, 동적 라우팅 플러그인은 먼저 클러스터의 ID 정보를 추출한 후 라우트를 재작성하고, 클러스터가 직접 연결되었는지 여부를 판단합니다.

직접 연결되지 않은 클러스터의 경우, 먼저 BCS 클러스터 관리자 업스트림을 생성한 후 BCS Agent와 상호 작용하여 최종적으로 클러스터의 APIServer에 요청을 전달합니다.

직접 연결된 클러스터의 경우, 위의 통합 인증 플러그인과 유사한 프로세스를 거치며, 플러그인은 주기적으로 클러스터와 관련된 기본 정보를 동기화합니다. 클러스터 정보를 찾은 후, 관련 업스트림을 생성하고 APISIX 플러그인을 통해 연결 로직을 재정의한 후, 요청을 클러스터 APIServer로 전송합니다.

클라이언트 인증서 관리

BlueKing의 실제 시나리오에서, 게이트웨이에 리소스를 등록할 때 더 복잡한 클라이언트 인증서 검증 모드를 사용하는 시스템 클래스가 있습니다. 따라서 사용자가 해당 리소스를 요청하려면 유효한 클라이언트 인증서를 제공해야 합니다.

구체적인 구현은 위 그림과 같습니다. 게이트웨이 관리자는 관리 측에서 다른 환경에 사용되는 클라이언트 인증서를 구성해야 합니다. 구성 후, 인증서는 해당 마이크로 게이트웨이가 위치한 K8s 클러스터에 게시됩니다.

이 프로세스는 K8s의 일부 CRD 리소스와 공식 Secret 리소스를 사용하며, 도메인 이름에 따라 해당 인증서를 찾는 등 핵심 Operator 서비스에 의해 지속적으로 조정됩니다. 유효한 클라이언트 인증서 구성은 최종적으로 APISIX Service의 관련 구성에 반영됩니다. (위 그림의 오른쪽 상단 빨간 상자 참조)

요약

Apache APISIX는 모든 API와 마이크로서비스를 위한 오픈소스, 동적, 확장 가능하며 고성능의 클라우드 네이티브 API 게이트웨이입니다. API7.ai가 Apache Software Foundation에 기부한 APISIX는 이제 최상위 오픈소스 Apache 프로젝트로 성장했습니다.

마이크로서비스 아키텍처와 내부 비즈니스 프로젝트의 발전에 따라, 이전의 API 게이트웨이는 더 이상 요구 사항을 충족할 수 없게 되었습니다. Tencent BlueKing은 문제를 해결할 뿐만 아니라, APISIX를 활용하여 더 풍부한 기능을 제공했습니다.