연쇄적인 장애전파를 막기위한 방법으로 Unhealthy 시스템으로의 트래픽을 제한하는 방법이다.  Istio 에 정확히 Circuit breaker 라는 이름의 설정은 없다. 하지만 Circuit breaker 로써 효율적으로 작동할 수 있는 두가지 방법을 제공한다.

 

1. 커넥션/요청 수 제한 - Fail Fast 전략

2. 이상 동작 엔드포인트 제거 (Eviction)

 

하나씩 구현해보자.

 

커넥션/요청 수 제한 - Fail Fast 전략 구현

응답 요청이 2초 이상 걸리는 서버를 임의로 구축한다. 그 후 DestinationRule을 추가해준다.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: test-dr
spec:
host: "test.io"
trafficPolicy:
connectionPool:
tcp:
maxConnections: 1
http:
http1MaxPendingRequests: 1
maxRequestsPerConnection: 1
maxRetries: 1
http2MaxRequests: 1

 

여기서 각 옵션들은 다음과 같다. 

 

maxConnections: 이 설정은 이 서비스에 대한 총 연결 수

http1MaxPendingRequests: HTTP/1.1 요청 대기열에 있는 최대 요청 수를 제한하여 그 이상의 요청은 차단. maxRequestsPerConnection: 각 연결에서 처리할 수 있는 최대 요청 수

maxRetries: 요청 실패 시 최대 재시도 횟수

http2MaxRequests: 1: HTTP/2 프로토콜을 사용하는 경우, 모든 호스트에 대해 동시에 처리할 수 있는 최대 요청 수

 

위의 DestinationRule은 결국에 TCP 연결과 HTTP 요청을 각각 최대 1로 제한하고, 요청 실패 시 한 번만 재시도하도록 설정해준다. 

서비스의 설계된 용량에 맞게 유연하게 변경할 수 있다.

 

이상 동작 엔드포인트 제거 (Eviction) 구현

임의로 에러를 발생시키는 서버를 배포했다고 가정하고 DestinationRule을 수정하자. 

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metatdata:
name: test-dr
spec:
host: "test.io"
trafficPolicy:
outlierDetection:
consecutive5xxErrors: 1
interval: 3s
baseEjectionTime: 5s
maxEjectionPercent: 100

 

옵션들은 다음과 같은 설정을 가진다.

 

consecutive5xxErrors: 서비스 인스턴스에서 5xx 오류가 x번 발생할 경우 비정상으로 간주

interval: 이상 감지 검사를 수행하는 주기 이 경우

baseEjectionTime: 비정상으로 감지된 서비스 인스턴스가 로드 밸런싱 풀에서 제외된 후, 다시 포함되기까지의 기본 시간

maxEjectionPercent: 전체 서비스 인스턴스의 최대 몇 퍼센트를 비정상 인스턴스로 간주하고 제외할 수 있는지에 대한 설정

 

위와 같이 했을경우 연속적으로 5xx 오류가 1회 발생하면 해당 인스턴스를 비정상으로 간주하고, 5초 동안 로드 밸런싱 풀에서 제외한다. 이상 동작 감지 검사는 3초마다 진행되며, 전체 인스턴스의 최대 100%가 제외될 수 있음. 이럴 경우 서비스가 모두 동작하지 않을 수 있으므로 퍼센티지와 비율을 조율하는 게 좋을 거 같다. 

 

다음은 Observability에 대해서 알아볼 예정인데, 내용이 복잡하고 많은 만큼 시간이 걸릴지도 모르겠다.