트래픽 관리 (Traffic Management)

트래픽 관리 (Traffic Management)

1️⃣ VirtualService (트래픽 라우팅, 리퀘스트 매칭, 규칙 정의)

1 VirtualService 개요

VirtualService는 Istio에서 트래픽 라우팅을 정의하는 리소스입니다. 이를 통해 서비스 간 요청을 동적으로 라우팅하고, URI 경로, 헤더, 쿠키 등 다양한 조건에 따라 요청을 처리할 수 있습니다. VirtualService는 서비스의 트래픽을 세밀하게 제어하는 핵심 컴포넌트입니다.

2 트래픽 라우팅

VirtualService는 기본적으로 라우팅 규칙을 정의하여, 외부에서 들어오는 요청을 해당하는 서비스로 전달합니다. 예를 들어, /v1으로 시작하는 요청은 서비스 A로, /v2는 서비스 B로 보내는 방식입니다.

📌 VirtualService 리소스 예시

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-virtualservice
spec:
  hosts:
    - "myapp.example.com"
  http:
    - match:
        - uri:
            exact: "/v1"
      route:
        - destination:
            host: myapp-v1
            port:
              number: 80
    - match:
        - uri:
            exact: "/v2"
      route:
        - destination:
            host: myapp-v2
            port:
              number: 80

3 리퀘스트 매칭 및 규칙 정의

트래픽을 특정 서비스로 라우팅할 때, VirtualService는 다양한 조건을 설정하여 리퀘스트를 매칭할 수 있습니다. 예를 들어, 요청의 URI, 헤더, 쿠키 값 등을 기반으로 트래픽을 라우팅할 수 있습니다.

  • URI 매칭: 요청 URL의 경로에 따라 라우팅
  • 헤더 매칭: 요청 헤더 값에 따른 라우팅
  • 리퀘스트 메소드 매칭: GET, POST와 같은 HTTP 메소드에 따른 라우팅

📌 헤더와 URI를 이용한 트래픽 라우팅 예시

http:
  - match:
      - uri:
          exact: "/api/v1"
        headers:
          user-agent:
            exact: "Mozilla"
    route:
      - destination:
          host: myservice
          port:
            number: 80

2️⃣ DestinationRule (부하 분산, 타임아웃, 리트라이 설정)

1 DestinationRule 개요

DestinationRule은 서비스의 부하 분산, 타임아웃, 리트라이 정책을 정의하는 리소스입니다. 이를 통해 서비스가 어떻게 요청을 처리할지, 예를 들어 여러 인스턴스가 있을 때 요청을 어떻게 분배할지, 타임아웃 및 리트라이 정책을 어떻게 적용할지 설정할 수 있습니다.

2 부하 분산 설정

DestinationRule에서는 부하 분산(Load Balancing) 전략을 설정할 수 있습니다. Istio는 여러 방식의 부하 분산을 지원합니다:

  • Round-robin: 기본값으로, 요청을 순차적으로 분배합니다.
  • Least Connection: 연결이 적은 서비스 인스턴스로 요청을 보냅니다.
  • Random: 요청을 임의의 인스턴스로 분배합니다.

📌 DestinationRule 리소스 예시

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-destination-rule
spec:
  host: myservice
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        maxRequestsPerConnection: 100
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 1s
      baseEjectionTime: 30s

3 타임아웃 및 리트라이 설정

DestinationRule을 사용하여 요청에 대한 타임아웃을 설정하거나 실패 시 자동으로 리트라이를 수행할 수 있습니다.

📌 타임아웃 및 리트라이 설정 예시

trafficPolicy:
  timeout: 5s
  retries:
    attempts: 3
    perTryTimeout: 2s
    retryOn: 5xx

3️⃣ Gateway (Ingress Gateway, Egress Gateway)

1 Gateway 개요

Gateway는 Istio에서 외부와 내부 간 트래픽을 라우팅하는 리소스입니다. Ingress Gateway는 외부에서 클러스터 내부로 들어오는 트래픽을 처리하고, Egress Gateway는 클러스터 내부에서 외부로 나가는 트래픽을 처리합니다.

2 Ingress Gateway

Ingress Gateway는 외부에서 오는 요청을 받아 내부 서비스로 전달하는 역할을 합니다. 이를 통해 외부에서 들어오는 트래픽에 대한 라우팅을 제어할 수 있습니다.

📌 Ingress Gateway 리소스 예시

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: example-ingress-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - "myapp.example.com"

3 Egress Gateway

Egress Gateway는 클러스터 내의 서비스에서 외부로 나가는 트래픽을 제어하는 역할을 합니다. 이를 통해 외부 서비스와의 연결을 제한하거나, 트래픽에 대한 추가적인 제어가 가능합니다.

📌 Egress Gateway 리소스 예시

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: example-egress-gateway
spec:
  selector:
    istio: egressgateway
  servers:
    - port:
        number: 443
        name: https
        protocol: HTTPS
      hosts:
        - "*.example.com"

4️⃣ ServiceEntry & Sidecar 리소스를 활용한 외부 서비스 접근

1 ServiceEntry 개요

ServiceEntry는 Istio 내에서 외부 서비스를 정의하는 리소스입니다. 이를 통해 클러스터 외부의 서비스를 Istio 내에서 접근할 수 있도록 설정할 수 있습니다. ServiceEntry는 외부 서비스에 대한 경로와 포트를 설정하고, 클러스터 내의 서비스처럼 트래픽을 라우팅합니다.

📌 ServiceEntry 리소스 예시

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: external-service-entry
spec:
  hosts:
    - "external.example.com"
  addresses:
    - "8.8.8.8"
  ports:
    - number: 80
      name: http
      protocol: HTTP
  location: MESH_EXTERNAL
  resolution: STATIC

2 Sidecar 리소스 활용

Sidecar 리소스를 사용하면 각 서비스의 사이드카 프록시를 통해 외부 서비스와의 트래픽을 관리할 수 있습니다. Sidecar를 통해 외부 서비스와의 연결을 보안적이고 효율적으로 제어할 수 있습니다.


5️⃣ Canary 배포, Blue-Green 배포, A/B 테스팅 적용 방법

1 Canary 배포

Canary 배포는 새로운 버전의 애플리케이션을 소규모 사용자에게 배포하여 안정성을 확인한 후 전체 사용자에게 배포하는 전략입니다. Istio는 트래픽을 부분적으로 새로운 버전으로 라우팅하는 방식으로 Canary 배포를 지원합니다.

📌 Canary 배포 예시

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-canary-vs
spec:
  hosts:
    - "myapp.example.com"
  http:
    - route:
        - destination:
            host: myapp-v1
            port:
              number: 80
          weight: 90
        - destination:
            host: myapp-v2
            port:
              number: 80
          weight: 10

2 Blue-Green 배포

Blue-Green 배포는 새로운 버전의 애플리케이션을 “Green” 환경에서 배포하고, 테스트 후에 “Blue” 환경으로 전환하는 방식입니다. Istio를 사용하여 트래픽을 새로운 버전으로 안전하게 전환할 수 있습니다.

📌 Blue-Green 배포 예시

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-blue-green-vs
spec:
  hosts:
    - "myapp.example.com"
  http:
    - route:
        - destination:
            host: myapp-blue
            port:
              number: 80
        - destination:
            host: myapp-green
            port:
              number: 80

3 A/B 테스팅

A/B 테스팅은 두 가지 버전의 애플리케이션을 동시에 배포하고, 사용자들에게 랜덤으로 각기 다른 버전을 노출시켜 성능을 비교하는 방법입니다. Istio에서는 A/B 테스팅을 통해 트래픽을 두 버전으로 나누어 실험할 수 있습니다.

RSS Feed
마지막 수정일자