서비스 메시 열풍: Aspen Mesh와 NGINX 중 선택하기

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

더 큰 컨테이너 생태계와 함께 서비스 메시도 계속해서 성숙 단계로 나아가고 있습니다. 하지만 아직은 초기 단계이며, 서비스 메시를 활용해 컨테이너 간 트래픽 관리 문제를 해결하기 위한 다양한 접근 방식이 적용되고 있습니다.

우리(여기서 '우리'는 회사를 뜻합니다)는 올봄 NGINX를 공식 인수하기 전까지 많은 질문을 받았습니다. 그중 상당수는 기술과 솔루션이 "중복되는" 영역에 관한 것이었습니다. 결국 NGINX와 F5 모두 프록시 기반 애플리케이션 딜리버리 솔루션을 제공하고 있으며, 둘 다 서비스 메시를 구축하고 있습니다. 그렇다면 어느 쪽이 승자가 될까요?

인수합병에서는 흔히 그렇게 되기 때문입니다.

NGINX 측 담당자와 제가 여러 차례 강조했듯이, 서로 중복된다고 지적된 기술들은 저희가 보기에 경쟁 관계라기보다 상호 보완적인 관계에 더 가까웠습니다. 이는 양사의 서비스 메시 솔루션에도 마찬가지로 적용됩니다.

이러한 논리는 애플리케이션 딜리버리에 대한 공통된 비전에서 비롯됩니다. 양측 모두 컨테이너와 클라우드, 마이크로서비스, 빈번한 보안 침해가 애플리케이션 딜리버리 아키텍처와 모델에 미치는 영향을 인식하고 있습니다. 이제 더 이상 "모든 애플리케이션을 제공하는 하나의 데이터 경로"가 존재하지 않는 것처럼, "모든 애플리케이션 서비스를 제공하는 하나의 애플리케이션 딜리버리 모델"도 존재하지 않습니다. 클라우드는 여러 데이터 경로를 만들고, 컨테이너는 새로운 데이터 경로를 추가합니다. 이 두 기술은 애플리케이션 서비스를 배치할 수 있는 위치를 네트워크 기반 프록시(ADC)에서 클라이언트, 네트워크, 서버, 컨테이너, 클라우드에 이르는 다양한 영역으로 확장합니다.

앞서 아키텍처에 초점을 맞춘 게시물과 Bridging the Divide 시리즈에서 언급했듯이, 애플리케이션 서비스를 어디에서 어떤 방식으로 제공할지는 여러 요인에 따라 달라집니다. 이는 단순히 공급업체의 구현 방식이나 "엔터프라이즈 대 FOSS" 중 하나를 선택하는 문제가 아닙니다. 위치(클라우드 또는 온프레미스), 운영 모델은 물론 구현 편의성과 필수 기능 간의 균형까지 고려해야 합니다. 제공 경로가 광범위하다는 점을 감안하면 애플리케이션 서비스를 삽입할 수 있는 선택지는 다양합니다.

이것이 바로 우리가 F5와 NGINX의 통합 포트폴리오를 경쟁 관계가 아닌 상호 보완 관계로 보는 이유입니다. 애플리케이션 딜리버리 시장 전반의 경쟁이 더 이상 단일 위치에 배치되기 위한 경쟁이 아니라 여러 위치에 배치되기 위한 경쟁으로 바뀌었기 때문입니다.

서비스 메시는 컨테이너 환경의 확장성과 보안을 강화하고 가시성을 제공하도록 설계되었습니다. 아직 초기 단계에 있으며 빠르게 발전하는 기술인 만큼 여러 모델이 등장하고 있습니다. 그중 하나는 사이드카 프록시를 사용하는 방식이며(Envoy는 선도적인 CNCF 프로젝트이자 업계 표준 사이드카 프록시로 자리 잡았습니다), 다른 하나는 NGINX Plus와 같은 애플리케이션별 프록시를 활용하는 방식입니다.

현재로서는 두 가지 모두 지원할 계획입니다. 컨테이너와 관련해서는 고객마다 인프라 선택에 대한 선호가 매우 뚜렷하기 때문입니다. 일부는 Istio와 Envoy를 선호하고, 다른 일부는 모든 것을 NGINX로 표준화했습니다.

컨테이너 환경에서 운영하고 관리해야 하는 구성 요소가 매우 많기 때문에 서비스 메시를 선택할 때 기존 기술에 대한 전문 지식이 중요한 요소로 작용합니다. 인프라를 NGINX로 표준화한 조직은 NGINX 프록시 또는 NGINX Unit부터 NGINX Controller에 이르기까지 모든 구성 요소가 NGINX 소프트웨어로 이루어진 NGINX 서비스 메시 솔루션을 자연스럽게 선호할 가능성이 높습니다. NGINX와 그 오픈 소스 생태계에 대한 기존 운영 전문 지식을 활용하면 배포 과정의 마찰과 지연을 줄일 수 있습니다.

다른 조직들도 Istio 및 Envoy와 같은 대체 오픈 소스 솔루션에 대해 같은 견해를 가지고 있습니다. Aspen Mesh는 Envoy를 사용하고 Istio를 기반으로 구현되므로, 기반 기술에 이미 투자한 조직에 더 적합한 선택입니다. 이는 테스트와 보안 강화, 패키징 및 검증을 거친 Istio 배포판입니다. Aspen Mesh는 Istio에 여러 기능을 추가합니다. 여기에는 Aspen Mesh 대시보드를 통한 더 간편한 사용자 경험, 사용자가 비즈니스 목표를 지정하고 측정하며 적용할 수 있는 정책 프레임워크, 그리고 Istio Vet 및 Traffic Claim Enforcer와 같은 도구가 포함됩니다. Aspen Mesh는 NGINX와 마찬가지로 F5 BIG-IP과도 원활하게 통합됩니다.

NGINX와 Aspen Mesh는 모두 Kubernetes 클러스터의 관리 및 시각화 기능을 제공합니다. Aspen Mesh와 NGINX는 모두 온프레미스 옵션으로 솔루션을 제공합니다. 또한 두 솔루션 모두 가시성 문제를 해결하는 데 필수적인 추적 및 메트릭 기능을 제공합니다. 가시성 문제는 Replex의 Kubernetes 현황 보고서에서 조직의 37%가 꼽은 주요 프로덕션 과제입니다.

서비스 메시에 사이드카 프록시 기반 접근 방식을 선호하는 조직은 Aspen Mesh를 선호할 것입니다. 애플리케이션별 프록시 기반 서비스 메시가 자사의 요구 사항에 가장 적합하다고 판단하는 조직은 NGINX를 선호할 것입니다.

어떤 솔루션을 선택할지는 다양한 요인에 따라 달라집니다. 또한 저희는 이 신흥 분야가 충분히 중요하다고 판단하여, 서로 다른 요구 사항과 필요의 조합을 충족하는 다양한 선택지를 지속적으로 지원하고자 합니다.

작성자 소개

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.

Lori Mac Vittie의 다른 블로그 게시물