Istio Hands-on Study [1기]

[3주차] 복원력(애플리케이션 네트워킹 문제 해결) : Locality-aware 로드 밸런싱

구구달스 2025. 4. 20. 21:11

🌍 Istio로 지역 기반
Locality-Aware Load Balancing 구현하기

서비스가 여러 지역에 배포되어 있을 때, 요청을 가장 가까운 곳으로 보내는 것은 성능과 비용 면에서 매우 중요합니다.

Locality-Aware Load Balancing은 Istio가 서비스의 위치 정보를 활용해 요청을 최적의 엔드포인트로 보내는 기능입니다.

🗺️ Locality-Aware Load Balancing이란?

  • Istio의 Control Plane은 서비스들의 위치와 네트워크 토폴로지를 파악해, 이를 기반으로 요청을 효율적으로 분배합니다. Locality-Aware Load Balancing은 서비스가 배포된 Region이나 Availability Zone을 고려해, 가까운 위치의 서비스에 우선적으로 요청을 보내는 방식입니다.
  • 예를 들어, simple-backend 서비스가 us-west, us-east, europe-west 지역에 배포되어 있고, simple-web이 us-west에 있다면, Istio는 us-west에 있는 simple-backend로 요청을 우선 보냅니다. 이렇게 하면 지연 시간(Latency) 과 지역 간 트래픽 비용을 줄일 수 있습니다.
Locality-Aware Load Balancing은 서비스의 지역 정보를 활용해 가까운 엔드포인트로 요청을 보내,
지연 시간과 비용을 최적화합니다.

그림 : simple-web이 us-west 지역에 있을 때, 같은 지역의 simple-backend로 요청이 우선적으로 전달되는 과정

🌍 Istio로 Locality-Aware Load Balancing 실습하기

서비스가 여러 지역에 흩어져 있을 때, 요청을 가장 가까운 엔드포인트로 보내는 것은 성능과 비용을 최적화하는 데 필수적입니다. Istio의 Locality-Aware Load Balancing은 서비스의 위치 정보를 활용해 이를 가능하게 합니다. 

🗺️ Locality-Aware Load Balancing 설정 준비

  • Istio는 서비스가 배포된 Region과 Zone 정보를 활용해 요청을 가까운 엔드포인트로 우선 보냅니다.
    Kubernetes에서는 노드에 특정 라벨을 추가해 이 정보를 제공합니다.

Kubernetes 노드 라벨

  • 노드에 추가되는 위치 정보 라벨은 다음과 같습니다:
    • 구형 라벨: failure-domain.beta.kubernetes.io/region, failure-domain.beta.kubernetes.io/zone
    • 신형 라벨: topology.kubernetes.io/region, topology.kubernetes.io/zone
  • 클라우드 제공자(예: Google Cloud, AWS)는 보통 이러한 라벨을 자동으로 추가합니다.
    Istio는 이 라벨을 읽어 Envoy의 Load Balancing에 위치 정보를 반영합니다
Kubernetes 노드 라벨 또는 istio-locality 라벨을 사용해 서비스의 지역 정보를 지정하면,
Istio가 이를 기반으로 Locality-Aware Load Balancing을 수행합니다.

🚀 서비스 배포와 Locality 설정

  • simple-web와 simple-backend 서비스를 배포해 Locality-Aware Load Balancing을 테스트합니다.
  • 배포는 다음과 같이 설정합니다:
    • simple-web: us-west1-a
    • simple-backend-1: us-west1-a (같은 Zone)
    • simple-backend-2: us-west1-b (다른 Zone)
  • 다음은 simple-web의 Deployment 예시입니다:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ cat ch6/simple-service-locality.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: simple-web
  name: simple-web
spec:
  replicas: 1
  selector:
    matchLabels:
      app: simple-web
  template:
    metadata:
      labels:
        app: simple-web
        istio-locality: us-west1.us-west1-a
    spec:
      serviceAccountName: simple-web
      containers:
      - env:
        - name: "LISTEN_ADDR"
          value: "0.0.0.0:8080"
        - name: "UPSTREAM_URIS"
          value: "http://simple-backend:80/"
        - name: "SERVER_TYPE"
          value: "http"
        - name: "NAME"
          value: "simple-web"
        - name: "MESSAGE"
          value: "Hello from simple-web!!!"
        - name: KUBERNETES_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        image: nicholasjackson/fake-service:v0.14.1
        imagePullPolicy: IfNotPresent
        name: simple-web
        ports:
        - containerPort: 8080
          name: http
          protocol: TCP
        securityContext:
          privileged: false
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: simple-backend
  name: simple-backend-1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: simple-backend
  template:
    metadata:
      labels:
        app: simple-backend
        istio-locality: us-west1.us-west1-a
        version: v1 #추가
    spec:
      serviceAccountName: simple-backend
      containers:
      - env:
        - name: "LISTEN_ADDR"
          value: "0.0.0.0:8080"
        - name: "SERVER_TYPE"
          value: "http"
        - name: "NAME"
          value: "simple-backend"
        - name: "MESSAGE"
          value: "Hello from simple-backend-1"
        - name: "TIMING_VARIANCE"
          value: "40ms"
        - name: "TIMING_50_PERCENTILE"
          value: "150ms"
        - name: KUBERNETES_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        image: nicholasjackson/fake-service:v0.14.1
        imagePullPolicy: IfNotPresent
        name: simple-backend
        ports:
        - containerPort: 8080
          name: http
          protocol: TCP
        securityContext:
          privileged: false
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: simple-backend
  name: simple-backend-2
spec:
  replicas: 2
  selector:
    matchLabels:
      app: simple-backend
  template:
    metadata:
      labels:
        app: simple-backend
        istio-locality: us-west1.us-west1-b
        version: v2 #추가
    spec:
      serviceAccountName: simple-backend
      containers:
      - env:
        - name: "LISTEN_ADDR"
          value: "0.0.0.0:8080"
        - name: "SERVER_TYPE"
          value: "http"
        - name: "NAME"
          value: "simple-backend"
        - name: "MESSAGE"
          value: "Hello from simple-backend-2"
        - name: "TIMING_VARIANCE"
          value: "10ms"
        - name: "TIMING_50_PERCENTILE"
          value: "150ms"
        - name: KUBERNETES_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        image: nicholasjackson/fake-service:v0.14.1
        imagePullPolicy: IfNotPresent
        name: simple-backend
        ports:
        - containerPort: 8080
          name: http
          protocol: TCP
        securityContext:
          privileged: false
  • 서비스를 배포합니다:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ kubectl apply -f ch6/simple-service-locality.yaml -n istioinaction
deployment.apps/simple-web configured
deployment.apps/simple-backend-1 configured
deployment.apps/simple-backend-2 configured

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ kubectl get deployment.apps/simple-backend-1 -n istioinaction \
-o jsonpath='{.spec.template.metadata.labels.istio-locality}{"\n"}'
us-west1.us-west1-a

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ kubectl get deployment.apps/simple-backend-2 -n istioinaction \
-o jsonpath='{.spec.template.metadata.labels.istio-locality}{"\n"}'
us-west1.us-west1-b
  • Istio의 Locality-Aware Load Balancing은 기본적으로 활성화되어 있습니다.
    비활성화하려면 meshConfig.localityLbSetting.enabled를 false로 설정하면 됩니다.
istio-locality 라벨을 사용해 서비스의 위치를 지정하고,
Locality-Aware Load Balancing을 활성화해 같은 지역의 엔드포인트로 요청을 우선 보냅니다.

⚠️ Locality-Aware Load Balancing의 주의점

  • Locality-Aware Load Balancing은 기본적으로 유용하지만, 특정 상황에서는 조정이 필요할 수 있습니다.
    예를 들어, 특정 지역에 타겟 서비스(simple-backend)의 인스턴스가 호출 서비스(simple-web)보다 적을 경우, 해당 지역의 서비스가 과부하될 수 있습니다.
  • 서비스 토폴로지와 부하 특성에 따라 Load Balancing 설정을 최적화해야 합니다.
Locality-Aware Load Balancing은 기본적으로 활성화되어 있지만,
서비스 배포 상황에 따라 과부하를 피하기 위해 조정이 필요할 수 있습니다.

🔍 Locality-Aware Load Balancing 테스트

  • 이제 simple-web에서 simple-backend로 요청을 보내 테스트합니다.
    simple-web과 simple-backend-1은 us-west1-a에, simple-backend-2는 us-west1-b에 있으므로, 요청은 주로 simple-backend-1로 가야 합니다.
  • 다음 명령어로 10번 호출해 결과를 확인합니다:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ for in in {1..10}; do curl -s http://simple-web.istioinaction.io:30000 | jq ".upstream_calls[0].body"; done
"Hello from simple-backend-1"
"Hello from simple-backend-2"
"Hello from simple-backend-1"
"Hello from simple-backend-1"
"Hello from simple-backend-1"
"Hello from simple-backend-2"
"Hello from simple-backend-2"
"Hello from simple-backend-1"
"Hello from simple-backend-2"
"Hello from simple-backend-1"

결과 분석

  • 예상과 달리, 요청이 simple-backend-1(us-west1-a)과 simple-backend-2(us-west1-b)에 고르게 분배되었습니다.
    이는 Health Checking이 설정되지 않아 Istio가 지역 정보를 무시하고 모든 엔드포인트에 요청을 분배했기 때문입니다.
Health Checking이 없으면 Locality-Aware Load Balancing이 작동하지 않아
요청이 모든 엔드포인트에 분배됩니다.

🩺 Outlier Detection으로 Health Checking 추가

  • Outlier Detection은 엔드포인트의 건강 상태를 수동적으로 모니터링해 비정상 엔드포인트를 제외합니다.
    이를 통해 Locality-Aware Load Balancing이 제대로 작동하도록 만듭니다.
    simple-backend에 Outlier Detection을 추가하는 DestinationRule을 설정합니다:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ cat ch6/simple-backend-dr-outlier.yaml
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: simple-backend-dr
spec:
  host: simple-backend.istioinaction.svc.cluster.local
  trafficPolicy: 
    outlierDetection: ##불안정한 인스턴스를 감지하고 트래픽 풀에서 제외하는 설정
      consecutive5xxErrors: 1 #인스턴스를 이상치로 간주하기 위한 연속 5xx 에러 응답 횟수로, 단 한 번의 5xx 에러로도 해당 인스턴스를 이상치로 판단
      interval: 5s #이상치 분석 간격으로, 5초마다 검사
      baseEjectionTime: 30s #이상치로 판단된 인스턴스가 트래픽 풀에서 제외되는 기본 시간으로, 30초 동안 트래픽을 받지 않습니다.
      maxEjectionPercent: 100 #한 번에 제외될 수 있는 인스턴스의 최대 비율로, 100%는 모든 인스턴스가 동시에 제외될 수 있음을 의미합니다.
  • 설정을 적용합니다:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ kubectl apply -f ch6/simple-backend-dr-outlier.yaml -n istioinactionoutlier.yaml -n istioinaction
destinationrule.networking.istio.io/simple-backend-dr configured
  • 다시 테스트를 실행합니다:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ for in in {1..10}; do curl -s http://simple-web.istioinaction.io:30000 | jq ".upstream_calls[0].body"; done
"Hello from simple-backend-1"
"Hello from simple-backend-1"
"Hello from simple-backend-1"
"Hello from simple-backend-1"
"Hello from simple-backend-1"
"Hello from simple-backend-1"
"Hello from simple-backend-1"
"Hello from simple-backend-1"
"Hello from simple-backend-1"
"Hello from simple-backend-1"
  • 이제 모든 요청이 simple-backend-1(us-west1-a)로 전달됩니다.
    Outlier Detection이 건강한 엔드포인트를 선택해 Locality-Aware Load Balancing이 제대로 작동한 것입니다.

Outlier Detection을 추가하면 Istio가 건강한 엔드포인트를 우선 선택해
Locality-Aware Load Balancing이 동일 지역으로 요청을 정확히 보냅니다.

🛑 비정상 엔드포인트 테스트

  • 이제 simple-backend-1이 비정상적으로 동작하도록 설정해, 트래픽이 다른 지역(us-west1-b)의 simple-backend-2로 넘어가는지 확인합니다.
    simple-backend-1이 모든 요청에 대해 HTTP 500 에러를 반환하도록 설정합니다:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ cat ch6/simple-service-locality-failure.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: simple-backend
  name: simple-backend-1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: simple-backend
  template:
    metadata:
      labels:
        app: simple-backend
        istio-locality: us-west1.us-west1-a
    spec:
      serviceAccountName: simple-backend
      containers:
      - env:
        - name: "LISTEN_ADDR"
          value: "0.0.0.0:8080"
        - name: "SERVER_TYPE"
          value: "http"
        - name: "NAME"
          value: "simple-backend"
        - name: "MESSAGE"
          value: "Hello from simple-backend-1"
        - name: "ERROR_TYPE"
          value: "http_error"
        - name: "ERROR_RATE"
          value: "1"
        - name: "ERROR_CODE"
          value: "500"
        - name: KUBERNETES_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        image: nicholasjackson/fake-service:v0.14.1
        imagePullPolicy: IfNotPresent
        name: simple-backend
        ports:
        - containerPort: 8080
          name: http
          protocol: TCP
        securityContext:
          privileged: false
          
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ kubectl apply -f ch6/simple-service-locality-failure.yaml -n istioinaction
deployment.apps/simple-backend-1 configured
  • 다시 테스트를 실행합니다:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ for in in {1..10}; do curl -s http://simple-web.istioinaction.io:30000 | jq ".upstream_calls[0].body"; done
"Hello from simple-backend-2"
"Hello from simple-backend-2"
"Hello from simple-backend-2"
"Hello from simple-backend-2"
"Hello from simple-backend-2"
"Hello from simple-backend-2"
"Hello from simple-backend-2"
"Hello from simple-backend-2"
"Hello from simple-backend-2"
"Hello from simple-backend-2"
  • 이제 모든 요청이 simple-backend-2(us-west1-b)로 전달됩니다.
    simple-backend-1이 HTTP 500 에러를 반환하며 비정상으로 표시되었기 때문에, Istio는 다음으로 가까운 지역(us-west1-b)의 엔드포인트로 트래픽을 보낸 것입니다.
비정상 엔드포인트가 감지되면 Istio는 Locality-Aware Load Balancing을 통해
다음으로 가까운 지역의 건강한 엔드포인트로 트래픽을 전환합니다.

📌핵심 요약

  • Istio의 Locality-Aware Load Balancing은 서비스의 지역 정보를 활용해 가까운 엔드포인트로 요청을 보내 지연 시간과 비용을 줄입니다.
  • Kubernetes 노드 라벨(topology.kubernetes.io/region, topology.kubernetes.io/zone) 또는 istio-locality 라벨을 사용해 위치를 지정할 수 있습니다.
  • 실습에서는 simple-web와 simple-backend-1을 us-west1-a에, simple-backend-2를 us-west1-b에 배포했습니다.
  • 초기 테스트에서는 Health Checking이 없어 요청이 모든 엔드포인트에 분배되었지만, Outlier Detection을 추가한 후 요청이 us-west1-a의 simple-backend-1로 정확히 전달되었습니다.
  • simple-backend-1을 비정상 상태로 만들자 트래픽이 us-west1-b의 simple-backend-2로 전환되었습니다.
  • 이를 통해 Locality-Aware Load Balancing이 건강 상태와 지역 정보를 기반으로 트래픽을 효과적으로 관리함을 확인했습니다.

⚖️ Istio로 가중치를 활용한
Locality-Aware Load Balancing 제어하기

Istio의 Locality-Aware Load Balancing은 기본적으로 요청을 같은 지역의 엔드포인트로 보내지만, 상황에 따라 트래픽을 여러 지역에 분배해야 할 때도 있습니다.

Weighted Distribution을 사용해 지역 간 트래픽 비율을 조정하는 방법을 설명합니다.

🌍 Weighted Locality-Aware Load Balancing이란?

  • 기본적으로 Istio는 모든 트래픽을 같은 지역(예: us-west1-a)의 서비스로 보내고, 엔드포인트가 비정상일 때만 다른 지역(예: us-west1-b)으로 트래픽을 전환합니다.
    하지만 특정 지역의 서비스가 과부하될 가능성이 있을 때, Weighted Distribution을 사용해 트래픽을 여러 지역에 미리 분배할 수 있습니다. 이를 통해 피크 트래픽이나 계절적 부하를 더 효과적으로 관리할 수 있습니다.
  • 예를 들어, simple-backend 서비스의 트래픽을 us-west1-a로 70%, us-west1-b로 30% 분배하도록 설정할 수 있습니다.
    이는 simple-backend-1(us-west1-a)로 70%, simple-backend-2(us-west1-b)로 30%가 가는 것을 의미합니다.
Weighted Locality-Aware Load Balancing은 트래픽을 지역별로 가중치를 설정해 분배하며,
과부하를 방지하고 안정성을 높입니다.

 

그림 : 트래픽을 us-west1-a와 us-west1-b에 각각 70%와 30%로 분배하는 Weighted Locality-Aware Load Balancing 설정

🛠️ 정상 서비스로 복구하기

  • 이전 실습에서 simple-backend-1을 비정상 상태(HTTP 500 에러)로 설정했으므로,
    먼저 모든 서비스가 정상적으로 HTTP 200 응답을 반환하도록 복구합니다:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ kubectl apply -f ch6/simple-service-locality.yaml -n istioinaction
deployment.apps/simple-web unchanged
deployment.apps/simple-backend-1 configured
deployment.apps/simple-backend-2 unchanged
  • 이제 simple-web, simple-backend-1, simple-backend-2 모두 정상적으로 동작합니다.
    이를 기반으로 Weighted Distribution을 설정합니다.
테스트를 시작하기 위해 모든 서비스를 정상 상태로 복구하여
Weighted Locality-Aware Load Balancing을 정확히 테스트할 준비를 합니다.

⚙️ Weighted Distribution 설정하기

  • 특정 지역(예: us-west1-a)의 서비스가 부하를 감당하지 못할 경우, 트래픽의 일부를 다른 지역(예: us-west1-b)으로 분배하도록 설정합니다.
    목표는 simple-backend 서비스의 트래픽을 us-west1-a로 70%, us-west1-b로 30% 분배하는 것입니다.
  • 이를 위해 DestinationRule에 localityLbSetting을 추가해 가중치를 설정합니다:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ cat ch6/simple-backend-dr-outlier-locality.yaml
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: simple-backend-dr
spec:
  host: simple-backend.istioinaction.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      localityLbSetting:
        distribute:
        - from: us-west1/us-west1-a/* #트래픽의 출발 지역
          to: #트래픽 분배 비율을 정의
            "us-west1/us-west1-a/*": 70 #같은 지역의 a 영역으로 70%의 트래픽 전송
            "us-west1/us-west1-b/*": 30 # 30% - b 영역으로 30%의 트래픽 전송
    connectionPool:
      http:
        http2MaxRequests: 10 # HTTP/2 연결당 최대 10개의 요청을 허용
        maxRequestsPerConnection: 10 #각 연결에서 처리할 수 있는 최대 요청 수로, 10개 요청 후 연결이 닫힙니다.
    outlierDetection:
      consecutive5xxErrors: 1
      interval: 5s
      baseEjectionTime: 30s
      maxEjectionPercent: 100
  • 설정을 적용합니다:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ kubectl apply -f ch6/simple-backend-dr-outlier-locality.yaml -n istioinaction
destinationrule.networking.istio.io/simple-backend-dr configured
DestinationRule의 localityLbSetting을 사용해 트래픽을
us-west1-a로 70%, us-west1-b로 30% 분배하도록 설정합니다.

🔍 Weighted Distribution 테스트

  • 이제 설정이 적용되었는지 확인하기 위해 simple-web 서비스를 호출합니다.
    트래픽이 simple-backend-1(us-west1-a)로 약 70%, simple-backend-2(us-west1-b)로 약 30% 분배되어야 합니다.
  • 다음 명령어로 10번 호출해 결과를 확인합니다:
(⎈|kind-myk8s:N/A) ssoon@DESKTOP-QMAIJOE:~/aews-labs/istio-in-action/book-source-code-master$ for in in {1..10}; do curl -s http://simple-web.istioinaction.io:30000 | jq ".upstream_calls[0].body"; done
"Hello from simple-backend-1"
"Hello from simple-backend-2"
"Hello from simple-backend-1"
"Hello from simple-backend-2"
"Hello from simple-backend-1"
"Hello from simple-backend-1"
"Hello from simple-backend-1"
"Hello from simple-backend-2"
"Hello from simple-backend-1"
"Hello from simple-backend-2"
  • 결과를 보면, 대부분의 요청이 simple-backend-1(us-west1-a)로 갔지만, 일부 요청이 simple-backend-2(us-west1-b)로 분배되었습니다. 이는 설정한 70:30 비율과 대략 일치합니다.

Weighted Distribution 설정을 통해 트래픽이
us-west1-a로 약 70%, us-west1-b로 약 30% 분배되어 과부하를 방지합니다.

🆚 Weighted Distribution과 Traffic Routing의 차이

  • Weighted Locality-Aware Load Balancing은 Traffic Routing(예: Chapter 5에서 다룬 버전별 트래픽 제어)과 다릅니다:
    • Weighted Distribution: 서비스의 토폴로지(지역 정보) 를 기반으로 트래픽을 분배합니다.
                                             특정 지역의 부하를 조정하는 데 유용합니다.
    • Traffic Routing: 서비스의 서브셋(버전, 클래스) 을 기준으로 트래픽을 제어합니다.
                                 특정 버전의 서비스로 트래픽을 보내는 데 사용됩니다.
  • 이 두 개념은 상호 배타적이지 않으며, 함께 사용해 더 정교한 트래픽 관리를 할 수 있습니다.
    Locality-Aware Load Balancing으로 지역별 트래픽을 분배한 후, Traffic Routing으로 특정 버전의 서비스를 선택할 수 있습니다.
Weighted Distribution 은 지역 기반 트래픽 분배를,
Traffic Routing 은 서비스 버전별 트래픽 제어를 담당하며,
둘을 조합해 더 세밀한 트래픽 관리가 가능합니다.

📌핵심 요약

  • Istio의 Weighted Locality-Aware Load Balancing은 트래픽을 지역별로 가중치를 설정해 분배하는 기능으로, 피크 트래픽이나 계절적 부하를 관리하는 데 유용합니다.
  • 실습에서는 simple-backend 서비스의 트래픽을 us-west1-a(simple-backend-1)로 70%, us-west1-b(simple-backend-2)로 30% 분배하도록 DestinationRule에 localityLbSetting을 설정했습니다. 테스트 결과, 트래픽이 설정한 비율에 따라 분배되어 과부하를 방지할 수 있음을 확인했습니다.
  • 이는 Traffic Routing과 달리 서비스 토폴로지를 기반으로 작동하며, 두 기능을 조합해 더 정교한 트래픽 관리가 가능합니다. Locality-Aware Load Balancing은 서비스 안정성과 성능을 최적화하는 강력한 도구입니다.

 

저작자표시 (새창열림)