## 배경

최근 몇 년 동안, 온라인 회의와 원격 근무의 발전과 함께 많은 유명한 온라인 회의 소프트웨어가 등장했습니다. 그 중 대표적인 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를 어떻게 사용하나요?

## 개요

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

### APISIX 사용 전의 문제점

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

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

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

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

- **다차원 리소스 지원 부족**

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

- **문제의 영향 통제 불가**

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

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

### APISIX 사용 후의 성과

- **고가용성**

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

- **고성능**

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

- **풍부한 기능**

    APISIX의 [풍부한 기능](https://apisix.apache.org/blog/2022/11/02/apache-apisix-v3-preview/) 덕분에, APISIX는 거의 모든 일반적인 NGINX 프록시 시나리오를 커버할 수 있습니다. vivo 프로젝트의 약 50%가 NGINX에서 APISIX 클러스터로 마이그레이션되었습니다.

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

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

## APISIX 기반의 vivo 시스템 설계

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

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

![vivo's API gateway architecture with APISIX](https://static.api7.ai/2022/11/23/637dc2f51318e.jpg)

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

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

### 구성 관리 및 출시 개선

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

#### 컨트롤 플레인 변경

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

A6 변경 플랫폼에서 데이터가 구성된 후, 정보는 RPC 알림을 통해 ManagerAPI로 전달됩니다. ManagerAPI는 오픈소스 [APISIX Dashboard](https://github.com/apache/apisix-dashboard)를 기반으로 vivo가 구축했습니다.

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

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

![vivo's management and publishing mode](https://static.api7.ai/2022/11/25/638036da44e7f.jpeg)

[etcd](https://etcd.io/docs/v3.5/learning/why/#comparison-chart "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](https://static.api7.ai/2022/11/25/6380381595b00.jpeg)

APISIX의 오픈소스 버전은 [etcd](https://apisix.apache.org/docs/apisix/FAQ/#why-does-apache-apisix-use-etcd-for-the-configuration-center)를 제공하여 모든 사람이 공유할 수 있도록 합니다. 그러나 회사의 프로젝트는 복잡하며, 발생하는 문제는 통제할 수 없습니다. 또한, 복잡한 플러그인을 사용하는 것은 불가피하며, 이는 시스템 성능에 영향을 미칩니다.

따라서, 클러스터 분리 관리를 통해 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](https://static.api7.ai/2022/11/23/637dc306a5fa1.jpg)

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

### 컨테이너화 개발 지원

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

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

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

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

- 하나의 서버에 여러 포트

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

4. 회사 내부 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](https://apisix.apache.org/blog/2022/09/13/why-is-apache-apisix-the-best-api-gateway/)를 트래픽 게이트웨이에서 API 게이트웨이로 확장할 계획이며, [속도 제한](https://apisix.apache.org/docs/apisix/plugins/limit-count/#attributes), [인증](https://apisix.apache.org/docs/ingress-controller/tutorials/mtls/), 서킷 브레이커 등의 장점을 활용할 것입니다. APISIX와 DPDK-NGINX를 결합하는 것을 고려하며, 기술 인력을 양성하고 커뮤니티 구축에 참여할 것입니다. 또한, 기본 기술을 강화하여 트래픽 및 서비스 거버넌스를 구축할 좋은 기반을 마련할 것입니다.

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

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


유명한 모바일 제조업체인 vivo는 어떻게 APISIX를 API 게이트웨이로 채택하고 이를 비즈니스에 맞게 조정했을까요?

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

## 개요

### 도전 과제

- Airwallex의 비즈니스가 전 세계로 확장됨에 따라 데이터 거버넌스에서의 중요한 도전 과제
- 다양한 시스템과 상호 연결의 복잡한 관리로 인해 한 시스템에서 문제가 발생하면 다른 시스템에도 문제가 발생

### 결과

- **15개월** 동안의 프로덕션 환경 운영에서 안정적인 성능
- 동적 라우팅, 멀티 테넌트 속도 제한, 멀티 테넌트 IP 화이트리스트, 인증 및 권한 부여가 활성화된 상태에서 **99%**의 응답 지연이 **23ms** 이내
- **130개 이상의 국가와 지역**에서 **50개 이상의 통화**를 포함한 데이터 주권을 안전하고 효율적으로 지원

## Airwallex 소개

글로벌 핀테크 기업인 [Airwallex](https://www.airwallex.com/us)는 전 세계 130개 이상의 국가와 지역에서 50개 이상의 통화를 커버하는 글로벌 결제 네트워크를 구축하고 있으며, 기업을 위한 디지털 핀테크 제품을 제공합니다.

![Airwallex 비즈니스](https://static.api7.ai/apisix-webp/202108/1646626634389-7d9a0a82-a76c-4645-93b6-8a431bb1f9a1.webp)

> 이 글은 Apache APISIX의 Committer이자 Airwallex의 기술 플랫폼 리드인 Yang Li 박사와의 인터뷰에서 나온 것입니다. Yang Li 박사는 Airwallex의 기술 플랫폼 진화를 담당하고 있습니다.

## 데이터 주권이 Airwallex에 도전 과제를 제시

[데이터 주권](https://api7.ai/blog/leveraging-api-gateway-for-data-sovereignty-and-data-compliance)은 사이버 공간 데이터 거버넌스에서 점점 더 중요해지고 있습니다. Airwallex는 다양한 지역의 사용자를 서비스하므로 자연스럽게 데이터 주권 문제가 발생합니다.

이전에는 데이터 주권 요구 사항이 없었기 때문에 데이터를 유럽에 배치하고 아시아 또는 전 세계의 어떤 데이터 센터로도 동기화할 수 있었습니다. 데이터 상호 작용 다이어그램은 다음과 같습니다:

![다중 클러스터 상호 작용](https://static.api7.ai/202108/1635907812257-962b1247-f5ca-448f-904d-fd47c3ea4586.png)

그러나 데이터 주권이 중요시되는 시대에는 데이터가 통제되며, 이전의 아키텍처를 채택할 수 없습니다. 유럽에서는 유럽 데이터만 처리할 수 있고, 아시아에서는 아시아 데이터만 처리할 수 있습니다. 데이터 상호 작용 변화는 다음과 같습니다.

![데이터 주권 환경에서의 상호 작용](https://static.api7.ai/uploads/2023/02/01/63Z7AhJx_2.webp)

결과적으로, 데이터 주권은 Airwallex의 글로벌 비즈니스에 상당한 도전 과제를 제시합니다. Airwallex는 유럽에서 다른 지역으로 데이터를 마이그레이션하려고 하며, EU의 데이터 주권 요구 사항과 일치하도록 해야 합니다.

## Airwallex가 APISIX를 선택한 이유

API 게이트웨이를 선택할 때, Airwallex는 주로 여섯 가지 차원에서 주요 게이트웨이 제품을 비교했습니다:

- **안정성**: Airwallex는 API 게이트웨이의 안정성을 보장하는 데 큰 중점을 둡니다. 전 세계 상위 1000개 웹사이트 중 **62.1%가 NGINX 기반**이며, 이는 NGINX 기반 웹 서버가 프로덕션 환경에서 복잡하고 다양한 시나리오를 통과했음을 보여줍니다. Apache APISIX는 NGINX 기반입니다. 또한, **Apache APISIX의 [완전 동적](https://api7.ai/blog/how-nginx-reload-work)** 기능 설계는 클라이언트의 장기 연결을 유지하면서도 재로드 없이 경로를 수정할 수 있게 합니다. 또한, **Airwallex는 Apache APISIX에 대한 스트레스 테스트를 수행했으며, CPU 사용률이 70% 이상일 때도 안정적으로 실행될 수 있음을 확인했습니다.**

- **성능**: 모든 API 요청은 API 게이트웨이를 통과합니다. 게이트웨이의 [성능](https://api7.ai/blog/apisix-kong-3-0-performance-comparison) 손실을 줄이면 Airwallex의 전체 API 응답 시간을 크게 줄일 수 있습니다.
  
    > "PoC에서 주요 게이트웨이 제품을 비교했을 때, **Apache APISIX의 응답 지연은 다른 게이트웨이보다 50% 이상 낮았습니다**. 또한, Apache APISIX의 독립적인 데이터 플레인은 클러스터 내에서 독립적인 인스턴스를 가능하게 하여 수평 확장을 본질적으로 지원합니다."라고 Li는 말했습니다.

- **확장성**: Airwallex는 복잡한 **[인증](https://api7.ai/blog/api-gateway-authentication), 권한 제어, [서비스 발견](https://api7.ai/blog/what-is-service-discovery-in-microservices), [속도 제한](https://api7.ai/blog/rate-limiting-in-api-management), 다운그레이드, 로드 밸런싱, 화이트리스트, 동적 라우팅**을 지원하는 API 게이트웨이로 APISIX가 작동해야 합니다.

- **활발한 커뮤니티**: 활발한 커뮤니티는 API 게이트웨이가 기술 진화의 속도를 따라잡는 데 핵심입니다.

    > **Apache APISIX의 [커뮤니티](https://api7.ai/category/community)는 아파치 인큐베이션 프로젝트였을 때부터 활발했으며, 기여자 수, 이슈 응답 시간, Pull Request 수로 판단할 수 있습니다.** Li는 공유했습니다.

- **프라이빗 배포**: API 게이트웨이는 Airwallex의 핵심 기술 아키텍처 구성 요소이며, 자체 프라이빗 네트워크의 에지에 API 게이트웨이를 배포합니다. **Apache APISIX는 다양한 환경, 클라우드 컴퓨팅 플랫폼을 포함한 환경에 쉽게 배포할 수 있는 우수한 환경 적응력을 가지고 있습니다.**

- **비즈니스 친화적인 오픈소스 라이선스**: Apache 2.0 라이선스는 Airwallex가 APISIX의 코드를 수정하고 상업화할 수 있게 하며, 벤더 락인에 대한 걱정 없이 사용할 수 있습니다.

## Apache APISIX의 지능형 라우팅 솔루션

**Airwallex는 Apache APISIX를 선택하여 지능형 라우팅 솔루션을 만들었으며**, 데이터를 어디에서 처리할지 결정하는 것은 Apache APISIX 게이트웨이입니다.

![Airwallex의 두 층 게이트웨이](https://static.api7.ai/uploads/2023/02/01/cGg9YfNp_3.webp)

게이트웨이는 두 층으로 구성됩니다. 첫 번째 층은 요청을 라우팅하고, 조건에 따라 요청이 도달해야 할 데이터 센터를 결정합니다. 두 번째 층은 트래픽 전달을 담당합니다.

또한, **Airwallex는 주요 기능을 사용자 정의 [플러그인](https://api7.ai/blog/how-to-implement-plugin-orchestration-in-api-gateway)으로 구현하여 언제든지 Apache APISIX의 새 버전으로 업그레이드할 수 있습니다.** 이렇게 하면 Airwallex의 코드 라이브러리와 Apache APISIX의 주요 저장소의 핵심 코드 간에 경쟁 조건이 발생하지 않습니다. 그러나 때로는 핵심 코드를 수정해야 할 때도 있습니다. 이때 Li는 가능한 한 이러한 기능을 오픈소스 커뮤니티에서 구현하려고 노력합니다. **커뮤니티의 기여자들은 기능 구현에 대해 매우 열정적으로 논의하며, 대부분의 경우 빠르게 사용 가능한 솔루션을 제공할 수 있습니다.**

## Airwallex가 APISIX 사용으로 얻는 이점

아래는 Airwallex와 APISIX의 통합을 보여주는 다이어그램입니다.

![Airwallex와 APISIX의 통합 다이어그램](https://static.api7.ai/uploads/2023/01/31/Q0LbIb0E_88.webp)

Airwallex는 Apache APISIX를 마이크로서비스 게이트웨이 모델의 핵심 구성 요소로 사용합니다. 이는 네트워크의 에지에 배포되며 Airwallex로 들어오는 모든 트래픽에 대해 일반적인 게이트웨이 기능을 제공합니다. 이로써 해결하는 문제는 다음과 같습니다:

- **데이터 주권**: 국경을 넘나드는 금융 인프라의 경우, 데이터 주권은 중요한 규제 요구 사항입니다. 이를 위해, **Airwallex는 Apache APISIX의 동적 업스트림 선택 기능을 활용하여 규제 준수 동적 라우팅 플러그인을 개발했습니다.** 동적 라우팅은 사용자 요청의 특성에 따라 업스트림을 지능적으로 선택하여 요청을 분배할 수 있으며, 복잡한 다중 데이터 센터 협업 문제를 서비스 계층에서 게이트웨이 계층으로 추상화합니다. 동적 라우팅의 본질은 두 가지 질문에 답하는 것입니다: 업스트림을 어떻게 그룹화할 것인가, 그리고 요청과 그룹을 어떻게 매칭할 것인가.

- **마이크로서비스의 격리**: Airwallex는 각 마이크로서비스의 엔지니어링 팀이 자체 서비스를 독립적으로 제어할 수 있기를 원하며, 이는 커뮤니케이션 및 조정 비용을 효과적으로 줄이고 엔지니어링 효율성을 향상시킵니다. 이러한 아키텍처 개념은 API 게이트웨이와 같은 다양한 팀이 공유하는 인프라 구성 요소가 테넌트 격리를 지원할 수 있어야 합니다. **APISIX는 테넌트 격리를 만족시키기에 완벽합니다.** 전체 시스템의 견고성과 비용 통제를 보장하면서도, APISIX는 비즈니스 팀이 자체 요구에 따라 게이트웨이 기능을 구성하고 확장할 수 있게 하여 마이크로서비스 팀과 서비스의 독립성을 유지합니다.

- **멀티 테넌트 속도 제한**: 멀티 테넌트 환경에서 각 테넌트의 트래픽 특성은 다릅니다. 다른 테넌트에 동일한 속도 제한을 적용하는 것은 상업적 요구를 충족시킬 수 없습니다. **멀티 테넌트 [속도 제한](https://api7.ai/blog/rate-limiting-in-api-management)은 사용자 특성에 따라 더 적절할 수 있습니다.**

- **멀티 테넌트 IP 화이트리스트**: 멀티 테넌트 환경에서 각 테넌트의 접근 IP는 다양합니다. **멀티 테넌트 IP 화이트리스트는 각 테넌트가 자체 화이트리스트를 제어할 수 있게 하여 다른 사용자의 자원 침입을 걱정하지 않아도 됩니다.**

- **인증**: 빈번한 키 업데이트는 사용자 자원의 보안을 보장하는 중요한 요소입니다. **APISIX는 요청 [인증](https://api7.ai/blog/understanding-microservices-authentication-services)뿐만 아니라 동적 키 업데이트도 지원합니다.**

- **권한 부여**: 기업 애플리케이션의 권한 관리는 매우 복잡하며, 다른 애플리케이션 시나리오는 완전히 다른 권한 관리 모델을 가지고 있습니다. **APISIX는 라우팅 구성에 따라 요청 사용자가 인터페이스에 접근할 충분한 권한이 있는지 확인하고, 불법 트래픽을 처음부터 차단할 수 있습니다.**

Airwallex의 프로덕션 환경은 **15개월** 동안 운영되었으며, 전체 성능은 매우 안정적입니다. 동적 라우팅, 멀티 테넌트 속도 제한, 멀티 테넌트 IP 화이트리스트, 인증, 권한 부여 및 기타 기능이 활성화된 상태에서 **99%의 응답 지연이 23ms 이내**입니다.

**Apache APISIX의 우수한 플러그인 메커니즘 덕분에, Airwallex는 핵심 코드를 수정하지 않고도 비즈니스 요구를 충족하는 프라이빗 플러그인을 추가할 수 있습니다.** 완전한 테스트 시스템은 소프트웨어 품질을 추가로 보장하며, 원래의 핵심 로직이 손상되지 않으면서도 플러그인의 개인화된 요구 사항을 안전하게 추가할 수 있습니다.

## 향후 계획

Airwallex의 향후 계획은 주로 세 가지 측면을 포함합니다:

1. 다층 네트워크를 사용하여 게이트웨이 로직을 다른 층으로 분할합니다. 예를 들어, 데이터 주권 또는 기타 게이트웨이 로직에 따라 트래픽을 분배합니다.

2. 읽기 쉽고 사용하기 쉬운 라우팅 관리는 API 게이트웨이의 성공에 중요합니다. 라우팅 관리는 개발자에게 친화적이어야 하며, 개발자가 게이트웨이가 무엇을 할 수 있는지, 어떻게 구성하고 게시할 수 있는지 쉽게 이해할 수 있어야 합니다.

3. 색상 코드 요청을 사용하여 프로덕션 환경 테스트를 구현합니다. API 게이트웨이의 색상 코드 요청을 사용하여 프로덕션 환경 테스트를 구현하면 더 많은 유연성과 사용 편의성을 제공할 수 있습니다.

## APISIX 지원을 찾고 계신가요?

[Apache APISIX](https://api7.ai/apisix)는 모든 API와 마이크로서비스를 위한 오픈소스, 동적, 확장 가능하며 고성능의 클라우드 네이티브 API 게이트웨이입니다. API7.ai가 아파치 소프트웨어 재단에 기부한 APISIX는 이제 최상위 오픈소스 아파치 프로젝트로 성장했습니다.

Airwallex처럼 자신감을 가지고 개발을 가속화하고 싶으신가요? APISIX 지원을 극대화하려면 [API7](https://api7.ai/)이 필요합니다. 우리는 귀하의 요구에 따라 APISIX 및 API 관리 솔루션에 대한 심층적인 지원을 제공합니다!

지금 문의하세요: [https://api7.ai/contact](https://api7.ai/contact).

인터뷰 대상자에 대한 더 많은 정보:

![Yang Li, Airwallex](https://static.api7.ai/uploads/2023/01/31/uGbiZnt5_Airwallex2.webp)


Airwallex는 데이터 주권(data sovereignty)이 가져오는 기술적 문제를 해결하고, Apache APISIX를 활용하여 지능형 라우팅 솔루션을 제공합니다.

What is Apache APISIX?

Why Apache APISIX?

APISIX vs alternatives

To Maximize APISIX, You Need API7

Case Studies

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

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

Airwallex가 Apache APISIX를 활용하여 글로벌 결제를 강화하는 방법

Looking for Apache APISIX Support?