Open-Source Project

Community-Driven

High Availability, Stability

Ultimate Performance,

Developer Friendly

Go for Apache APISIX

Looking for the best API Gateway?

Companies choose Apache APISIX as their API gateway after comparing it with Kong. Not only is Apache APISIX is faster, but the experience is also excellent.

Apache APISIX vs Kong:

## 배경

최근 몇 년 동안, 온라인 회의와 원격 근무의 발전과 함께 많은 유명한 온라인 회의 소프트웨어가 등장했습니다. 그 중 대표적인 Zoom은 재택 근무, 온라인 교육, 소셜 시나리오에서 인기 있는 회의 도구가 되었습니다. Zoom은 하루 3억 5천만 명의 회의 참가자와 약 47만 명의 유료 비즈니스 고객이 이 플랫폼을 사용하고 있습니다. 또한 최근 데이터에 따르면 회의 진행을 위해 사용된 시간은 연간 3조 3천억 분 이상에 달합니다.

그러나 다른 SaaS 및 인터넷 기업과 마찬가지로 Zoom도 비즈니스가 빠르게 확장되면서 기술적 도전에 직면했습니다.

- **많은 수의 마이크로서비스**: Zoom의 비즈니스와 팀의 빠른 성장으로 인해 100개 이상의 백엔드 서비스를 제공해야 합니다. 그러나 많은 수의 마이크로서비스를 효율적으로 관리하는 것은 어렵습니다.

- **다양한 배포 환경**: SaaS 기업은 종종 고객이 전용 클라우드, 프라이빗 클라우드, 멀티 클라우드에 배포해야 하는 시나리오를 마주합니다. Zoom의 비즈니스 서비스는 전 세계에 걸쳐 있기 때문에 많은 수의 하이브리드 클라우드 환경에서 기술적 도전이 있습니다.

- **복잡한 인프라**: 중대형 인터넷 기업은 일반적으로 API 게이트웨이, 설정 센터, 키 관리, 로그, 모니터링 알람, 데이터베이스 등을 담당하는 전용 인프라 팀을 보유하고 있습니다. Zoom의 R&D 팀이 전 세계에 분산되어 있기 때문에 이러한 복잡한 미들웨어와 인프라를 지속적 제공 파이프라인에 통합하는 것은 큰 도전입니다.

**위의 도전들은 단순한 가산 관계가 아니라 승산 관계입니다. 즉, 실제 상황은 훨씬 더 복잡합니다.** 그러나 Zoom이 이전에 사용했던 오픈소스 도구들은 더 이상 Zoom의 현재 요구 사항을 충족시키지 못합니다. 그래서 신뢰할 수 있는 지속적 제공 파이프라인이 중요한 이유입니다.

아래는 Zoom이 이전의 오픈소스 도구를 계속 사용하지 않은 이유에 대한 상세한 설명입니다.

| Helm/Kustomize  | Terraform/Pulumi  | KubeVela + Crossplane  |
| ------------ | ------------ | ------------ |
| Kubernetes 외의 시스템과 연결 불가능  | Kubernetes 및 미들웨어 계층에서 Terraform 사용이 어려움, 추가 Provider 개발 필요  | 너무 새로운 기술 스택으로 빠른 업데이트, 프로덕션 환경에서 채택하기에 안전하고 안정적이지 않음  |
| Git 하위 저장소 모드에서 플랫폼을 중앙에서 제어하기 어려움  | 또 다른 설정 관리 언어인 hcl을 배우는 비용 증가  | Kubevela의 Trait + Cuelang 템플릿 정의 및 프로그래밍 표현 능력이 Kubernetes 시스템 외부의 다양한 비-클라우드 네이티브 미들웨어 플랫폼을 충분히 커버하지 못함  |
| Helm Chart Template의 복잡한 로직으로 인해 유지보수 및 디버깅이 어려움  | Mono Repo 중앙 제어 모드는 대규모 팀에 적합하지 않음  | /  |
| 많은 환경에서 동적 매개변수를 관리할 수 있는 강력한 매개변수 시스템 부재  | /  | /  |

위의 오픈소스 도구의 한계로 인해 Zoom은 결국 지속적 제공 파이프라인을 구축하기 위한 몇 가지 주류 솔루션을 조사했습니다.

몇 차례의 비교와 검증을 거친 후, Zoom은 새로운 지속적 제공 파이프라인을 지원하기 위해 APISIX Ingress Controller를 최종적으로 선택했습니다.

## Apache APISIX Ingress Controller

### Apache APISIX Ingress Controller란?

[Apache APISIX Ingress Controller](https://github.com/apache/apisix-ingress-controller)는 Apache APISIX를 데이터 플레인으로 사용하여 트래픽을 처리하고 CRD(CustomResourceDefinition)를 활용하여 Kubernetes의 기능을 확장하는 클라우드 네이티브 인그레스 컨트롤러입니다. 이 컨트롤러는 Kubernetes API 서버와 상호 작용하고, 역할 기반 접근 제어(RBAC)를 적용하며, 변경 사항을 모니터링하고, Ingress 컨트롤러 내에서 객체 변환을 구현하고, 변경 사항을 비교한 후 Apache APISIX에 동기화합니다. 또한, APISIX Route, APISIX Upstream 및 Kubernetes의 기타 네이티브 인그레스와 같은 사용자 정의 리소스를 지원하여 Kubernetes에 배포된 서비스에 외부 트래픽이 접근하도록 제어할 수 있습니다.

아래는 [APISIX Ingress Controller의 타이밍 다이어그램](https://apisix.apache.org/docs/ingress-controller/design/#timing-diagram)입니다.

![APISIX Ingress의 타이밍 다이어그램](https://static.api7.ai/2022/10/27/635a5613af56a.jpeg)

## Zoom이 APISIX Ingress Controller를 선택한 이유는?

위의 배경을 바탕으로, Zoom이 어떤 종류의 지속적 제공 파이프라인을 구축하려고 하는지, 그리고 어떻게 APISIX Ingress를 채택하여 그 기반이 되는 지속적 제공 파이프라인을 구축했는지에 대한 질문이 생깁니다.

Zoom은 이전에 NGINX를 API 게이트웨이로 사용했습니다. 그러나 비즈니스의 급속한 발전과 마이크로서비스의 증가로 인해 현재의 NGINX 솔루션의 한계가 점점 더 명확해지고 있습니다.

다른 팀이 NGINX를 별도로 유지보수해야 하며, 수천 줄의 NGINX 설정 파일로 인해 유지보수가 어렵습니다. 또한, NGINX는 클라우드 서버에 많은 라인을 배포할 때 빠르게 확장할 수 없습니다. NGINX의 리로드 모드에 대해서는 [이 블로그](https://api7.ai/blog/how-nginx-reload-work)를 참조하십시오. Zoom의 비즈니스는 Ingress Controller로 진화하기 시작했습니다.

API 게이트웨이 팀은 몇 가지 오픈소스 솔루션을 조사했습니다. NGINX의 실제 비즈니스 설정을 시뮬레이션하고 이전하고, 성능과 플러그인 생태계 비교를 위한 많은 벤치마크 테스트를 거친 후, Zoom은 결국 Apache Software Foundation의 APISIX Ingress Controller 프로젝트를 선택하여 더 진보된 클라우드 네이티브 게이트웨이를 탐구했습니다.

Zoom은 비즈니스 시나리오를 고려하여 아래 두 부분에 더 중점을 두었으며, 이는 APISIX Ingress로 충족될 수 있습니다.

- **데이터 보안**: Zoom은 고객의 프라이버시와 서비스 보안을 중요하게 여기기 때문에, 온라인 회의실과 전화 통화에서 mTLS 인증 및 검증이 널리 사용됩니다. 그러나 많은 유사한 API 게이트웨이는 이러한 서비스를 엔터프라이즈 버전에서만 제공할 수 있는 반면, APISIX Ingress는 이 목표를 달성하는 데 큰 가능성과 편의성을 제공합니다.

- **서비스 안정성**: Zoom의 백엔드 서비스는 여러 가용 영역(Multi-AZ) 배포가 필요하며, 다른 지역에서 고가용성을 제공합니다. 일반적으로 비즈니스를 다른 데이터 센터에 배치합니다. 원래 데이터 센터에서 오류가 발생하면 클라이언트 트래픽을 다른 데이터 센터로 전환해야 하는데, APISIX Ingress는 이 요구 사항을 성공적으로 충족할 수 있습니다.

### Apache APISIX Ingress Controller의 특징

Apache APISIX를 데이터 플레인으로 사용하여 비즈니스 트래픽을 처리하는 Apache APISIX Ingress Controller는 Apache APISIX로부터 다음과 같은 장점을 상속받습니다.

- **고성능 및 안정성**: 고성능 동적 오픈소스 API 게이트웨이인 Apache APISIX는 많은 [기업의 대규모 트래픽 시나리오](https://apisix.apache.org/blog/tags/case-studies/)에서 탄력적이고 안정적인 성능을 보여줍니다.

- **활발한 커뮤니티**: 최상위 및 가장 활발한 오픈소스 API 게이트웨이 프로젝트인 Apache APISIX는 활발한 커뮤니티를 보유하고 있으며, 첫날부터 우수한 성장률을 유지하고 있습니다.

- **풍부한 생태계**: Apache APISIX는 HTTP(S), HTTP2, Dubbo, IoT 프로토콜인 MQTT 등을 포함한 L7 프로토콜을 지원합니다. 또한, APISIX는 TCP/UDP와 같은 L4 프로토콜도 지원합니다. 또한, Apache APISIX 3.0에서는 ARM64에 대한 완전한 지원이 제공됩니다.

- **다양한 플러그인**: APISIX 공식에서 거의 100개의 플러그인이 출시되어 사용자가 간단히 드래그 앤 드롭으로 사용할 수 있습니다. 플러그인의 핫 리로딩과 동적 오케스트레이션은 사용자에게 큰 편의를 제공합니다.

또한, APISIX Ingress Controller는 다음과 같은 고유한 장점도 가지고 있습니다:

- **좋은 호환성**: APISIX Ingress Controller는 여러 버전의 인그레스 리소스를 지원하며, 다양한 Kubernetes 버전과 호환될 수 있습니다.

- **동적 업데이트**: 라우트, 인증서 및 기타 설정을 수정할 때 서비스를 리로드할 필요가 없어 비즈니스의 원활한 운영을 보장합니다.

- **유연한 확장성**: APISIX Ingress Controller는 컨트롤 플레인과 데이터 플레인을 분리한 구조를 채택하고 있기 때문에, Apache APISIX의 데이터 플레인 클러스터를 독립적으로 확장할 수 있으며, APISIX Ingress Controller를 확장할 필요가 없습니다.

![APISIX Ingress Controller 아키텍처](https://static.api7.ai/2022/10/27/635a56148940c.jpeg)

- **운영 및 유지보수에 친화적**: 현재 아키텍처에서 사용자는 실제 상황에 따라 데이터 플레인 APISIX 클러스터를 Kubernetes 클러스터 또는 물리적 베어메탈 머신 환경에 배포할 수 있습니다. 또한, APISIX 인그레스의 아키텍처 분리로 인해 데이터 플레인에서 APISIX가 트래픽을 처리하는 동안 APISIX 인그레스 컨트롤러는 컨트롤 플레인 구성 요소입니다. 따라서 APISIX Ingress Controller의 장애는 비즈니스 트래픽에 영향을 미치지 않습니다.

게이트웨이 선택이 완료된 후, API 게이트웨이 팀은 새로운 도전에 직면했습니다: 수백 개의 서비스의 원래 API 게이트웨이 설정을 APISIX Ingress로 마이그레이션하는 방법은 무엇인가? Zoom의 인프라 팀은 nginx.conf 및 기타 Ingress 설정을 APISIX Ingress로 변환하는 마이그레이션 비용을 크게 줄일 수 있는 지속적 제공 파이프라인을 개발 중이었습니다.

## 지속적 제공 파이프라인 구축 과정 및 기능

### Zoom의 지속적 제공 파이프라인

지속적 제공 파이프라인은 모든 애플리케이션 제공 요구 사항을 선언하고 모든 지속적 제공 단계를 한 줄로 배열하고 실행하는 종단 간 애플리케이션 제공 시스템입니다.

![Zoom의 지속적 제공 파이프라인](https://static.api7.ai/2022/10/27/635a56149b270.jpg)

지속적 제공 파이프라인에는 여섯 가지 부분이 있습니다:

1. **준비**: 인프라, 미들웨어, 클라우드 서비스 리소스 등 사전 설정된 리소스를 준비합니다.

2. **설정**: 애플리케이션에 필요한 설정 파일과 키를 준비합니다.

3. **배포**: 클라우드 네이티브 시나리오에서 K8s를 사용하여 배포합니다(컨테이너, 컨테이너 이미지, 매개변수, 버전 및 인스턴스에 대한 정보 포함).

4. **접근**: 배포가 외부 접근이 필요한 경우 Kubernetes Service를 생성하고 Apache APISIX Ingress의 라우팅 규칙을 자동으로 설정합니다.

5. **관찰**: 모니터링, 알람, 로깅 및 추적 분석과 같은 관찰 관련 설정을 수행합니다.

6. **확장**: KEDA(Kubernetes Event-driven Autoscaling)의 동적 확장 규칙을 모니터링 지표를 통해 선언합니다.

### 파이프라인에서 APISIX Ingress를 어떻게 채택하는가

![Zoom의 파이프라인 아키텍처 개요](https://static.api7.ai/2022/10/27/635a5616254ed.jpg)

**프로젝트 관리**

프로젝트 관리자는 R&D 반복에 더 많은 관심을 가지고 있으며, 반복에 해당하는 타임라인에서 반복 릴리스 진행 상황과 인력 효율성을 더 잘 관리하는 방법에 중점을 둡니다. Zoom은 내부적으로 GitOps 워크플로우를 사용하여 API 게이트웨이 설정을 애플리케이션 제공 모델에 통합합니다. 이 모델에서 APISIX 라우팅 규칙의 정의는 "배포" 및 기타 링크와 통합되어 변경 제어를 GitHub에 넘깁니다. GitHub 브랜치의 생성과 병합을 통해 파이프라인은 애플리케이션과 게이트웨이 설정 릴리스 및 롤백 간의 일관된 타임라인을 실현합니다.

```yaml
# Zoom의 CD 파이프라인 코드 스니펫
deploy:
  type: Deployment
  replicas: ~{ replicas, 2 }
  version: "latest"
  containers:
    - name: my-app
      image: "busybox"
      command: "echo 'Demo' && sleep 99d"
access:
  - protocol: https
    host: my-domain.my-org.com
    cert: my-tls-cert
    apisix:
      routes:
        http:
          - name: my-api
            authentication:
              # ......
            match:
              paths:
                - /my-api/*
```

이 방법은 릴리스 관리를 GitHub 내의 워크플로우 관리로 단순화하고, 여러 반복이 동시에 처리될 때 업스트림과 다운스트림 시스템 간의 변경 사항 매칭 문제를 해결합니다.

**애플리케이션 개발**

개발자는 주로 API의 라우팅 및 인증 기능에 중점을 두며, 이는 비즈니스 서비스와 밀접하게 관련되어 있어 개발자가 자동화 효과를 달성하기 위해 작성해야 합니다. 또한, 개발자는 비즈니스 기능과 상위 비즈니스를 개발하고 구현하는 데 관심을 가지고 있으며, 즉시 사용할 수 있는 인프라를 구축하기를 원합니다.

위의 코드에서 볼 수 있듯이, 개발자는 이 지속적 제공 파이프라인에서 `Authentication`과 `Match`만 정의하면 됩니다. 그들은 기본 로직을 알 필요가 없습니다:

- 먼저, 이를 Kubernetes Deployment 및 Service로 변환합니다.
- 그런 다음, 플랫폼 API를 호출하여 경로의 정확성을 검증합니다.
- 마지막으로, ApisixRoute 객체로 변환합니다.

APISIX의 설정과 지속적 제공 파이프라인 워크플로우를 통합함으로써 개발자에게 더 편리한 방법을 제공합니다.

**환경 관리**

복잡한 환경 관리 및 제어 요구 사항은 종종 toB 시나리오에서 발생하며, 일부 프라이빗 클라우드, 전용 클라우드 및 하이브리드 클라우드 시나리오에서의 제공 문제를 고려해야 합니다.

APISIX 인그레스의 일부 설정은 환경 차이를 숨기기 위해 구현되었습니다. 이 방법으로 시스템 관리자는 일부 이기종 환경의 차이를 포괄적으로 제어할 수 있습니다. 환경에 배포된 모든 서비스는 효과적이며, 환경 차이로 인한 애플리케이션 및 운영 개발자의 인지 부담과 특수 배포 작업을 피할 수 있습니다. 예를 들어, Zoom은 일부 환경에서 추적을 비활성화하기 위해 사용자 정의 설정을 사용하고, ApisixRoute 객체를 네이티브 Ingress 객체 및 NGINX Ingress Annotation으로 변환하고, 다른 이미지를 사용하여 시크릿을 가져올 수 있습니다.

또한, 여러 비즈니스 라인이 APISIX 환경을 사용할 때 다중 테넌트 격리가 필요합니다. **APISIX Ingress는 Annotation 선택기를 제공**하여 다른 ApisixRoute 객체가 다른 APISIX Ingress Controller 인스턴스에 의해 선택될 수 있도록 합니다.

**인프라 관리**

API 게이트웨이 팀은 모든 APISIX 인스턴스를 제어하고, 보안 정책을 포괄적으로 설정하고, 다중 가용 영역을 구현해야 합니다.

파이프라인의 각 플러그인은 인프라 엔지니어를 위한 설정 항목을 제공합니다. `ingress-apisix` 플러그인에는 `defaultPlugins` 속성이 있습니다.

API 게이트웨이 팀이 이 속성을 설정하면, 모든 서비스에 대해 설정이 적용되며, 이는 통합 보안 및 위험 관리 전략에 적합합니다.

## 결론

APISIX Ingress Controller는 Zoom의 지속적 제공 파이프라인에서 중요한 역할을 하며, 프로젝트 관리, 애플리케이션 개발, 환경 관리, 미들웨어 및 인프라 관리의 부담을 덜어줍니다. Zoom의 사례는 다른 기업들에게도 배울 만한 가치가 있으며, APISIX Ingress Controller가 더 많은 기업의 혁신에 기여하기를 기대합니다.

또한, Apache APISIX Ingress는 2022년 8월에 V1.5를 공식 출시하여 모든 리소스 API 버전의 제안을 통일하고 모든 CRD API 버전을 V2로 업그레이드했습니다. 동시에, 대부분의 Gateway API 리소스를 지원합니다. Apache APISIX Ingress는 Ingress 리소스가 임의의 APISIX 플러그인을 사용할 수 있도록 Ingress 리소스에 새로운 Annotation "k8s.apisix.apache.org/plugin-config-name"을 추가했습니다. 이 방법은 APISIX Ingress Controller의 사용 편의성을 크게 높이고, 다른 Ingress Controller에서 APISIX Ingress Controller로 마이그레이션하는 비용을 줄일 것입니다.

더 많은 정보는 [Apache APISIX Ingress V1.5](https://apisix.apache.org/blog/2022/08/05/apisix-ingress-1.5rc1-release/)를 참조하십시오.


Zoom은 APISIX Ingress Controller를 지속적 전달 파이프라인에 통합하여 프로젝트, 애플리케이션, 환경 및 인프라 관리의 전반적인 관리를 실현합니다.

Zoom은 지속적 전달 파이프라인에서 APISIX Ingress를 어떻게 사용하나요?

## 개요

### 도전 과제

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

### 목표

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

### 결과

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

## iQIYI의 뒷이야기

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

2010년 4월 22일에 중국 최대 온라인 검색 엔진인 Baidu에 의해 설립된 [**iQIYI**](https://www.iq.com/?lang=en_us)는 현재 전 세계에서 가장 큰 온라인 비디오 사이트 중 하나로, 매월 약 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 게이트웨이 아키텍처를 구축하기 시작했습니다. 아래는 도메인 이름, 게이트웨이, 서비스 인스턴스 및 모니터링 알람을 포함한 새로운 아키텍처입니다.

![iQIYI의 API 게이트웨이 아키텍처 다이어그램](https://static.api7.ai/2022/12/02/6389647220deb.jpeg)

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

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

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

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

![마이크로서비스-게이트웨이.webp](https://static.api7.ai/2022/11/21/637b4c61c02c0.webp)

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

iQIYI는 [Apache APISIX](https://github.com/apache/apisix)로 조정한 후 API 아키텍처에 속도 제한, 인증, 알람, 모니터링 등과 같은 기본 기능을 구현했습니다.

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

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

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

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

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

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

![iQIYI의 동적 서비스 발견 업데이트 프로세스](https://static.api7.ai/2022/12/02/63897fa31ff83.jpeg)

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

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

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

![iQIYI의 방향성 경로 다이어그램](https://static.api7.ai/2022/12/02/63898546bd508.jpeg)

### 성과 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](https://api7.ai/contact).


iQIYI의 기술 팀은 APISIX와 Kong을 비교하고, iQIYI의 인프라를 업데이트 및 통합하여 완전히 새로운 API 게이트웨이를 성공적으로 구축했습니다.

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

## 개요

세계적인 기업용 컨소시엄 블록체인 인프라 공급자이자 솔루션 제공업체인 [Hyperchain Technologies](https://www.hyperchain.cn/en/about/company)는 혁신적인 인프라를 구축하고 사회의 디지털 발전을 지원하기 위해 노력하고 있습니다. 빠르게 성장하는 과정에서 Hyperchain은 Hyperchain 블록체인 플랫폼을 구축하면서 다음과 같은 문제들을 직면했습니다:

- 표준화된 트래픽 관리가 없어 시스템 붕괴 위험이 있음
- 불완전한 보안 제어 및 인증 관리
- 불편한 권한 제어
- 공용 네트워크 IP 주소에 대한 높은 비용
- 불안정한 블록체인 노드: 단일 노드가 공격에 취약함
- 다양한 프로토콜에 대한 통합 관리 부재

Hyperchain은 Kong과 NGINX를 시도했지만, 불행히도 Hyperchain의 비즈니스 시나리오를 충족시키지 못했습니다. **그러나 Apache APISIX를 도입한 후, 위에서 언급한 모든 문제들이 해결되어 Hyperchain 블록체인 플랫폼에 무한한 활력을 불어넣었습니다.**

### Hyperchain 블록체인 플랫폼 소개

Hyperchain 블록체인 플랫폼은 블록체인 프레임워크를 클라우드 컴퓨팅 플랫폼에 내장하여 클라우드 서비스 인프라의 배포 및 관리 이점을 활용합니다. 이는 개발자들에게 편리하고 고성능의 블록체인 생태계와 관련 지원 서비스를 제공할 수 있는 오픈 블록체인 플랫폼이며, web3에서의 비즈니스 확장 및 운영도 지원합니다.

**Hyperchain 블록체인 플랫폼은 블록체인 네트워크를 빠르고 유연하게 구축할 수 있습니다. 이 플랫폼을 통해 기업은 블록체인 비즈니스를 통합적으로 관리할 수 있습니다.** 예를 들어, 통합 개발 환경에서 계약을 체결한 후 생성된 블록체인 네트워크에 배포할 수 있습니다. 상위 서비스 모듈은 블록체인 관련 계약을 호출하여 비즈니스 프로세스를 계속할 수 있습니다.

체인 내에 수십 개에서 수천 개에 이르는 많은 노드가 존재하기 때문에 플랫폼의 지원 없이는 체인의 운영을 모니터링하고 유지하는 것이 어렵습니다. **Hyperchain 블록체인 플랫폼을 사용하면 사용자는 비용을 절약할 뿐만 아니라 블록체인을 더 편리하게 관리하고 전체 시스템의 보안을 강화할 수 있습니다.**

Hyperchain을 예로 들어, 블록체인 기업들이 많은 API 게이트웨이 중에서 Apache APISIX를 선택해야 하는 이유와 방법을 알아보겠습니다. 아래에서는 APISIX의 Hyperchain 블록체인 플랫폼 및 블록체인 노드에서의 적용 사례를 분석하겠습니다.

## Hyperchain 블록체인 플랫폼에서의 APISIX 적용

아래는 Hyperchain 블록체인 플랫폼에서 APISIX의 애플리케이션 상호작용 다이어그램입니다. 백엔드 서비스는 비즈니스 특성에 따라 etcd에 서비스 정보를 등록한 후, 라우트 등록 모듈을 통해 APISIX에 서비스를 등록합니다.

APISIX는 시스템 내부의 마이크로서비스에 대한 통합 진입점으로 작동합니다. 외부 요청은 먼저 APISIX로 전송되고, 인증을 통과한 후 API를 통해 액세스 계층에 접근하며, 이후 RPC(원격 프로시저 호출)를 통해 핵심 서비스에 접근합니다.

![Hyperchain 애플리케이션 상호작용 다이어그램](https://static.api7.ai/2022/11/15/637335a53d73c.png)

### 라우트 전달

때로는 동일한 도메인 이름 아래에 API를 노출해야 할 경우가 있습니다. 이 경우 동일한 서비스의 API 경로에 `/baas-core` 또는 `/baas-other`와 같은 접두사를 추가할 수 있습니다. 클라이언트가 이러한 API를 요청할 때, API 게이트웨이는 추가된 접두사를 제거한 후 백엔드 서비스로 요청을 전달해야 합니다. APISIX의 [proxy-rewrite 플러그인](https://apisix.apache.org/docs/apisix/plugins/proxy-rewrite/)은 이러한 경우를 편리하게 처리할 수 있도록 도와줍니다.

예를 들어:
방문 시: http://apisix:8080/baas-{service}/api/v1/…
요청은 http://{service}/api/v1/…로 전달될 수 있습니다.
정규 표현식 작성: `^/baas-core/(.*)$,/$1`

![proxy-rewrite 플러그인 편집](https://static.api7.ai/2022/11/15/637335b538dc0.png)

### 트래픽 제한 관리

사용자는 Hyperchain뿐만 아니라 IBM 데이터 Fabric, Baidu XuperChain 등과 같은 컨소시엄 블록체인을 필요에 따라 선택할 수 있습니다. 따라서 Hyperchain은 시스템 내 모든 컨소시엄 블록체인의 라이프사이클 관리를 수행해야 합니다.

컨소시엄 체인을 생성할 때, Hyperchain은 블록체인 플랫폼에 하드 코드를 작성하고 플러그형 드라이브 컴포넌트를 블록체인 플랫폼에 업로드하여 호출하여 컨소시엄 체인을 생성합니다. 일부 프라이빗 배포 사례에서는 플러그형 드라이브 컴포넌트가 빠르게 지원될 수 있습니다.

드라이브 컴포넌트에 대한 모든 호출은 제한이 필요한 프로세스이며, 특히 호출 횟수가 많을 때 더욱 그렇습니다. 따라서 APISIX의 [limit-req 플러그인](https://apisix.apache.org/docs/apisix/plugins/limit-req/)은 플랫폼의 트래픽 입출력을 제한하여 안정성을 보장하는 데 유용합니다.

limit-req 플러그인은 속도 및 버스트에 대한 사용자 정의 구성을 허용합니다.

![limit-req 플러그인 모델](https://static.api7.ai/2022/11/15/637335b790f49.jpeg)

### 보안 제어 및 권한 관리

APISIX와 협력하기 위해 Hyperchain은 프라이빗 배포 환경을 위한 플러그인을 개발했습니다. 파티 A는 종종 자체 인증 서비스 또는 서비스 계정 시스템을 사용하려고 합니다. 프론트엔드 트래픽이 웹사이트를 방문할 때, 먼저 Access-auth 플러그인을 통과해야 하며, 인증을 통과한 후에만 백엔드 BFF(Backend for Frontend)에 접근할 수 있습니다.

![인증 프로세스 다이어그램](https://static.api7.ai/2022/11/15/637335b994030.png)

Restful 표준 사양의 세 가지 주요 요소(인증 정보, Restful 경로, GET, POST, PUT, DELETE, PATCH 등의 HTTP 동사)에 따라 계정-역할-권한 인증이 수행됩니다. 인증이 통과되면 헤더에 사용자 정보가 반환되고, 그렇지 않으면 403이 반환됩니다.

![API 인증 경로](https://static.api7.ai/2022/11/15/637335bd3e080.png)

### 핫 리로딩

APISIX는 내부적으로 개발된 플러그인의 [핫 리로딩](https://apisix.apache.org/docs/java-plugin-runner/hot-reloading/)을 제공합니다. 이를 통해 개발 시간을 절약하고 사용자는 플러그인 러너를 재시작하지 않고도 코드의 일부를 변경할 수 있습니다. 이렇게 하면 개발자는 백엔드에서 인터페이스를 조정하여 즉시 적용할 수 있어 온라인 릴리스에 편리하고 친화적입니다.

### Kong을 사용하지 않는 이유

Hyperchain은 이전에 Kong을 사용했지만 결국 Apache APISIX로 대체했습니다. 주된 이유는 다음과 같습니다:

- **높은 배포 및 유지 관리 비용**

    Kong 클러스터는 Postgresql 데이터베이스와 협력해야 하며, 고가용성을 위해 특정 데이터베이스 관리자가 필요합니다. Postgresql 데이터베이스의 클러스터 배포는 구현이 상대적으로 어렵고, 후속 운영 및 유지 관리 비용을 증가시킵니다.

- **시스템 복잡성 및 장애율 증가**

    Hyperchain 블록체인 플랫폼은 MySQL 데이터베이스를 사용하므로 Kong을 도입하면 시스템 내에 두 개의 관계형 데이터베이스가 존재하게 되어 시스템이 더 복잡해집니다. 또한 두 데이터베이스 간의 호환성을 개선하는 과정에서 장애율이 증가합니다.

## 블록체인 노드에서의 APISIX 적용

![Hyperchain 블록체인 다이어그램](https://static.api7.ai/2022/11/15/637335bfa08dc.png)

### 공용 네트워크 IP 주소 비용 절감

사용자는 Hyperchain 블록체인 플랫폼을 통해 블록체인을 구매합니다. 그런 다음 상위 비즈니스 및 개발자 클라이언트가 노드에 연결할 수 있습니다. 서비스는 하나 이상의 노드에 연결될 수 있으며, 사용자는 하나 이상의 노드에 접근할 수 있습니다. 이로 인해 거의 모든 노드가 방문되며, 단일 노드의 방문 압력이 증가합니다.

일부 프라이빗 배포 환경에서는 상대적으로 쉽게 처리할 수 있습니다. 그러나 인터넷 사용자를 대상으로 하는 시스템의 경우 너무 많은 노드와 공용 네트워크 IP가 필요합니다. 4MB 트래픽의 공용 네트워크 IP 가격은 월 200CNY에 달할 수 있습니다. Hyperchain 플랫폼에는 수천 개의 노드가 있어 높은 공용 IP 비용이 발생합니다.

APISIX는 모든 방문 요청을 관리하고 해당 블록체인 노드로 트래픽을 분배합니다. 이를 통해 Hyperchain은 높은 비용을 절감했습니다.

![APISIX를 사용한 Hyperchain의 모드](https://static.api7.ai/2022/11/15/637335c23f4f8.png)

### 편리한 권한 제어

Hyperchain 블록체인 플랫폼에는 다양한 블록체인이 있으며, 각 체인에는 복잡한 RBAC 권한 제어가 있습니다. 따라서 클라이언트 측에 TLS 인증서와 같은 다양한 종류의 인증서를 추가해야 하며, 이는 사용자에게도 혼란을 줍니다.

현재 APISIX의 [key-auth 플러그인](https://apisix.apache.org/docs/apisix/plugins/key-auth/)을 사용하여 이 문제를 효율적으로 해결할 수 있습니다. 인증된 사용자는 권한 구성을 걱정하지 않고 블록체인에 직접 접근할 수 있으며, APISIX는 기본 체인을 통합합니다.

### 클러스터링으로 노드 안정성 향상

위에서 언급한 바와 같이, 노드는 자주 방문됩니다. 대부분의 은행 사용자에게는 높은 동시성이 존재하며, TPS(초당 트랜잭션 수)는 40,000-50,000회에 달할 수 있습니다.

블록체인의 단일 노드는 취약한 것으로 밝혀졌는데, 각 트랜잭션이 방문된 노드에 영향을 미치기 때문입니다.

Hyperchain은 K8s에 Apache APISIX를 배포하고 Horizontal Pod Autoscaler를 사용했습니다. APISIX는 동적 확장성이 뛰어난 etcd를 사용하므로 단일 지점 트래픽 영향을 효과적으로 해결할 수 있습니다.

### 다양한 프로토콜 지원

Hyperchain 블록체인 플랫폼의 이종 체인 프로토콜은 HTTP 프로토콜, Websocket 프로토콜, gRPC 프로토콜, TCP 프로토콜, UDP 프로토콜 등 다양합니다.

APISIX는 다양한 프로토콜을 지원하여 서로 다른 블록체인의 기본 계층에 유연하게 적응하므로 개발 비용을 절감할 수 있습니다.

### NGINX를 사용하지 않는 이유

Hyperchain은 NGINX를 사용하여 문제를 해결할 수 있을 것 같았지만, 시도 후 포기했습니다. 그 이유는 다음과 같습니다:

- **동적 확장에 부적합**

    Hyperchain은 블록체인 플랫폼에서 노드를 자주 추가 및 삭제해야 하는데, 이는 재시작 후에만 적용되므로 개발자에게 불편합니다. 또한 개발자는 NGINX의 conf 파일에 플러그인을 위한 복잡한 규칙 코드를 작성해야 합니다.

- **클러스터링이 어려움**

    NGINX는 클러스터를 지원하지 않아 사용자에게 상대적으로 복잡하고 불친절합니다.

- **TCP 및 UDP 직접 지원 부재**

    NGINX는 7계층 프로토콜만 프록시할 수 있으며, 4계층 프로토콜을 직접 지원하지 않습니다. 또한 모듈이 기본적으로 컴파일되지 않아 추가 처리가 필요합니다.

- **대시보드 부재**

    NGINX에는 시각화된 인터페이스가 없어 개발자와 운영자가 많은 노드를 관리하기 어렵습니다.

## 요약

위에서 언급한 내용을 통해 Apache APISIX는 블록체인 영역에서 적용할 수 있는 동적 API 게이트웨이라는 것을 알 수 있습니다. 또한 Apache APISIX는 로드 밸런싱, 동적 업스트림, 카나리 릴리스, 서킷 브레이킹, 인증, 관찰 가능성 등과 같은 풍부한 트래픽 관리 기능을 제공합니다.

APISIX가 더 많은 블록체인 기업들이 새로운 발전 단계로 나아갈 수 있도록 지원하기를 바랍니다.
Apache APISIX에 대해 더 알아보려면 https://api7.ai/contact로 문의하십시오.


블록체인 유니콘 기업인 Hyperchain이 오픈소스 API 게이트웨이인 APISIX를 활용하여 Hyperchain 블록체인 플랫폼의 웹3 환경에서 블록체인 트래픽을 관리하는 방법에 대해 설명합니다. 이 글에서는 APISIX, Kong, NGINX 간의 비교도 다룹니다.

Apache APISIX vs Kong:
93x Faster & 200% QPS

APISIX vs Kong Performance Report

Looking for the best API Gateway?

Go for Apache APISIX

Community-Driven

Open-Source Project

Ultimate Performance,

High Availability, Stability

Developer Friendly

Apache APISIX vs Kong

Case Studies

Zoom은 지속적 전달 파이프라인에서 APISIX Ingress를 어떻게 사용하나요?

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

Web3를 위한 API Gateway: APISIX가 Hyperchain에 힘을 실어주는 방법

API 관리를 시작할 준비가 되셨나요?

Apache APISIX vs Kong:.css-j8kk69{background-image:var(--chakra-colors-gradient-600);color:transparent;-webkit-background-clip:text;background-clip:text;}93x Faster & 200% QPS

APISIX vs Kong Performance Report

Looking for the best API Gateway?

Go for Apache APISIX

Community-Driven

Open-Source Project

Ultimate Performance,

High Availability, Stability

Developer Friendly

Apache APISIX vs Kong

Case Studies

Zoom은 지속적 전달 파이프라인에서 APISIX Ingress를 어떻게 사용하나요?

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

Web3를 위한 API Gateway: APISIX가 Hyperchain에 힘을 실어주는 방법

API 관리를 시작할 준비가 되셨나요?

Apache APISIX vs Kong:
93x Faster & 200% QPS