iQIYI, Apache APISIX로 API Gateway 혁신을 열다

개요

도전 과제

1. 대량의 트래픽으로 인해 매일 수많은 CPU IDLE 과소 경고가 발생합니다.
2. 시스템 아키텍처에 너무 많은 컴포넌트가 의존하고 있습니다.
3. 운영 및 유지보수 비용이 너무 높습니다.

목표

1. iQIYI의 요구 사항에 맞는 우수한 API 게이트웨이를 선택합니다.
2. 마이그레이션 비용을 최소화합니다.
3. 활발한 커뮤니티와 건강한 생태계를 가진 API 게이트웨이를 찾습니다.
4. 클라우드 네이티브 트렌드에 맞는 새로운 API 게이트웨이를 구축합니다.

결과

1. 성능이 이전보다 10배 향상되어 매일 수백만 QPS를 처리합니다.
2. 9,000개 이상의 API 온라인 비즈니스 프로젝트를 쉽게 지원합니다.
3. 전국적으로 다중 사이트 및 다중 수준의 데이터 재해 복구를 성공적으로 구현했습니다.

iQIYI의 뒷이야기

iQIYI의 선임 R&D 엔지니어인 Cong He는 최근 상하이에서 열린 Apache APISIX Meetup에서 강연을 공유했습니다. 그는 IIG 인프라 부서의 컴퓨팅 클라우드 팀에서 근무하며 iQIYI의 게이트웨이 개발 및 운영 작업을 담당하고 있습니다. 그의 강연과 iQIYI의 API 게이트웨이 이야기를 통해 Apache APISIX에 대해 더 잘 이해해 보겠습니다.

2010년 4월 22일에 중국 최대 온라인 검색 엔진인 Baidu에 의해 설립된 iQIYI는 현재 전 세계에서 가장 큰 온라인 비디오 사이트 중 하나로, 매월 약 60억 시간의 서비스 이용 시간과 5억 명 이상의 월간 활성 사용자를 보유하고 있습니다.

iQIYI는 이전에 Kong을 기반으로 자체 개발한 API 게이트웨이인 Skywalker를 사용했습니다. Skywalker는 현재 대량의 트래픽을 처리해야 하며, 게이트웨이 서비스의 일일 피크는 백만 QPS와 수천 개의 API 경로에 이를 수 있습니다. 그러나 이 제품의 단점이 점차 드러나기 시작했습니다.

1. 게이트웨이 성능이 iQIYI의 요구 사항을 더 이상 충족하지 못하며, 대량의 트래픽으로 인해 매일 수많은 CPU IDLE 과소 경고가 발생합니다.
2. 시스템 아키텍처에 너무 많은 컴포넌트가 의존하고 있습니다.
3. 운영 및 유지보수 비용이 너무 높습니다.

올해 이 프로젝트를 인수한 Cong은 위의 문제와 어려움을 해결하기 위해 유사한 게이트웨이 제품을 조사하기 시작했고, 마침내 Apache APISIX를 발견했습니다.

Apache APISIX가 Kong을 능가하는 방법

Apache APISIX를 선택하기 전에 iQIYI는 이미 Kong을 사용하기 시작했지만 나중에 이를 포기했습니다.

Kong을 포기한 이유?

Kong을 실제로 사용해 본 후, Cong은 그의 팀이 Kong을 포기한 이유를 설명했습니다. 아래는 Kong의 몇 가지 핵심 단점입니다.

1. Kong의 경로는 순회 쿼리를 사용하며, 속도가 빠르지 않습니다.
2. Kong의 Postgres 데이터베이스는 배포가 비대해지고, 동기화 효율이 낮으며, 가용성이 낮습니다.
3. 코드의 결합도가 높습니다.

APISIX를 선택한 이유?

"조사 중에 Apache APISIX와 Kong의 성능을 비교했을 때, 놀랍게도 Apache APISIX가 성능 최적화 측면에서 Kong보다 10배 더 우수하다는 것을 발견했습니다. 또한 Apache APISIX를 다른 주요 게이트웨이 제품과 비교했을 때, Apache APISIX의 응답 지연 시간이 항상 다른 제품보다 50% 이상 낮았습니다. 더욱이, Apache APISIX는 CPU 사용률이 70% 이상에 도달해도 안정적으로 실행될 수 있습니다. APISIX는 정말 놀랍습니다!" Cong은 말했습니다.

Apache APISIX와 Kong은 기술적으로 OpenResty를 기반으로 개발되었으며, 이는 상대적으로 낮은 마이그레이션 비용을 가져옵니다. 또한, Apache APISIX는 클라우드 컴퓨팅 플랫폼을 포함한 다양한 환경에서 쉽게 배포할 수 있는 우수한 적응력을 가지고 있습니다.

"동시에, Apache APISIX가 매우 활발한 오픈소스 프로젝트이며 문제를 매우 빠르게 해결한다는 것도 발견했습니다. 그 클라우드 네이티브 프레임워크는 우리 회사의 후속 계획과도 잘 맞습니다. 따라서 우리는 API 게이트웨이로 Apache APISIX를 선택했습니다."

APISIX 사용 후 iQIYI의 API 게이트웨이 아키텍처 혁신

훌륭한 API 게이트웨이를 선택한 후, iQIYI는 새로운 API 게이트웨이 아키텍처를 구축하기 시작했습니다. 아래는 도메인 이름, 게이트웨이, 서비스 인스턴스 및 모니터링 알람을 포함한 새로운 아키텍처입니다.

DPVS는 iQIYI가 LVS를 기반으로 개발한 오픈소스 프로젝트입니다. Hubble 모니터링 알람도 오픈소스 프로젝트를 기반으로 깊이 있는 맞춤 개발을 거쳤으며, Consul의 성능과 고가용성에 대한 몇 가지 최적화가 이루어졌습니다.

성과 1: 클러스터 및 서비스 관리를 위한 데이터 및 제어 플레인 개선

데이터 플레인은 주로 프론트엔드 사용자를 대상으로 하며, LB에서 게이트웨이까지의 전체 아키텍처는 재해 복구를 위해 다중 사이트 및 다중 링크 배포를 가지고 있어 사용자가 가장 가까운 데이터 센터에 접근할 수 있습니다.

제어 플레인에는 다중 클러스터 및 서비스를 관리하는 마이크로서비스 플랫폼이 존재합니다. 마이크로서비스 플랫폼은 사용자가 티켓을 제출하지 않고도 원스톱 서비스를 경험할 수 있게 하여 상당한 시간을 절약합니다. 백엔드에서는 게이트웨이 컨트롤러가 주로 모든 API의 구성(예: API 생성 및 플러그인)을 제어하며, 서비스 컨트롤러는 등록, 취소 및 상태 확인을 처리합니다.

성과 2: 보안 제어, 속도 제한 및 모니터링과 같은 추가 기능 구현

iQIYI는 Apache APISIX로 조정한 후 API 아키텍처에 속도 제한, 인증, 알람, 모니터링 등과 같은 기본 기능을 구현했습니다.

첫 번째 부분은 HTTPS에 관한 것입니다. 보안 제어를 위해 iQIYI는 게이트웨이 서버에 인증서나 키를 저장하지 않고 전용 원격 서버에 저장합니다. 그러나 Kong을 사용할 때는 이를 실현하기 어려웠고, 대신 iQIYI는 접두사 NGINX를 사용하여 HTTPS 오프로드를 수행했습니다. Apache APISIX로 마이그레이션한 후, iQIYI는 이 기능을 Apache APISIX에서 성공적으로 구현하여 링크를 통해 한 단계 더 전송하는 것을 절약했습니다.

속도 제한 측면에서는 기본 속도 제한 기능 외에도 정밀 속도 제한 및 사용자 단위 속도 제한도 구현했습니다. 인증을 위해 패스포트 인증을 위한 전용 서비스를 제공했습니다. 또한, iQIYI는 회사의 WAF 보안 클라우드에 접근하여 불법 산업을 걸러낼 수 있습니다.

모니터링 알람 기능은 Apache APISIX의 내장 플러그인인 Prometheus를 사용하여 구현되었으며, 지표 데이터는 회사의 모니터링 시스템으로 직접 전송됩니다. Apache APISIX는 또한 iQIYI에 로깅 및 추적 분석 서비스를 지원합니다.

성과 3: 동적 서비스 발견 업데이트 프로세스 구축

위에서 언급한 서비스 발견은 주로 서비스 센터를 통해 Consul 클러스터에 서비스를 등록한 다음 DNS 서비스 발견을 사용하여 동적으로 업데이트합니다. 그래프의 QAE는 회사 내부에서 사용하는 마이크로서비스 플랫폼입니다. 인스턴스 업데이트 프로세스를 간단히 설명하기 위해 예를 들어 보겠습니다.

인스턴스를 업데이트할 때, 먼저 Consul에서 해당 노드를 로그아웃하고 API 게이트웨이 컨트롤러를 통해 게이트웨이에 DNS 캐시 업데이트 요청을 보냅니다. 캐시가 성공적으로 업데이트되면, 컨트롤러는 QAE 플랫폼에 요청을 보내 모든 관련 백엔드 애플리케이션 노드를 중지하여 오프라인 노드로 트래픽이 재전송되지 않도록 합니다.

성과 4: 방향성 경로 기능 개선

게이트웨이는 다중 사이트 배포를 가지고 있으며, 사전에 다중 사이트 백업 링크의 전체 세트를 구축했습니다. 또한, Cong은 사용자가 백엔드 서비스에 대해 다중 사이트 최근 접근 배포를 가지도록 권장합니다. 따라서 사용자는 Skywalker 게이트웨이 플랫폼에서 API 서비스를 생성할 수 있으며, 컨트롤러는 모든 DC 게이트웨이 클러스터에 API 경로를 배포합니다. 동시에, 서비스 도메인의 기본 CNAME은 통합 게이트웨이 도메인 이름으로 라우팅됩니다.

Apache APISIX는 최근 접근 다중 사이트 배포 및 재해 복구를 위한 장애 조치 기능을 직접 제공할 수 있으며, 사용자가 정의한 경로 해결을 지원합니다. 또한, 사용자는 장애 조치, 블루-그린 배포, 카나리 릴리스가 필요한 경우 UUID 도메인 이름을 통해 경로 해결 구성을 사용자 정의할 수 있습니다. 추가적으로, Apache APISIX는 백엔드 서비스 복구의 사용자 정의 스케줄링도 지원합니다.

성과 5: 다중 사이트 및 다중 수준 재해 복구 개선

대량의 트래픽, 수많은 클러스터 및 광범위한 클라이언트를 처리하기 위해 iQIYI는 운영 수준에서 최근 서비스 접근 및 재해 복구가 필요합니다.

다중 사이트 및 다중 링크 백업 외에도, iQIYI는 다중 수준 및 다중 노드 상황에 대한 문제도 고려해야 합니다. APISIX가 이를 도와줍니다. 클라이언트가 죽은 노드에 가까울수록 비즈니스 및 트래픽에 미치는 영향이 더 큽니다.

1. 가장 먼 백엔드 서비스 노드가 다운되면, iQIYI는 서비스 센터 및 게이트웨이 상태 확인 메커니즘을 통해 죽은 DC의 단일 노드 차단 또는 장애 조치를 달성할 수 있습니다. 따라서 영향은 특정 서비스로 제한되며 사용자에게 영향을 미치지 않습니다.
2. 게이트웨이가 다운되면, iQIYI는 L4 DPVS의 상태 확인 메커니즘을 사용하여 실패한 게이트웨이 노드를 차단할 수 있으며, 영향은 상대적으로 작아 사용자에게 영향을 미치지 않습니다.
3. 위의 회로 차단 조치로 죽은 노드를 복구할 수 없는 경우, iQIYI는 외부망에서 도메인 이름 단위의 다중 노드 가용성 일일 테스트를 통해 DNS에서 자동 장애 조치를 달성할 수 있습니다. 그러나 이 방법은 상대적으로 느리며 다른 많은 서비스에 영향을 미칠 수 있으며 사용자가 이를 인지할 수 있습니다.

iQIYI의 미래 계획

APISIX와의 통합에서 iQIYI는 비즈니스에 더 잘 맞도록 몇 가지 문제를 최적화하려고 합니다.

1. etcd, Prometheus 모니터, 로깅 서비스와 같은 일부 의존 컴포넌트의 가능한 병목 현상을 고려하여, iQIYI는 하이브리드 배포 방식을 사용할 계획입니다. 즉, 대형 클러스터 내부에서 정보를 공유하고 소형 클러스터를 독립적으로 유지합니다. 예를 들어, 중요한 서비스는 소형 클러스터로 배포됩니다.

2. 특히 DNS 서비스 발견에 대해 Prometheus 모니터링 지표에 대한 추가 감소 및 최적화가 이루어질 것입니다.

Cong은 말했습니다, "우리는 Apache APISIX가 미래의 개발 및 업데이트에서 더 많은 기능을 지원하고 우수한 성능 효율성과 안정성을 유지하기를 바랍니다."

APISIX 지원을 찾고 계신가요?

iQIYI처럼 자신 있게 개발을 가속화하고 싶으신가요? APISIX 지원을 극대화하려면 API7이 필요합니다. 우리는 귀하의 요구에 따라 APISIX 및 API 관리 솔루션에 대한 심층 지원을 제공합니다!

언제든지 연락주세요: https://api7.ai/contact.