Istio Circuit breaking 정리

 

이번 포스팅은 이스티오의 circuit breaking에 대해 다룬다. 

 

마이크로 서비스 아키텍처에서 가장 일반적인 문제는 cascading failure다.

 

어떤 이유로든 서비스가 응답하지 않는 경우, 서비스에 요청을 반복적으로 보내면 

대기시간이 길어지고 서비스에 불필요한 부하가 발생한다. 

 

한 서비스의 부하는 다른 서비스의 부하로 이어지는데 이런 현상을 cascading failure라 한다. 

 

이때 circuit breaking을 통해 과부하된 서비스의 연결을 끊고 서비스가 회복할 시간을 줄 수 있다. 

 

 

 

예시를 통해 확인해보자. 

 

다음은 fleet-staff-service에서 risky와 safe으로 트래픽을 보내는 경우다.

safe의 경우 200 응답이 오지만, risky는 종종 5xx에러의 응답이 온다. 

 

 

 

 

curl을 통해서 트래픽을 확인해보자.

while (true) do curl http://[IP]/api~; echo; done

 

 

fleetman-staff-service에서 로드밸런싱되어 risky와 safe를 번갈아 가며 호출한다.

하지만 종종 risky를 호출할때 502 error가 발생한다. 

 

위와 같은 에러가 계속 반복되면 대기 시간이 늘어나고 서비스에 불필요한 부하가 발생한다.

 

 

 

이제 Destination rule을 이용해 fleetman-staff-service에 circuit breaking을 설정한다. 

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: circuit-breaker-for-the-entire-default-namespace
spec:
  host: "fleetman-staff-service.default.svc.cluster.local"  
  # This is the name of the k8s service that we're configuring

  trafficPolicy:
    outlierDetection: # Circuit Breakers HAVE TO BE SWITCHED ON
      maxEjectionPercent: 100
      consecutive5xxErrors: 2
      interval: 10s
      baseEjectionTime: 30s

 

 

outlierDetection을 이용하여 circuit breaker를 동작시킨다.

 

maxEjectionPercent: 접속하는 호스트 중 몇  %만 제외시킬지 

consecutive5xxErrors: 연속으로 들어오는 5xx 에러의 수 

inteval: 시간 간격 

baseEjectionTime: 얼마동안 Ejection을 시킬 것인지.

 

위 yaml의 outlierDetection을 요약하면 

10초 동안 연속으로 2개의 5xx에러 응답을 받으면

30초동안 pod를 ejection하여 어떤 호스트도 접근하지 못하게한다. 

 

 

 

curl을 통해 확인해본다. 

while (true) do curl http://[IP]/api~; echo; done

 

 

 

 

circuit breaking rule을 적용하면 키알리에서는 다음과 같이 번개 모양의 아이콘이 나타난다.