istio 복원력 - circuit breaker

# istio in action 6장 
사내에서 구현한 istio circuit breaker 정리해보려합니다.

 

 

 

들어가면서

쿠버네티스에 올라간 사내 A 서비스는 디플로이먼트 형태로 각 노드에 분산되어 배포되어 있습니다.

디플로이먼트 형태로 배포되었으니, 과연 모든 장애에 대응할 수 있을까요?

 

Deployment는 파드가 종료(OOM, crash)되면 replicas 수를 유지하기 위해 자동으로 재생성합니다.
그러나 프로세스가 죽는 장애와 네트워크 또는 응답 오류는 다른 문제입니다.

 

파드가 Ready 상태를 유지하고 있지만, 내부적으로 5xx 오류를 반환한다면
Kubernetes Service는 이를 감지하고 다른 파드로 자동 전환할 수 있을까요?

 

분산 시스템은 이따끔 예측할 수 없는 방식으로 실패합니다.

마이크로서비스 구조에서는 서비스 간 호출이 연쇄적으로 이어지기 때문에,
하나의 파드에서 발생한 지연이나 오류가 전체 시스템의 응답 지연으로 확산될 수 있습니다.

 

과거에는 이러한 기본 복원력 패턴을 애플리케이션 코드에 많이 포함했지만 

이스티오는 프록시를 통해 해당 문제를 코드변경없이 해결할 수 있습니다.

 

 

 

istio proxy

istio proxy 동작에 대해서는 아래 글을 참고하시길 바랍니다.

https://gnobaaaaar.tistory.com/125

[istio] envoy proxy

 

이스티오의 서비스 프록시는 애플리케이션 컨테이너 옆에 사이드 컨테이너 형태로 위치해서

애플리케이션을 드나드는 모든 네트워크 트래픽을 처리합니다.

파드B도 프록시가 트래픽을 받습니다.

 

서비스 프록시는 L7 수준의 메시지(HTTP 요청 등)을 이해하므로 프록시 안에서 복원력 기능을 구현할 수 있습니다.

 

 

복원력 패턴

- 클라이언트 측 로드 밸런싱

- 지역 인식 로드 밸런싱

- 타임아웃 및 재시도

- 서킷 브레이킹

 

여러 기능이 있지만 여기서는 서킷 브레이킹에 대해 작성해 보겠습니다.

 

 

 

서킷 브레이킹

서킷 브레이커는 말그대로 전기 차단기에서 온 용어입니다.

해당 방식은 차단기가 동작하는 방식과 의도가 비슷합니다.

 

예를 들어 web 프론트 서비스가 web 백엔드 서비스를 호출하는데

백엔드가 연속된 호출에서 오류를 반환하면 서킷 브레이커가 

아래와 같이 동작해서 복원력을 확보합니다.

1. 오류가 임계치를 초과하면 일정 기간 호출을 차단
2. 서비스가 회복할 시간을 확보한 뒤 일부 요청으로 상태를 확인
3. 정상으로 판단되면 다시 트래픽을 허용

 

 

서킷 브레이커 동작 위치

서킷브레이커는 Client Proxy 쪽에서 동작합니다.

┌──────────────────────┐
│   Web Front App      │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│ Envoy Sidecar        │
│ (Client)             │
│                      │
│  - Load Balancing    │
│  - Circuit Breaker   │  ← 여기서 차단 / eject 판단
│  - Outlier Detection │
└──────────┬───────────┘
           │
           ▼
      ───── Network ─────
           │
           ▼
┌──────────────────────┐
│ Envoy Sidecar        │
│ (Server)             │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│ Backend Pod          │
└──────────────────────┘

 

 

 

 

서킷 브레이커 2가지 핵심 기능

Connection Pool 기반 서킷 브레이커는 과부하 보호
Outlier Detection은 문제 인스턴스 격리

 

 

커넥션 풀 제어로 느린 서비스에 대응하기

Istio DestinationRule.trafficPolicy.connectionPool로 업스트림(호출 대상 서비스)로 나가는 자원을 제한

 

옵션값

https://istio.io/latest/docs/reference/config/networking/destination-rule/#ConnectionPoolSettings

Destination Rule

 

maxConnections
대상(파드) 하나에 만들 수 있는 HTTP/1 또는 TCP 커넥션 수 상한  
http1MaxPendingRequests
커넥션 풀에서 사용 가능한 커넥션을 기다리며 큐에 쌓아둘 수 있는 요청 수 (보류)
http2MaxRequests
대상(파드)으로 동시에 활성(진행중) 상태로 허용할 요청 수 상한  
maxRequestsPerConnection
커넥션 1개당 처리할 요청 수(=1이면 keep-alive 사실상 끔)  

 

 

예를 들어 a-service 파드가 3개라면,

• maxConnections: 1
• http1MaxPendingRequests: 1

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: a-service-cb
spec:
  host: a-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 1 # 대상 파드에 생성할 수 있는 최대 TCP 커넥션 수
      http:
        http1MaxPendingRequests: 1 # 대기열(Queue)에 쌓아둘 수 있는 최대 보류 요청 수

 

 

엔드포인트 파드 당 하나만 커넥션이 가능하고

Pod A → 최대 1 connection
Pod B → 최대 1 connection
Pod C → 최대 1 connection

 

옵션을 보면 보류중인 커넥션이 1개까지 가능하므로 (4번째 연결시도)

 

이후에는 connection pool 한계를 초과하면

해당 요청은 업스트림으로 전달되지 않고
클라이언트 측 Envoy에서 즉시 503 실패 처리됩니다.

 

사용목적

connection pool 제한은 연결을 적게만들기 위한 장치가 아니라,

느려진 업스트림을 향해 요청이 무한히 쌓이는 (대기열이 폭등) 상황을 막는 것입니다.

 

connection pool 의 옵션들은 위 장애를 적당한 선에서 차단해서 

시스템 성공률이 아닌 시스템 전체를 위해서 빨리 실패 시키는 장치입니다.

 

 

 

이상값 탐지 감지방식

 

Envoy는 실제 트래픽 결과(5xx 응답, 연결 실패, 지연 등)를 기반으로
문제가 있다고 판단되는 엔드포인트를 로드밸런싱 풀에서 일시적으로 제외(eject)합니다

 

https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/outlier

Outlier detection — envoy 1.38.0-dev-d568d5 documentation

 

 

자주 쓰는 필드

https://istio.io/latest/docs/reference/config/networking/destination-rule/#OutlierDetection

Destination Rule

consecutive5xxErrors: 연속 5xx가 몇 번이면 eject할지 (0이면 비활성 가능) 
interval: ejection 판단을 스윕하는 주기 
baseEjectionTime: 최소 eject 시간(그리고 연속 eject되면 곱해져 길어짐) 
maxEjectionPercent: 한 번에 eject할 수 있는 최대 비율 

 

 

특정 파드가 5xx를 연속 5번 내면, 30초 동안 빼고(첫 eject)

계속 문제면 더 오래 제외한다면

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: a-service-od
spec:
  host: a-service
  trafficPolicy:
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 5s
      baseEjectionTime: 30s
      maxEjectionPercent: 50

 

동일 엔드포인트가 반복적으로 eject될 경우,
ejection 시간은 baseEjectionTime × 횟수만큼 증가합니다.

 

 

사용목적

Outlier Detection은 부분적 장애를 감지하여
문제가 있는 엔드포인트만 일시적으로 격리함으로써
전체 서비스의 성공률과 응답시간을 보호합니다

 

 

차이점

상태 기반인 Kubernetes readiness probe와 달리

실제 트래픽 결과를 기반으로 동적으로 격리하는 메커니즘입니다

실제로 envoy 호출 이후 이상값 판단결과에 따라 동작합니다.

 

 

 

쿠버네티스 서비스와 엔드포인트와 비교

쿠버네티스 서비스도 엔드포인트가 존재하고

엔드포인트에서 제외되면 파드로 트래픽이 전달되지 않습니다.

 

하지만 위에서도 언급했지만

파드가 죽는 장애(OOM, crash)와 네트워크 이슈는 성격이 다릅니다.

 

파드가 Ready 상태를 유지한 채 5xx를 반환하거나,
노드 장애로 kubelet이 즉시 상태를 보고하지 못하는 경우
일정 시간 동안 트래픽이 비정상 엔드포인트로 전달될 수 있습니다.

 

하지만 위와 같은 복원력 패턴을 사용하면 이와 같은 장애에 대응되게 설계할 수 있습니다.

참고로 istio envoy는 쿠버네티스 서비스 엔드포인트와는 다른

내부 엔드포인트목록 (파드IP+Port)를 가지고 있습니다.

 

DestinationRule에서 host: a-service 로 설정하더라도,
실제 Client Envoy는 a-service에 해당하는 개별 엔드포인트(Pod IP:Port) 목록을 

Upstream Cluster로 관리합니다.

Outlier Detection이 동작하면, 문제로 판단된 엔드포인트는 해당 클러스터에서 완전히 삭제되는 것이 아니라
일정 시간 동안 로드밸런싱 대상에서 제외(eject)됩니다.

 

---

호출하는 쪽 (Client) Envoy Proxy는 내부에 업스트림 목적지에 대한 엔드포인트를 가지고 있습니다.

Client Envoy 내부 Upstream Cluster (a-service)

Endpoints:
---------------------------------
10.244.1.12:8080  (Pod A)
10.244.2.15:8080  (Pod B)
10.244.3.21:8080  (Pod C)
---------------------------------

LB 대상에서 제외 시:

10.244.1.12:8080  (EJECTED)
10.244.2.15:8080
10.244.3.21:8080

오해하기 쉬운 부분입니다. (쿠버네티스 서비스 엔드포인트 동작과 다릅니다)

---

 

정리하자면,

Deployment는 프로세스가 종료되었을 때 복구합니다.
반면 Istio Circuit Breaker는 프로세스는 살아있지만 비정상적으로 동작할 때를 보호합니다.

Kubernetes는 상태(State) 기반 복구를 제공하고,
Istio는 실제 요청 흐름을 기반으로 한 트래픽(Traffic) 기반 복원력을 제공합니다.

Kubernetes가 다시 띄우는 역할을 한다면

Istio는 전파를 막는 차단 역할을 수행합니다.

나머지 복원력 패턴은 차후에 정리해 보겠습니다.