오픈소스 API 게이트웨이 Apache APISIX의 기술적 탐구
배경
Apache APISIX는 동적, 실시간, 고성능 오픈소스 API 게이트웨이로, 로드 밸런싱, 동적 라우팅, 카나리 릴리스, 서킷 브레이커, 인증, 관측 가능성 등 다양한 트래픽 관리 기능을 제공합니다.
API 게이트웨이로서 Apache APISIX는 게이트웨이, Kubernetes Ingress, 서비스 메시와 같은 시나리오에서 기업이 API와 마이크로서비스 트래픽을 빠르고 안전하게 처리할 수 있도록 도와줍니다. 또한, 클라이언트에서 서버로의 남북 트래픽과 기업 내 다양한 마이크로서비스 간의 동서 트래픽을 처리할 수 있습니다.
2019년 6월 6일에 오픈소스로 공개된 APISIX는 2019년 10월에 Apache 소프트웨어 재단에 기증되었으며, 몇 달 만에 Apache 소프트웨어 재단의 최상위 프로젝트로 빠르게 성장했습니다.
APISIX가 짧은 시간 동안 급성장할 수 있었던 이유는 무엇일까요? APISIX가 어떤 마법 같은 기술적 탐구를 했을까요? 왜 점점 더 많은 개발자와 기업이 APISIX를 사용하려고 할까요? 함께 알아봅시다.
Apache APISIX의 주요 기능
데이터베이스 의존성 없음
APISIX 프로젝트가 등장하기 전에도 많은 상용 API 게이트웨이 또는 오픈소스 API 게이트웨이 프로젝트가 있었습니다. 이러한 경쟁 제품들의 잠재적인 문제는 대부분의 제품들이 API 데이터, 구성 정보, 인증서 구성, 라우트 정보를 관계형 데이터베이스에 저장한다는 점입니다.
관계형 데이터베이스에 저장하는 명백한 장점은 사용자가 SQL 문을 사용하여 유연한 쿼리를 수행하고 백업 및 후속 유지보수를 쉽게 할 수 있다는 것입니다.
그러나 모든 것에는 양면이 있습니다. 기본 미들웨어로서 API 게이트웨이는 모든 클라이언트 트래픽을 처리하므로 가용성에 대한 요구가 더 높아집니다. API 게이트웨이가 관계형 데이터베이스에 의존하는 경우, 데이터베이스 오류가 발생하면 게이트웨이도 영향을 받게 됩니다. 예를 들어, 데이터베이스가 충돌하거나 데이터가 손실되면 시스템 전체의 가용성이 제한됩니다.
따라서 APISIX의 설계자들은 이러한 문제를 피하기 위해 기본 아키텍처 측면에서 다양한 방법을 시도했습니다.
APISIX의 아키텍처는 크게 두 부분으로 나뉩니다. 첫 번째 부분은 데이터 플레인으로, 클라이언트의 요청과 트래픽을 처리하는 구성 요소입니다. 이는 인증, 인증서 오프로딩, 로그 분석, 관측 가능성을 지원합니다. 데이터 플레인은 데이터를 저장하지 않는 무상태 구조입니다.
두 번째 부분은 컨트롤 플레인입니다. APISIX는 전통적인 MySQL과 같은 구성 저장소를 사용하지 않고 컨트롤 플레인에서 etcd를 사용합니다.
이렇게 하는 장점은 다음과 같습니다:
- 클라우드 네이티브 아키텍처와 더 잘 통합됨
- API 게이트웨이가 저장하는 데이터 유형에 더 적합함
- 고가용성 특성을 더 잘 반영함
- 변경 사항을 밀리초 단위로 알림
etcd를 사용함으로써 데이터 플레인은 etcd의 변경 사항만 모니터링하면 됩니다. 데이터베이스를 폴링하는 경우 최신 구성을 얻는 데 5-10초가 걸릴 수 있지만, etcd 구성 변경을 주시하면 밀리초 내에 피드백을 받아 실시간 효과를 달성할 수 있습니다.
따라서 관계형 데이터베이스 대신 etcd를 사용함으로써 APISIX는 기본 클라우드 환경과 더 잘 호환되고 고가용성의 장점을 강화할 수 있습니다.
다양한 프로그래밍 언어를 위한 플러그인
API 게이트웨이는 데이터베이스 및 기타 미들웨어와는 다소 다릅니다. 후자와 비교할 때 게이트웨이는 사용자 정의 개발 및 시스템 통합에서 더 자주 사용됩니다.
APISIX는 많은 공식 플러그인을 출시했지만, 여전히 모든 사용 시나리오를 커버하기는 어렵습니다. 따라서 실제 사용에서는 비즈니스를 위해 일부 사용자 정의 플러그인을 개발해야 할 필요가 있습니다. APISIX는 또한 게이트웨이를 통해 더 많은 프로토콜이나 시스템을 통합하고 최종적으로 게이트웨이 계층에서 통합 관리할 수 있습니다.
처음에 APISIX는 Lua 언어로만 플러그인 개발을 지원했습니다. 이는 개발된 플러그인이 기본 프로그래밍 언어의 최적화를 통해 높은 성능을 가질 수 있다는 장점이 있습니다. 그러나 명백한 단점은 새로운 언어인 Lua를 배우는 데 시간과 학습 비용이 필요하다는 것입니다.
APISIX는 이 문제를 두 가지 방법으로 해결합니다.
첫 번째 방법은 Java, Python, Go와 같은 더 많은 주류 프로그래밍 언어를 Runner 플러그인을 통해 지원하는 것입니다. 백엔드 엔지니어라면 이 언어 중 적어도 하나는 알고 있을 것이며, RPC 프로토콜을 활용하여 익숙한 언어로 APISIX 플러그인을 쉽게 개발할 수 있습니다.
한편으로는 개발 비용을 줄이고 개발 효율성을 높이는 데 유리하지만, 다른 한편으로는 성능 측면에서 약간의 지연이 발생합니다. 따라서 Lua의 기본 성능과 고급 언어를 동시에 고려할 수 있는 해결책이 있을까요?
여기서 두 번째 방법이 등장합니다. 위 그림의 왼쪽 부분에서 볼 수 있듯이, WebAssembly는 처음에 프론트엔드나 브라우저에서 기술로 사용되었고 점차 서버 측에서도 그 장점을 제공하기 시작했습니다.
APISIX에 WebAssembly를 내장함으로써, 사용자는 이를 사용하여 APISIX에서 실행되는 WebAssembly 바이트코드로 컴파일할 수 있습니다. 최종 효과는 고성능이면서도 고급 프로그래밍 언어로 작성된 APISIX 플러그인을 효율적으로 개발할 수 있다는 것입니다.
따라서 현재 APISIX 버전에서는 사용자가 Lua, Go, Python, Wasm 등의 방법을 사용하여 APISIX를 기반으로 코드를 사용자 정의할 수 있습니다. 이 설계는 개발자의 진입 장벽을 낮추고 APISIX의 기능에 더 많은 가능성을 제공합니다.
플러그인의 핫 리로딩
APISIX는 NGINX와 비교하여 두 가지 중요한 발전을 이루었습니다: APISIX는 클러스터 관리와 동적 리로딩을 지원합니다.
NGINX를 사용해본 적이 있다면, NGINX의 모든 구성이 nginx.conf 파일에 작성된다는 것을 알 것입니다. 클러스터 제어를 수행하려면 모든 서버에서 nginx.conf 파일을 수정해야 합니다. 이 전체 과정에서 중앙 집중식 관리 컨트롤 플레인이 없습니다. 각 NGINX는 데이터 플레인과 컨트롤 플레인의 조합입니다. 사용자가 수십 대 또는 수백 대의 NGINX 서버를 가지고 있다면 관리 비용이 매우 높을 것입니다.
위에서 언급한 시나리오에서, nginx.conf 파일을 수정한 후에는 모든 NGINX 서버를 재시작해야 합니다. 예를 들어, 인증서 업데이트 또는 업스트림 변경이 있을 때, 먼저 구성 파일을 수정하고 서버를 재시작해야 적용됩니다. 요청이 특별히 많지 않다면 이 방법은 어느 정도 받아들일 수 있습니다. 그러나 API와 마이크로서비스가 점점 더 많이 등장함에 따라, 각 수정마다 서버를 재시작해야 한다면 클라이언트에 미치는 영향이 매우 클 것입니다.
- 핫 업데이트 및 핫 플러그인: 재시작 없이 구성과 플러그인을 지속적으로 업데이트합니다!
- 프록시 재작성: 요청을 업스트림으로 보내기 전에 호스트, URI, 스키마, 메서드, 헤더를 재작성할 수 있습니다.
- 응답 재작성: 클라이언트에게 사용자 정의 응답 상태 코드, 본문, 헤더를 설정할 수 있습니다.
- 동적 로드 밸런싱: 가중치를 가진 라운드 로빈 로드 밸런싱.
- 해시 기반 로드 밸런싱: 일관된 해시 세션을 사용한 로드 밸런싱.
- 헬스 체크: 업스트림 노드에서 헬스 체크를 활성화하고 로드 밸런싱 중에 비정상 노드를 자동으로 필터링하여 시스템 안정성을 보장합니다.
- 서킷 브레이커: 비정상 업스트림 서비스를 지능적으로 추적합니다.
- 프록시 미러: 클라이언트 요청을 미러링할 수 있는 기능을 제공합니다.
- 트래픽 분할: 사용자가 다양한 업스트림 간에 트래픽의 백분율을 점진적으로 지정할 수 있습니다.
위 그림은 APISIX가 현재 핫 리로딩을 구현한 구성 요소들을 나열합니다. 업스트림부터 인증서, 심지어 플러그인까지 코드가 실시간으로 적용되는 것을 볼 수 있습니다. 일부 커뮤니티 멤버들은 업스트림과 인증서가 동적인 이유를 이해할 수 있지만, 플러그인 수정이 동적이어야 하는 이유에 대해 의문을 가질 수 있습니다. 그들은 플러그인 수정이 드물게 발생하므로 매우 활성화될 필요가 없다고 생각할 수 있습니다.
APISIX의 기본 설계자로서, 우리는 궁극적으로 동적이어야 한다고 생각하며, 이는 기업에 더 많은 가능성을 제공하는 중요한 장점입니다. 예를 들어, 사용자는 디버그 플러그인을 수정하면서 코드를 문제 해결할 수 있으며, 플러그인 코드를 변경하지 않고도 문제를 재현하고 기록할 수 있습니다. 디버깅 기능이 있는 플러그인과 핫 리로딩 메커니즘을 결합하면 매우 유연해져 개발자가 문제 해결에 시간과 노력을 절약할 수 있습니다.
플러그인의 동적 오케스트레이션
핫 리로딩 외에도, APISIX는 플러그인 간의 실시간 동적 오케스트레이션을 지원합니다. 동적 오케스트레이션은 플러그인 운영에 무한한 가능성을 가져다줍니다.
플러그인 오케스트레이션이란 무엇일까요? 우리가 다양한 요구 사항을 제시할 때, 요청을 플러그인으로 바꾸는 것을 LEGO를 조립하는 것과 같다고 생각할 수 있습니다. 우리는 통일된 표준을 통해 무한한 다양한 형태를 만들 수 있으며, 이것이 LEGO의 즐거움 중 하나입니다. APISIX 플러그인의 경우, 각 플러그인은 독립적인 사례 요구 사항을 충족시킵니다. 우리는 사용자가 LEGO를 조립하듯이 플러그인을 사용하여 자신의 요구 사항을 사용자 정의할 수 있도록 할 수 있는지 궁금해할 수밖에 없습니다.
예를 들어, APISIX에 100개의 플러그인이 있다면, 사용자는 이 100개 플러그인의 기능만 볼 수 있으며, 그들의 기본 유연성을 볼 수 없습니다. 따라서 미들웨어를 개발할 때, 우리는 제품이 무엇이 될 수 있는지, 그리고 사람들이 이를 사용할 때 더 많은 가능성을 부여할 수 있는 방법을 고려해야 합니다.
APISIX는 현재 거의 100개의 플러그인을 가지고 있지만, 100개 이상의 가능성을 가지고 있습니다. 따라서 플러그인 배열 기능을 개발한 후, 조합은 100 * 99 * 98 * 97 * 96 * ...에 가까워져 거의 무한에 가깝습니다.
예를 들어, 사용자의 속도를 제한한 후에는 일반적으로 오류 코드가 발생합니다. 이 경우 로깅 플러그인이나 오류 보고 플러그인을 연결하여 후속 활동을 기록할 수 있습니다. 아래 그림은 APISIX의 플러그인 오케스트레이션 모델을 보여줍니다.
이 기능에는 숨겨진 이점이 있습니다: 각 플러그인의 코드를 완전히 테스트하는 테스트 스위트가 있습니다. 사용자가 플러그인을 배열할 때, 어떤 코드도 작성할 필요가 없습니다. 이 설계는 제품 관리자, 보안 엔지니어, 운영 및 유지보수 엔지니어에게 매우 친화적입니다. 그들은 긴 시간 동안 교육과 학습을 할 필요 없이 플러그인을 드롭하여 설정을 조정함으로써 새로운 APISIX 플러그인을 만들 수 있습니다. 또한, 새로운 플러그인 코드의 품질은 오픈소스 APISIX의 공식 코드만큼 높습니다.
전방향 트래픽을 위한 게이트웨이
게이트웨이 관련 개발을 하는 서버 측 엔지니어라면 두 가지 기본 개념에 익숙할 것입니다: 클라이언트, 브라우저 또는 IoT(사물인터넷) 장치에서 서버로의 트래픽을 의미하는 남북 트래픽과 기업 내 시스템 및 마이크로서비스 간의 상호 호출을 의미하는 동서 트래픽입니다.
남북 트래픽과 동서 트래픽을 처리하는 구성 요소는 다릅니다. 예를 들어, 남북 트래픽은 로드 밸런서를 통과하여 API 게이트웨이로 이동한 후 서비스 게이트웨이로 들어갈 수 있습니다. 이것이 NGINX, APISIX, Spring Cloud Gateway와 같은 구성 요소가 있는 이유입니다. 동서 트래픽을 처리할 때는 Envoy와 같은 구성 요소를 사용할 수 있으며, 이는 많아 보이지만 기능에 초점을 맞추면 그들의 유사점을 찾을 수 있습니다. 대부분은 라우팅 스케줄링, 동적 업스트림, 보안 인증을 위한 플러그인입니다. 이 경우, 남북 및 동서 트래픽을 처리하는 구성 요소를 통합할 수 있을까요? 이상적인 방법은 클라이언트의 요청이 서버에 들어올 때 APISIX가 모두 처리하는 것입니다. 남북이든 동서든 모든 트래픽과 데이터는 컨트롤 플레인을 통해 제어됩니다. 이것은 현재 APISIX의 기술로 완전히 실현 가능합니다.
일부 사용자들은 이미 이 모드가 사용자의 운영 및 유지보수 비용을 크게 줄일 수 있다는 것을 확인했습니다. 동시에, 복잡성을 줄여 전체 시스템의 응답 속도를 향상시킬 수 있습니다. 또한, 이러한 긍정적인 피드백은 APISIX의 후속 반복에 대해 더 명확한 방향을 제공하여 APISIX가 전체 트래픽 게이트웨이 수준에서 더 많은 기능과 역할을 시도할 수 있도록 합니다.
다중 서비스 발견 구성 요소 지원
게이트웨이는 기본적이지만 중요한 구성 요소입니다. 모든 클라이언트 요청을 처리하고 다양한 시스템 및 오픈소스 프로젝트와 통합하는 것이 더 중요합니다.
또 다른 중요한 구성 요소 - 서비스 발견 및 등록은 다른 요소와 통합할 때 사용됩니다. 사용자는 Eureka 및 Nacos와 같은 다양한 서비스를 별도의 부분에 배치할 것입니다. 결과적으로, 대규모 및 장기간의 IT 시스템에서는 여러 서비스 발견 구성 요소가 공존하는 것이 일반적입니다.
이러한 상황에서, 모든 트래픽 입구와 출구는 게이트웨이가 됩니다. 거의 모든 게이트웨이는 하나의 서비스 발견만 지원합니다. A 라우트에는 별도의 Nacos 서비스 발견 구성 요소를 지정하고 B 라우트에는 또 다른 Consul 구성 요소를 지정해야 합니다. 결과적으로, 특정 게이트웨이를 다른 서비스 발견 구성 요소와 일치시키기 위해 여러 게이트웨이를 배포해야 합니다.
현재, APISIX는 데이터 플레인에서 서비스 발견을 지원할 뿐만 아니라 컨트롤 플레인에서 서비스 등록 및 서비스 발견 구성 요소를 점차 지원하고 있습니다. 이는 일부 대규모 및 장기간의 기업 서비스에 매우 효율적인 솔루션입니다. 하나의 API 게이트웨이만 배포하여 다양한 서비스 발견 및 등록 구성 요소에 쉽게 연결할 수 있습니다.
멀티 클라우드 및 하이브리드 클라우드 시나리오 탐구
사용자가 클라우드 네이티브 아키텍처를 갖춘 프로덕션 환경에 게이트웨이를 배포한다면, 멀티 클라우드 및 하이브리드 클라우드는 장기적인 기술 시나리오가 될 것입니다. 반면에, APISIX가 모든 기능, 성능, 플러그인 및 다중 서비스 발견을 갖추고 있다면, 문제는 사용자가 프로덕션 환경에서 더 잘 실행할 수 있도록 하는 방법에서 비롯됩니다. 멀티 클라우드 및 하이브리드 클라우드 시나리오는 APISIX에 더 많은 도전을 가져옵니다. 따라서 다음과 같은 세부 사항을 고려해야 합니다.
1. 업스트림 및 다운스트림 모두 mTLS 지원
이전에는 업스트림 mTLS를 지원하는 기능이 높은 우선순위가 아니라고 생각했습니다. 그러나 크로스 클라우드 시나리오에서는 업스트림이 다른 클라우드의 서비스가 되거나 심지어 다른 SaaS 서비스가 될 수 있습니다. 따라서 데이터 보안을 향상시키기 위해 업스트림 mTLS를 지원하는 것이 필요합니다.
2. 컨트롤 플레인과 데이터 플레인 아키텍처의 완전한 분리
지난 몇 년 동안 APISIX의 몇 가지 보안 취약점이 노출되었으며, 대부분은 컨트롤 플레인과 데이터 플레인의 혼합 배포에서 비롯되었습니다. 즉, APISIX 서비스가 시작된 후 컨트롤 플레인과 데이터 플레인이 동일한 서비스에 있습니다. 따라서 해커가 특정 데이터 플레인을 보안 취약점을 통해 침입하면 컨트롤 플레인에도 침입하여 전체 데이터를 제어할 수 있으며, 이는 치명적인 결과를 초래할 수 있습니다.
3. 안전 관리 강화
게이트웨이는 일반적으로 일부 민감한 데이터를 저장합니다. 예를 들어, 일부 사용자는 SSL 인증서 또는 etcd에 연결하기 위한 중요한 정보를 게이트웨이에 저장할 수 있습니다. 이러한 상황에서 etcd 또는 데이터 플레인이 침해되면 심각한 데이터 유출이 발생할 수 있습니다. 따라서 일부 중요한 정보를 저장할 때는 Vault와 같은 키 저장 전용 구성 요소를 사용하여 민감한 데이터를 보호하는 것이 필요합니다.
4. 더 많은 클라우드 표준 통합
우리는 사용자가 멀티 클라우드 시나리오에서 다양한 클라우드 플랫폼에서 원활하게 실행할 수 있도록 보장하려고 합니다. 이는 사용자가 사용자 정의 플러그인을 구성할 필요가 없지만, APISIX가 다양한 클라우드의 표준, API 또는 기타 서비스를 직접 통합할 수 있도록 하는 것을 의미합니다. 이 모드는 사용자가 미리 적응할 수 있도록 하고 후속 사용에 편리함과 편안함을 보장합니다.
Apache APISIX의 지원자
APISIX의 개발 역사를 통해 많은 기술적 혁신이 이루어졌습니다. 코드 구축 단계부터 함께 일해온 커뮤니티 기여자들이 APISIX를 통합된 API 게이트웨이로 만들었습니다. 오늘날 APISIX는 지원자들의 노력 덕분에 빠른 반복을 유지하고 있습니다.
오픈소스 제품의 반복과 업그레이드는 기여자와 사용자에게 기인합니다.
APISIX가 3년 전 Apache 소프트웨어 재단에 기증되었을 때, 이는 불완전한 프로젝트였으며 20명의 기여자만 있었습니다. 다행히 APISIX는 빠른 발전 덕분에 전 세계적으로 더 많은 사용자, 기여자 및 기업을 끌어모았습니다. 예를 들어, 우리의 고객에는 Tencent, WPS, Sina Weibo, iQiyi와 같은 회사가 포함되어 있으며, 매일 수십억 건의 API 호출을 처리합니다. 또한 NASA, European Factory Platform, Swisscom 등 다양한 산업의 국제 사용자들도 우리의 고객 목록에 포함되어 있습니다.
WPS를 예로 들어보겠습니다. 이는 중국의 SaaS 오피스 소프트웨어 회사로, Microsoft Office 365와 같은 소프트웨어를 제공합니다. 여러 사람이 모바일, 브라우저 또는 터미널 장치에서 동일한 문서를 편집하고 수정 사항을 동시에 볼 수 있습니다. 이 기능은 다양한 API 호출을 통해 실현됩니다.
대부분의 거대 기업들은 수십억 건의 API 호출을 처리하며, QPS 피크가 100만을 초과합니다. 이러한 사용 규모는 APISIX가 대규모 상황에서 실제 사용자로부터 피드백을 얻을 수 있도록 합니다. 이러한 기업 사용자들의 지원 덕분에 APISIX는 빠르게 성숙한 오픈소스 프로젝트로 발전할 수 있었습니다.
또한, 많은 사용자들이 커뮤니티에서 APISIX 사용 경험이나 코드 기능 반복을 공유하며, 상호 이익과 윈윈을 달성하고 있습니다. 이는 사용자들이 APISIX를 좋은 제품으로 여길 뿐만 아니라 가치 있는 오픈소스 프로젝트로 여기고 있음을 보여줍니다. 우리가 개발자들의 신뢰를 얻은 후에야 가치 있는 오픈소스 프로젝트가 될 수 있습니다.
기여자들은 경험과 피드백을 적응시켜 많은 제품 기능을 만들고, 사용자들은 이러한 기능을 활용하여 기업에 가치를 가져다줍니다. 이러한 선순환이 발생하며, 이것이 오픈소스의 본질입니다. 우리는 항상 이러한 진실을 찾고 있으며, 수많은 팔로워의 거품을 맹목적으로 추구하지 않습니다.
APISIX 3.0 미리보기
지금까지 우리는 APISIX가 과거와 현재에 무엇을 했는지에 대해 많이 이야기했습니다. APISIX의 개발 과정은 여러 단계로 나눌 수 있습니다.
APISIX 1.0은 프레임워크를 구축하고 기본 아키텍처를 강화하며 API 게이트웨이의 필수 기능을 제시하는 것이었습니다. 2.0 버전에서는 더 깊이 탐구하여 기본을 더 유연하게 만들고 아키텍처를 더 성숙하게 만들었습니다.
성숙한 오픈소스 프로젝트의 경우, 그 성숙의 징후는 훌륭한 기능에 초점을 맞추는 것이 아니라 사용자와 개발자에게 더 나은 경험을 제공하는 데 있습니다.
현재 단계에서 APISIX는 많은 기술적 탐구와 혁신을 이루었지만, 사용자 경험을 완전히 고려하지는 못했습니다. 이 문제는 문서 품질의 불안정성과 튜토리얼 비디오의 부족으로 나타납니다. 따라서 많은 사용자들이 처음 APISIX를 접할 때 어떻게 사용해야 하는지, 특정 기능을 다양한 사용 사례에 어떻게 적용해야 하는지, APISIX가 기업에 어떤 독특한 가치를 가져다줄 수 있는지에 대해 혼란스러워합니다.
따라서 다음 APISIX 3.0 버전에서는 이러한 문제를 해결하고 개발자 경험에 불친절한 많은 결함을 재구성하려고 합니다. 예를 들어, etcd의 특정 반환 값에 대한 의존성을 제거하기 위해 API를 재설계하고, 공식 문서를 더 사용자 친화적이고 간결한 설명으로 갱신할 것입니다. 기능 측면에서, 컨트롤 플레인과 데이터 플레인을 분리하여 보안을 강화하고, 더 많은 레이어 4 프로토콜 및 RPC 프로토콜을 지원하여 사용자가 모든 게이트웨이 방향에서 트래픽을 빠르게 얻을 수 있도록 할 것입니다.
위 기능을 구현한 후, APISIX 3.0은 더 안전하고 신뢰할 수 있으며 사용하기 쉬워질 것입니다. 우리는 항상 우수한 운영과 사용자 경험에 주의를 기울입니다. 우리는 APISIX가 전 세계의 모든 API 및 마이크로서비스 요청을 처리하고 기업이 API 및 마이크로서비스 트래픽을 더 효율적으로 관리할 수 있도록 돕기를 바랍니다.
APISIX는 2022년 말에 새로운 버전인 3.0을 출시할 예정입니다. 최신 버전의 APISIX 동향을 계속 팔로우하고 Apache APISIX 프로젝트의 기여에 적극적으로 참여해 주시기 바랍니다.
APISIX의 미래
서버 측 기술의 개발과 교체는 매우 빠릅니다. 5년 전에 인기 있었던 많은 기술과 프레임워크가 사라지고 있습니다. 그 이유는 엔지니어들이 새로운 것을 선호하기 때문이 아니라, 이러한 기술이 엔지니어와 기업의 실제 요구를 충족시키지 못하기 때문입니다. 그들의 운명은 정해져 있습니다: 점점 사라질 것입니다. 이 중요한 현실은 기술이 비즈니스와 제품을 위해 서야 하며, 현재 시장 요구에 맞지 않으면 생존할 수 없다는 것을 알려줍니다.
"늪 위에 성을 짓지 마라." 이 말은 Apache APISIX의 개발자들에게 항상 실제 요구와 시나리오에 의존하여 개발과 진화를 이끌어야 한다는 것을 상기시킵니다. 그렇지 않으면 제품은 점점 엔지니어들에게 버려질 것입니다.
Apache APISIX의 기술이 업계에서 선두를 유지하려면 어떻게 해야 할까요? 이것은 Apache APISIX가 앞으로도 개발자와 기업 사용자를 계속 끌어모을 수 있는지에 대한 중요한 질문입니다. 답은 간단합니다: 빠르게 성장하는 회사와 엔지니어들과 함께 성장하고 서로 지원하는 것입니다. 이것이 Apache APISIX가 항상 기술의 최전선에 서 있도록 합니다. 이를 통해 APISIX는 세계적인 상록 오픈소스 프로젝트가 될 잠재력을 가질 수 있습니다.
APISIX의 미래는 Serverless 시나리오를 더 잘 지원하고, 서비스 메시를 개선하며, API 전체 생명주기 플랫폼을 구축하고, 퍼블릭 클라우드에서의 사용자 경험을 개선하는 것입니다. 이것은 소수의 내부 개발자에 의해 계획된 것이 아니라 업계의 수천 명의 개발자에 의해 계획된 것입니다. 그러니 우리와 함께 오픈소스의 매력을 경험해 보세요!