xRPC 출시 예정, APISIX Ecosystem에 대한 더 많은 정보 확인하기

비즈니스 시나리오와 요구사항이 점점 더 복잡하고 다양해짐에 따라, 점점 더 많은 표준과 프로토콜이 등장하고 있습니다. Apache APISIX는 Apache 재단의 탑 오픈 소스 프로젝트로서, 관련 생태계 확장에 적극적으로 참여하고 이를 촉진해 왔습니다.

이 글에서는 다중 프로토콜 프록시와 다국어 지원이라는 두 가지 관점에서 Apache APISIX의 곧 출시될 xRPC 프레임워크와 다국어 플러그인에 대한 예시를 소개합니다.

다중 프로토콜 프록시

Apache APISIX에서 각 요청은 Route 객체에 대응합니다. 현재 Apache APISIX에는 두 가지 주요 프록시 시나리오가 있습니다.

첫 번째는 HTTP 프로토콜 프록시로, 현재 APISIX에서 가장 일반적으로 사용되는 요청 프록시입니다. HTTP 프로토콜 프록시를 기반으로 Apache APISIX는 현재 세밀한 트래픽 제어, 보안, 관찰 가능성 등 수십 가지의 트래픽 관리 기능을 구현하고 있습니다.

두 번째는 TCP 및 UDP 기반의 동적 프로토콜 프록시와 로드 밸런싱으로, 가장 기본적인 트래픽 허용 기능과 링크 수준의 로깅 기능을 제공합니다. 이 프록시 모델은 MySQL, Redis, Mongo 또는 DNS와 같은 TCP/UDP 프로토콜 기반의 요청을 프록시할 수 있습니다. 그러나 상위 애플리케이션 계층 프로토콜이 없는 TCP/UDP 기반 프록시이기 때문에 사중항에 대한 기본 정보만 얻을 수 있어 확장성 측면에서 약간 부족합니다.

xRPC가 필요한 이유

Stream Route의 프로토콜 프록시 측면의 한계와 APISIX에서 더 많은 애플리케이션 계층 프로토콜을 지원하여 더 많은 사용자와 애플리케이션 시나리오를 제공하고자 하는 욕구로 인해 xRPC 프레임워크가 탄생했습니다.

xRPC 프레임워크는 특정 및 개인 데이터 프로토콜 모두를 쉽게 확장할 수 있게 해주며, HTTP 프로토콜 프록시와 유사한 정밀한 세분화와 더 높은 수준의 7계층 제어를 제공합니다. 예를 들어 요청 수준의 관찰 가능성, 고급 접근 제어, 프록시 정책 등이 있습니다.

xRPC란 무엇인가

xRPC는 문자 그대로 X가 프로토콜 리소스의 추상적 표현임을 의미합니다. 그리고 RPC는 게이트웨이를 통과하는 모든 리소스를 프로세스 디스패치로 간주하는 것으로, 즉 프로토콜 확장 프레임워크입니다. 따라서 xRPC는 특정 프로토콜의 구현이 아닌 기본 프레임워크로 위치지어집니다.

위 아키텍처에서 볼 수 있듯이, xRPC는 APISIX Core 확장을 기반으로 한 프레임워크입니다. 이 프레임워크 위에서 사용자는 Redis, MySQL, Mongo 및 Postgres와 같은 다양한 애플리케이션 계층 프로토콜을 구현할 수 있습니다. 다양한 프로토콜 위에서 공통 요소를 추상화하고 관련 플러그인 기능을 구현하여 서로 다른 프로토콜이 이러한 기능을 공유할 수 있게 합니다.

따라서 xRPC의 주요 역할은 다음과 같이 요약할 수 있습니다: 표준화된 애플리케이션 계층 프로토콜에 대한 접근 제공, 프로토콜 간 기능 공유 지원, 사용자 정의 프로토콜 확장 기능 제공.

예제 애플리케이션 시나리오

xRPC 프로토콜 프레임워크가 준비되면, 어떤 시나리오를 해결할 수 있을까요? 몇 가지 예를 들어보겠습니다.

• 예제 1: Redis의 초기 버전은 TLS를 지원하지 않습니다. 시스템에 여러 버전의 Redis가 있고, 어떤 이유로 프로덕션 환경에서 Redis를 업그레이드할 수 없지만 TLS 기능을 추가해야 하는 경우, xPRC 기반 Redis 프로토콜을 사용하여 위 상황을 해결할 수 있습니다.
• 예제 2: 특정 IP 또는 호출자의 빈도를 제한하고 각 호출 소스의 빈도를 시각화하고 싶을 때, Redis는 이를 지원하지 않습니다. xRPC로 확장된 Redis 프로토콜을 사용하면 이를 완벽하게 해결할 수 있습니다.
• 예제 3: MySQL을 사용하여 일시적으로 슬로우 쿼리 기능을 활성화하려는 경우, MySQL 프로토콜에 접근하고 APISIX에서 관련 정책을 구성하기만 하면 됩니다. 이는 인스턴스 기계에 하나씩 로그인하는 번거로운 단계를 생략할 수 있습니다.

물론 이와 유사한 많은 애플리케이션 시나리오가 있으며, 기능 출시 후 실제 애플리케이션에서 더 많은 경험과 실습을 해보시길 바랍니다. xPRC 호출 과정은 다음 다이어그램과 같습니다.

Apache APISIX가 업스트림 서비스를 인수하면, 다양한 업스트림 애플리케이션 서비스를 통합적으로 관리할 수 있습니다. 로깅, 모니터링, 보안, 문제 해결과 같은 기능은 모두 표준화된 정책 세트를 통해 수행할 수 있습니다.

계획된 구현 단계

현재 Apache APISIX xRPC 프레임워크의 설계는 초기에 5단계로 나뉩니다.

• 1단계: 데이터 읽기 및 프로토콜 디코딩.
• 2단계: 접근 단계. 플러그인 접근 기능 제공, 보안, 트래픽 제어 및 접근 요구 시나리오 구현.
• 3단계: 프록시 데이터 전달 및 로드 밸런싱. 사용자 정의 로드 밸런싱 정책 및 알고리즘에 대한 접근 지원 제공.
• 4단계: 데이터 전송 및 프로토콜 인코딩.
• 5단계: 로깅 단계. 로깅 및 로깅 요구 시나리오를 구현하기 위한 플러그인 접근 제공.

다국어 생태계

점점 더 풍부하고 큰 컴퓨팅 언어 기반을 충족시키기 위해, 다국어 환경에 대한 코드 지원을 만드는 것은 미래 기술 발전에 대응하기 위한 첫 번째 관문이 되었습니다. Apache APISIX는 다국어 개발의 길에서 많은 탐구와 실천을 해왔습니다.

예를 들어, 최근 WebAssembly에 대한 지원을 구현했습니다. 자세한 내용과 기능은 "Apache APISIX Embraces WASM Ecology" 글을 참조하세요. 물론 Apache APISIX에서 WASM에 대한 지원은 아직 실험적이며, 앞으로 WASM에 대한 지원을 계속 개선할 예정입니다. 이 프로젝트에 관심이 있다면 wasm-nginx-module 프로젝트에 기여해 주세요.

한편, Apache APISIX는 WASM 지원이 구현되기 전에 "xPluginRunner 다국어 플러그인 런타임"을 통해 여러 개발 언어를 지원하고 있습니다. 즉, APISIX 플러그인을 개발할 때, APISIX에서 기본적으로 지원하는 Lua 코드뿐만 아니라 Go, Java 및 Python과 같은 자신이 익숙한 언어로도 APISIX 플러그인을 작성하고 확장할 수 있습니다.

xPluginRunner

xPluginRunner의 구현은 위 그림과 같습니다. 전체 통신 과정은 내장 플러그인 실행 "전"과 "후"에 APISIX가 각 언어의 플러그인 런타임에 로컬 RPC 요청을 시작합니다. 플러그인 러너에서는 각 플러그인 내의 계산 및 정책 처리가 구현되며, 최종적으로 응답 결과를 APISIX에 반환하여 후속 결정을 내립니다.

xPluginRunner는 Apache APISIX와의 통신을 위한 다리 역할을 하며, 주로 개인 데이터 프로토콜의 파싱과 RPC 메시지의 캡슐화 및 역캡슐화를 구현합니다.

현재 Apache APISIX xPluginRunner 솔루션은 비교적 안정적인 단계에 있으며, 커뮤니티 피드백을 통해 일부 기업이 프로덕션 환경에서 시도하기 시작했다는 것을 알고 있습니다. 이 프로젝트에 관심이 있다면 다양한 개발 언어 플러그인 프로젝트에 참여해 주세요.

• apisix-go-plugin-runner
• apisix-java-plugin-runner
• apache-apisix-python-runner

마지막으로, 간단한 Java 예제를 통해 Java Plugin Runner를 기반으로 APISIX 플러그인을 개발하는 방법을 보여드리겠습니다.

Java Plugin Runner 예제

먼저, 플러그인을 개발할 때 PluginFilter 인터페이스를 구현해야 합니다. 인터페이스의 name 메서드는 주로 플러그인 이름을 식별하고 추출하는 데 사용되며, filter 메서드는 요청을 필터링(즉, 플러그인 본체 로직 실행)하는 데 사용됩니다.

위 코드에 나타나는 request 및 response 매개변수는 Runner에 고정된 로직이 있습니다(모든 Runner에 적용):

1. 요청을 계속 전달하고 일부 정책 설정(예: 요청 매개변수, 헤더 재작성 등)만 하려면 request 객체를 조작하면 됩니다.
2. 요청을 종료하려면 response 객체로 할 수 있습니다(예: 응답 본문, 응답 헤더, 상태 코드 설정 등).

APISIX는 Runner에서 response 객체가 조작되면 현재 요청을 즉시 종료합니다.

플러그인 개발이 완료되면 APISIX에서 애플리케이션을 실습할 차례입니다.

먼저, Runner와 프로젝트의 플러그인을 jar 패키지로 컴파일하고, jar 패키지의 절대 경로를 다음과 같이 주요 APISIX 구성 파일에 구성합니다.

마지막으로, Apache APISIX를 재시작하고 라우팅 및 플러그인 구성과 요청 검증 세션을 준비합니다.

요약

이 글은 Apache APISIX의 곧 출시될 xRPC 프레임워크와 관련 세부 사항, 그리고 다국어 개발 지원에 대한 Apache APISIX의 상세한 데모를 소개합니다.

이 글은 또한 Apache APISIX의 다국어 개발 지원에 대한 세부 사항을 보여줍니다. 다중 프로토콜 프록시와 다국어 지원이라는 두 가지 관점에서 Apache APISIX의 생태계 지향적 노력을 보여줍니다.

GitHub Discussions에서 토론을 시작하거나 메일링 리스트를 통해 소통해 주세요.