Istio Service Mesh 환경에서 Virtual Service 리소스를 통한 트래픽 관리

Istio Service Mesh 의 트래픽 라우팅 규칙을 사용하면 서비스 간 트래픽 및 API 호출의 흐름을 쉽게 제어할 수 있습니다.
Istio는 회로 차단기 (circuit breaker), timeout, retry와 같은 서비스 수준 속성의 구성을 간소화하고, 백분율 기반 트래픽 분할을 통해 A/B Testing, Canary Rollout, 단계적 Rollout과 같은 중요한 작업을 쉽게 설정할 수 있습니다.
또한 종속 서비스 또는 네트워크의 장애에 대해 애플리케이션의 복원력을 높이는 데 도움이 되는 기본 제공 안정성 기능도 제공합니다.

목차

1. Istio Service Mesh 의 Traffic Management
2. Istio Service Mesh 의 Virtual Service 란?
 2-1. Virtual Service 를 써야하는 이유
3. Istio Service Mesh Virtual Service 예제
 3-1. Virtual Service – host
 3-2. Virtual Service – match
 3-3. Virtual Service – destination
4. NGINX Ingress Controller Service Mesh 환경에서의 Virtual Service

1. Istio Service Mesh 의 Traffic Management

이 서비스 레지스트리를 사용하여 Envoy 프록시는 트래픽을 관련 서비스로 보낼 수 있습니다.
대부분의 마이크로서비스 기반 애플리케이션에는 로드 밸런싱 영역이라고도 하는 서비스 트래픽을 처리하기 위해 각 서비스 워크로드의 여러 인스턴스가 있습니다.
기본적으로 Envoy 프록시는 영역에서 무작위로 선택한 두 호스트에서 Active 요청이 가장 적은 호스트로 각 요청을 라우팅하는 최소 요청 모델을 사용하여 각 서비스의 로드 밸런싱 영역에 트래픽을 분산하므로 가장 부하가 많은 호스트는 다른 호스트보다 부하가 덜 걸릴 때까지 요청을 받지 않습니다.

Istio의 기본 Service Discovery 및 로드 밸런싱은 Service Mesh를 제공하지만, 이는 Istio가 할 수 있는 모든 것이 아닙니다.
사용자는 대부분 Service Mesh 트래픽에 발생하는 상황을 보다 세밀하게 제어하고 싶어합니다.
A/B Testing의 일환으로 특정 비율의 트래픽을 새 버전의 서비스로 보내거나 특정 서비스 인스턴스 하위 집합의 트래픽에 대해 다른 부하 분산 정책을 적용하고 싶을 수 있습니다.
또한 Service Mesh로 들어오고 나가는 트래픽에 특별한 규칙을 적용하거나 Service Mesh의 외부 종속성을 서비스 레지스트리에 추가하고 싶을 수도 있습니다.
이 모든 작업은 Istio Service Mesh의 Traffic Management API를 사용하여 자체 트래픽 구성을 추가하여 수행할 수 있습니다.

2. Istio Service Mesh 의 Virtual Service 란?

Virtual Service는 Destination rules과 함께 Istio의 트래픽 라우팅 기능의 핵심 구성 요소입니다.
Virtual Service를 사용하면 Istio와 플랫폼에서 제공하는 기본 연결 및 검색을 기반으로 요청이 Istio Service Mesh 내의 서비스로 라우팅되는 방식을 구성할 수 있습니다.
각 Virtual Service는 순서대로 평가되는 일련의 라우팅 규칙으로 구성되며, Istio는 Virtual Service에 대한 각 요청을 Service Mesh 내의 특정 실제 대상과 일치시킬 수 있습니다.
사용 사례에 따라 Service Mesh에는 여러 개의 Virtual Service가 필요하거나 Virtual Service가 필요하지 않을 수 있습니다.

2-1. Virtual Service 를 써야하는 이유

Virtual Service는 Istio의 트래픽 관리를 유연하고 강력하게 만드는 데 핵심적인 역할을 합니다.
이는 클라이언트가 요청을 보내는 위치와 실제로 이를 처리하는 대상 워크로드를 강력하게 분리함으로써 가능합니다. 또한 Virtual Service는 이러한 워크로드로 트래픽을 보내기 위한 다양한 트래픽 라우팅 규칙을 풍부하게 지정할 수 있는 방법을 제공합니다.

이것이 왜 유용할까요? 가상 서비스가 없다면, Envoy는 소개에서 설명한 대로 모든 서비스 인스턴스 간에 최소 요청 부하 분산을 사용하여 트래픽을 분배합니다. 하지만 워크로드에 대해 알고 있는 정보를 바탕으로 이 동작을 개선할 수 있습니다. 예를 들어, 일부 워크로드는 서로 다른 버전을 나타낼 수 있습니다. 이는 A/B Testing에서 유용할 수 있으며, 다른 서비스 버전 간에 트래픽 경로를 백분율로 구성하거나 내부 사용자로부터 오는 트래픽을 특정 인스턴스 집합으로 직접 보내고자 할 때 유용할 수 있습니다.

3. Istio Service Mesh Virtual Service 예제

다음 가상 서비스는 요청이 특정 사용자로부터 오는지 여부에 따라 요청을 다른 버전의 서비스로 라우팅합니다.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v3

3-1. Virtual Service – host

host 필드에는 가상 서비스의 호스트, 즉 이러한 라우팅 규칙이 적용되는 사용자 주소 지정이 가능한 대상의 목록이 나열됩니다. 클라이언트가 서비스에 요청을 보낼 때 사용하는 주소입니다.

hosts:
- reviews

Virtual Service host 이름은 IP 주소, DNS 이름 또는 플랫폼에 따라 짧은 이름(예: Kubernetes 서비스의 짧은 이름)일 수 있으며, 이는 명시적이거나 암시적으로 완전한 도메인 이름(FQDN)으로 해석됩니다.
또한 와일드카드(“*”) 접두사를 사용하여 일치하는 모든 서비스에 대해 단일 라우팅 규칙 세트를 생성할 수 있습니다.
Virtual Service host는 실제로 Istio 서비스 레지스트리의 일부일 필요는 없으며, 단순히 가상의 목적지입니다.
이를 통해 Istio Service Mesh 내부에 라우팅 가능한 항목이 없는 가상 호스트의 트래픽을 모델링할 수 있습니다.

3-2. Virtual Service – match

예제의 첫 번째 라우팅 규칙은 match 필드로 시작합니다. 이 경우 이 라우팅이 ‘jason‘ 사용자의 모든 요청에 적용되도록 하려면 headers, end-user 및 exact 필드를 사용하여 적절한 요청을 라우팅하면 됩니다.

- match:
   - headers:
       end-user:
         exact: jason

3-3. Virtual Service – destination

route 섹션의 destination 필드는 이 조건에 맞는 트래픽의 실제 목적지를 지정합니다.
가상 서비스의 host와 달리, destination의 host는 Istio Service Mesh 의 서비스 레지스트리에서 실제로 존재하는 목적지여야 하며, 그렇지 않으면 Envoy가 트래픽을 어디로 보낼지 알 수 없습니다.
이는 프록시가 있는 Istio Service Mesh 서비스거나 서비스 엔트리를 사용하여 추가된 비 Istio Service Mesh 서비스일 수 있습니다.
아래의 경우 Kubernetes에서 실행되고 있으며, 호스트 이름은 Kubernetes 서비스 이름입니다.

route:
- destination:
    host: reviews
    subset: v2

4. NGINX Ingress Controller Service Mesh 환경에서의 Virtual Service

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: devops-istio
spec:
  hosts:
    - "*"
  gateways:
    - nginx-ingress-gateway
  http:
  - match:
    - uri:
        prefix: /svc1
    rewrite:
      uri: "/"
    route:
    - destination:
        host: webapp-svc1.nginx-ingress.svc.cluster.local
  - match:
    - uri:
        prefix: /svc2
    rewrite:
      uri: "/"
    route:
    - destination:
        host: webapp-svc2.nginx-ingress.svc.cluster.local

해당 YAML 파일은 Istio Service Mesh 환경에서 VirtualService 리소스를 정의하여 특정 URI 패턴을 가진 HTTP 요청을 지정된 서비스로 라우팅합니다.

클라이언트가 /svc1로 시작하는 URI로 요청을 보내면, 이 요청은 nginx-ingress-gateway를 통해 수신됩니다. Istio의 VirtualService 규칙에 따라 이 요청의 URI가 /로 재작성되고, webapp-svc1.nginx-ingress.svc.cluster.local 서비스로 라우팅됩니다.

마찬가지로, 클라이언트가 /svc2로 시작하는 URI로 요청을 보내면, 이 요청도 nginx-ingress-gateway를 통해 수신됩니다. URI가 /로 재작성되고, webapp-svc2.nginx-ingress.svc.cluster.local 서비스로 라우팅됩니다.

webapp-svc는 NGINX로 구성된 파드로 이루어져 있는 서비스입니다.

이를 통해 Istio는 특정 URI 패턴에 따라 트래픽을 적절한 내부 서비스로 투명하게 전달합니다.

Istio Service Mesh의 트래픽 흐름을 시각화 할 수 있는 Kiali 도구를 통해 확인하면 다음과 같이 Virtual Service의 라우팅 규칙에 따라 트래픽이 서비스로 전달되는 것을 확인할 수 있습니다.

Istio 와 NGINX Ingress Controller를 사용하여 Service Mesh 환경에서 라우팅 규칙을 통한 트래픽 관리를 하고 싶으신가요?
지금 NGINX STORE에 문의하여 이와 같은 Service Mesh 사용 사례에 대해 상담 받아보세요.