어떨 때 사용할까요? API Gateway vs Ingress Controller vs Service Mesh

많은 Ingress Controller 웨비나에서 ” API Gateway 와 어떻게 다릅니까?” 라는 질문을 많이 들었습니다. 또는 “Kubernetes에서 API Gateway와 Ingress Controller(또는 Service Mesh)가 모두 필요합니까?” 라는 질문을 하셨습니다.

Ingress Controller 및 Service Mesh는 많은 API Gateway 사용 사례를 충족할 수 있습니다.
일부 공급업체는 API Gateway 도구를 Ingress Controller 또는 Service Mesh 사용의 대안으로 포지셔닝하거나 세 가지 기능을 모두 하나의 도구로 통합합니다.

이 모범 사례에서는 이러한 도구가 어떻게 다른지, Kubernetes 관련 API Gateway 사용 사례에 사용할 도구를 다룹니다.

목차

1. 정의(Definitions)
  1-1. API Gateway란 무엇입니까?
   1-1-1. 복원력 사용 사례(Resilience Use Cases)
   1-1-2. 트래픽 관리 사용 사례(Traffic Management Use Cases)
   1-1-3. 보안 사용 사례(Security Use Cases)
2. Ingress Controller란?
3. Service Mesh란?
4. Kubernetes 환경을 위한 Kubernetes 도구 사용
5. North-South API Gateway 사용 사례: Ingress Controller 사용
  5-1. 샘플 시나리오: Method-Level 라우팅
6. East-West API Gateway 사용 사례: Service Mesh 사용
  6-1. 샘플 시나리오: Canary 배포
7. Kubernetes 앱용 API Gateway 도구를 사용하는 시기 및 방법
  7-1. 비즈니스 요구 사항
  7-2. API를 Kubernetes 환경으로 마이그레이션
  7-3. Kubernetes에서 SOAP API 지원
8. Kubernetes 내부 및 외부 모두의 API 트래픽 관리
9. NGINX Plus API Gateway 시작하기

1. 정의(Definitions)

API Gateway, Ingress Controller 및 Service Mesh는 핵심적으로 사용자 환경 안팎으로 트래픽을 가져오도록 설계된 프록시 유형입니다.

1-1. API Gateway 란 무엇입니까?

API Gateway는 클라이언트의 API 요청을 적절한 서비스로 라우팅합니다. 그러나 이 간단한 정의에 대한 큰 오해는 API Gateway가 고유한 기술이라는 생각입니다. 그렇지 않습니다. 오히려 “API Gateway”는 다양한 유형의 프록시(가장 일반적으로 Load Balancer 및 Reverse Proxy, 그리고 점점 더 Ingress Controller 또는 Service Mesh)를 통해 구현될 수 있는 일련의 사용 사례를 설명합니다.
API Gateway 역할을 하는 도구에 대해 어떤 기능이 “필수”인지에 대한 업계의 동의는 많지 않습니다. 일반적으로 다음 기능이 필요한 고객을 봅니다(사용 사례별로 그룹화).

1-1-1. 복원력 사용 사례(Resilience Use Cases)

  • A/B testing, canary 배포 및 blue-green 배포
  • 프로토콜 변환(예: JSON과 XML 간)
  • 속도 제한(Rate limiting)
  • 서비스 발견(Service discovery)

1-1-2. 트래픽 관리 사용 사례(Traffic Management Use Cases)

  • 메서드(Method) 기반 라우팅 및 매칭(Matching)
  • 요청/응답 헤더 및 본문(body) 조작(manipulation)
  • Layer 7에서 라우팅 요청

1-1-3. 보안 사용 사례(Security Use Cases)

  • API schema enforcement
  • 클라이언트 인증 및 권한 부여
  • 맞춤(Custom) 응답
  • 세분화된 액세스 제어(Fine‑grained access control)
  • TLS termination

이러한 거의 모든 사용 사례는 Kubernetes에서 일반적으로 사용됩니다. 프로토콜 변환, 요청/응답 헤더 및 본문 조작은 일반적으로 Kubernetes 및 마이크로서비스 환경에 적합하지 않은 레거시 API에 연결되어 있기 때문에 덜 일반적입니다.

NGINX API Gateway – API 정의 및 인증 구현에 대해 자세히 알아보십시오.

2. Ingress Controller란?

Ingress Controller(Kubernetes Ingress Controller – 줄여서 KIC라고도 함)는 트래픽을 Kubernetes로 가져오고 서비스로 이동하고 다시 되돌리는 특수 Layer 4 및 Layer 7 프록시입니다(Ingress-egress 또는 North-south 트래픽이라고 함). ). 트래픽 관리 외에도 Ingress Controller는 가시성 및 문제 해결, 보안 및 ID, 가장 고급 API Gateway 사용 사례를 제외한 모든 용도로 사용할 수 있습니다.

3. Service Mesh란?

Service Mesh는 Kubernetes 서비스 간의 트래픽 흐름(서비스 간 또는 east-west 트래픽이라고 함)을 처리하며 일반적으로 종단 간 암호화(E2EE)를 달성하는 데 사용됩니다. Service Mesh 채택은 작지만 고급 배포를 시작하거나 E2EE에 대한 요구 사항이 있는 조직이 늘어남에 따라 증가하고 있습니다. Service Mesh는 앱에 매우 가까운 분산형(경량) API Gateway로 사용할 수 있으며 Service Mesh Sidecar를 통해 데이터 평면 수준에서 가능합니다.

4. Kubernetes 환경을 위한 Kubernetes 도구 사용

Mark Church가 Kubernetes 및 애플리케이션 네트워킹의 미래에 대한 NGINX Sprint 2.0 기조 연설에서 “API Gateway, Load Balancer 및 Service Mesh는 계속해서 서로 점점 더 유사하게 보이고 유사한 기능을 제공할 것”이라고 들었습니다. 우리는 이 내용에 전적으로 동의하며 더 나아가 어디에서(그리고 어떻게) 사용할 것인지에 따라 작업에 적합한 도구를 선택하는 것이라고 덧붙입니다. 결국, 칼과 버터 칼은 모두 절단에 사용되지만 아침 토스트에는 전자를 사용하지 않을 것입니다.

그렇다면 어떤 도구가 자신에게 적합한지 어떻게 결정합니까? 간단하게 설명하겠습니다. Kubernetes 내부에 API Gateway 기능이 필요한 경우 일반적으로 YAML과 같은 기본 Kubernetes 구성 도구를 사용하여 구성할 수 있는 도구를 선택하는 것이 가장 좋습니다. 일반적으로 Ingress Controller 또는 Service Mesh입니다. 하지만 “내 API Gateway 도구에는 내 Ingress Controller(또는 Service Mesh)보다 훨씬 더 많은 기능이 있습니다. 놓치고 있지 않습니까?” 아니요! 특히 도구 복잡성이 킬러가 될 수 있는 Kubernetes 내에서 더 많은 기능이 더 나은 도구와 같지 않습니다.

참고: Kubernetes 네이티브(Knative와 동일하지 않음)는 Kubernetes용으로 설계 및 구축된 도구를 나타냅니다. 일반적으로 Kubernetes CLI와 함께 작동하고 Helm을 사용하여 설치하고 Kubernetes 기능과 통합할 수 있습니다.

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

  • YAML은 Kubernetes팀에게 친숙한 언어이므로 API Gateway 기능에 기존 Kubernetes 도구를 사용하는 경우 학습 곡선이 작거나 아예 존재하지 않습니다. 이렇게 하면 팀이 가끔씩만 사용할 수 있는 새 도구를 구성하는 방법을 배울 필요 없이 기존 기술 범위 내에서 작업할 수 있습니다.
  • 다른 Kubernetes 도구와 동일한 방식으로 YAML 친화적인 도구를 자동화할 수 있습니다. 워크플로에 완벽하게 맞는 모든 것이 팀에서 인기가 있어 팀에서 사용할 가능성이 높아집니다.
  • Ingress Controller, Service Mesh 또는 둘 다를 사용하여 Kubernetes 트래픽 관리 도구 스택을 축소할 수 있습니다. 결국 모든 추가 홉이 중요하며 불필요한 대기 시간이나 단일 실패 지점을 추가할 이유가 없습니다. 물론 Kubernetes 내에 배포된 기술의 수를 줄이는 것도 예산과 전반적인 보안에 좋습니다.

5. North-South API Gateway 사용 사례: Ingress Controller 사용

Ingress Controller는 많은 API Gateway 사용 사례를 활성화할 가능성이 있습니다. 정의에 설명된 항목 외에도 다음을 구현할 수 있는 Ingress Controller를 조직에서 가장 중요하게 생각합니다.

  • 인증 및 권한 부여 오프로드(Offload)
  • 권한 부여(Authorization) 기반 라우팅
  • Layer 7 수준 라우팅 및 matching(HTTP, HTTP/S, 헤더, 쿠키, methods)
  • 프로토콜 호환성(HTTP, HTTP/2, WebSocket, gRPC)
  • 속도 제한(Rate limiting)

5-1. 샘플 시나리오: Method-Level 라우팅

API 요청에서 POST 메서드를 거부하기 위해 Ingress Controller를 사용하여 Method-Level 매칭 및 라우팅을 구현하려고 합니다.

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

예를 들어 새로운 API /coffee/{coffee-store}/brand가 방금 클러스터에 추가되었다고 가정합니다. 첫 번째 단계는 NGINX Ingress Controller를 사용하여 API를 노출하는 것입니다. 간단히 업스트림 필드에 API를 추가하면 됩니다.

apiVersion: k8s.nginx.org/v1
kind: 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

method-level matching를 활성화하려면 경로 필드에 /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: "You are rejected!"
    - conditions:
      - variable: $request_method
        value: GET
        action:
          pass: coffee
  - path: /tea
    action:
      pass:tea

6. East-West API Gateway 사용 사례: Service Mesh 사용

대부분의 API Gateway 사용 사례에서는 Service Mesh가 필요하지 않거나 처음에는 도움이 되지 않습니다. 왜냐하면 달성하고자 하는 대부분의 작업이 Ingress 계층에서 일어날 수 있고 또 일어나야 하기 때문입니다. 그러나 아키텍처가 복잡해짐에 따라 Service Mesh를 사용하여 가치를 얻을 가능성이 높아집니다. 가장 유익한 사용 사례는 A/B testing, canary 배포 및 blue-green 배포와 같은 E2EE 및 트래픽 분할과 관련이 있습니다.

6-1. 샘플 시나리오: Canary 배포

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

이점은 대부분의 프로덕션 트래픽에 영향을 주지 않고 새로운 기능이나 버전과 같은 API 변경 사항을 점진적으로 롤아웃할 수 있다는 것입니다.

현재 NGINX Ingress Controller는 NGINX Service Mesh에서 관리하는 두 서비스(Coffee.frontdoor.svc 및 Tea.frontdoor.svc) 간에 트래픽을 라우팅합니다. 이러한 서비스는 NGINX Ingress Controller에서 트래픽을 수신하고 이를 Tea.cream1.svc를 포함한 적절한 앱 기능으로 라우팅합니다. 새 버전 Tea.cream2.svc를 호출하여 Tea.cream1.svc를 리팩터링하기로 결정합니다. 베타 테스터가 새 기능에 대한 피드백을 제공하도록 하여 베타 테스터의 고유한 세션 쿠키를 기반으로 Canary 트래픽 분할을 구성하여 일반 사용자가 Tea.cream1.svc만 경험하도록 하고 싶습니다.

NGINX Service Mesh를 사용하여 Tea.cream1.svc 및 Tea.cream2.svc를 포함하여 Tea.frontdoor.svc가 앞에 있는 모든 서비스 간에 트래픽 분할을 만드는 것으로 시작합니다. 조건부 라우팅을 활성화하려면 HTTPRouteGroup 리소스(tea-hrg라는 이름)를 만들고 이를 트래픽 분할과 연결합니다. 그 결과 베타 사용자의 요청(세션 쿠키가 버전=베타로 설정된 요청)만 라우팅됩니다. Tea.frontdoor.svc에서 Tea.cream2.svc로. 일반 사용자는 Tea.frontdoor.svc 뒤에 있는 버전 1 서비스만 계속 경험합니다.

apiVersion: split.smi-spec.io/v1alpha3
kind: 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 분할로 canary 배포를 시작합니다. 즉, 모든 베타 테스터가 Tea.cream2.svc를 경험하지만 물론 베타 테스트 전략에 맞는 비율로 시작할 수 있습니다. 베타 테스트가 완료되면 쿠키 라우팅 없이 간단한 canary 배포를 사용하여 Tea.cream2.svc의 복원력을 테스트할 수 있습니다.

NGINX Service Mesh를 사용한 트래픽 분할에 대한 자세한 내용은 문서를 확인하십시오. 루트 서비스도 백엔드 서비스로 나열되므로 위의 트래픽 분할 구성은 자체 참조입니다. 이 구성은 현재 Service Mesh 인터페이스 사양(smi-spec)에서 지원되지 않습니다. 그러나 사양은 현재 알파 버전이며 변경될 수 있습니다.

7. Kubernetes 앱용 API Gateway 도구를 사용하는 시기 및 방법

Kubernetes에 대한 대부분의 API Gateway 사용 사례는 Ingress Controller 또는 Service Mesh로 해결할 수 있고 해결해야 하지만 NGINX Plus와 같은 API Gateway 도구가 적합한 몇 가지 특수한 상황이 있습니다.

7-1. 비즈니스 요구 사항

여러 팀 또는 프로젝트가 Ingress Controller 세트를 공유할 수 있거나 Ingress Controller가 환경별로 전문화될 수 있지만 기존 Ingress Controller를 활용하는 대신 Kubernetes 내부에 전용 API Gateway를 배포하도록 선택할 수 있는 이유가 있습니다. Kubernetes 내에서 Ingress Controller와 API Gateway를 모두 사용하면 조직이 비즈니스 요구 사항을 달성할 수 있는 유연성을 제공할 수 있습니다. 일부 시나리오는 다음과 같습니다.

  • API Gateway팀은 Kubernetes에 익숙하지 않으며 YAML을 사용하지 않습니다. 예를 들어 NGINX 구성에 익숙하다면 NGINX Plus를 Kubernetes의 API Gateway로 배포하면 마찰이 줄어들고 학습 곡선이 줄어듭니다.
  • 플랫폼 운영 팀은 앱 트래픽 관리 전용 Ingress Controller를 선호합니다.
  • 클러스터의 서비스 중 하나에만 적용되는 API Gateway 사용 사례가 있습니다. Ingress Controller를 사용하여 모든 north-south 트래픽에 정책을 적용하는 대신 API Gateway를 배포하여 필요한 경우에만 정책을 적용할 수 있습니다.

7-2. API를 Kubernetes 환경으로 마이그레이션

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

7-3. Kubernetes에서 SOAP API 지원

대부분의 최신 API는 REST를 사용하여 생성되지만 부분적으로는 RESTful 또는 gRPC 서비스 및 API가 Kubernetes 플랫폼을 최대한 활용할 수 있기 때문에 재설계되지 않은 일부 SOAP API가 여전히 있을 수 있습니다. SOAP API는 마이크로서비스에 최적화되어 있지 않기 때문에 Kubernetes에 권장되지 않지만 결국 다시 설계할 수 있을 때까지 Kubernetes에 SOAP API를 배포해야 할 수 있습니다. API는 REST 기반 API 클라이언트와 통신해야 할 수 있으며, 이 경우 SOAP와 REST 프로토콜 간에 변환할 방법이 필요합니다. Ingress Controller로 이 기능을 수행할 수 있지만 리소스 집약적이기 때문에 권장하지 않습니다. 대신 API Gateway 도구를 Pod당 또는 Service당 프록시로 배포하여 SOAP와 REST 간에 변환하는 것이 좋습니다.

8. Kubernetes 내부 및 외부 모두의 API 트래픽 관리

상대적으로 적은 수의 고객이 Kubernetes 환경 내부 및 외부에 걸친 API 관리에 관심이 있습니다. API 관리 전략이 Kubernetes 기본 도구를 선택하는 것보다 우선순위가 더 높은 경우 Kubernetes에 배포된 “Kubernetes 친화적” API Gateway(API 관리 솔루션과 통합할 수 있음)가 올바른 선택일 수 있습니다.

참고: Kubernetes 기본 도구와 달리 Kubernetes 친화적 도구(Kubernetes 수용이라고도 함)는 Kubernetes용으로 설계되지 않았으며 Kubernetes 구성을 사용하여 관리할 수 없습니다. 그러나 민첩하고 가벼우므로 상당한 대기 시간을 추가하거나 광범위한 해결 방법을 요구하지 않고 Kubernetes에서 수행할 수 있습니다.

9. NGINX Plus API Gateway 시작하기

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

Kubernetes 네이티브 도구:

  • NGINX Ingress Controller – 고급 트래픽 제어 및 셰이핑, 모니터링 및 가시성, 인증 및 싱글 사인온(SSO)을 처리하는 Kubernetes용 NGINX Plus 기반 Ingress Controller.
  • NGINX Service Mesh – NGINX Plus를 엔터프라이즈 사이드카로 제공하는 경량의 턴키 방식의 개발자 친화적인 서비스 메시입니다.

Kubernetes 환경 내부 또는 외부의 Kubernetes 친화적 API Gateway의 경우:

  • NGINX Plus – 고가용성, 활성 상태 확인, DNS 시스템 검색, 세션 지속성 및 RESTful API와 같은 엔터프라이즈급 기능을 갖춘 API Gateway, 로드 밸런서, 리버스 프록시, 입니다. 전체 API 수명 주기 솔루션을 위해 NGINX Controller와 통합됩니다.

NGINX Plus와 함께 안전한 API Gateway 패턴 배포 테스트를 사용해 보려면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.