[Service Mesh] 4. Istio Traffic Management (1) - Virtual Service & Destination Rule

Service Mesh 알아보기

1. [Service Mesh] 1. Service Mesh란?
2. [Service Mehs] 2. Envoy Proxy
3. [Service Mesh] 3. Istio?
4. [Service Mesh] 4. Istio Traffic Management (1) - Virtual Service & Destination Rule
5. [Service Mesh] 5. Istio Traffic Managerment (2) - Gateway & Service Entry
6. [Service Mesh] 6. Service Monitoring in Istio
7. [Service Mesh] 7. Logging

 

---

이번 글에서는 Istio의 Traffic Management에 대해서 알아보겠습니다. Istio의 중요한 기능 중 하나는 들어오는 요청을 적절하게 라우팅 해주는 트래픽 관리 기능입니다. Istio에서 어떻게 트래픽 관리를 수행하는지 알기 위해서는 Virtual Service와 Destination Rule이라는 개념에 대해 알아야 합니다. 

Virtual Service?

Virtual Service는 쿠버네티스에서 Ingress가 L7 기반 서비스 라우팅을 해주는 것처럼 트래픽을 적절한 Service에 라우팅하게 됩니다. 

Destination Rule? 

Destination Rule은 트래픽에 적용될 라우팅 정책을 정의합니다. Virtual Service와 헷갈릴 수도 있는데 먼저 요청이 어떤 Service에 라우팅 되는지 결정하기 위해 사용되는 것이 Virtual Service, 이후 Service에서 어떻게 트래픽을 전송할 것인지 정하는 기능을 하는 것이 Destination Rule입니다. 추가로 Destination Rule에서는 Load Balancing, Connection Pool Size, 이상 탐지 설정과 같은 기능도 설정할 수 있습니다.

설명으로는 이해가 잘 가지 않을 수 있기 때문에 간단한 어플리케이션 구성을 통해 트래픽 관리를 수행해보겠습니다.

---

Trrafic Management Tutorial

다음으로 Destination Rule 및 Virtual Service를 테스트하기 위해 간단한 Spring Boot 어플리케이션을 만들어보겠습니다. 어플리케이션은 Front Application과 Server Application으로 구성하였습니다. 먼저 Front Application은 Minikube 환경에서 테스트를 위해 NodePort 타입의 Service로 노출되며  /hello로 들어오는 요청을 받으면 RestTemplate을 통해 http://webservice:80/로 GET 요청을 보냅니다. 
Server Application은 /로 요청이 들어오면 현재 시간과 해당 어플리케이션의 Version을 반환하게 됩니다.

Front 및 Server Application의 코드는 글의 내용과 무관한 코드이기 때문에 따로 언급하지 않겠습니다. 코드가 궁금하시거나 테스트를 직접 구동해보기 원하시는 분은 Github의 코드를 참고하실 수 있습니다.

 

---

1. 도커 이미지 생성

Front Application과 다른 버전을 갖는 Server Application의 도커 이미지를 빌드해줍니다.

//front
➜ docker build . -t front:1.0
//server
➜ docker build . -t server:1.0 --build-arg version=1.0
➜ docker build . -t server:2.0 --build-arg version=2.0

---

2. 쿠버네티스 리소스 생성 (Front Application)

이제 쿠버네티스 클러스터에 해당 어플리케이션을 배포하고 서비스를 통해 노출시켜야 합니다. 먼저 Front Application을 위한 Service와 Deployment는 다음과 같습니다. Minikube 환경에서 테스트를 용이하게 진행하기 위해 Front Application는 NodePort 타입으로 노출되도록 구성하였습니다.

Service (Front Application)

apiVersion: v1
kind: Service
metadata:
  name: frontservice
spec:
  selector:
    app: front
  type: NodePort
  ports:
  - name: http-frontservice
    port: 8080
    protocol: TCP
    targetPort: 8080

 

Deployment(Front Application)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-front
  labels:
    app: front
spec:
  replicas: 1
  selector:
    matchLabels:
      app: front
  template:
    metadata:
      labels:
        app: front
    spec:
      containers:
      - name: front
        image: front:1.0
        ports:
        - containerPort: 8080

---

3. 쿠버네티스 리소스 생성 (Server Application)

다음으로 Server Application을 위한 리소스를 살펴보겠습니다. 저는 버전에 따른 Subset 구성과 라우팅을 테스트 해보기 위해 Server Application을 webservice라는 하나의 Service를 통해 노출하고 각 버전에 따른 Deployment를 구성하였습니다.

Service (Server Application)

apiVersion: v1
kind: Service
metadata:
  name: webservice
spec:
  selector:
    app: server
  ports:
  - name: http-webservice
    port: 80
    protocol: TCP
    targetPort: 8080

 

Deployment-v1.0/v2.0 (Server Application)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server-v1
  labels:
    app: server
    version: v1.0
spec:
  replicas: 1
  selector:
    matchLabels:
      app: server
  template:
    metadata:
      labels:
        app: server
        version: v1.0
    spec:
      containers:
      - name: server
        image: server:1.0
        ports:
        - containerPort: 8080
        
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server-v2
  labels:
    app: server
    version: v2.0
spec:
  replicas: 1
  selector:
    matchLabels:
      app: server
  template:
    metadata:
      labels:
        app: server
        version: v2.0
    spec:
      containers:
      - name: server
        image: server:2.0
        ports:
        - containerPort: 8080

---

4. Destination Rule 설정

Destination Rule의 Subset에 v1.0과 v2.0를 정의해줍니다. 아래 설정에서 webservice라는 host로 오는 요청은 v1(v1.0 버전 레이블을 지닌 그룹)과 v2(v2.0 버전 레이블을 지닌 그룹)으로 구분되어집니다.

Destination Rule

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: web-destination
spec:
  host: webservice
  subsets:
  - name: v1
    labels:
      version: v1.0
  - name: v2
    labels:
      version: v2.0

 

추가로 subset 정의 이외에도 Connection Pool, Load Balancing, Outlier Detection과 같은 기능들도 수행할 수 있습니다. 

1) Connection Pool

Connection Pool은 모든 연결을 새로 만드는 것에 대한 비용을 개선하기 위해 필요합니다. 특히, 서비스 메시 아키텍쳐에서 TLS를 활성화 했을 경우 연결을 맺는데 발생하는 비용을 효과적으로 감소시킬 수 있습니다. Istio에서는 이런 설정들을 기본적으로 지원하고 있습니다. 많은 설정이 존재하지만 주로 사용하는 몇가지 설정들만 확인해보겠습니다.

• maxConnections : Connection 수의 최대값
• connectionTimeout: TCP 연결에 발생하는 timeout 제한
• Http1MaxPendingRequests: Pending 상태의 HTTP 요청 수 제한

참고로, Connection Pool은 Envoy Proxy를 통해 모니터링되며 설정한 제한값들에 도달하게 되면 회로 차단기 메커니즘을 통해 Connection Pool의 상태를 조절합니다.

2) Load Balancing

Destination Rule에서는 Subset간의 로드밸런싱을 위해 다양한 메커니즘을 지원합니다.

• Round Robin : 시간 퀀텀마다 임의 배분
• Least Connection : 가장 적은 수의 연결을 제공하는 호스트 선택
• Random : 임의 배분
• Consistent Hash : 요청 헤더 및 쿠키 기반 해싱

3) Outlier Detection

Istio에서는 로드 밸런싱 대상 호스트에서 비정상적인 동작을 하는 호스트를 탐지해 로드 밸런싱 호스트에서 제거하는 기능을 지원합니다. Istio는 서비스에서 발생한 연속 오류를 기록하며 이 때 연결 타임아웃, 5xx 응답과 같은 상황이 발생하면 오류로 기록하게 됩니다.

위의 설정에서 v1.0에 Load Balacing 및 Connection Pool 설정을 적용해 Destination Rule을 수정하여 사용해보겠습니다.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: web-destination
spec:
  host: webservice
  subsets:
  - name: v1
    labels:
      version: v1.0
    trafficPolicy:
      loadBalancer: 
        simple: ROUND_ROBIN
      connectionPool:
        tcp:
          maxConnections: 100
          connectTimeout: 30ms
          tcpKeepalive:
            time: 7200s
            interval: 75s
  - name: v2
    labels:
      version: v2.0

---

5. Virtual Service 설정

Virtual Service는 요청을 서비스 메시에 정의된 서비스에 매핑하는 기능을 담당합니다. 이 때 구성 요소에 대한 분석은 Destination Rule을 통해 수행됩니다. 요청을 처리하는 방법은 다양하게 존재합니다.

1) Forwarding
요청을 서비스에 그대로 전달합니다.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata: 
  name: webservice-vs
spec:
  hosts:
    - web-server
  http:
  - route:
    - destination:
      host: webservice
      subset: v1

위의 설정을 이용하게 되면 모든 요청을 webservice의 subset v1(v1.0)으로 라우팅하게 됩니다.

2) Rewrite
요청을 재작성합니다. 요청을 재작성할 때에는 match 속성을 통해 재작성할 요청을 정의하고, rewrite 속성을 통해 새로운 URI를 정의합니다.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata: 
  name: webservice-vs
spec:
  hosts:
    - web-server
  http:
  - match:
    - headers:
        x-upgrade:
          exact: "TRUE"
    - uri:
      prefix: /hello
    rewrite:
      uri: /
    route:
    - destination:
        host: webservice
        subset: v1

위의 설정을 이용하게 되면 /hello로 들어오는 요청 중 Header의 x-upgrade가 TRUE인 요청을 재작성하여 subset v1의 /로 전송하게 됩니다.

3) Weight
Istio는 서비스 간의 요청을 정의한 비율로 분배할 수 있습니다. 위에서 설정한 v1.0, v2.0에 대해 50:50으로 분배하는 설정은 다음과 같습니다.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata: 
  name: webservice-vs
spec:
  hosts:
    - web-server
  http:
  - route:
    - destination:
        host: webservice
        subset: v1
      weight: 50
    - destination:
        host: webservice
        subset: v2.0
      weight: 50

참고로 match 속성과 weight를 통해 서비스의 트래픽을 제어하여 카나리 배포 및 블루-그린 배포를 수행할 수 있습니다. 

이번 테스트에서는 weight 방식을 사용하여 v1과 v2에 50:50의 가중치로 라우팅되는 것을 확인해보겠습니다. Virtual Service는 위의 weight 설정을 사용하였습니다.

---

6. Test 수행

먼저 모든 리소스를 Istio가 설치된 Minikube 클러스터에 배포한 후, Front Application Service로 접근해줍니다.

➜ minikube service frontservice
|-----------|--------------|------------------------|---------------------------|
| NAMESPACE |     NAME     |      TARGET PORT       |            URL            |
|-----------|--------------|------------------------|---------------------------|
| default   | frontservice | http-frontservice/8080 | http://192.168.64.2:31410 |
|-----------|--------------|------------------------|---------------------------|
🎉  Opening service default/frontservice in default browser...

 

weight를 50:50으로 설정했기 때문에 위의 URL에 접속하면 v1.0과 v2.0에 대한 응답을 확인할 수 있습니다. (글을 쓰다가 v2.0 캡쳐 전에 minikube cluster가 멈춰버려서 캡쳐본은 없습니다... 맥북 프로 사고 싶다.....)

v1.0 Response

---

이번 글에서는 Destination Rule 및 Virtual Service를 통해 서비스 메시에 들어오는 요청에 대한 라우팅에 대해 알아봤습니다. 하지만, 이번글에서 다룬 작업들은 서비스 메시 내부에서 발생하는 요청들에 대해서는 처리가 가능하지만 외부에서 발생하는 요청들에 대해서는 처리할 수 없다는 문제가 존재합니다. 따라서 외부 구성 요소들과 상호작용하기 위해 필요한 Istio의 컴포넌트에 대해서 알아보겠습니다.

블로그에 사용된 모든 예제는 Github에서 확인하실 수 있습니다.

---

참고자료

• Istio Document - Virtual Service
• Istio Documetn - Destination Rule
• 조대협님의 블로그
• Istio로 시작하는 서비스 메시