Jiakaobaodian이 APISIX Ingress Controller를 선택한 이유

Qiang Zeng

September 29, 2022

Case Study

Kubernetes(줄여서 K8s)의 보편화로 인해, 공식 기본 NGINX Ingress Controller 외에도 더 많은 선택지가 생겼으며, Apache APISIX Ingress Controller 또한 많은 기업들에게 인기 있는 선택지가 되었습니다. 점점 더 많은 기업들이 자신들의 Ingress Controller를 APISIX Ingress Controller로 교체하고 있습니다.

배경

2011년에 설립된 Wuhan Mucang Technology Co., Ltd는 Jiakaobaodian과 같은 수십 개의 자동차 애플리케이션을 주요 제품으로 하고 있습니다. 10년 이상의 역사를 가진 이 회사는 기술 트렌드를 따라 2019년부터 클라우드 네이티브를 도입하기 시작했으며, 회사 내 다양한 프로젝트가 Kubernetes를 기반으로 진행되고 있습니다.

하지만 당시 K8s가 막 등장한 시기였기 때문에 트래픽 진입 포털로 선택할 수 있는 옵션이 많지 않았습니다. 따라서 우리는 거의 4년 동안 기본 Ingress Controller인 NGINX Ingress Controller를 사용했습니다. 그러나 그 기간 동안 NGINX Ingress Controller가 더 이상 우리의 요구를 충족시킬 수 없다는 것이 점점 명확해졌고, 이로 인해 새로운 선택을 해야 했습니다. 주요 Ingress Controller들을 비교한 후, 우리는 Apache APISIX를 회사의 진입 게이트웨이로 사용하기로 결정했습니다.

NGINX Ingress Controller의 문제점

회사의 서비스는 HTTP 프로토콜과 TCP 프로토콜을 사용하며, NGINX Ingress Controller를 통해 TCP 프록시를 구성하는 방법을 정확히 아는 것은 운영 및 유지보수 엔지니어뿐이었습니다. 그러나 운영 및 유지보수 인력은 제한적입니다. 따라서 개발 팀에게 NGINX의 기본적인 작업과 구성을 일부 위임하여 운영 및 유지보수 비용을 절감하는 것이 가장 좋습니다.

이 외에도 우리는 다음과 같은 문제를 겪었습니다:

  • 일부 구성 변경 시 재로드가 필요함;
  • TCP 프록시 사용 비용이 높으며, 모든 종류의 트래픽 시나리오를 커버할 수 없음;
  • 라우팅 또는 트래픽 작업은 annotations로만 정의할 수 있으며, 의미론적으로 구성 정의 및 재사용이 불가능함;
  • 리라이트, 서킷 브레이킹, 요청 전송 등의 작업이 annotations를 통해 구현됨;
  • 관리 플랫폼이 부족하며, 운영 및 유지보수 직원이 YAML을 통해 작업해야 하므로 오류가 발생하기 쉬움;
  • 이식성이 낮음;
  • 컨테이너 플랫폼 통합에 불리함.

이러한 이유로, 우리는 기존의 Ingress Controller를 새로운 것으로 교체하기로 결정했습니다.

APISIX Ingress Controller를 선택한 이유

우리는 Apache APISIX와 다른 Ingress Controller를 조사하고, 성능, 사용 편의성, 확장성, 플랫폼 통합 측면에서 비교한 후, APISIX Ingress Controller를 K8s 트래픽 진입 게이트웨이로 선택했습니다. 그 이유는 다음과 같습니다.

  • 우수한 확장성;
  • 구성 핫 로딩 지원;
  • 높은 성능;
  • 다양한 플러그인;
  • 자체 개발 컨테이너 플랫폼과의 통합을 위한 CRD 지원.

전체 아키텍처

이제 전체 게이트웨이 아키텍처를 살펴보겠습니다. 실제 비즈니스 시나리오에서 사용자는 먼저 SLB(Server Load Balancer)를 통해 트래픽을 전달하고, 트래픽이 K8s에 진입하면 각 서비스가 APISIX 클러스터를 통해 호출됩니다. 또한 게이트웨이 측에서 많은 일반적인 기능(카나리 릴리스, 흐름 제어, API 서킷 브레이킹, 트래픽 보안 제어, 요청/응답 트래픽 제어 등)을 구현하여 서비스 관리를 통합하고, 비즈니스의 복잡성을 줄이며 비용을 절감합니다.

아키텍처 다이어그램

배포 방법

우리의 비즈니스는 다양한 클라우드 플랫폼(Huawei Cloud, Tencent Cloud, Alibaba Cloud)에 배포되어 있으며, APISIX Ingress Controller가 지원하는 Helm Chart를 통해 비즈니스를 빠르게 온라인으로 전환할 수 있습니다. APISIX Ingress Controller를 사용하면서 개선할 수 있는 기능을 발견하면, 커뮤니티에 PR을 제출하여 기능 업데이트 및 반복을 돕기도 합니다. 실제 배포 과정에서 우리는 비즈니스 특성에 맞게 일부 구성을 사용자 정의했습니다. 예를 들어:

  • K8s를 통해 NameSpace를 생성하고, APISIX와 APISIX Ingress Controller를 다른 NameSpace에 배포하여 제품 라인과 서비스 중요도에 따라 트래픽을 분리;
  • APISIX initContainer에서 Linux TCP 커널 매개변수 최적화;
  • 제품 라인과 서비스 중요도에 따라 트래픽을 분리해야 하므로, K8s의 ClassName 정보를 구성해야 함.

다양한 제품 라인과 중요도에 따라 트래픽을 분리함으로써, 소프트웨어 장애로 인한 손실을 최소화할 수 있습니다.

CRD를 사용한 자체 개발 컨테이너 플랫폼 통합

APISIX Ingress Controller는 현재 많은 CRD 리소스를 지원하므로, CRD 리소스를 사용하여 APISIX Ingress Controller를 자체 컨테이너 플랫폼과 통합할 수 있습니다. 그러나 APISIX가 Java Client를 제공하지 않기 때문에, K8s에서 제공하는 코드 생성 도구를 사용하여 Model을 생성하고 CustomObjectApi를 사용하여 CRD를 관리합니다. ApisixRoute 객체는 컨테이너 플랫폼 애플리케이션과 연결되며, 코어 객체와 구조화되어 있어 운영 직원과 프로젝트 관리자가 컨테이너 플랫폼에서 작업할 수 있습니다.

적용 시나리오

인증

Apache APISIX를 사용하기 전에, 우리는 Istio 게이트웨이를 기반으로 인증을 구현했습니다. Apache APISIX로 마이그레이션한 후, forward-auth 플러그인을 사용하기로 결정했습니다. 이 플러그인은 인증 및 권한 부여 로직을 외부 인증 서비스로 옮기는 방식입니다. 사용자의 요청은 게이트웨이를 통해 인증 서비스로 전달되며, 인증 서비스가 20x가 아닌 상태로 응답하면 원래 요청이 차단되고 결과가 대체됩니다. 이렇게 하면 인증 실패 시 사용자 정의 오류 보고서를 반환하거나 사용자를 인증 페이지로 리디렉션할 수 있습니다.

클라이언트가 애플리케이션에 요청을 보내면, 먼저 APISIX의 forward-auth 플러그인에 의해 처리되고, forward-auth를 통해 외부 인증 서비스로 요청이 전달되며, 결과는 최종적으로 APISIX 게이트웨이로 반환됩니다. 인증이 성공하면 클라이언트는 정상적으로 서비스를 요청할 수 있습니다. 인증이 실패하면 오류 코드가 반환됩니다.

흐름 제어

회사의 비즈니스 특성상, 매년 5~6개월 동안 피크 트래픽이 발생합니다. 요청이 너무 많아지면 수동으로 용량을 확장해야 하지만, 요청이 쌓이면 서비스가 확장 후 시작되지 않을 수 있어 전체 링크가 무너질 수 있습니다. 따라서 클러스터의 흐름과 속도를 제한해야 합니다.

따라서 우리는 APISIX의 limit-conn, limit-req, limit-count 플러그인을 사용하여 요청을 제한하고 무너짐을 방지합니다. 플러그인을 수정하여 흐름과 속도를 제한하는 것이 더 쉽고, APISIX의 핫 로딩 메커니즘 덕분에 플러그인을 구성할 때 재시작할 필요가 없으므로 즉시 적용됩니다. 트래픽을 제어함으로써 일부 악의적인 공격을 막고 시스템 보안을 보호할 수도 있습니다. 또한 K8s 플랫폼에서 HPA(Horizontal Pod Autoscaler)를 구현하여 트래픽 양이 너무 많거나 적을 때 자동으로 확장 및 축소되도록 하며, APISIX 흐름 및 속도 제한 플러그인을 사용하여 대규모 무너짐을 방지합니다.

관측 가능성

관측 가능성 측면에서, 우리는 현재 SkyWalking을 통해 플랫폼 전반의 트래픽을 모니터링합니다. APISIX SkyWalking 플러그인은 기존 SkyWalking 플랫폼과 직접 인터페이스할 수 있으며, SkyWalking UI를 통해 성능을 소모하는 링크 노드를 쉽게 확인할 수 있습니다. 또한 모니터링 포인트가 게이트웨이 측에 위치해 있어 사용자와 더 가깝기 때문에 시간 소모 지점을 쉽게 확인할 수 있습니다.

kafka-logger 플러그인을 사용하면, APISIX에서 생성된 접근 및 오류 로그를 Apache Kafka 클러스터에 직접 기록할 수 있습니다. 이 장점 덕분에, APISIX 클러스터는 상태 없이 수평적으로 확장할 수 있으며, 디스크 포맷, 로그 회전 또는 기타 작업을 수행할 필요가 없습니다. 로그를 로컬에 저장하면 추가 작업이 필요하며 빠른 확장을 달성할 수 없습니다. 로그를 Apache Kafka 클러스터로 전송함으로써, 로그를 실시간으로 분석하고 분석 결과를 기반으로 시스템을 개선 및 최적화할 수 있습니다.

결론

APISIX Ingress Controller가 막 출시되었기 때문에, 아직 많은 적용 시나리오가 없습니다. 우리는 계속해서 적용 시나리오를 깊이 파고들어 커뮤니티에 더 많은 사용 예시를 제공할 것입니다.

점점 더 많은 팀들이 프로덕션 환경에서 Apache APISIX Ingress Controller를 사용하고 있습니다. 만약 여러분도 APISIX Ingress Controller를 사용하고 있다면, 커뮤니티에 여러분의 사용 사례를 공유해 보시기 바랍니다.

Tags:
APISIX Ingress Controller
NGINX
Comparison to Competitors