Apache APISIX 3.0: 오픈소스 API 게이트웨이의 11가지 주요 특징
오픈소스 API 게이트웨이인 Apache APISIX 버전 3.0이 출시됩니다! 주요 11가지 기능을 간략히 소개합니다.
API 게이트웨이는 오랫동안 핵심 구성 요소로 자리 잡아 왔습니다. 속도 제한, 인증 (예: Keycloak을 사용하여 API 보안 설정), 관측 가능성 등 비즈니스 수준의 다양한 기능을 제공하는 데 주력해 왔습니다.
API 게이트웨이 Apache APISIX
Apache APISIX는 클라우드 네이티브 환경과 마이크로서비스에서 기업이 직면하는 새로운 문제를 해결하기 위해 탄생했습니다. 예를 들어, 완전 동적 기능을 통해 비즈니스 트래픽의 자동 확장을 제공하고, 한 번의 수정으로 클러스터 관리를 더욱 편리하게 달성할 수 있습니다.
따라서 APISIX의 아키텍처 설계에서는 데이터 플레인과 컨트롤 플레인이 분리되어 완전 동적 및 클러스터 관리를 달성하며, 이는 주로 etcd 컴포넌트를 통해 이루어집니다.
APISIX는 etcd에 라우팅 및 플러그인 관련 설정을 저장하고 관리합니다. 위 그림에서 볼 수 있듯이, Admin API (컨트롤 플레인)에서의 설정은 etcd에 저장되며, 왼쪽의 데이터 플레인은 주로 etcd의 변경 사항을 모니터링합니다. 데이터 플레인은 설정 파일을 수정할 필요 없이 빠르게 변경 사항을 관찰할 수 있습니다.
하지만 이러한 문제만 해결하는 것으로는 충분하지 않습니다. 업스트림과 다운스트림 모두에서 요청을 받는 미들웨어로서, API 게이트웨이는 기업 아키텍처에서 트래픽 입구와 서비스 계층 간의 연결로서 중요한 위치를 차지합니다. API 게이트웨이의 역할은 사용자의 비즈니스 수준에서만 요청을 받는 데이터베이스와는 다릅니다.
비즈니스 수준의 요구 사항 외에도, API 게이트웨이는 사용자 정의 및 통합에 대한 요구 사항도 있습니다. 따라서 APISIX를 사용할 때 개발자가 사용자 정의 개발을 더 쉽게 할 수 있도록 하는 것이 APISIX가 해결하는 또 다른 중요한 문제점이며, 개발자가 코딩하는 데 필요한 문턱을 낮춥니다.
APISIX에서는 주로 Lua를 통해 플러그인을 개발하며, LuaJIT (Lua의 Just-In-Time 컴파일러)를 사용하여 컴파일된 코드의 성능이 충분히 좋도록 보장합니다.
Lua에 익숙하지 않다면, Plugin Runner를 사용하여 익숙한 프로그래밍 언어로 APISIX 플러그인을 개발할 수 있습니다. 또한 Wasm을 APISIX에 내장하여 Wasm 바이트코드를 컴파일하여 APISIX에서 실행할 수 있습니다. 결과적으로 사용자는 Lua, Go, Python, Wasm 등을 사용하여 APISIX에서 사용자 정의 플러그인을 만들 수 있습니다.
APISIX의 아키텍처와 성능 우위 덕분에, APISIX의 전 세계 사용자 증가는 출시 이후 3년 동안 기대를 훨씬 뛰어넘었습니다. 예를 들어, WPS, Sina Weibo, iQiyi와 같은 대형 기술 기업들은 매일 수십억 건의 API 요청을 처리하는 기업급 사용자입니다. 또한 NASA와 European Factory Platform과 같은 과학 연구 기관도 APISIX를 사용하고 있습니다.
APISIX 3.0의 11가지 새로운 하이라이트
APISIX는 2022년 초에 새로운 3.0 로드맵을 제안했습니다. 버전 3.0에서는 사용성과 생태계에 초점을 맞춘 반복 및 업데이트가 이루어질 것입니다.
APISIX 3.0은 2022년 10월 말에 공식 출시되었습니다. 흥미로운 새로운 하이라이트를 간략히 살펴보겠습니다!
1. ARM64 완전 지원
ARM64는 클라우드 제조업체들에게 매우 주류 서버 아키텍처 선택이 되었습니다. AWS Graviton, GCP Tau T2A부터 Huawei Kunpeng 및 기타 제품에 이르기까지 다양한 클라우드 제조업체들이 Arm 아키텍처 기반 서버를 출시하기 시작했습니다. 다음 그래프는 인기 있는 Arm 기반 서버에서 APISIX의 스트레스 테스트 성능을 보여줍니다:
현재 데이터에 따르면, Arm 기반 서버의 성능은 x86보다 약간 더 좋습니다. 시대의 기술적 흐름에 맞추기 위해, APISIX는 ARM64에서도 다양한 기능을 원활하게 실행할 수 있도록 포괄적인 CI 회귀 테스트를 수행했습니다.
2. AI 플레인
Apache APISIX는 3.0 버전에서 AI 플레인을 추가하여 성능을 30% 향상시켰습니다(스트레스 테스트에서의 QPS로 측정). AI 플레인은 사용자의 라우트 및 플러그인 설정, 로그 메트릭 등 포괄적인 데이터를 활용하여 데이터 플레인 구성을 동적으로 최적화합니다. 예를 들어, 다음 세 가지 시나리오는 AI 플레인에 의해 자동으로 최적화될 수 있습니다:
- 매칭 요구 사항이 단순한 경우(예: uri 또는 host만 포함), 캐시를 활성화하여 라우트 매칭 프로세스를 가속화합니다.
- 플러그인이 없는 경우, 업스트림과 관련된 코드만 실행됩니다.
- 업스트림 노드가 하나만 있고 다른 구성 옵션이 활성화되지 않은 경우, 업스트림이 경량 방식으로 구성됩니다.
AI 플레인은 트래픽 처리에 새로운 가능성을 열어줍니다. 앞으로 업스트림 서비스의 자동 워밍업 및 보안 위협 탐지 등이 AI 플레인을 통해 처리될 수 있습니다.
3. gRPC 클라이언트 추가
버전 3.0에서 Apache APISIX는 새로운 core.grpc 모듈을 지원합니다. 그러나 NGINX와 OpenResty에 익숙하다면, 이들이 gRPC에 대한 지원이 매우 제한적이며, 리버스 프록시나 로드 밸런싱과 같은 기본 기능만 제공한다는 것을 알 수 있습니다.
APISIX는 현재 2.x 버전에서 gRPC와 HTTP 프로토콜 간의 변환을 이미 구현했습니다. 버전 3.0에서 Apache APISIX는 새로운 gRPC 클라이언트를 추가하여 개발자가 추가 컴포넌트를 도입하거나 서비스 제공자가 다른 HTTP 인터페이스를 사용할 필요 없이 직접 타사 gRPC 서비스를 호출할 수 있도록 하여 프로세스를 훨씬 간소화합니다.
4. Admin API 재설계
현재 APISIX를 사용할 때, APISIX의 응답 본문에 많은 의미 없는 데이터가 혼합되어 있는 것을 발견할 수 있습니다. 예를 들어, 일부 etcd 반환 값이 클라이언트에 직접 전달되며, 전혀 다듬어지지 않았습니다. 또한, 전체 응답 본문의 아키텍처 설계가 이상적이지 않으며, 많은 중복 필드가 있습니다.
APISIX 3.0 버전에서는 응답 본문의 구조가 개선되었습니다. 또한, 새로운 설계는 전체 요청 형식과 반환 본문을 더 RESTful하게 만들어 사용자가 최신 버전의 Admin API를 더 쉽게 사용할 수 있도록 합니다. 물론, 이 과정에서 매개변수를 통해 어떤 버전의 Admin API를 사용할지 설정할 수 있으므로, 호환되지 않는 버전으로 업그레이드하는 것에 대한 두려움에서 벗어날 수 있습니다.
5. 데이터 플레인(DP)과 컨트롤 플레인(CP) 분리
APISIX는 지난 2년 동안 여러 보안 관련 취약점을 겪었습니다. 대부분의 취약점의 근본 원인은 기본 배포 모드에서 DP와 CP가 함께 배포되기 때문입니다. 따라서 데이터 플레인에 보안 취약점이 존재하면, 공격자가 DP를 통해 CP를 직접 침입하여 다른 모든 DP에 영향을 미칠 수 있습니다.
따라서 버전 3.0에서는 배포 모드 구성을 지원하며, 기본 배포 모드는 traditional로, DP와 CP가 함께 배포됩니다. 물론, 새로운 배포 모드에서는 속성을 data_plane 또는 control_plane로 설정하여 분리할 것을 권장합니다.
분리되면 위에서 언급한 보안 위험을 해결할 수 있을 뿐만 아니라, DP와 CP의 기능 반복도 서로 영향을 미치지 않고 더 쉽게 관리할 수 있습니다.
6. 서비스 디스커버리 지원 개선
현재 버전에서 APISIX는 Apache ZooKeeper, Consul, Nacos 등 많은 서비스 디스커버리 컴포넌트와의 통합을 지원합니다. 하지만 현재 이러한 통합은 모두 데이터 플레인에서 이루어집니다. DP에 많은 노드가 있는 경우, 이는 다음 서비스 디스커버리 컴포넌트에 큰 부담을 줍니다. 동시에, 사용자의 실제 생산 환경에서는 Consul KV 또는 DNS 통합과 같은 간단한 통합과 건강 검사와 같은 완전한 기능 통합을 원합니다.
따라서 APISIX 3.0에서는 서브 프로젝트 APISIX-SEED를 추가하여 컨트롤 플레인 수준에서 서비스 디스커버리 지원을 달성하고 서비스 디스커버리 컴포넌트의 부담을 줄였습니다.
7. xRPC 프레임워크 추가
현재 버전의 APISIX는 TCP 프록시를 지원하지만, 순수 TCP 프로토콜 프록시만으로는 충분하지 않은 경우가 있습니다. 사용자는 특정 애플리케이션 프로토콜에 대한 프록시가 필요합니다. 예를 들어, Redis 프록시, Kafka 프록시 등이 있습니다. 왜냐하면 프로토콜이 인코딩 및 디코딩된 후에야 일부 기능을 구현할 수 있기 때문입니다.
따라서 버전 3.0에서 APISIX는 xRPC라는 전송 계층 프로토콜 확장 프레임워크를 구현하여 개발자가 특정 애플리콜을 사용자 정의할 수 있도록 합니다. xRPC를 기반으로, 개발자는 Lua 코드를 통해 요청과 응답을 인코딩 및 디코딩한 후, 프로토콜 내용을 이해한 기반으로 오류 주입, 로그 보고, 동적 라우팅 등을 구현할 수 있습니다.
xRPC 프레임워크를 기반으로, APISIX는 여러 주류 애플리케이션 프로토콜에 대한 프록시 구현을 제공할 수 있습니다. 동시에, 사용자는 이 프레임워크를 기반으로 자신만의 사적인 TCP 기반 애플리케이션 프로토콜을 지원할 수 있으며, 이를 통해 HTTP 프로토콜 프록시와 유사한 정밀한 그레이닝과 높은 수준의 애플리케이션 계층 제어를 가질 수 있습니다. 또한, 다양한 프로토콜 위에서 공통 요소를 추상화하여 관련 플러그인 기능을 구현할 수 있으므로, 다른 프로토콜도 이러한 기능을 공유할 수 있습니다.
8. 전송 계층 프로토콜에 대한 더 많은 관측 가능성 지원
APISIX는 항상 관측 가능성 지원에 큰 투자를 해왔으며, Zipkin, Apache SkyWalking, Datadog 등 거의 모든 관측 가능성 컴포넌트를 지원합니다. 다양한 로깅 컴포넌트도 지원되지만, 대부분 애플리케이션 계층에서 이루어집니다.
Apache APISIX는 3.0에서 전송 계층 관측 가능성 지원을 더 추가할 것입니다. 예를 들어, Prometheus 및 다양한 로그에 대한 지원이 추가되어 사용자가 애플리케이션 계층 트래픽의 문제를 쉽게 관찰할 수 있을 뿐만 아니라, 전송 계층 트래픽의 운영 상태도 확인할 수 있게 됩니다.
9. OpenAPI 사양 통합
API는 설계부터 코딩, 테스트, 배포에 이르는 전체 개발 생명주기에 걸쳐 관련된 요소입니다. APISIX 3.0에서 Apache APISIX는 표준 OpenAPI 3.0 사양을 지원할 것입니다.
따라서 API 설계 및 테스트 소프트웨어에서 API를 관리하는 경우, APISIX의 데이터를 내보내고 가져오는 것으로 쉽게 관리하고 유지할 수 있습니다. 동시에, APISIX의 다양한 API도 OpenAPI 3.0 사양을 통해 다른 시스템으로 전송되어 사용될 수 있습니다.
또한, APISIX 3.0은 Postman 관련 사용자 정의 형식(Postman Collection Format v2)도 지원하여 두 시스템 간의 데이터 전송을 가능하게 하여 통합을 더 쉽게 만듭니다.
10. 게이트웨이 API 및 서비스 메시 완전 지원
게이트웨이 API에 대한 지원은 APISIX Ingress Controller에서 시작되었으며, 최신 1.5 릴리스에서 거의 모든 게이트웨이 API 구성을 지원합니다.
이 경우, APISIX Ingress는 게이트웨이 API를 사용하여 구성할 수 있으며, 이는 다른 데이터 플레인 간에 전환할 수 있음을 의미합니다. 올해 말까지 APISIX Ingress는 게이트웨이 API에 대한 완전한 지원과 추가 전송 및 애플리케이션 계층 기능을 제공할 것입니다.
대부분의 서비스 메시 솔루션과 달리, APISIX의 서비스 메시 솔루션은 데이터 플레인에서 우위를 가집니다(APISIX 자체의 높은 성능 덕분에). 따라서 컨트롤 플레인 선택 시, 커뮤니티의 일부 주류 솔루션과 호환되기를 바랍니다. 마지막으로, xDS 프로토콜을 사용하여 Istio와 통합하고, 얻은 구성을 APISIX의 xDS 구성 센터에 기록하여 APISIX가 특정 라우팅 규칙을 생성하여 해당 라우팅 요청을 완료하도록 합니다.
이 솔루션은 전체 서비스 메시를 더 가볍게 만들 뿐만 아니라, APISIX의 높은 확장성으로 인해 사용자 정의 개발 및 마이그레이션을 더 편리하게 만듭니다.
11. 더 많은 생태계와 통합
위에서 언급한 OpenAPI 표준 외에도, 버전 3.0에서는 OpenFunction, ClickHouse, Elasticsearch, SAML, CAS 등 많은 생태계 플러그인이 추가되어 인증, 보안, 관측 가능성에 대한 더 많은 지원을 통합할 것입니다.
흥미로운 플러그인 중 하나인 workflow는 트래픽 스케줄링을 위해 사용됩니다: 트래픽 제어 수준에서 일부 세분화된 처리를 할 수 있습니다.
curl http://127.0.0.1:9180/apisix/admin/routes/1 \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
"uri":"/hello/*",
"plugins":{
"workflow":{
"rules":[
{
"case": [
["uri", "==", "/hello/rejected"]
],
"actions": [
[
"return",
{"code": 403}
]
]
},
{
"case": [
["uri", "==", "/hello/v2/appid"]
],
"actions": [
[
"limit-count",
{
"count": 2,
"time_window": 60,
"rejected_code": 429
}
]
]
}
]
}
},
"upstream": {
"type": "roundrobin",
"nodes": {
"127.0.0.1:1980": 1
}
}
}'
예를 들어, 조건 A가 참일 때 특정 작업을 수행하고, 조건 B가 참일 때 다른 작업을 수행하는 등의 방식으로 사용자는 다양한 비즈니스 트래픽을 더 편리하게 스케줄링할 수 있습니다.
Apache APISIX 3.0 시작하기
이제 GitHub 릴리스 페이지와 다운로드 페이지에서 APISIX 3.0을 확인할 수 있습니다!
APISIX는 초기 버전부터 3.0 버전까지 많은 성장을 이루었습니다. 오픈소스 프로젝트는 단순히 성능과 기능만으로 평가될 수 없으며, 사용자, 개발자, 기업의 관점에서 현재의 문제점을 빠르고 효과적으로 해결할 수 있는지 고려해야 합니다.
이 글에서 언급한 하이라이트와 새로운 기능은 모두 오픈소스 커뮤니티를 통해 만들어졌습니다. Apache APISIX는 다양한 개발자와 기업 사용자의 피드백을 받아 더욱 활기차게 성장하고 있습니다. 이 분위기에 동참하고 싶다면, 여기에서 커뮤니티를 확인하세요!