Istio 정복하기 #7 - Locality-aware load balancing
Locality-aware Load Balancing은 요청을 처리할 때 지리상 가까운 인스턴스에 로드 밸런싱해서 응답 시간이 줄어드는 것을 기대할 수 있는 방법이다. Istio에서는 이 기능을 활용하여 다양한 지역의 트래픽을 효과적으로 관리할 수 있다. 물론 나는 Minikube이므로 정확한 환경을 셋티할 수 없지만 라벨링을 통해서 임시적으로 구성해보려고 한다.

Locality-aware load balancing 구현
구현 자체는 어렵지 않다. 먼저 Deployment에 라벨링을 수정해주자.
apiVersion: apps/v1 kind: Deployment metadata: labels: app: test name: test spec: replicas: 1 selector: matchLabels: app: test template: metadata: labels: app: test istio-locality: us-east-1/us-east-1a # <-- AWS 기준 spec: serviceAccountName: test containers: - images: {} imagePullPolicy: IfNotPresent name: test ports: - containerPort: 8080 name: http protocol: TCP
이러면 us-east-1a의 라벨링이 붙게 되는데, 이렇게만 했을 때는 정상 동작하지 않는다. 그 이유는 Locality-aware가 동작하려면 헬스 체킹이 필수이기 때문이다. 즉 DestinationRule를 생성해줘야 한다.
apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: test-destination-rule spec: host: test.default.svc.cluster.local trafficPolicy: outlierDetection: consecutive5xxErrors: 1 interval: 10s baseEjectionTime: 30s
이렇게 하면 10초에 한 번씩 헬스 체킹을 하게 되는데, 1번이라도 5xx 에러가 발생하면 30초동안 트래픽을 끊게 된다. 한 번 직접 테스트 해보면 좋을 거 같다.
Locality-aware load balancing 가중치
가중치 또한 줄 수 있는데, DesinationRule을 조금만 수정해주면 된다.
apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: test-destination-rule spec: host: test.default.svc.cluster.local trafficPolicy: loadBalancer: localityLbSetting: distribute: - from: us-east-1/us-east-1a/* to: "us-east-1/us-east-1a/*": 70 "us-east-1/us-east-1b/*": 30 connectionPool: http: http2MaxRequests: 10 maxRequestsPerConnection: 10 outlierDetection: consecutive5xxErrors: 1 interval: 5s baseEjectionTime: 30s maxEjectionPercent: 100
이렇게하면 us-east-1a에서 오는 요청에 대해서 70%의 비율은 us-east-1a로 가게되고, 나머지 30은 us-east-1b로 가게 된다.
'DevOps > Kubernetes' 카테고리의 다른 글
Istio 정복하기 #8 - Timeouts and retries (0) | 2025.04.02 |
---|---|
Istio 정복하기 #6 - Client-side load balancing (0) | 2025.03.30 |
Istio 정복하기 #5 - 트래픽 관리 - 하 (0) | 2025.03.24 |
Istio 정복하기 #4 - 트래픽 관리 - 상 (0) | 2025.03.23 |
Istio 정복하기 #3 - Istio Ingress Gateway - 하 (0) | 2025.03.20 |
댓글
이 글 공유하기
다른 글
-
Istio 정복하기 #8 - Timeouts and retries
Istio 정복하기 #8 - Timeouts and retries
2025.04.02타임 아웃과 리트라이에 대해서 알아보려고 한다. 타임 아웃은 서비스가 요청에 대해 응답하지 않고 기다리는 최대 시간을 의미한다.서비스 간의 통신에서 대기 시간이 길어져 사용자 경험이 저하되는 것을 방지하고, 시스템 자원을 적절히 관리하기 위해 필요하다.리트라이는 실패한 요청에 대해 자동으로 다시 시도하는 기능으로 일시적인 오류로 인해 요청이 실패하는 경우, 요청을 다시 시도함으로써 성공적인 응답을 받을 수 있는 가능성을 높여준다. 구현 자체는 간단하니 하나씩 살펴보자. Timeout 구현VirtualService에서 간단하게 설정해 주면 된다. apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata: name: test-virtual-… -
Istio 정복하기 #6 - Client-side load balancing
Istio 정복하기 #6 - Client-side load balancing
2025.03.30Client-side load balancing는 클라이언트에게 endpoint들을 알려주고, 클라이언트가 LB 알고리즘을 선택하게 하도록 하는 방법이다. 이것으로 얻는 이점은 다음과 같다. 1. 중앙집중적인 load balancing을 피할 수 있음2. 불필요한 홉 없이 클라이언트가 직접 요청을 전달할 수 있음 (로드밸런서가 필요 없어짐.) 물론 단점으로는 헬스 체크, 알고리즘이 효율성, 엔드포인트 관리 등이 있지만, 장점도 있으니 알아보자. Client-side load balancing 구현DestinationRule로 구현을 할 수 있는데, Gateway와 VritualService부터 생성하자. apiVersion: networking.istio.io/v1alpha3kind: Gatewaymet… -
Istio 정복하기 #5 - 트래픽 관리 - 하
Istio 정복하기 #5 - 트래픽 관리 - 하
2025.03.24하에서는 Mirroring과 Outbound Traffic Control을 알아보겠다. Mirroring미러링은 실시간 트래픽을 다른 서비스로 복제하여 보내는 기술이다. 즉 v1으로 트래픽이 왔을 때 v2로도 트래픽이 복제돼서 보내진다. 하는 방법은 어렵지 않고, VirtualService를 조금만 수정해 주면 된다.apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata: name: testspec: hosts: - "test.io" gateways: - test-gateway http: - route: - destination: host: test subset: version-v1 … -
Istio 정복하기 #4 - 트래픽 관리 - 상
Istio 정복하기 #4 - 트래픽 관리 - 상
2025.03.23다양한 트래픽 제어 기법을 제공하여 마이크로서비스 간의 통신을 보다 효율적이고 안정적으로 관리할 수 있다. 이 중에서 4개를 알아볼 예정이고, 상에서는 Routing과 Traffic Shifting을 알아본다. Routing라우팅은 클라이언트 요청을 올바른 서비스나 서비스의 특정 버전으로 보내는 방식이다. 이것은 새롭게 배포한 버전에 클라이언트가 바로 요청을 보내지 않고, 내부에서 테스트한 후에 요청을 보낼 수 있도록 활용할 수 있다. 이전에 사용한 VirtualService와 DestinationRule을 추가하면 된다. 리소스는 다음과 같이 있다고 가정하자. apiVersion: networking.istio.io/v1alpha3kind: Gatewaymetadata: name: test-gate…
댓글을 사용할 수 없습니다.