어떻게 선택해야 할까? API 게이트웨이 vs. 인그레스 컨트롤러 vs. 서비스 메시

Jenn GileNGINX 제품 마케팅 총괄

2021년 한 해 동안 진행한 Ingress 컨트롤러 및 서비스 메시에 관한 거의 모든 웨비나에서 다음과 같은 질문을 여러 형태로 받아 왔습니다. “이 도구는 API 게이트웨이와 어떻게 다른가요?” 또는 “Kubernetes에서 API 게이트웨이와 Ingress 컨트롤러(또는 서비스 메시)가 모두 필요한가요?”

이러한 혼란은 다음 두 가지 이유로 충분히 이해할 수 있습니다:

• 인그레스 컨트롤러와 서비스 메시는 API 게이트웨이의 다양한 사용 사례를 충족할 수 있습니다.
• 일부 공급업체는 자사의 API 게이트웨이 도구를 Ingress 컨트롤러나 서비스 메시의 대안으로 내세우거나, 이 세 가지 기능을 하나의 도구에 모두 통합하기도 합니다.

이 블로그에서는 이러한 도구의 차이점과 Kubernetes 전용 API 게이트웨이 사용 사례에 어떤 도구를 사용해야 하는지 살펴봅니다. 데모를 포함한 자세한 내용을 알아보려면 웨비나 Kubernetes를 위한 API 게이트웨이 사용 사례를 시청하세요.

정의

본질적으로 API 게이트웨이, Ingress 컨트롤러, 서비스 메시는 모두 트래픽을 환경 내부로 유입시키고 환경 내에서 전달하도록 설계된 프록시의 한 유형입니다.

API 게이트웨이란 무엇인가요?

API 게이트웨이는 클라이언트의 API 요청을 적절한 서비스로 라우팅합니다. 하지만 이 간단한 정의와 관련해 흔히 발생하는 큰 오해는 API 게이트웨이를 하나의 고유한 기술로 여긴다는 것입니다. 실제로는 그렇지 않습니다. 오히려 ‘API 게이트웨이’는 다양한 유형의 프록시를 통해 구현할 수 있는 일련의 사용 사례를 의미합니다. 가장 일반적으로는 ADC 또는 로드 밸런서와 리버스 프록시를 사용하며, 최근에는 Ingress 컨트롤러나 서비스 메시도 점점 더 많이 사용되고 있습니다.

업계에서는 도구가 API 게이트웨이 역할을 수행하기 위해 반드시 갖춰야 할 기능이 무엇인지에 대한 합의가 충분히 이루어지지 않았습니다. 일반적으로 고객이 요구하는 기능은 다음과 같습니다(사용 사례별로 분류):

복원력 사용 사례

• A/B 테스트, 카나리 배포 및 블루-그린 배포
• 프로토콜 변환(예: JSON과 XML 간 변환)
• 요청 속도 제한
• 서비스 디스커버리

트래픽 관리 사용 사례

• 메서드 기반 라우팅 및 매칭
• 요청/응답 헤더 및 본문 조작
• 레이어 7에서의 요청 라우팅

보안 사용 사례

• API 스키마 적용
• 클라이언트 인증 및 권한 부여
• 사용자 지정 응답
• 세분화된 액세스 제어
• TLS 종료

이러한 사용 사례는 거의 모두 Kubernetes에서 일반적으로 사용됩니다. 프로토콜 변환과 요청/응답 헤더 및 본문 조작은 대개 Kubernetes 및 마이크로서비스 환경에 적합하지 않은 레거시 API와 관련되어 있어 상대적으로 덜 사용됩니다.

API 게이트웨이 사용 사례에 대한 자세한 내용은 블로그의 NGINX를 API 게이트웨이로 배포하기, 1부에서 확인하세요.

인그레스 컨트롤러란 무엇인가요?

An Ingress 컨트롤러(Kubernetes Ingress Controller, 줄여서 KIC라고도 함)는 트래픽을 Kubernetes로 유입시켜 서비스에 전달한 후 다시 외부로 내보내는 특수한 레이어 4 및 레이어 7 프록시입니다. 이러한 트래픽을 인그레스-이그레스 트래픽 또는 남북 트래픽이라고 합니다. Ingress 컨트롤러는 트래픽 관리뿐만 아니라 가시성 확보 및 문제 해결, 보안 및 ID 관리, 그리고 최고 수준의 고급 기능을 제외한 대부분의 API 게이트웨이 사용 사례에도 활용할 수 있습니다.

Ingress 컨트롤러를 기본적인 트래픽 관리 이상의 용도로 활용하는 방법에 대해 자세히 알아보려면 블로그의 Ingress 컨트롤러 선택 가이드, 1부: 요구 사항 파악하기를 참조하세요.

서비스 메시란 무엇인가요?

A 서비스 메시는 Kubernetes 서비스 간에 흐르는 트래픽(서비스 간 트래픽 또는 동서 트래픽이라고 함)을 처리하며, 일반적으로 종단 간 암호화(E2EE)를 구현하는 데 사용됩니다. 고급 배포를 도입하거나 E2EE가 필요한 조직이 늘어나면서 서비스 메시 도입률은 아직 낮지만 점차 증가하고 있습니다. 서비스 메시는 앱과 매우 가까운 곳에서 분산형(경량) API 게이트웨이로 사용할 수 있으며, 이는 데이터 플레인 수준에서 서비스 메시 사이드카를 통해 구현됩니다.

서비스 메시와 서비스 메시를 도입할 적절한 시점에 대해 자세히 알아보려면 블로그의 서비스 메시 선택 방법을 참조하세요.

Kubernetes 환경에는 Kubernetes 네이티브 도구 사용

Mark Church가 NGINX Sprint 2.0에서 발표한 Kubernetes와 애플리케이션 네트워킹의 미래 기조연설에서 언급했듯이, “API 게이트웨이, 로드 밸런서, 서비스 메시는 앞으로 점점 더 서로 비슷해지고 유사한 기능을 제공하게 될 것입니다.” 저희도 이 말에 전적으로 동의하며, 결국 중요한 것은 어디에서, 그리고 어떻게 사용할지에 따라 작업에 적합한 도구를 선택하는 것이라고 덧붙이고 싶습니다. 마체테와 버터 나이프는 둘 다 무언가를 자르는 데 쓰이지만, 아침 식사로 먹을 토스트에 마체테를 사용하지는 않을 테니까요.

그렇다면 자신에게 적합한 도구는 어떻게 결정해야 할까요? 간단히 말씀드리겠습니다. Kubernetes 내에서 API 게이트웨이 기능이 필요하다면 일반적으로 YAML과 같은 Kubernetes 네이티브 구성 도구를 사용해 설정할 수 있는 도구를 선택하는 것이 가장 좋습니다. 대개 Ingress 컨트롤러나 서비스 메시가 이에 해당합니다. 하지만 “내 API 게이트웨이 도구는 Ingress 컨트롤러(또는 서비스 메시)보다 기능이 훨씬 많은데, 그러면 그런 기능들을 놓치는 것 아닌가요?”라고 생각하실 수도 있습니다. 그렇지 않습니다! 기능이 많다고 해서 더 좋은 도구인 것은 아닙니다. 특히 도구의 복잡성이 치명적인 문제가 될 수 있는 Kubernetes 환경에서는 더욱 그렇습니다.

참고: Kubernetes 네이티브(다음과 혼동하지 마세요: Knative)는 Kubernetes용으로 설계 및 개발된 도구를 의미합니다. 일반적으로 이러한 도구는 Kubernetes CLI와 함께 사용할 수 있고, Helm을 사용해 설치할 수 있으며, Kubernetes 기능과 통합됩니다.

대부분의 Kubernetes 사용자는 개발 또는 GitOps 환경을 변경하지 않아도 되므로 Kubernetes 네이티브 방식으로 구성할 수 있는 도구를 선호합니다. YAML 친화적인 도구는 다음과 같은 세 가지 주요 이점을 제공합니다:

• YAML은 Kubernetes 팀에 익숙한 언어이므로, 기존 Kubernetes 도구를 API 게이트웨이 기능에 활용한다면 학습 부담이 적거나 아예 없을 수도 있습니다. 따라서 팀은 가끔만 사용할 수도 있는 새로운 도구의 구성 방법을 따로 익힐 필요 없이 기존 역량을 그대로 활용해 작업할 수 있습니다.
• YAML과 호환되는 도구도 다른 Kubernetes 도구와 동일한 방식으로 자동화할 수 있습니다. 워크플로에 자연스럽게 통합되는 도구라면 팀에서도 선호할 것이며, 실제로 사용할 가능성도 높아집니다.
• Ingress 컨트롤러나 서비스 메시 또는 둘 다를 사용하면 Kubernetes 트래픽 관리 도구 스택을 간소화할 수 있습니다. 추가되는 모든 홉은 성능에 영향을 미치므로 불필요한 지연이나 단일 장애 지점을 만들 이유가 없습니다. 물론 Kubernetes 내에 배포되는 기술의 수를 줄이면 비용 절감과 전반적인 보안 강화에도 도움이 됩니다.

남북 방향 API 게이트웨이 사용 사례: Ingress 컨트롤러 사용

Ingress 컨트롤러는 다양한 API 게이트웨이 사용 사례를 지원할 수 있습니다. 정의에 설명된 사례 외에도, 조직에서는 다음 기능을 구현할 수 있는 Ingress 컨트롤러를 가장 중요하게 여기는 것으로 나타났습니다:

• 인증 및 권한 부여 오프로딩
• 권한 부여 기반 라우팅
• 계층 7 수준의 라우팅 및 매칭(HTTP, HTTP/S, 헤더, 쿠키, 메서드)
• 프로토콜 호환성(HTTP, HTTP/2, WebSocket, gRPC)
• 요청 속도 제한

샘플 시나리오: 메서드 수준 라우팅

메서드 수준의 매칭 및 라우팅을 구현하고, Ingress 컨트롤러를 사용하여 API 요청의 POST 메서드를 거부하려고 합니다.

일부 공격자는 API 정의를 준수하지 않는 유형의 요청을 전송하여 API의 취약점을 찾습니다. 예를 들어 GET 요청만 허용하도록 정의된 API에 POST 요청을 전송합니다. 웹 애플리케이션 방화벽(WAF)은 요청 문자열과 본문만 검사하여 공격 여부를 판단하므로 이러한 유형의 공격을 탐지할 수 없습니다. 따라서 Ingress 계층에서 API 게이트웨이를 사용해 잘못된 요청을 차단하는 것이 좋습니다.

예를 들어 새 API /coffee/{coffee-store}/brand가 클러스터에 방금 추가되었다고 가정해 보겠습니다. 첫 번째 단계는 API를 upstreams 필드에 추가하여 NGINX Ingress Controller를 통해 노출하는 것입니다.

apiVersion: k8s.nginx.org/v1kind: VirtualServer
metadata:
name: cafe
spec:
host: cafe.example.com
tls:
secret: cafe-secret
upstreams:
-name: tea
service: tea-svc
port: 80
-name: coffee
service: coffee-svc
port: 80

메서드 수준의 매칭을 활성화하려면 routes 필드에 /coffee/{coffee-store}/brand 경로를 추가하고, $request_method 변수를 사용하여 GET 요청과 POST 요청을 구분하는 두 가지 조건을 추가합니다. HTTP GET 메서드를 사용하는 모든 트래픽은 자동으로 coffee 서비스로 전달됩니다. POST 메서드를 사용하는 트래픽은 "요청이 거부되었습니다!"라는 메시지가 표시되는 오류 페이지로 이동합니다. 이렇게 하면 원치 않는 POST 트래픽으로부터 새 API를 보호할 수 있습니다.

routes: - path: /coffee/{coffee-store}/brand
matches:
- conditions:
- variable: $request_method
value: POST
action:
return:
code: 403
type: text/plain
body: "요청이 거부되었습니다!"
- conditions:
- variable: $request_method
value: GET
action:
pass: coffee
- path: /tea
action:
pass:tea

오류 페이지와 함께 메서드 수준 라우팅 및 매칭을 사용하는 방법에 대한 자세한 내용은 NGINX Ingress Controller 문서를 참조하세요. API 게이트웨이 기능에 Ingress 컨트롤러를 활용하는 보안 관련 예시는 블로그의 Okta 및 NGINX Ingress Controller를 사용하여 Kubernetes용 OpenID Connect 인증 구현하기를 읽어보세요.

동서 간 API 게이트웨이 사용 사례: 서비스 메시 사용

대부분의 API 게이트웨이 사용 사례에서는 서비스 메시가 필요하지 않으며, 초기에는 오히려 도움이 되지 않을 수도 있습니다. 달성하려는 작업의 대부분은 Ingress 계층에서 처리할 수 있고, 또 그렇게 하는 것이 바람직하기 때문입니다. 하지만 아키텍처가 복잡해질수록 서비스 메시를 활용해 더 큰 이점을 얻을 가능성이 높아집니다. 특히 유용한 사용 사례로는 E2EE와 트래픽 분할이 있으며, A/B 테스트, 카나리 배포, 블루-그린 배포 등이 이에 해당합니다.

샘플 시나리오: 카나리 배포

HTTP/S 기준에 따른 조건부 라우팅을 사용하여 서비스 간 카나리 배포를 설정하려고 합니다.

대부분의 프로덕션 트래픽에 영향을 주지 않으면서 새로운 기능이나 버전과 같은 API 변경 사항을 점진적으로 배포할 수 있다는 장점이 있습니다.

현재 NGINX Ingress Controller는 NGINX Service Mesh에서 관리하는 두 서비스인 Coffee.frontdoor.svc와 Tea.frontdoor.svc 간에 트래픽을 라우팅합니다. 이러한 서비스는 NGINX Ingress Controller에서 트래픽을 수신하여 Tea.cream1.svc를 비롯한 적절한 앱 기능으로 라우팅합니다. Tea.cream1.svc를 리팩터링하고 새 버전의 이름을 Tea.cream2.svc로 지정하기로 합니다. 베타 테스터에게 새 기능에 대한 피드백을 받고자 하므로 베타 테스터의 고유한 세션 쿠키를 기반으로 카나리 트래픽 분할을 구성하여 일반 사용자에게는 Tea.cream1.svc만 제공되도록 합니다.

NGINX Service Mesh를 사용하여 먼저 Tea.cream1.svc 및 Tea.cream2.svc를 비롯해 Tea.frontdoor.svc가 프런트엔드 역할을 하는 모든 서비스 간에 트래픽 분할을 생성합니다. 조건부 라우팅을 활성화하려면 HTTPRouteGroup 리소스(이름: tea-hrg)를 생성하여 트래픽 분할과 연결합니다. 그러면 베타 사용자로부터 온 요청(세션 쿠키가 version=beta로 설정된 요청)만 Tea.frontdoor.svc에서 Tea.cream2.svc로 라우팅됩니다. 일반 사용자는 계속해서 Tea.frontdoor.svc 뒤에 있는 버전 1 서비스만 이용하게 됩니다.

apiVersion: split.smi-spec.io/v1alpha3kind: TrafficSplit
metadata:
name: tea-svc
spec:
service: tea.1
backends:
- service: tea.1
weight: 0
- service: tea.2
weight: 100
matches:
- kind: HTTPRouteGroup
name: tea-hrg

apiVersion: specs.smi-spec.io/v1alpha3
kind: HTTPRouteGroup
metadata:
name: tea-hrg
namespace: default
spec:
matches:
- name: beta-session-cookie
headers:
- cookie: "version=beta"

이 예에서는 카나리 배포를 0‑100 비율로 시작하므로 모든 베타 테스터가 Tea.cream2.svc를 사용하게 됩니다. 물론 베타 테스트 전략에 맞는 비율로 시작할 수도 있습니다. 베타 테스트가 완료되면 간단한 카나리 배포(쿠키 라우팅 제외)를 사용하여 Tea.cream2.svc의 복원력을 테스트할 수 있습니다.

NGINX Service Mesh의 트래픽 분할에 대한 자세한 내용은 문서를 참조하세요. 위의 트래픽 분할 구성은 루트 서비스가 백엔드 서비스로도 나열되어 있으므로 자기 참조 방식입니다. 이 구성은 현재 Service Mesh Interface 사양(smi-spec)에서 지원되지 않습니다. 다만 이 사양은 현재 알파 단계이므로 변경될 수 있습니다.

Kubernetes 앱에 API 게이트웨이 도구를 사용해야 하는 시점과 방법

Kubernetes에서 API 게이트웨이가 필요한 대부분의 사용 사례는 Ingress 컨트롤러나 서비스 메시로 해결할 수 있고 또 그렇게 하는 것이 바람직하지만, NGINX Plus와 같은 API 게이트웨이 도구가 적합한 특수한 상황도 있습니다.

비즈니스 요구 사항

여러 팀이나 프로젝트가 일련의 Ingress 컨트롤러를 공유하거나 환경별로 Ingress 컨트롤러를 특화할 수 있지만, 기존 Ingress 컨트롤러를 활용하는 대신 Kubernetes 내부에 전용 API 게이트웨이를 배포해야 할 수도 있습니다. Kubernetes 내부에서 Ingress 컨트롤러와 API 게이트웨이를 함께 사용하면 조직이 비즈니스 요구 사항을 충족하는 데 필요한 유연성을 확보할 수 있습니다. 몇 가지 시나리오는 다음과 같습니다:

• API 게이트웨이 팀이 Kubernetes에 익숙하지 않고 YAML을 사용하지 않을 수 있습니다. 예를 들어 팀이 NGINX 구성에 익숙하다면 Kubernetes에서 NGINX Plus를 API 게이트웨이로 배포할 경우 업무상 마찰을 줄이고 학습 부담을 낮출 수 있습니다.
• 플랫폼 운영 팀이 Ingress 컨트롤러를 애플리케이션 트래픽 관리 전용으로 사용하려고 합니다.
• 클러스터 내 서비스 중 하나에만 적용되는 API 게이트웨이 사용 사례가 있습니다. Ingress 컨트롤러를 사용하여 모든 남북 방향 트래픽에 정책을 적용하는 대신, API 게이트웨이를 배포하여 필요한 곳에만 정책을 적용할 수 있습니다.

Kubernetes 환경으로 API 마이그레이션

기존 API를 Kubernetes 환경으로 마이그레이션할 때 해당 API를 Kubernetes 외부에 배포된 API 게이트웨이 도구에 게시할 수 있습니다. 이 시나리오에서 API 트래픽은 일반적으로 외부 로드 밸런서(클러스터 간 로드 밸런싱용)를 거친 다음, API 게이트웨이 역할을 하도록 구성된 로드 밸런서를 거쳐, 최종적으로 Kubernetes 클러스터 내의 Ingress 컨트롤러로 라우팅됩니다.

Kubernetes에서 SOAP API 지원

대부분의 최신 API는 REST를 사용하여 생성됩니다. 이는 부분적으로 RESTful 또는 gRPC 서비스와 API가 Kubernetes 플랫폼을 최대한 활용할 수 있기 때문입니다. 하지만 아직 재설계되지 않은 SOAP API가 일부 남아 있을 수 있습니다. SOAP API는 마이크로서비스에 최적화되어 있지 않으므로 Kubernetes에서 사용하는 것이 권장되지는 않지만, 재설계가 완료될 때까지 Kubernetes에 SOAP API를 배포해야 할 수도 있습니다. 이 API는 REST 기반 API 클라이언트와 통신해야 할 가능성이 높으며, 이 경우 SOAP 프로토콜과 REST 프로토콜 간에 변환할 방법이 필요합니다. Ingress 컨트롤러로 이 기능을 구현할 수도 있지만, 리소스가 매우 많이 소모되므로 권장하지 않습니다. 대신 SOAP과 REST 간 변환을 위해 API 게이트웨이 도구를 Pod별 또는 서비스별 프록시로 배포하는 것이 좋습니다.

Kubernetes 내부 및 외부의 API 트래픽 관리

Kubernetes 환경 내부와 외부에 걸쳐 API를 관리하는 데 관심이 있는 고객은 비교적 소수입니다. Kubernetes 네이티브 도구를 선택하는 것보다 API 관리 전략의 우선순위가 더 높다면, Kubernetes에 배포할 수 있고 API 관리 솔루션과 통합 가능한 ‘Kubernetes 친화적’ API 게이트웨이가 적합한 선택일 수 있습니다.

참고: Kubernetes 네이티브 도구와 달리 Kubernetes 친화적 도구(때로는 Kubernetes 수용형)는 Kubernetes용으로 설계되지 않았으며 Kubernetes 구성을 사용하여 관리할 수 없습니다. 하지만 민첩하고 가벼워서 지연 시간을 크게 늘리거나 복잡한 우회 방법을 사용하지 않고도 Kubernetes에서 작동할 수 있습니다.

NGINX 시작하기

NGINX는 세 가지 배포 시나리오 모두에 적합한 옵션을 제공합니다.

Kubernetes 네이티브 도구:

• NGINX Ingress Controller – 고급 트래픽 제어 및 조정, 모니터링 및 가시성, 인증 및 통합 인증(SSO)을 처리하는 Kubernetes용 NGINX Plus 기반 Ingress 컨트롤러입니다.
• NGINX Service Mesh – NGINX Plus를 엔터프라이즈 사이드카로 제공하는 경량의 즉시 사용 가능하고 개발자 친화적인 서비스 메시입니다.

지금 30일 무료 평가판을 신청하여 NGINX App Protect WAF 및 DoS가 포함된 NGINX Ingress Controller를 시작하고, 항상 무료로 제공되는 NGINX Service Mesh를 다운로드하세요.

Kubernetes 환경 내부 또는 외부에서 사용할 수 있는 Kubernetes 친화적인 API 게이트웨이:

• NGINX Plus – 고가용성, 능동 상태 확인, DNS 시스템 검색, 세션 지속성, RESTful API와 같은 엔터프라이즈급 기능을 갖춘 올인원 로드 밸런서, 리버스 프록시, 웹 서버 및 API 게이트웨이입니다. 완전한 API 수명 주기 솔루션을 위해 NGINX Controller [현재 F5 NGINX Management Suite]와 통합됩니다.

NGINX Plus를 API 게이트웨이로 사용하는 방법에 대해 자세히 알아보려면 30일 무료 평가판을 신청하고 NGINX를 API 게이트웨이로 배포하기를 참조하세요.

작성자 소개

Jenn GileNGINX 제품 마케팅 총괄

Jenn Gile의 다른 블로그 게시물