vivo는 어떻게 APISIX와 통합되나요?

November 25, 2022

Case Study

개요

2021년 5월부터 vivo는 Apache APISIX를 API 게이트웨이로 도입했습니다. vivo에서 1년 이상의 실습을 거친 후, APISIX는 많은 기술적 및 비즈니스적 문제점을 해결했으며 대규모로 사용되고 있습니다.

APISIX 사용 전의 문제점

  • 비즈니스 시나리오 및 시스템 유지 관리의 복잡성

    비즈니스의 급속한 성장으로 인해 다양한 시나리오와 이를 지원하는 시스템이 존재하며, vivo는 이를 통합적으로 관리할 방법이 필요했습니다.

  • 데이터 플레인과 컨트롤 플레인 간의 상호작용

    vivo와 같은 중대형 기업의 경우, 데이터 플레인에서 발생하는 작은 문제가 컨트롤 플레인에 영향을 미칠 수 있다는 것은 예상치 못한 일이었습니다.

  • 다차원 리소스 지원 부족

    다양한 프로젝트로 인해 다양한 도메인 이름과 URL이 존재하며, 비즈니스 부서는 다양한 리소스 차원에 따라 검색해야 합니다.

  • 문제의 영향 통제 불가

    vivo의 프로젝트는 복잡하며, 발생하는 문제의 영향은 통제할 수 없습니다. 일부 복잡한 플러그인의 사용은 이를 더욱 악화시킵니다.

APISIX로 NGINX를 대체함으로써, vivo는 결국 아래와 같은 성과를 달성했습니다.

APISIX 사용 후의 성과

  • 고가용성

    APISIX가 vivo에서 출시된 이후로 큰 장애가 발생하지 않았으며, 시스템 가용성은 **99.99%**를 초과합니다.

  • 고성능

    대규모 온라인 트래픽을 처리하고 많은 서비스를 제공하며, 현재 온라인 전달 트래픽은 초당 백만 QPS에 근접합니다.

  • 풍부한 기능

    APISIX의 풍부한 기능 덕분에, APISIX는 거의 모든 일반적인 NGINX 프록시 시나리오를 커버할 수 있습니다. vivo 프로젝트의 약 50%가 NGINX에서 APISIX 클러스터로 마이그레이션되었습니다.

  • 클라우드 네이티브 구축 및 개발 지원

    컨테이너화를 지원하는 K8s 베어메탈은 10,000 규모에 도달했습니다. 약 40%의 프로젝트가 베어메탈 및 가상 머신에서 K8s 컨테이너 플랫폼으로 마이그레이션되었으며, vivo의 컨테이너화 진행을 지원하고 촉진했습니다.

APISIX 기반의 vivo 시스템 설계

다음으로, APISIX를 도입한 후의 vivo 시스템 설계를 살펴보겠습니다.

APISIX 기반의 맞춤형 아키텍처 표시

vivo's API gateway architecture with APISIX

위의 다이어그램에서 분석할 수 있듯이, vivo는 다음과 같은 작업을 완료했습니다.

  • 4계층 및 7계층 트래픽 게이트웨이 구축 완료, APISIX가 이를 지원
  • 베어메탈, 가상 머신, 컨테이너의 트래픽 접근 및 혼합 배포 실현
  • APISIX 클러스터 관리 구현
  • 내부 DevOps 플랫폼 및 비즈니스 배포 서비스 연결, 빠르고 자동으로 트래� 접근 가능
  • 모니터링 구축 개선

구성 관리 및 출시 개선

비즈니스 부서의 실제 요구를 더 잘 충족시키기 위해, vivo는 APISIX에 대해 일련의 조정을 수행했습니다. 아래는 컨트롤 플레인 변경, 클러스터 분리 관리, 데이터 전달 등과 같은 조정 사항입니다.

컨트롤 플레인 변경

전체 프로세스는 다음과 같습니다.

A6 변경 플랫폼에서 데이터가 구성된 후, 정보는 RPC 알림을 통해 ManagerAPI로 전달됩니다. ManagerAPI는 오픈소스 APISIX Dashboard를 기반으로 vivo가 구축했습니다.

그런 다음 트래�은 apisix-agent로 전송됩니다. APISIX는 권한 있는 프로세스를 통해 정기적으로 apisix-agent를 폴링하여 변경 작업을 일괄적으로 가져옵니다. 다음으로, 권한 있는 프로세스는 공유 큐를 통해 worker에게 알려 메모리 변경을 실현합니다.

동시에, APISIX는 작업 결과를 apisix-agent에 알리고 ManagerAPI로 전달합니다. 또한, A6 변경 플랫폼은 ManagerAPI를 폴링하여 작업 결과를 얻을 수 있습니다.

vivo's management and publishing mode

etcd는 APISIX의 하이라이트로, 컨트롤 플레인과 데이터 플레인의 독립적인 운영을 가능하게 합니다. 아키텍처의 독특성을 고려하여, vivo는 위의 프로세스에서 etcd를 폐기했습니다. 그 이유는 다음과 같습니다.

vivo의 프로젝트 다양성으로 인해 다양한 도메인 이름과 URL이 존재합니다. 또한, 비즈니스 부서는 다양한 차원에 따라 쿼리해야 합니다. APISIX는 etcd뿐만 아니라 다양한 데이터베이스와도 호환되므로, vivo는 MongoDB와 같은 데이터베이스를 APISIX와 함께 사용할 수 있었습니다.

또한, vivo는 Apache APISIX와 호환되도록 아래와 같은 기여를 했습니다.

  • 에이전트 컴포넌트 개발

    2021년 5월부터 vivo는 Apache APISIX를 도입했습니다. 기술적 배경과 맥락을 고려할 때, vivo는 OpenResty와 Lua에 대한 경험이 없어 APISIX를 도입할 수 없을 것이라고 생각했습니다. 또한, 로그 수집 및 모니터링 처리와 같은 비전달 작업이 많아 데이터 플레인의 관리 복잡성이 증가할 수 있었습니다. 결과적으로, vivo는 개발 복잡성을 줄이기 위해 에이전트 컴포넌트를 개발했습니다.

  • 디스크에 데이터 기록

    시스템을 조정 가능하게 만들고 데이터 플레인이 독립적으로 실행되도록 하여 컨트롤 플레인에 대한 의존성을 줄이기 위해, vivo는 구성 파일을 디스크에 기록했습니다. APISIX가 시작될 때, 구성 센터에서 완전히 가져오는 것을 지원하며, 로컬 디스크의 파일 디렉토리에서 직접 구성 리소스를 가져오는 것도 지원합니다. 이 방식은 데이터의 독립성과 시스템의 견고성을 크게 향상시킵니다. 또한, 디스크에 배치된 구성된 경로 및 업스트림 정보를 이해하는 것이 매우 직관적이며, 문제 해결에 도움이 됩니다.

  • 변경 작업 결과 콜백

    대기업인 vivo는 라우터 및 업스트림과 같은 리소스에 대한 변경이 효과적이고 성공적으로 이루어질 수 있도록 보장해야 하며, 이러한 변경이 실패할 경우 시스템이 오류를 보고할 수 있어야 합니다. 이러한 ACK(승인 코드) 로직은 머신의 NGINX 작업자가 콜백할 수 있도록 보장합니다. 콜백 작업이 성공하면 APISIX의 모든 작업자가 관련 메모리에 리소스 변경 사항을 업데이트합니다.

클러스터 분리 관리

Cluster Split Management

APISIX의 오픈소스 버전은 etcd를 제공하여 모든 사람이 공유할 수 있도록 합니다. 그러나 회사의 프로젝트는 복잡하며, 발생하는 문제는 통제할 수 없습니다. 또한, 복잡한 플러그인을 사용하는 것은 불가피하며, 이는 시스템 성능에 영향을 미칩니다.

따라서, 클러스터 분리 관리를 통해 APISIX에서 클러스터 구성의 격리를 실현하여 다음을 수행할 수 있습니다.

  • 장애 도메인을 통제하고 프로젝트 복잡성을 효과적으로 지원하며 다른 프로젝트에 영향을 미치지 않음
  • 컨테이너 노드가 자주 변경될 때 APISIX 비전달 계층으로 인한 부하를 효과적으로 줄임
  • 헬스 체크로 인한 부하 영향을 줄임

HTTPS가 처리할 수 있는 QPS 증가

중국 산업정보화부의 관련 요구 사항에 따라, 외부 네트워크 트래픽은 HTTPS 프로토콜을 통해야 합니다. TLS 기반의 HTTP 암호화 프로토콜인 HTTPS는 암호화 및 복호화 과정에서 CPU에 큰 부담을 줍니다.

라우팅 및 기타 구성이 동일할 때, HTTPS가 처리할 수 있는 트래픽은 HTTP의 약 1/8 - 1/10입니다.

Intel® QAT(QuickAssist Technology) 가속기 카드를 패치한 후, vivo는 복호화 처리를 QAT 가속기 카드에 위임하여 CPU를 해방시켜 단일 머신에서 HTTPS가 처리할 수 있는 QPS를 증가시켰습니다. 아래 그림에서 볼 수 있듯이, 단일 머신의 HTTPS 처리 용량은 약 두 배로 증가했습니다.

data showing vivo's improvment on carrying traffic

vivo가 비즈니스와 APISIX를 어떻게 결합하는가

컨테이너화 개발 지원

컨테이너화 개발을 지원하기 위해, vivo는 K8s ingress 컨트롤러를 자체 개발했습니다. 아래는 그 기능 중 일부입니다.

  1. vivo의 수정된 비동기 푸시 구성 변경 메커니즘에 적응

  2. 다중 K8s 클러스터 이벤트 처리 알림을 APISIX에 전달

  3. 다음과 같은 복잡한 프로젝트 시나리오 처리:

  • 하나의 서버에 여러 포트

  • Dubbo 및 gRPC와 같은 다른 RPC 프레임워크 서버가 K8s에 연결될 때, 프로젝트 구성 특성에 따라 APISIX 또는 다른 프레임워크에 포트 정보를 알리는 통합 처리 로직 필요

  1. 회사 내부 DevOps 및 기타 자동화 시나리오의 특수 요구에 적응, 빠른 배포 및 트래픽 활성화 용이

NGINX에서 APISIX로 프로젝트 마이그레이션 지원

vivo의 프로젝트는 기존 NGINX 클러스터에 배포되어 오랫동안 안정적으로 운영되었습니다. 그러나 이는 프로젝트에 비즈니스가 아닌 작업 부하와 불안정성을 가져왔습니다. 결과적으로, 마이그레이션을 수행하는 것은 어려웠습니다. 그렇다면 프로젝트를 APISIX로 마이그레이션하는 것을 어떻게 촉진할까요?

  • 먼저, 협력 부서의 프로젝트를 찾아 비즈니스 부서를 잘 지원하여 벤치마크를 설정하고 기술 지도 및 교육 제공

  • 비즈니스 접근 및 비즈니스 부서의 다차원 관리를 용이하게 하는 사용하기 쉬운 컨트롤 플레인 시스템 구축

  • NGINX 구성에서 APISIX 구성으로의 자동 변환 기능 및 기본 구성 제공

APISIX 업그레이드 및 오픈소스 버전 지원

APISIX 2.4 버전을 기반으로, vivo는 일부 조정을 하고 새로운 버전을 출시했으며, 올해 2분기에 더 새로운 버전으로 업그레이드했습니다.

한편으로, APISIX의 모듈식 아키텍처 덕분에 vivo의 수정된 Lua 코드를 APISIX의 상위 버전 브랜치에 통합하는 것이 상대적으로 쉬웠습니다. 다른 한편으로, vivo는 OpenResty 섹션도 계속 업그레이드하며, 약 1년에 한 번씩 버전을 업그레이드합니다. vivo는 많은 PATCH와 QAT와 같은 유용한 기능을 사용하기 때문에, 이 컴포넌트를 업그레이드하는 것은 어렵고 힘든 작업입니다.

NGINX 커뮤니티 기능의 무료 버전은 업데이트가 느리고 활성화되지 않았습니다. vivo는 APISIX와 공동으로 구축할지 고려 중입니다. 관련 시스템 테스트에 필요한 인력을 줄이기 위해, vivo는 시스템 통합 테스트를 위한 일반 테스트 자동화 프레임워크인 Robot Framework를 채택했습니다. 그들은 단위 테스트 커버리지 및 TDD(테스트 주도 개발) 개발 모델을 위한 관련 컴포넌트를 촉진하고 있습니다.

vivo의 미래 계획

내년에, vivo는 APISIX를 트래픽 게이트웨이에서 API 게이트웨이로 확장할 계획이며, 속도 제한, 인증, 서킷 브레이커 등의 장점을 활용할 것입니다. APISIX와 DPDK-NGINX를 결합하는 것을 고려하며, 기술 인력을 양성하고 커뮤니티 구축에 참여할 것입니다. 또한, 기본 기술을 강화하여 트래픽 및 서비스 거버넌스를 구축할 좋은 기반을 마련할 것입니다.

Apache APISIX에 대해 더 알아보세요.

https://api7.ai/contact에서 저희에게 연락할 수 있습니다.

Tags:
APISIX Basics
Best API Gateway
Consumer