Istio 정복하기 #6 - Client-side load balancing

Client-side load balancing는 클라이언트에게 endpoint들을 알려주고, 클라이언트가 LB 알고리즘을 선택하게 하도록 하는 방법이다. 이것으로 얻는 이점은 다음과 같다.

 

1. 중앙집중적인 load balancing을 피할 수 있음

2. 불필요한 홉 없이 클라이언트가 직접 요청을 전달할 수 있음 (로드밸런서가 필요 없어짐.)

 

물론 단점으로는 헬스 체크, 알고리즘이 효율성, 엔드포인트 관리 등이 있지만, 장점도 있으니 알아보자.

 

Client-side load balancing 구현

DestinationRule로 구현을 할 수 있는데, Gateway와 VritualService부터 생성하자. 

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: test-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "test.io"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: test-vs
spec:
  hosts:
  - "test.io"
  gateways:
  - test-gateway
  http:
  - route:
    - destination:
        host: test-backend

 

이제 DestinationRule을 생성해 준다. 

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: test-destination-rule
spec:
  host: test.default.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
      
--- 요청 보냈을 때
..
"test-1",
# 3번째 호출
..
"test-2",
..

 

라운드 로빈은 응답을 바꿔가면서 보내게 된다. 하지만 라운드 로빈 방식은 서버의 응답시간을 고려하지 않고 보내게 되므로 특정 요청은 빠르게 응답이 올 수 있지만, 특정 답변은 늦을 수 있다. 그래서 그중 하나인 응답 속도를 가지고 밸런싱 해보는 방법에 대해서 알아보자. 

 

 

이때 임의로 Application V1-1에 sleep을 줘서 1초의 대기시간을 주게 되면 응답 속도는 느려지게 된다. 이때 완벽한 해결 방법은 아니지만 LEAST_CONN(Least-connection)를 적용해 보자. 

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: test-destination-rule
spec:
  host: test.default.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: LEAST_CONN
      
--- 요청 보냈을 때
..
"test-1",
# 3번째 호출
..
"test-2",
..
..
"test-2",
..
..
"test-2",
..

 

LEAST_CONN 옵션은 엔드포인트의 Latency를 어느 정도 고려하는 지표들을 참고하는 로드 밸런싱 방식이다. 대표적으로 queue depth(현재 대기 중인 요청의 수), active requests(현재 진행 중인 요청)와 같이 병목 지표를 기준으로 동작하게 된다. 이밖에 옵션들의 설명은 다음과 같다. 

 

1. ROUND_ROBIN - 각 요청을 순차적으로 서비스 인스턴스에 배분. 모든 인스턴스에 균일하게 부하를 분산시킴

 

2. LEAST_CONN - 현재 연결 수가 가장 적은 인스턴스에 요청을 보냄 이는 인스턴스별로 연결된 클라이언트 수를 균등하게 유지하려고 할 때 유용함

 

3. RANDOM - 랜덤 하게 요청을 인스턴스에 배분함.

 

4. PASSTHROUGH - 요청을 서비스 인스턴스에 직접 전달하며, 특정 로드 밸런싱 전략 없이 원래 설정된 대로 요청을 처리함. 이 방식은 주로 로드 밸런싱을 사용하지 않으려는 경우에 사용됨.

 

5. MAGLEV: 강력한 일관성과 오류 허용을 강조함 Google에서 개발한 알고리즘으로, 변화에 민감하지 않은 로드 분산을 제공함.

 

각자 환경에 맞는 것을 선택하면 좋을 거 같다.