Apache APISIX, 서비스 메시와 통합된 전체 트래픽 관리 통합

클라우드 네이티브의 급속한 성장과 함께, 서비스 메시(Service Mesh)도 점점 뜨거워지고 있습니다. 현재 많은 유명한 서비스 메시 솔루션이 있으며, 각 제품마다 고유한 장점을 가지고 있습니다. 따라서 서비스 메시 솔루션의 결정은 다양한 산업이나 비즈니스 배경에 따라 개인마다 다릅니다.

서비스 메시의 현황과 문제점

서비스 메시의 등장은 현재 비즈니스 아키텍처의 진화와 밀접하게 연결되어 있습니다. 클라우드 네이티브의 급성장과 함께, 대부분의 기업들은 마이크로서비스로의 전환을 시작했으며, 이 과정에서 애플리케이션이 점점 작아지고 각 애플리케이션 내부에 공통적인 요소가 있음을 발견했습니다. 그래서 우리는 "공통 시나리오를 해결할 수 있는 기술이 있을까?"라는 생각을 하게 되었고, 이에 따라 사이드카(Sidecar)가 등장했습니다.

사이드카를 통해 서비스 등록 및 발견, 트래픽 관리, 관찰 가능성, 보안과 같은 기능을 사이드카로 옮길 수 있게 되어, 비즈니스 서비스는 비즈니스 로직 개발에 집중할 수 있게 되었습니다.

하지만 사이드카의 등장은 실무에서 몇 가지 문제점을 점차 깨닫게 했습니다. 예를 들어:

• 너무 많은 솔루션이 있어 선택 후 이전이 어렵다. 현재 수많은 서비스 메시 솔루션이 있으며, 각 솔루션마다 특성과 기능이 다릅니다. 한 번 선택한 솔루션은 더 이상 교체되지 않습니다. 그러나 비즈니스가 확장되면서 새로운 요구 사항을 충족하기 어려울 경우, 이전에는 큰 비용이 발생합니다.
• 인프라와의 통합 비용이 높다. 실무에서 구현된 서비스 메시는 종종 이전의 마이크로서비스 아키텍처, MQ, 데이터베이스 인프라 구성 요소와의 통합이 필요합니다. 레거시 문제나 역사적인 기술 부채도 통합 과정에서 저항을 일으킬 수 있습니다.
• 성능 손실과 추가 자원 소비. 현재 어떤 서비스 메시 솔루션을 선택하더라도 일정 수준의 성능 손실이 발생합니다. 또한 사이드카로 인해 비즈니스를 구성할 때 추가 자원을 할당해야 합니다.
• 확장성이 심각하게 어렵다. 일부 서비스 메시 솔루션은 프로토콜이나 기능 측면에서 기존 구성 방법으로 확장할 수 없으며, 플러그인 방식으로 커스터마이징이 불가능합니다.

따라서 이러한 비즈니스 상황과 문제점 속에서, 우리는 이러한 문제를 해결할 수 있는 이상적인 서비스 메시 솔루션이 있을지 고민하게 되었습니다.

이상적인 서비스 메시는 어떤 모습일까?

비즈니스 시나리오에서 우리가 서비스 메시에 요구하는 사항은 위와 같습니다. 즉, 자원, 성능, 트래픽 관리, 확장성 측면에서 다양한 요구 사항이 있습니다. 물론 이 외에도 다른 차원에서 더 세부적인 요구 사항이 있을 수 있습니다. 예를 들어:

• 첫째, 사용 경험 측면에서 시작 비용이 낮아야 합니다. 서비스 메시를 적용하기 위해 개발자보다 운영 및 유지보수 작업이 더 많을 수 있으므로, 시작 비용은 솔루션 선택의 중요한 요소 중 하나입니다.
• 둘째, 기술적 측면에서 컨트롤 플레인의 구성이 쉽게 시작할 수 있어야 합니다. 동시에 관련 권한을 엄격하고 안전하게 제어할 수 있어야 하며, 구성은 공개 수준에 가까워야 합니다.
• 데이터 측면에서는 여러 프로토콜 또는 심지어 사용자 정의 프로토콜을 기본적으로 지원하는 것이 좋습니다. 이는 일부 레거시 시스템 마이그레이션으로 인한 문제를 고려해야 하기 때문입니다. 사이드카의 존재로 인해 자원 소비가 관리 가능해야 하므로 비용을 효과적으로 통제할 수 있습니다. 또한 커스터마이징을 위한 확장성도 필요합니다.
• 마지막으로, 제품의 전체 생태계 내에서 커뮤니티와 제품 수리가 "적시 응답" 속도와 일치해야 합니다.

이렇게 명확한 요구 사항과 목표가 있으므로, 다음 단계는 이러한 이상적인 솔루션을 구현하고 구축하는 것입니다.

APISIX 기반 서비스 메시 솔루션

Apache APISIX는 동적, 실시간, 고성능 클라우드 네이티브 API 게이트웨이로, 로드 밸런싱, 동적 업스트림, 카나리 릴리스, 서킷 브레이커, 인증, 관찰 가능성 등 다양한 트래픽 관리 기능을 제공합니다.

전 세계 수백 개의 기업이 이미 Apache APISIX를 사용하여 비즈니스 크리티컬 트래픽을 처리하고 있으며, 금융, 인터넷, 제조, 소매, 통신사 등 다양한 산업에서 사용되고 있습니다. 예를 들어 NASA, European Factory Platform, China Airlines, China Mobile, Tencent, Huawei, Weibo, Netease, Ke Holdings Inc., 360, Taikang, Nayuki Holdings Limited 등이 있습니다. 따라서 APISIX 기반 서비스 메시 솔루션은 사용 수준뿐만 아니라 다양한 산업 분야에서도 강력한 수요가 있을 것입니다.

현재 서비스 메시 솔루션의 아키텍처는 Istio를 컨트롤 플레인으로, APISIX를 데이터 플레인으로 사용합니다.

먼저, Istio를 컨트롤 플레인으로 선택한 이유는 Istio가 현재 가장 인기 있는 서비스 메시 솔루션이며, 활발한 커뮤니티를 가지고 있어 거의 모든 주요 클라우드 벤더가 Istio를 지원하기 때문입니다. 이는 현재 시장 수요와 방향을 어느 정도 반영합니다. 따라서 컨트롤 플레인 선택에 있어 자체 개발 모듈을 사용하지 않고, Istio를 수용하는 것이 더 적합하고 높은 수용률을 보장합니다.

데이터 플레인은 Apache APISIX가 강점을 발휘할 수 있는 부분입니다. 클라우드 네이티브 API 게이트웨이로서, APISIX는 이 서비스 메시 솔루션에서 Istio의 데이터 플레인으로 어떤 조치를 취했을까요?

APISIX에 익숙한 사람들은 APISIX가 etcd를 데이터 저장소로 사용한다는 것을 알고 있습니다. 하지만 APISIX를 사이드카로 사용한다면, 그 구성은 어디에서 오는 것일까요? 이것이 고려해야 할 문제입니다. etcd 구성 요소를 사이드카에 포함시키면 전체 자원 소비가 매우 크고 유연성이 떨어집니다.

따라서 이 과정에서 우리는 먼저 APISIX에 xDS라는 구성 센터를 추가하여 etcd의 필요성을 없앴고, 그런 다음 Amesh를 도입했습니다. 위 그림과 같이, Amesh는 Go 프로그램으로 작성된 동적 링크 라이브러리로, APISIX가 시작될 때 로드됩니다. 이는 xDS 프로토콜을 사용하여 Istio와 상호 작용합니다. 그런 다음, 얻은 구성을 APISIX의 xDS 구성 센터에 기록하고, 이는 특정 라우팅 규칙을 생성하며, 결국 APISIX를 사용하여 해당 요청을 라우팅합니다.

위 아키텍처 구성을 통해 다음과 같은 결과를 얻을 수 있습니다:

• Amesh와 APISIX는 동일한 생명주기를 유지하며 함께 켜고 끌 수 있습니다.
• APISIX의 xDS Discovery 기본 지원 덕분에, 데이터는 xDS 프로토콜을 통해 상호 변환되며, 자원 소비 수준이 제어됩니다.
• CRD를 사용하여 전체 솔루션을 빠르고 쉽게 확장할 수 있으며, 특히 Istio에서 아직 지원되지 않는 기능에 대해 확장할 수 있습니다. 예를 들어, APISIX에 가장 풍부한 플러그인 구성을 CRD로 구성할 수 있으며, 컨트롤러와 Istio를 함께 사용하여 Istio와 APISIX 서비스 메시 솔루션의 확장성을 극대화할 수 있습니다.

솔루션의 구체적인 성능

상당한 성능 개선

데이터는 항상 기술 제품을 가장 직관적이고 효과적으로 보여주는 방법입니다. 우리는 서비스 메시 솔루션에서 APISIX와 Envoy를 데이터 플레인으로 사용하고, 5,000개의 라우트를 사용하여 다양한 시나리오에서 스트레스 테스트를 진행한 후, 다음과 같은 데이터 비교를 제시합니다.

테스트 시나리오는 "5,000개 라우트 중 3,000번째 라우트 매칭"입니다. 테스트 시나리오가 많아 중간 부분의 라우트 매칭만 설명하며, 앞부분과 뒷부분의 라우트 매칭 시나리오도 있습니다. (데이터가 너무 많아 3,000개 라우트 테스트 결과만 표시합니다).

위 데이터에서 볼 수 있듯이, 동일한 압력과 동일한 머신 구성에서 APISIX는 QPS 수준에서 5배의 성능 향상을 보여줍니다. 또한 요청 지연 시간 측면에서 APISIX는 Envoy보다 낮은 마이크로초 범위를 유지하며, Envoy는 밀리초 범위입니다. 또한 이 측정에서 APISIX의 CPU 소비는 Envoy가 이미 최대 용량으로 실행 중일 때 50%에 불과합니다.

자원 사용량 감소

서비스 메시 솔루션에 사이드카를 주입할 때, 일반적으로 추가 자원이 소비됩니다. API 기반 솔루션은 자원 소비를 60%까지 줄일 수 있습니다. 왜 이런 것이 가능할까요?

첫째, 구성은 필요에 따라 분배됩니다. Istio는 사이드카의 자원 관리를 위한 일부 필요에 따른 정책을 제공하지만, 이 과정은 사용자 운영에 추가적인 부담과 관리 어려움을 초래합니다.

둘째, 구성이 이해하기 쉬운지 여부입니다. Envoy에서 라우트를 구성할 때, Dump를 통해 확인하면 이미 수천 개의 라우트 정보가 있는 반면, 실제로는 그렇게 많지 않습니다. 이는 시작 속도에 영향을 미치고 일부 구성이 부피가 커져 자원 사용량을 증가시킵니다.

APISIX를 사용하면 이러한 문제를 모두 피할 수 있습니다. APISIX 구성은 간단하고 명확하며, 메모리에 저장된 데이터를 줄이고, 고성능과 결합하여 CPU 자원 소비를 줄입니다. 전체 솔루션의 자원 소비는 약 60% 감소합니다.

낮은 학습 비용과 높은 커스터마이징 능력

첫째, Apache Software Foundation의 활발한 오픈 소스 프로젝트인 APISIX는 커뮤니티에서 풍부한 문서와 학습 리소스를 제공하여 APISIX를 시작하려는 사람들의 학습 비용을 줄입니다.

둘째, APISIX의 소스 코드는 Lua로 구현되어 있어 비교적 읽기 쉽고 이해하기 쉬운 경량 스크립트 언어이므로, APISIX 소스 코드를 보는 것이 더 명확합니다.

마지막으로, APISIX 기반의 2차 개발은 매우 쉽습니다. 비즈니스를 위해 플러그인을 커스터마이징하려는 경우, 기본 Lua 언어뿐만 아니라 Python, Java, Go, 심지어 Wasm과 같은 더 익숙한 언어로 2차 개발을 구현할 수 있습니다.

APISIX의 생태계적 힘은 제품의 강력한 확장성 덕분입니다.

APISIX 자체는 보안, 로깅, 관찰 가능성 등을 위한 다양한 플러그인을 제공합니다. 이러한 플러그인은 APISIX가 전통적인 게이트웨이 구성 요소로 사용될 때 최대한 활용할 수 있습니다. 그러나 APISIX가 컨트롤 플레인에서 Istio와 함께 사용되어 서비스 메시를 생성할 때, 많은 리소스가 Istio 컨트롤 플레인에 정의되지 않습니다. 이 경우 어떻게 할 수 있을까요?

그것이 바로 사용자 정의 CRD를 사용하는 것입니다. 예를 들어, 우리가 결함 주입 플러그인을 만들고 싶다면, 이 플러그인은 이미 APISIX에 있으므로 여기서 몇 가지 추가 매개변수만 구성하면 됩니다. 물론 여기서는 결함 주입 플러그인의 예시일 뿐이며, APISIX에는 보안 인증, 속도 제한 등 일반적인 플러그인도 이 방법으로 접근하여 세밀한 제어를 달성할 수 있습니다.

이렇게 CRD를 사용하는 가장 직접적인 이점은 확장이 더 원시적이 되고, 선언적 구성을 사용하여 사용자가 더 쉽게 수용할 수 있도록 하면서도 Istio의 원래 구성을 침해하지 않고 완벽한 호환성을 유지할 수 있다는 것입니다. 또 다른 이점은 이미 Istio 솔루션을 사용 중인 사용자의 경우 마이그레이션 비용이 낮아진다는 것입니다.

요약하자면, APISIX 기반 서비스 메시 솔루션은 개발자나 사용자에게 더 쉽게 사용하고 확장할 수 있으며, 우수한 성능과 풍부한 생태계 지원을 제공합니다. APISIX 제품의 능력 덕분에 플러그인과 다중 프로토콜 측면에서도 좋은 지원을 받을 수 있습니다. 우리는 올해 말 APISIX 기반 서비스 메시의 다음 버전을 여러분에게 선보일 예정입니다. 기대해 주세요!

APISIX 기반 서비스 메시 솔루션의 미래 전망

돌이켜보면, APISIX 기반 서비스 메시 솔루션은 이미 앞서 언급한 문제점을 해결하기 위해 노력하고 있으며, 이상적인 서비스 메시 솔루션을 향해 나아가고 있습니다.

APISIX 기반 서비스 메시 솔루션을 통해 외부에서 들어오는 트래픽이 APISIX Ingress를 통해 처리되고, 중간에 APISIX를 통해 처리되는 것을 볼 수 있습니다. 이 과정에서 APISIX Ingress는 남북 트래픽을 처리하고, Amesh + Istio는 동서 트래픽을 처리합니다.

이와 같은 배포 아키텍처는 비용 절감과 통합 기술 스택과 같은 비즈니스 수준의 가치를 가져올 수 있습니다. 전통적인 게이트웨이 내부에서 사용되던 공통 기능을 서비스 메시로 빠르게 복제할 수 있습니다. 이를 통해 비즈니스 수준에서 통합 관리가 가능하며, 비용을 통제하고 게이트웨이, Ingress, 서비스 메시에서의 경험을 높은 재사용성을 가질 수 있습니다.

향후 반복에서 APISIX 기반 서비스 메시 솔루션은 계속 심화될 것이며, 다음과 같은 계획된 방향을 달성할 것입니다:

• APISIX 기능과 함께 xRPC 기능 구현 구축.
• 기본적으로 이기종 다중 프로토콜 지원 수행.
• Istio를 포함한 모든 종류의 시나리오와 구성을 커버하여 사용자 마이그레이션 비용을 크게 줄임.

결론적으로, 현재 기술 트렌드 중에서 서비스 메시는 미래의 인기 트렌드가 될 것입니다. 비록 다양한 솔루션이 아직 완벽하지는 않지만, 전체적인 상황은 상승 곡선을 그리고 있습니다. 물론, APISIX 기반 서비스 메시도 모두가 생각하는 이상적인 서비스 메시 솔루션을 향해 나아가고 있습니다.