API Gateway에서 Plugin Orchestration 구현 방법

동영상 보기

먼저 저를 소개하겠습니다. 저는 API7.ai의 공동 창립자인 Ming Wen입니다. 저는 오픈 소스 프로젝트 Apache APISIX의 부사장이자 PMC 멤버입니다. 또한 Apache Skywalking의 커미터이기도 합니다. 추가로, 저는 Qihoo 360 오픈 소스 위원회의 창립자, Tencent Cloud TVP, 그리고 TARS Foundation의 TOC 멤버입니다. 저는 40개 이상의 보안 특허를 보유하고 있습니다.

오늘의 주제에서는 4가지 부분을 소개하겠습니다. 첫 번째는 Apache APISIX에 대한 간단한 소개입니다. Apache APISIX는 무엇이며, 무엇을 도와줄 수 있는지 설명하겠습니다. 두 번째 부분은 API 게이트웨이에서의 커스텀 개발에 대한 내용입니다. 세 번째 부분은 Apache APISIX의 플러그인에 대해 설명하고, 이를 자동으로 생성하는 방법을 소개하겠습니다. 마지막으로 API 게이트웨이의 미래에 대한 몇 가지 생각을 공유하겠습니다.

먼저 Apache APISIX에 대해 간단히 소개하겠습니다. 한 마디로, Apache APISIX는 클라우드 네이티브 API 게이트웨이입니다. 여기 GitHub에 있는 Apache APISIX의 저장소 주소입니다.

Apache APISIX는 매우 젊은 프로젝트입니다. 작년 6월에 오픈 소스로 공개되었고, 10월에 Apache 인큐베이터에 기증되었습니다. 올해 7월에는 Apache 인큐베이터를 졸업하고 탑 레벨 프로젝트가 되었습니다. 이는 매우 빠르게 성장한 커뮤니티로, 단 9개월 만에 이루어졌습니다.

Apache APISIX에 익숙하지 않은 개발자들을 위해, 간단히 NGINX의 강화된 버전으로 생각할 수 있습니다. NGINX의 모든 기능을 포함하면서 Lua를 사용하여 NGINX에 더 많은 동적 기능을 추가하여 매우 강력한 API 게이트웨이로 변신시킵니다. Apache APISIX의 가장 큰 특징은 완전히 동적이라는 점입니다. 라우팅, SSL 인증서, 플러그인 등 모든 기능이 관리자 API를 통해 동적으로 구성되며, 서비스를 재시작할 필요가 전혀 없습니다. Apache APISIX에서는 사용자의 비즈니스 요구 사항이 모두 Lua를 사용하여 플러그인을 개발함으로써 구현됩니다. APISIX에는 40개 이상의 내장 플러그인이 있으며, 인증, 속도 제한, 요청 제한, 보안, 로그, 관측 가능성 등 기업에서 사용자가 마주할 수 있는 모든 기능을 기본적으로 포함하고 있습니다.

그렇다면 Apache APISIX가 무엇을 할 수 있는지 살펴보겠습니다. 4계층과 7계층 트래픽을 처리할 수 있으며, HTTP, HTTPS, TCP, UDP, MQTT 등을 포함합니다.

Apache APISIX는 NGINX를 기반으로 하기 때문에, 자연스럽게 NGINX 대신 Apache APISIX를 사용하여 남북 트래픽을 처리할 수 있습니다. 동시에 Apache APISIX는 마이크로서비스 간의 트래픽도 잘 처리할 수 있으므로, envoy를 대체할 수 있습니다. 또한 일부 사용자는 Apache APISIX를 Kubernetes의 ingress 컨트롤러로 사용하기도 합니다. 동시에 Apache APISIX의 mqtt 플러그인을 활용하여 IoT 게이트웨이로 사용하거나, IDP 플러그인을 사용하여 APISIX를 제로 트러스트 게이트웨이로 변환할 수도 있습니다. 따라서 APISIX는 게이트웨이 자체의 힘에 더 초점을 맞추고 있습니다. 플러그인을 통해 사용자는 APISIX를 자신의 비즈니스에 필요한 다양한 게이트웨이로 변환할 수 있습니다.

이것이 Apache APISIX의 기술 아키텍처입니다. 여기서 APISIX는 두 부분으로 나뉩니다. 왼쪽은 데이터 플레인이고, 오른쪽은 컨트롤 플레인입니다.

먼저 데이터 플레인을 살펴보겠습니다. 사용자의 요청이 Apache APISIX를 통해 처리된 후, 프라이빗 API, 퍼블릭 API 또는 파트너 API로 전달될 수 있습니다. Apache APISIX 내부에서는 플러그인이 레고 블록과 유사한 방식으로 구축되어 있습니다. 서비스를 재시작하지 않고도 쉽게 플러그인을 제거하거나 추가할 수 있습니다.

그 다음 컨트롤 플레인을 살펴보겠습니다. 컨트롤 플레인에서는 관리자가 관리자 API를 통해 etcd 클러스터에 구성을 작성하고, APISIX 데이터 플레인이 etcd를 감시하여 구성이 밀리초 단위로 모든 데이터 플레인에 전달됩니다. 데이터 플레인의 노드가 데이터를 처리한 후, skywalking, Prometheus 등의 컴포넌트에 일부 메트릭과 로그 데이터를 보고합니다.

이 아키텍처 다이어그램에서 볼 수 있듯이, APISIX는 etcd에만 의존하며, MySQL이나 PostgreSQL과 같은 RDS를 사용하지 않습니다. 따라서 APISIX는 고가용성을 위해 더 잘 설계되었습니다. 동시에 아키텍처가 더 단순하여 배포와 운영이 편리합니다.

이 그림은 Apache APISIX의 전체적인 모습입니다. 왼쪽에서 보면, APISIX는 많은 4계층 및 7계층 프로토콜을 지원합니다. 브라우저와 모바일 앱의 트래�을 처리할 뿐만 아니라, 다양한 IoT 장치가 APISIX에 트래픽을 보고할 수 있도록 지원합니다.

Apache APISIX는 또한 etcd, Consul 등 많은 외부 서비스 디스커버리 센터를 지원합니다.

매우 중요한 인프라 소프트웨어인 API 게이트웨이는 일반적으로 트래픽의 입구에 위치합니다. 따라서 클라이언트의 모든 요청을 처리해야 할 뿐만 아니라, skywalking, datadog, Kafka 등과 같은 일부 백엔드 서비스에 연결해야 합니다.

이 그림의 하단에서 볼 수 있듯이, APISIX는 베어 메탈뿐만 아니라 다양한 퍼블릭 클라우드의 서버에서도 실행할 수 있습니다. 또한 ARM 플랫폼에서도 실행할 수 있습니다.

좋습니다. 첫 번째 부분은 APISIX에 대한 간단한 소개였습니다. 두 번째 부분에서는 API 게이트웨이에서의 커스텀 플러그인 개발에 대해 소개하겠습니다.

오� 소스 게이트웨이를 사용할 때 커스텀 개발은 매우 중요한 부분이며, 높은 진입 장벽이 있습니다. 게이트웨이는 데이터베이스나 메시지 큐와 달리 바로 사용할 수 있는 소프트웨어가 아닙니다. MQ와 데이터베이스는 설치 후 바로 사용할 수 있지만, 게이트웨이는 그렇지 않습니다. 이는 게이트웨이가 어느 정도 커스텀 개발이 필요하기 때문입니다.

예를 들어, 회사에 일부 레거시 시스템이 있거나, 금융 및 보안 산업의 특수 프로토콜과 같은 경우, 게이트웨이 수준에서 일부 트랜스코딩이 필요할 수 있습니다.

반면, APISIX는 40개 이상의 플러그인을 제공하지만, 기업의 모든 요구 사항을 충족시킬 수는 없습니다. 각 회사마다 고유한 요구 사항이 있기 때문입니다. 따라서 기존 플러그인을 커스텀 개발하여 요구 사항을 충족시켜야 하는 경우가 많습니다. 이는 실제로 큰 문제입니다. 왜냐하면 플러그인 개발은 여전히 더 많은 기술이 필요하기 때문입니다. 플러그인 개발을 위해, 다양한 오픈 소스 프로젝트가 각기 다른 솔루션을 제공합니다.

먼저 Kong을 살펴보겠습니다. Kong은 잘 알려진 API 게이트웨이 프로젝트로, 5년 된 프로젝트입니다. Kong의 기술 스택은 기본적으로 APISIX와 동일하며, 둘 다 NGINX와 Lua를 기반으로 구현되었습니다. 하지만 Kong의 기술 아키텍처는 APISIX와 다릅니다. Kong은 PostgreSQL과 Cassandra와 같은 RDS를 기반으로 합니다. APISIX는 etcd를 사용하며, APISIX의 솔루션은 Kubernetes와 클라우드 네이티브에 더 가깝습니다.

Kong과 APISIX의 공통점은 개발자가 Lua를 사용하여 플러그인을 개발해야 한다는 점입니다. Lua는 인기 있는 프로그래밍 언어가 아니며, 많은 개발자들이 익숙하지 않습니다. Lua 자체는 간단하지만, 여전히 진입 장벽이 있습니다. 따라서 플러그인을 더 간단하게 만드는 것 외에 더 나은 솔루션이 있을까요?

Kong의 솔루션은 Go로 플러그인을 작성할 수 있도록 지원하는 것입니다. 이 접근 방식은 더 많은 Go 개발자들이 자신의 회사의 커스텀 요구 사항을 충족시키기 위해 플러그인을 작성하도록 유도할 수 있습니다. 이는 좋은 아이디어이지만, 반면에 Kong은 기본적으로 NGINX와 Lua를 기반으로 구현되었으며, Go로 작성된 플러그인은 실제로 다른 프로세스를 호출해야 하므로 프로세스 간 통신이 발생하며, 이는 성능 문제를 일으킬 수 있습니다.

두 번째로 살펴볼 것은 매우 잘 알려진 오픈 소스 데이터 플레인 프로젝트인 Envoy입니다. Envoy는 C++로 작성되었으며, 자연스럽게 플러그인도 C++로 구현됩니다. 따라서 시작하기가 쉽지 않습니다.

Envoy는 또한 Lua 필터를 지원하며, Lua 필터는 Kong과 동일한 문제를 가지고 있습니다. 즉, Lua에 익숙한 개발자가 적다는 것입니다. 따라서 Envoy는 WASM도 지원하여 더 많은 다른 언어 개발자들이 플러그인을 작성할 수 있도록 합니다. 이 솔루션은 완벽하지 않으며, WASM의 안정성과 성능은 시간이 필요합니다.

Kong과 Envoy의 솔루션은 동일합니다: 더 많은 개발자들이 Go, Lua 또는 WASM을 사용하여 플러그인을 개발할 수 있는 능력을 갖추기를 바랍니다. 따라서 APISIX로 돌아가서, 우리는 실버 불릿을 찾고자 합니다.

그렇다면 이 실버 불릿은 어떤 모습일까요? 우리는 게이트웨이 수준에서 다음 두 가지 문제를 먼저 해결해야 한다고 생각합니다.

첫 번째는 개발해야 할 많은 플러그인이 실제로 간단하다는 점입니다. 이미 존재하는 40개 이상의 오픈 소스 플러그인을 어떻게 재사용할 수 있을까요?

두 번째는 기업 내 게이트웨이의 수요 측, 예를 들어 제품 관리자, 운영 및 보안 팀이 최소한의 비용으로 자신의 요구 사항을 게이트웨이에 구현할 수 있도록 하는 것입니다. 코드를 작성하지 않고도 가능하다면 가장 좋습니다.

이 두 문제를 해결할 수 있다면, 개발자뿐만 아니라 더 많은 사람들이 AP 게이트웨이를 개발할 수 있도록 할 수 있습니다.

먼저 첫 번째 문제인 기존 플러그인의 재사용을 어떻게 해결할 수 있는지 살펴보겠습니다. 마이크로서비스는 이미 매우 인기 있는 기술입니다. 따라서 API 게이트웨이 플러그인에 이 개념을 도입할 수 있을까요?

각 플러그인이 하나의 기능만 수행하도록 만들 수 있습니다. 이는 마이크로서비스와 마찬가지로 Linux의 프로세스 설계와도 동일합니다. 따라서 우리는 마이크로 플러그인이라는 개념을 제안했습니다.

각 플러그인은 독립적인 기능만 수행합니다. 그런 다음, 이러한 마이크로 플러그인을 연결하기 위해 Linux 파이프와 유사한 설계가 필요합니다.

예를 들어, 먼저 URI 차단 플러그인을 호출합니다. 호출이 완료된 후, URI가 실제로 차단되었는지 판단합니다. 차단되었다면, Kafka 플러그인을 호출하여 로그를 기록합니다.

이러한 파이프 방식으로 플러그인을 연결할 수 있습니다. Apache APISIX에는 현재 40개 이상의 플러그인이 있습니다. 40개 이상의 플러그인의 조합은 무한한 가능성을 가지며, 사용자의 요구 사항을 충족시키기에 충분합니다.

하지만 현재의 문제는 모든 오픈 소스 API 게이트웨이에서 플러그인이 컨텍스트를 공유하지 않고 서로 협력할 수 없다는 점입니다. 따라서 이러한 플러그인을 연결해야 합니다. 이를 통해 마이크로 플러그인을 사용하여 플러그인 재사용 문제를 해결할 수 있습니다.

두 번째 문제는 마이크로 플러그인을 갖춘 후, API 게이트웨이의 새로운 플러그인 개발 비용을 최대한 줄여 사용자 요구를 충족시키는 것입니다. 우리는 비개발자, 즉 기술 배경이 없고 프로그래밍을 모르는 제품 관리자와 보안 담당자들이 개발 없이도 자신의 요구 사항을 구현할 수 있기를 바랍니다. 왜냐하면 그들이 우리의 요구 사항을 가장 잘 이해하기 때문입니다.

동시에, 이는 API 게이트웨이 개발의 진입 장벽을 낮추어 더 많은 사람들이 AP 게이트웨이에 기여할 수 있도록 합니다. 슬로건으로 표현하자면, "창의에서 창조로"입니다. 우리는 단순히 개발자를 위해 문서에 아이디어를 적는 것뿐만 아니라, 직접 새로운 플러그인을 만들 수 있습니다.

이것은 좋은 아이디어처럼 들리지만, 실제로 실현 가능할까요? 사실 우리는 기술적 사고에서 벗어나 다른 산업이 어떻게 해결했는지 볼 수 있습니다.

예를 들어, 의료 산업의 프로세스 엔진은 GUI 방식으로 구축되었습니다. 그들의 사용자는 의사들이기 때문입니다. 또한, 어린이를 위한 레고도 마찬가지입니다. 제한된 수의 블록을 사용하여 무한한 가능성의 형태를 만들 수 있습니다.

GUI와 레고 아이디어를 결합하면, 실제로 스크래치와 같은 것입니다. 스크래치는 어린이들이 프로그래밍을 배우는 방식으로, 진입 장벽이 매우 낮습니다.

앞서 해결한 두 가지 문제를 기반으로, APISIX는 플러그인 오케스트레이션이라는 새로운 개념을 독창적으로 제안했습니다. 여기 플러그인 오케스트레이션의 데모가 있습니다. 짧은 동영상을 먼저 살펴보겠습니다.

이 동영상에서는 먼저 URI 차단 플러그인을 생성합니다. 그런 다음 조건부 판단을 생성합니다. URI 차단이 true이면, fault injection 플러그인에 추가합니다. URI 차단 결과가 False이면, Kafka 플러그인에 전달하여 로그를 기록합니다.

그런 다음 각 플러그인과 판단 조건을 구성합니다. 마지막으로 curl을 사용하여 이 새로운 플러그인이 게이트웨이 노드에서 실제로 작동하는지 확인합니다. 네, 작동합니다.

다음으로, 이 플러그인 오케스트레이션이 어떻게 구현되었는지 설명하겠습니다. 이는 모두가 관심을 가질 수 있는 기술적 문제일 것입니다.

플러그인 오케스트레이션을 구현하기 위해 세 단계를 거쳐야 합니다.

첫 번째 단계에서는 DAG를 사용하여 이 새로운 플러그인을 설명해야 합니다. 왼쪽의 화살표가 있는 그래프는 실제로 DAG(방향성 비순환 그래프)이며, 이전 동영상에서 설명한 코드와 동일합니다. 이는 인간에게 친숙한 설명 방법입니다. 컴퓨터를 위해 이를 오른쪽의 데이터 구조 설명 언어로 변환해야 합니다. 예를 들어, 1번 노드 뒤에 2, 4, 6이 있다는 것은 1번 노드가 2번, 4번, 6번 노드를 가리킨다는 것을 의미합니다. 3번 노드의 값이 nil이라는 것은 3번 노드 뒤에 다른 노드가 없다는 것을 의미하며, 나머지도 유사합니다. 이렇게 DAG를 데이터 구조 설명으로 변환합니다.

이 데이터 구조를 갖춘 후, 이 데이터 구조를 JSON 문자열로 변환하고, 이 JSON 문자열을 서버에 전달합니다. 오른쪽의 JSON 문자열은 데모에서 본 플러그인에서 변환된 것입니다.

첫 번째 단계를 거치면 이미 JSON으로 설명된 문자열이 있지만, 이 문자열을 APISIX에서 실행할 수 있는 코드로 어떻게 변환할까요?

APISIX에서는 Lua 코드를 실행하고 있으므로, JSON을 AST(추상 구문 트리)로 파싱하고, 최종적으로 Lua 코드를 생성하는 컴파일러가 필요합니다. 이 단계에서 우리는 jsonschema를 사용했습니다. 아래는 오픈 소스 저장소입니다.

Lua 코드를 생성한 후, APISIX 컨트롤 플레인을 통해 관리자 API로 Lua 코드를 etcd에 작성합니다. 그런 다음 APISIX 데이터 플레인 노드가 etcd를 감시하여 Lua 코드를 가져옵니다. APISIX는 Lua 코드를 동적으로 실행할 수 있는 능력을 가지고 있으며, 이는 APISIX의 서버리스 플러그인과 유사합니다.

따라서 플러그인 오케스트레이션에 의해 생성된 새로운 플러그인은 DAG에서 데이터 노드의 실제 실행까지 전체 프로세스가 모두 동적입니다. 이는 APISIX의 매우 중요한 특징입니다.

여기까지 보셨다면, 어디서 시도해볼 수 있는지 궁금하실 것입니다. 걱정하지 마세요. 여기 오픈 소스 프로젝트가 있으며, 온라인 데모도 있습니다.

마지막 부분에서는 API 게이트웨이의 미래에 대한 우리의 생각을 이야기하고 싶습니다. API 게이트웨이는 오랫동안 존재해 왔습니다. 10년 전부터 많은 회사와 오픈 소스 프로젝트가 API 게이트웨이를 개발해 왔습니다. 클라우드 네이티브 시대에 API 게이트웨이는 사용자 요구의 변화에 직면하며, AP 게이트웨이에 대한 더 높은 요구 사항이 제기되고 있습니다.

하나의 트렌드는 전통적인 남북 API 게이트웨이가 동서 마이크로서비스 트래픽을 처리하기 시작한다는 것입니다. 예를 들어, NGINX는 NGINX 컨트롤과 NGINX 유닛을 출시했습니다. Kong과 APISIX도 마이크로서비스 API 게이트웨이로 활동하고 있습니다.

동시에, 동서 서비스 매시 프로젝트도 남북 접근 게이트웨이로 활동하려고 합니다. 따라서 오픈 소스 프로젝트는 모두 전체 트래픽을 처리하려고 합니다.

트래픽 처리에 관한 오픈 소스 프로젝트가 활발히 진행되고 있으며, Baidu의 BFE와 Alibaba의 MOSN을 볼 수 있습니다. 이들은 모두 트래픽에 초점을 맞추고 있습니다.

두 번째는 로우 코드입니다. 최고의 솔루션은 제품 관리자가 플러그인 오케스트레이션을 통해 직접 기능을 구현할 수 있도록 하는 것입니다. 이렇게 하면 개발자는 게이트웨이 자체에 더 집중할 수 있습니다.

이렇게 하면 비즈니스와 API 게이트웨이의 핵심이 분리됩니다. 기술과 플러그인 개발을 이해하지 못하는 사람들도 오픈 소스 프로젝트에 플러그인을 기여할 수 있습니다. 이는 매우 중요합니다.

세 번째는 실시간입니다. 5G와 IoT의 보급, 그리고 Kubernetes의 기업 내 도입으로 인해 구성의 실시간 효과, 요청 처리, 실시간 데이터 분석에 대한 매우 높은 요구 사항이 제기되었습니다. 게이트웨이의 경우, 실시간, 매우 높은 성능, 매우 낮은 지연 시간을 제공하지 못한다면, 향후 3~5년 동안 생존할 수 없을 것입니다.

마지막으로, 오픈 소스입니다. 우리는 소프트웨어가 하드웨어를 먹어치우고, 오픈 소스 소프트웨어가 소프트웨어를 먹어치우는 것을 볼 수 있습니다. 결국 모든 인프라 소프트웨어는 오픈 소스가 될 것입니다.

API 게이트웨이도 마찬가지입니다. 오픈 소스는 기업이 더 낮은 비용으로 사용할 수 있도록 하며, 벤더 락인에 대한 걱정 없이 사용할 수 있습니다. 또한 오픈 소스의 상업적 기회는 오픈 소스 개발자들에게 더 많은 것을 가져다줄 것입니다. 이는 윈윈 상황을 위한 좋은 모델입니다.