Horizon Robotics의 Ingress Controller 탐구: Traefik에서 APISIX로
Xin Zhang
October 10, 2022
자동차 산업에서 대부분의 기업들은 자율 주행과 신에너지로 전환하고 있습니다. 특히 자율 주행 분야에서는 각 기업이 자율 주행 모델의 개발과 훈련을 완료하기 위해 많은 자원을 투자하고 있습니다.
이 과정에서 제품이 빠르게 반복되는 동안 비즈니스의 안정성과 효율성을 어떻게 보장할 수 있을까요?
이 글에서는 Horizon Robotics의 AI 개발 플랫폼을 예로 들어, API 게이트웨이인 Apache APISIX와 Ingress Controller가 Horizon Robotics의 R&D 팀이 이 문제를 해결하는 데 어떻게 도움을 주었는지 살펴보겠습니다.
게이트웨이 비교
Traefik의 한계
APISIX Ingress Controller를 사용하기 전에, 비즈니스 시스템에서 사용하던 Ingress Controller는 Traefik1.x였지만 몇 가지 문제가 있었습니다.
- Traefik 1.x는 Ingress를 통해 라우팅 규칙을 구성하며, 일부 플러그인은 Annotation을 추가하여 구성해야 합니다. 이 방식으로는 현재 Ingress 아래의 모든 규칙에 플러그인을 추가할 수만 있고, 더 세분화된 구성을 할 수 없습니다.
- Traefik 1.x는 특정 규칙의 시각적 구성을 지원하지 않으며, 브라우저를 통해 요청 URL에 접근하여 특정 서비스를 직접 찾을 수 없습니다.
- Traefik의 기본 구성 파일(
ConfigMap
)은 속성이 적으며, 많은 기본 구성은 공식 문서를 참조해야 하고, 일부 매개변수는 NGINX 기본 구성과 일치하지 않아 유지 보수가 더 번거롭습니다.
위의 문제에 대응하여 Horizon Robotics의 기술 팀은 Ingress Controller를 교체하기로 결정했습니다. 선택 과정 초기에 팀은 Traefik을 2.0으로 업그레이드하여 위의 문제를 해결하는 것을 고려했지만, 새로운 CRD를 사용해야 하고 마이그레이션 비용이 높아 다른 Ingress Controller 솔루션도 시도해야 했습니다.
APISIX Ingress Controller의 장점
선택 초기에는 주로 Apache APISIX, Kong, Envoy를 비교했습니다. 그러나 다른 솔루션들은 기능이나 성능 면에서 기존 시나리오의 요구를 충족시키지 못했지만, APISIX Ingress는 이를 충족시켰습니다. 따라서 최종적으로 APISIX Ingress를 선택했습니다. 일반적인 기능 외에도 우리는 다음과 같은 점에 더 관심이 있었습니다.
- 풍부한 플러그인: 플러그인 생태계가 잘 갖춰져 있으며, APISIX가 지원하는 모든 플러그인을
apisix-ingress-controller
를 사용하여 선언적으로 구성할 수 있고,ApisixRoute
아래의 단일 백엔드에 대해 플러그인을 사용자 정의할 수 있습니다. - 시각적 구성: APISIX Dashboard를 통해 각
apisix route
를 확인할 수 있습니다. 또한 동일한 도메인이 여러namespaces
또는 YAML 파일에 구성된 경우, APISIX Dashboard와 함께 경로 접두사를 검색하여 충돌 시 빠르게 찾을 수 있습니다. - 세분화된 검증: APISIX Ingress Controller는 관리하는 CRD에 선언된 리소스를 검증합니다. CRD에 존재하지 않는 서비스가 선언된 경우, 오류 메시지는
ApisixRoute
의event
에 저장되고 변경 사항은 적용되지 않아 오용으로 인한 문제를 어느 정도 줄일 수 있습니다. - 풍부한 기능: APISIX는 핫 업데이트 및 핫 플러그인, 프록시 요청 재작성, 다중 인증, 다국어 플러그인 개발 등 다양한 기능을 지원합니다. 자세한 내용은 APISIX 기능을 참조하세요.
- 활발한 커뮤니티: 다른 오픈소스 솔루션의 커뮤니티와 비교했을 때, APISIX는 Slack, GitHub, 메일링 리스트에서 많은 활발한 유지 관리자와 기여자가 있습니다.
- 높은 성능: 아래 차트에서 볼 수 있듯이, Envoy의 부하 테스트와 비교했을 때 APISIX의 성능은 Envoy의 약 120%이며, 코어 수가 많을수록 QPS 차이가 더 큽니다.
전체 아키텍처
아래 아키텍처 다이어그램에서 볼 수 있듯이, APISIX Ingress는 모든 트래픽의 진입점 역할을 합니다. 명령줄 도구, 웹, SaaS 플랫폼 또는 OpenAPI를 통해 접근한 모든 트래픽은 APISIX Ingress를 통해 업스트림(비즈니스 서비스)으로 들어갑니다. 인증의 경우, 회사 자체적으로 전용 인증 서비스가 있기 때문에 APISIX의 forward-auth
플러그인을 사용하여 외부 인증을 구현했습니다.
게이트웨이 레이어에서는 모든 트래픽이 도메인 이름을 통해 들어오며, 트래픽은 먼저 LVS를 통과한 후 백엔드 APISIX 노드로 전달되고, APISIX는 라우팅 규칙에 따라 해당 Pod로 트래픽을 분배합니다. LVS에서는 APISIX Ingress의 기본 포트를 9180
에서 80
으로 변경하여 LVS가 APISIX Ingress를 직접 가리키도록 하여 트래픽 전달을 더 쉽게 했습니다.
시나리오
전체 아키텍처를 이해한 후, 현재 우리 회사가 APISIX Ingress로 구현하고 있는 몇 가지 시나리오를 공유하겠습니다.
대용량 파일 업로드
첫 번째는 대용량 파일 업로드 시나리오입니다. 일반적인 회사에서는 흔하지 않을 수 있지만, AI 모델 훈련을 하는 회사에서는 더 흔한 시나리오입니다. 이 시나리오는 주로 Horizon Robotics의 모델 훈련 시스템에서 R&D가 수집한 데이터를 네트워크를 통해 시스템에 업로드하는 경우이며, 데이터의 크기는 보통 수백 GB를 넘습니다. APISIX의 매개변수를 조정하지 않으면 업로드 데이터 양이 너무 많을 때 OOM이 발생합니다.
기본 client_body_buffer_size
가 1MB이기 때문에 버퍼가 가득 차면 임시 파일이 디스크에 기록되어 높은 디스크 IO를 유발합니다.
임시 파일이 기록되는 디렉토리를 공유 메모리(/dev/shm
)로 지정하면 다시 APISIX(캐시)가 높아집니다.
지속적인 디버깅 후, APISIX가 스트리밍 업로드를 활성화하지 않았기 때문이라는 것을 발견했습니다. 이 시나리오를 위해 APISIX 버전을 2.11에서 2.13으로 업그레이드하고 APISIX 매개변수를 조정했습니다. 먼저 APISIX ConfigMap
에서 proxy_request_buffering
매개변수를 off로 변경하여 스트리밍 업로드를 활성화했습니다. 두 번째로, APISIX Ingress Controller가 제공하는 CRD ApisixPluginConfig
에서 재사용 가능한 구성을 추출하고 이 시나리오가 필요한 경로에 대해 client_max_body_size
를 namespace
수준 구성으로 동적으로 설정했습니다.
멀티 클라우드 환경에서의 서비스 호출
멀티 클라우드 환경에서의 서비스 호출의 경우, 일부 비즈니스 트래픽은 먼저 로컬 IDC에 도달한 후 APISIX Ingress를 통해 Pod로 전달됩니다. Pod의 일부 서비스는 도메인 이름을 통해 AliCloud의 서비스에 접근합니다. 또한, 서비스가 다른 서비스를 호출하는 시나리오도 주로 멀티 클라우드 훈련을 위해 존재합니다. 사용자는 IDC를 진입점으로 선택하고 해당 클라우드 클러스터에 작업을 제출할 클러스터를 선택합니다.
forward-auth를 통한 외부 인증
APISIX Ingress를 처음 사용할 때, APISIX는 forward-auth
플러그인을 지원하지 않았기 때문에 apisix-go-plugin-runner를 기반으로 사용자 정의 플러그인을 정의했습니다. 그러나 이는 추가적인 gRPC 호출 계층을 생성하여 디버깅이 어렵고 로깅이 보이지 않게 만들었습니다. 올해 초 APISIX가 forward-auth 플러그인을 지원하기 시작하면서, 사용자 정의 플러그인을 공식 플러그인으로 교체하여 gRPC 호출 계층을 하나 줄이고 모니터링을 더 편리하게 했습니다.
애플리케이션 모니터링
애플리케이션 모니터링에서는 APISIX Prometheus
플러그인을 전역적으로 활성화하고 자체 비즈니스에 대한 디버깅과 최적화를 수행했습니다. 예를 들어, 실시간 동시 접속자 수, QPS, APISIX 실시간 API 성공률, APISIX 실시간 대역폭을 추가하여 APISIX를 더 세밀하게 모니터링할 수 있도록 했습니다.
요약
현재 우리는 일부 비즈니스 라인에 대해서만 Apache APISIX Ingress Controller를 트래픽 게이트웨이로 사용하고 있으며, 다른 비즈니스도 출시하여 커뮤니티에 더 풍부한 애플리케이션 시나리오를 제공할 예정입니다. 만약 Ingress Controller 솔루션을 비교 중이라면, 이 글이 몇 가지 힌트를 제공할 수 있기를 바랍니다. 점점 더 많은 사용자들이 Apache APISIX Ingress를 프로덕션 환경에서 사용하고 있으며, 만약 APISIX Ingress를 사용 중이라면 커뮤니티에서 사용 사례를 공유해 주세요.