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

배경

최근 몇 년 동안, 온라인 회의와 원격 근무의 발전과 함께 많은 유명한 온라인 회의 소프트웨어가 등장했습니다. 그 중 대표적인 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는 Apache APISIX를 데이터 플레인으로 사용하여 트래픽을 처리하고 CRD(CustomResourceDefinition)를 활용하여 Kubernetes의 기능을 확장하는 클라우드 네이티브 인그레스 컨트롤러입니다. 이 컨트롤러는 Kubernetes API 서버와 상호 작용하고, 역할 기반 접근 제어(RBAC)를 적용하며, 변경 사항을 모니터링하고, Ingress 컨트롤러 내에서 객체 변환을 구현하고, 변경 사항을 비교한 후 Apache APISIX에 동기화합니다. 또한, APISIX Route, APISIX Upstream 및 Kubernetes의 기타 네이티브 인그레스와 같은 사용자 정의 리소스를 지원하여 Kubernetes에 배포된 서비스에 외부 트래픽이 접근하도록 제어할 수 있습니다.

아래는 APISIX Ingress Controller의 타이밍 다이어그램입니다.

APISIX Ingress의 타이밍 다이어그램

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

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

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

다른 팀이 NGINX를 별도로 유지보수해야 하며, 수천 줄의 NGINX 설정 파일로 인해 유지보수가 어렵습니다. 또한, NGINX는 클라우드 서버에 많은 라인을 배포할 때 빠르게 확장할 수 없습니다. NGINX의 리로드 모드에 대해서는 이 블로그를 참조하십시오. 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는 많은 기업의 대규모 트래픽 시나리오에서 탄력적이고 안정적인 성능을 보여줍니다.
활발한 커뮤니티: 최상위 및 가장 활발한 오픈소스 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 아키텍처

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

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

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

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

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

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

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

준비: 인프라, 미들웨어, 클라우드 서비스 리소스 등 사전 설정된 리소스를 준비합니다.
설정: 애플리케이션에 필요한 설정 파일과 키를 준비합니다.
배포: 클라우드 네이티브 시나리오에서 K8s를 사용하여 배포합니다(컨테이너, 컨테이너 이미지, 매개변수, 버전 및 인스턴스에 대한 정보 포함).
접근: 배포가 외부 접근이 필요한 경우 Kubernetes Service를 생성하고 Apache APISIX Ingress의 라우팅 규칙을 자동으로 설정합니다.
관찰: 모니터링, 알람, 로깅 및 추적 분석과 같은 관찰 관련 설정을 수행합니다.
확장: KEDA(Kubernetes Event-driven Autoscaling)의 동적 확장 규칙을 모니터링 지표를 통해 선언합니다.

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

Zoom의 파이프라인 아키텍처 개요

프로젝트 관리

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

# 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를 참조하십시오.