Linkerd Rate-Limited 엔드포인트 처리
백엔드가 레이트 리미팅을 구현해서 HTTP 429 또는 gRPC RESOURCE_EXHAUSTED를 반환하면, 기본적으로 프록시는 이런 응답을 로드 밸런싱 관점에서 성공 응답으로 취급해요. 이런 유형의 응답은 보통 매우 빠르기 때문에, Linkerd의 EWMA 로드 밸런싱이 오히려 이런 레이트 제한 상태의 엔드포인트에 더 많은 트래픽을 보낼 수 있어요. 그러면 클라이언트가 높은 429 또는 RESOURCE_EXHAUSTED 비율을 경험하는 피드백 루프가 생길 수 있어요.
Linkerd에는 레이트 제한 상태에 있는 엔드포인트에서 트래픽을 돌려 보내는 데 도움이 되는 두 가지 실험적 기능이 있어요.
Linkerd 프로덕션 팁
이 페이지에는 오픈소스 커뮤니티의 최선 노력 기반 지침이 포함되어 있어요. 미션 크리티컬 애플리케이션을 운영하는 프로덕션 사용자는 Linkerd 프로덕션 리소스를 숙지하고/하거나 상용 Linkerd 제공업체와 연결하는 것이 좋아요.
경고
Rate Limit Aware Load Balancing은 실험적이며 옵트인(opt-in) 기능이에요.
로드 바이어서 (Load Biaser)
Linkerd는 레이트 제한 응답(HTTP 429 또는 gRPC RESOURCE_EXHAUSTED)을 고려하는 더 정교한 버전의 EWMA 로드 밸런싱 알고리즘을 사용하도록 구성할 수 있어요. 이 알고리즘을 Load Biaser라고 하는데, 최근 레이트 제한 응답을 반환한 엔드포인트에서 트래픽을 편향(bias)시키기 때문이에요.
Load Biaser는 EWMA와 정확히 동일하게 동작하지만, 레이트 제한 응답을 받으면 실제 지연 시간 대신 고정된 페널티 값을 대입한다는 차이가 있어요(지연 시간이 더 높지 않은 경우에요). 예를 들어 페널티가 5s로 구성되어 있고 Load Biaser가 10ms 만에 429 응답을 받으면, 로드 밸런싱 목적으로 그 응답의 지연 시간을 5s로 취급해요.
이런 방식으로 로드 밸런서는 레이트 제한 응답을 빠르게 반환하는 엔드포인트를 선호하지 않게 돼요.
서버가 Retry-After HTTP 응답 헤더나 grpc-retry-pushback-ms gRPC 트레일러를 설정하면 페널티 값을 더 정교하게 다듬을 수 있어요. 이 값 중 하나가 존재하고 구성된 페널티보다 크면 그 값이 페널티 대신 사용돼요. 이를 통해 서버가 더 크거나 작은 푸시백(pushback)을 가할 수 있어요.
Service에 대해 Linkerd가 Load Biaser를 사용하도록 하려면 Service 리소스에 다음 어노테이션을 설정하세요:
| Annotation | Type | Default | Notes |
|---|---|---|---|
| balancer.alpha.linkerd.io/penalize-failures | bool | false | Enables the Load Biaser for this Service |
Load Biaser는 Service 리소스의 다음 어노테이션으로 추가 구성할 수 있어요:
| Annotation | Type | Default | Notes |
|---|---|---|---|
| balancer.alpha.linkerd.io/load-biaser-penalty | duration | 5s | The latency value to inject for rate-limited responses and failures |
| balancer.alpha.linkerd.io/load-biaser-max-retry-after | duration | 300s | The maximum allowed value of a Retry-After header |
통합 서킷 브레이커 (Unified Circuit Breaker)
Linkerd는 실패 누적 기법 중 하나인 '연속 실패(consecutive failures)'의 더 정교한 버전인 Unified failure accrual을 사용하도록 구성할 수 있어요.
Unified failure accrual은 성공률 임계값으로 구성할 수 있어요. 고정된 시간 창 안의 응답 비율이 이 임계값 아래로 떨어지면 서킷 브레이커가 트립되어 일시적으로 이 엔드포인트의 트래픽을 차단하고 회복할 시간을 줘요. 중요한 점은, 어떤 레이트 제한 응답이라도 이 성공률 계산에서는 실패로 간주된다는 것이에요.
Unified failure accrual은 또한 연속 실패 누적 방식처럼 구성된 수만큼 연속 실패를 만나면 역시 트립돼요.
Service에서 Unified failure accrual 서킷 브레이커를 활성화하려면 Service 리소스에 다음 어노테이션을 "unified"로 설정하세요:
| Annotation | Type | Default | Notes |
|---|---|---|---|
| balancer.linkerd.io/failure-accrual | string | None | The failure-accrual mode. Set to unified to enable Unified failure accrual |
Unified failure accrual은 Service 리소스의 다음 어노테이션으로 추가 구성할 수 있어요:
| Annotation | Type | Default | Notes |
|---|---|---|---|
| balancer.alpha.linkerd.io/failure-accrual-success-rate-threshold | number between 0 and 1 | 0.8 | The success rate threshold at which to trip the breaker |
| balancer.alpha.linkerd.io/failure-accrual-success-rate-window | duration | 10s | The window over which the success rate is calculated |
| balancer.alpha.linkerd.io/failure-accrual-success-rate-min-requests | number | 5 | Only trip if there are at least this many requests in the window |
| balancer.linkerd.io/failure-accrual-consecutive-max-failures | number | 7 | Trip if we encounter this many consecutive failures |
| balancer.linkerd.io/failure-accrual-consecutive-min-penalty | duration | 1s | The minimum duration for which to cut off traffic |
| balancer.linkerd.io/failure-accrual-consecutive-max-penalty | duration | 1m | The maximum duration for which to cut off traffic |
| balancer.linkerd.io/failure-accrual-consecutive-jitter-ratio | number between 0.0 and 100.0 | 0.5 | The amount of randomness to inject into the backoff |
실패 누적 구성에 대한 자세한 내용은 레퍼런스 문서를 참고하세요.
본문
백엔드가 레이트 리미팅을 구현해서 HTTP 429 또는 gRPC RESOURCE_EXHAUSTED를 반환하면, 기본적으로 프록시는 이런 응답을 로드 밸런싱 관점에서 성공 응답으로 취급해요. 이런 유형의 응답은 보통 매우 빠르기 때문에, Linkerd의 EWMA 로드 밸런싱이 오히려 이런 레이트 제한 상태의 엔드포인트에 더 많은 트래픽을 보낼 수 있어요. 그러면 클라이언트가 높은 429 또는 RESOURCE_EXHAUSTED 비율을 경험하는 피드백 루프가 생길 수 있어요.
Linkerd에는 레이트 제한 상태에 있는 엔드포인트에서 트래픽을 돌려 보내는 데 도움이 되는 두 가지 실험적 기능이 있어요.
Linkerd 프로덕션 팁
이 페이지에는 오픈소스 커뮤니티의 최선 노력 기반 지침이 포함되어 있어요. 미션 크리티컬 애플리케이션을 운영하는 프로덕션 사용자는 Linkerd 프로덕션 리소스를 숙지하고/하거나 상용 Linkerd 제공업체와 연결하는 것이 좋아요.
경고
Rate Limit Aware Load Balancing은 실험적이며 옵트인(opt-in) 기능이에요.
로드 바이어서 (Load Biaser)
Linkerd는 레이트 제한 응답(HTTP 429 또는 gRPC RESOURCE_EXHAUSTED)을 고려하는 더 정교한 버전의 EWMA 로드 밸런싱 알고리즘을 사용하도록 구성할 수 있어요. 이 알고리즘을 Load Biaser라고 하는데, 최근 레이트 제한 응답을 반환한 엔드포인트에서 트래픽을 편향(bias)시키기 때문이에요.
Load Biaser는 EWMA와 정확히 동일하게 동작하지만, 레이트 제한 응답을 받으면 실제 지연 시간 대신 고정된 페널티 값을 대입한다는 차이가 있어요(지연 시간이 더 높지 않은 경우에요). 예를 들어 페널티가 5s로 구성되어 있고 Load Biaser가 10ms 만에 429 응답을 받으면, 로드 밸런싱 목적으로 그 응답의 지연 시간을 5s로 취급해요.
이런 방식으로 로드 밸런서는 레이트 제한 응답을 빠르게 반환하는 엔드포인트를 선호하지 않게 돼요.
서버가 Retry-After HTTP 응답 헤더나 grpc-retry-pushback-ms gRPC 트레일러를 설정하면 페널티 값을 더 정교하게 다듬을 수 있어요. 이 값 중 하나가 존재하고 구성된 페널티보다 크면 그 값이 페널티 대신 사용돼요. 이를 통해 서버가 더 크거나 작은 푸시백(pushback)을 가할 수 있어요.
Service에 대해 Linkerd가 Load Biaser를 사용하도록 하려면 Service 리소스에 다음 어노테이션을 설정하세요:
| Annotation | Type | Default | Notes |
|---|---|---|---|
| balancer.alpha.linkerd.io/penalize-failures | bool | false | Enables the Load Biaser for this Service |
Load Biaser는 Service 리소스의 다음 어노테이션으로 추가 구성할 수 있어요:
| Annotation | Type | Default | Notes |
|---|---|---|---|
| balancer.alpha.linkerd.io/load-biaser-penalty | duration | 5s | The latency value to inject for rate-limited responses and failures |
| balancer.alpha.linkerd.io/load-biaser-max-retry-after | duration | 300s | The maximum allowed value of a Retry-After header |
통합 서킷 브레이커 (Unified Circuit Breaker)
Linkerd는 실패 누적 기법 중 하나인 '연속 실패(consecutive failures)'의 더 정교한 버전인 Unified failure accrual을 사용하도록 구성할 수 있어요.
Unified failure accrual은 성공률 임계값으로 구성할 수 있어요. 고정된 시간 창 안의 응답 비율이 이 임계값 아래로 떨어지면 서킷 브레이커가 트립되어 일시적으로 이 엔드포인트의 트래픽을 차단하고 회복할 시간을 줘요. 중요한 점은, 어떤 레이트 제한 응답이라도 이 성공률 계산에서는 실패로 간주된다는 것이에요.
Unified failure accrual은 또한 연속 실패 누적 방식처럼 구성된 수만큼 연속 실패를 만나면 역시 트립돼요.
Service에서 Unified failure accrual 서킷 브레이커를 활성화하려면 Service 리소스에 다음 어노테이션을 "unified"로 설정하세요:
| Annotation | Type | Default | Notes |
|---|---|---|---|
| balancer.linkerd.io/failure-accrual | string | None | The failure-accrual mode. Set to unified to enable Unified failure accrual |
Unified failure accrual은 Service 리소스의 다음 어노테이션으로 추가 구성할 수 있어요:
| Annotation | Type | Default | Notes |
|---|---|---|---|
| balancer.alpha.linkerd.io/failure-accrual-success-rate-threshold | number between 0 and 1 | 0.8 | The success rate threshold at which to trip the breaker |
| balancer.alpha.linkerd.io/failure-accrual-success-rate-window | duration | 10s | The window over which the success rate is calculated |
| balancer.alpha.linkerd.io/failure-accrual-success-rate-min-requests | number | 5 | Only trip if there are at least this many requests in the window |
| balancer.linkerd.io/failure-accrual-consecutive-max-failures | number | 7 | Trip if we encounter this many consecutive failures |
| balancer.linkerd.io/failure-accrual-consecutive-min-penalty | duration | 1s | The minimum duration for which to cut off traffic |
| balancer.linkerd.io/failure-accrual-consecutive-max-penalty | duration | 1m | The maximum duration for which to cut off traffic |
| balancer.linkerd.io/failure-accrual-consecutive-jitter-ratio | number between 0.0 and 100.0 | 0.5 | The amount of randomness to inject into the backoff |
실패 누적 구성에 대한 자세한 내용은 레퍼런스 문서를 참고하세요.