Alternative to NGINX That Makes Your Life Easier: Apache APISIX

Zexuan Luo

Zexuan Luo

September 15, 2022

Products

API는 디지털 세계에서 필수적인 부분이며, API 게이트웨이는 API의 첫 번째 관문으로서 그 보안과 안정성을 보호하는 중요한 역할을 맡고 있습니다. 많은 소프트웨어 엔지니어와 팀들이 이전에 NGINX를 사용했지만, NGINX의 병목 현상과 제약에 불편을 느꼈습니다. 더 나은 대안이 있을까요?

NGINX의 훌륭한 대안은 Apache APISIX입니다. 그렇다면 Apache APISIX는 무엇일까요?

Apache APISIX란?

APISIX Word Cloud

Apache APISIX는 고성능, 동적, 전체 트래픽 API 게이트웨이입니다. Apache APISIX의 네 가지 주요 특징은 다음과 같습니다:

  1. Apache 속성: APISIX는 오픈 소스이며, Apache Software Foundation의 최상위 프로젝트입니다. ElasticSearch와 MongoDB가 그랬던 것처럼 중간에 오픈 소스 라이선스를 변경할 수 없습니다. APISIX는 Apache Software Foundation(ASF)에 속해 있기 때문에 더 이상 회사나 개인의 프로젝트가 아닙니다.
  2. 고성능: APISIX는 OpenResty(NGINX 배포판)를 기반으로 개발되었기 때문에, APISIX는 NGINX 자체의 강력한 성능을 상속받았습니다.
  3. 동적: NGINX가 견고한 기반 아키텍처를 제공한다면, OpenResty는 Lua를 사용하여 NGINX의 동작을 제어할 수 있게 함으로써 NGINX에 더 많은 가능성을 추가합니다. 그리고 APISIX는 그 유연성과 다른 시스템과의 강력한 연결성을 통해 완전히 동적인 API 게이트웨이가 됩니다. Flow Software Architecture
  4. 실시간: APISIX는 설정을 etcd에 저장합니다. 이는 etcd RESTful API를 통해 설정 변경을 실시간으로 모니터링하고 얻을 수 있다는 장점이 있습니다. etcd 자체가 분산 KV 데이터베이스이기 때문이며, Kubernetes도 설정을 저장하기 위해 etcd를 사용합니다. NGINX는 설정을 정적 파일로 저장하며, 설정이 업데이트되면 NGINX를 다시 로드하는 데 시간이 오래 걸립니다.

Apache APISIX vs NGINX

APISIX가 NGINX를 기반으로 개발되었다고 언급했으니, APISIX와 NGINX의 차이점이 무엇인지 궁금할 수 있습니다.

먼저, APISIX와 NGINX의 비교는 동등한 비교가 아니라는 점을 주목해야 합니다. 결국 NGINX는 경량 프록시이고, APISIX는 제품의 기능을 더 성숙하게 만드는 데 초점을 맞추고 있습니다. 또한, APISIX는 NGINX를 기반으로 재개발되었기 때문에 더 많은 기능을 가지고 있습니다.

만약 NGINX를 게이트웨이로 사용하고 있다면, APISIX의 다음 두 가지 장점이 더 깊은 인상을 줄 것입니다.

더 유연한 설정

NGINX의 설정 파일과 비교하여, APISIX는 다양한 설정 방법을 제공합니다. 예를 들어:

  • HTTP API를 통해 APISIX를 설정할 수 있습니다. 설정은 etcd에 기록된 후 etcd에 의해 각 노드에 동기화됩니다;
  • APISIX Dashboard를 통해 설정할 수 있습니다. APISIX Dashboard에서는 그래픽 시각화를 통해 더 명확하게 설정할 수 있습니다;
  • etcd와 같은 상태 저장 방식을 사용하고 싶지 않다면, K8s와 같은 정적 파일을 사용할 수 있습니다. APISIX는 로컬 YAML 파일에서 개별 설정을 가져오는 것도 지원합니다;
  • K8s에 APISIX를 배포한다면, APISIX Ingress Controller를 사용하여 CRD에서 발행된 설정을 얻을 수 있습니다;
  • Istio의 데이터 플레인으로 APISIX를 배포한다면, xDS를 인식하여 Istio에서 발행된 설정을 얻을 수도 있습니다.

더 나은 확장성

NGINX도 NJS를 도입하여 동적 제어를 가능하게 했지만, APISIX의 확장성만큼 이상적이지는 않습니다.

APISIX는 LuaJIT로 확장할 수 있으며, Go, Java, Python, Node.js 등과 같은 언어로 작성된 외부 플러그인을 실행하기 위한 out-process Plugin Runner도 지원합니다.

Multi-Language Architecture

또한, APISIX 2.11부터 Wasm 플러그인을 실행할 수 있습니다. 이 기능을 통해 Rust, TinyGo 등과 같은 언어로 APISIX 플러그인을 작성한 후 Wasm 코드로 컴파일하여 APISIX에서 실행할 수 있습니다.

APISIX에서 Wasm 플러그인과 Lua 플러그인을 설정하는 것은 기능적으로 거의 차이가 없습니다. 결과적으로 Lua의 네이티브 구현과 유사한 성능을 달성하고 고급 언어의 개발 효율성을 달성할 수 있습니다.

Apache APISIX의 주요 이점은 무엇인가요?

위에서 설명한 장점들은 꽤 좋지만, APISIX의 가장 중요한 장점은 아닙니다. APISIX의 가장 큰 장점은 많은 프로젝트와 얽혀 있는 생태계 네트워크입니다.

APISIX's Ecosystem

  • 인증 수준에서, APISIX는 OIDC 및 LDAP와 같은 프로토콜을 지원합니다. 동시에 Keycloak, Casdoor, Casbin, OPA 등과 같은 여러 인증 서비스 또는 프레임워크와 통합할 수 있습니다.
  • 관찰 가능성 수준에서, APISIX는 Clickhouse, Datadog, Splunk, Apache Kafka, Apache RocketMQ 등과 같은 여러 로그 도구와의 연결을 지원합니다. 또한 Prometheus를 통해 풍부한 메트릭을 노출하여 OpenTracing, OpenTelemetry, Apache Skywalking 등과 같은 여러 추적 시스템을 지원합니다.
  • 서비스 발견 수준에서, APISIX는 Nacos, Eureka, Consul, Zookeeper에서 업스트림 주소를 얻는 것뿐만 아니라 DNS(A/AAAA 레코드 또는 SRV 레코드)에서도 얻을 수 있습니다. 또한, APISIX를 K8s Ingress Controller로 사용한다면, Ingress 리소스에서 해당 설정을 얻을 수 있습니다(APISIX는 K8s Gateway API 사양을 지원합니다).

현재 APISIX는 여전히 빠르게 발전하는 단계에 있습니다. 시간이 지남에 따라 APISIX는 점점 더 많은 프로젝트와 통합되어 협력의 가능성을 열고 기존 시스템과의 통합 작업을 크게 단순화할 것입니다.

연결하려는 서비스가 APISIX 플러그인 생태계에 없더라도, 기존 플러그인을 사용하여 비즈니스에 더 특화된 기능을 달성할 수 있습니다.

어떤 API 게이트웨이를 선택해야 할까요?

물론, 적합한 게이트웨이를 선택하려면 실제 비즈니스 상황도 고려해야 합니다.

이미 비즈니스 애플리케이션 앞에서 NGINX를 프록시로 사용하고 있고, 일부 로직이 NGINX에 배치되어 있다면, APISIX가 최선의 선택이 될 것입니다. APISIX는 NGINX를 기반으로 개발되었기 때문에, 필요에 따라 NGINX를 APISIX로 원활하게 마이그레이션할 수 있습니다.

만약 게이트웨이를 사용한 적이 없고 팀의 상황에 맞는 오픈 소스 API 게이트웨이 프로젝트를 선택하려면, 다음 사항에 주목해야 합니다:

  1. 업데이트 빈도가 충분히 좋은지. 각 프로젝트의 활동을 관찰하여 잘 유지되는 API 게이트웨이 프로젝트를 선택할 수 있습니다. 아무도 하락세를 타는 프로젝트를 선택하고 싶어하지 않기 때문입니다. Contributor Over Time 그래프를 통해 프로젝트 활동을 파악할 수 있습니다.
  2. 프로젝트의 기능이 완전한지. 선택한 게이트웨이가 팀의 현재 및 미래 비즈니스 요구를 충족하지 못하고, 프로젝트가 개발 작업(예: 설정 관리, 내부 서비스와의 연결)을 추가한다면 신중히 고려해야 합니다.
  3. 프로젝트의 복잡한 기술 지표가 잘 수행되는지, 예를 들어 QPS, 지연 시간, 메모리 사용량이 비즈니스 요구를 충족하는지. 일반적으로 게이트웨이를 혁신적으로 최적화하는 것은 어렵습니다. 따라서 이러한 복잡한 지표를 충족하지 못하는 게이트웨이는 나중에 어떻게 반복하더라도 돌파구를 만들기 어렵습니다.
  4. 팀에 API 게이트웨이를 학습하고 유지할 충분한 인력과 시간이 있는지. 결국 기술 결정은 순수한 기술 활동이 아닙니다.

물론, 다른 API 게이트웨이를 사용했지만 현재 비즈니스 시나리오를 충족하지 못한다면, Apache APISIX를 선택지 중 하나로 고려할 수 있습니다.

NGINX에서 Apache APISIX로 마이그레이션하는 방법

이 글을 읽고 기존 NGINX를 APISIX로 교체하기로 결정했다면, 현명한 선택입니다!

하지만 마이그레이션하기 전에, 현재 사용 중이거나 사용하려는 제품 기능을 다시 한 번 점검해야 합니다. 일반적으로 이러한 기능은 세 가지 범주로 나눌 수 있습니다:

  1. 직접 교체 가능. APISIX는 사용자가 NGINX 설정을 직접 사용할 수 있도록 허용하므로, NGINX의 대부분의 전역 설정은 APISIX에서 재사용할 수 있습니다. 애플리케이션 수준 설정은 APISIX Routes로 교체할 수 있습니다;
  2. 조정이 필요한 경우, 예를 들어 메트릭 변경;
  3. 추가 개발이 필요한 경우

필요한 개발을 완료한 후, 실제 비즈니스 시나리오에서 NGINX를 APISIX로 점진적으로 교체할 수 있습니다. 원활한 마이그레이션 과정에서 다음 세 가지 질문을 고려해야 합니다:

  1. 클라이언트 요청을 APISIX로 프록시하는 방법은?
  2. 동등한 설정을 APISIX와 NGINX에 어떻게 배치할 것인가?
  3. APISIX와 NGINX가 노출한 메트릭을 어떻게 처리할 것인가?

위의 세 가지 질문과 실제 애플리케이션 환경을 고려해야 합니다. 마지막으로, 버그에 대한 "롤백 계획"을 미리 준비하는 것을 잊지 마세요.

이 글을 통해 Apache APISIX의 강력함을 이해했을 것입니다. Apache APISIX를 API 게이트웨이로 사용해 보세요!

Tags:
APISIX Basics
NGINX
Comparison to Competitors