Istio 회로 차단기: 결함이 있는 컨테이너 비활성화

연휴가 끝나고 Istio Service Mesh 시리즈의 두 번째 게시물로 돌아왔습니다.

오늘의 주제는 회로 차단기(Circuit Breaker)입니다. 이는 러시아 전기 공학에서 "회로 차단기"를 의미하며, 일반적으로 "회로 차단기"를 의미합니다. Istio에서만 이 머신은 단락되거나 과부하된 회로가 아니라 결함이 있는 컨테이너의 연결을 끊습니다.

이것이 이상적으로 작동하는 방식

예를 들어 OpenShift 플랫폼 내에서 Kubernetes로 마이크로서비스를 관리하면 로드에 따라 자동으로 확장 및 축소됩니다. 마이크로서비스는 포드에서 실행되므로 하나의 엔드포인트에 컨테이너화된 마이크로서비스의 여러 인스턴스가 있을 수 있으며 Kubernetes는 요청을 라우팅하고 인스턴스 간에 로드 밸런싱을 수행합니다. 그리고 이상적으로는 이 모든 것이 완벽하게 작동해야 합니다.

우리는 마이크로서비스가 작고 일시적이라는 것을 기억합니다. 여기서 나타나고 사라지는 용이함을 뜻하는 덧없음은 종종 과소평가되기도 한다. Pod에서 또 다른 마이크로서비스 인스턴스의 탄생과 소멸은 상당히 예상되는 일입니다. OpenShift와 Kubernetes는 이를 잘 처리하며 모든 것이 훌륭하게 작동하지만 이론상으로는 다시 그렇습니다.

실제 작동 방식

이제 마이크로서비스의 특정 인스턴스, 즉 컨테이너가 사용할 수 없게 되었다고 상상해 보십시오. 응답하지 않거나(오류 503), 더 불쾌한 것은 응답하지만 너무 느립니다. 즉, 결함이 발생하거나 요청에 응답하지 않지만 풀에서 자동으로 제거되지는 않습니다. 이 경우 어떻게 해야 합니까? 다시 시도하시겠습니까? 라우팅 구성표에서 이를 제거해야 합니까? 그리고 "너무 느리다"는 것은 무엇을 의미합니까? 그 숫자는 몇 개이며, 누가 결정합니까? 잠시 쉬었다가 나중에 다시 시도해 보세요. 그렇다면 얼마나 나중에요?

Istio의 풀 배출이란 무엇입니까?

그리고 여기서 Istio는 라우팅 및 로드 밸런싱 리소스 풀에서 결함이 있는 컨테이너를 일시적으로 제거하고 풀 제거 절차를 구현하는 회로 차단기 보호 시스템을 사용하여 구조에 나섰습니다.

Istio는 이상값 감지 전략을 사용하여 라인을 벗어난 Pod 곡선을 감지하고 절전 창이라고 하는 미리 결정된 시간 동안 리소스 풀에서 이를 제거합니다.

OpenShift 플랫폼의 Kubernetes에서 이것이 어떻게 작동하는지 보여주기 위해 저장소의 예에서 정상적으로 작동하는 마이크로서비스의 스크린샷부터 시작하겠습니다. Red Hat 개발자 데모. 여기에는 각각 하나의 컨테이너를 실행하는 v1과 v2라는 두 개의 포드가 있습니다. Istio 라우팅 규칙이 사용되지 않으면 Kubernetes는 기본적으로 균등하게 균형 잡힌 라운드 로빈 라우팅을 사용합니다.

실패에 대비하기

풀 제거를 수행하기 전에 Istio 라우팅 규칙을 생성해야 합니다. Pod 간에 요청을 50/50 비율로 배포한다고 가정해 보겠습니다. 또한 다음과 같이 v2 컨테이너의 수를 XNUMX에서 XNUMX로 늘릴 것입니다.

oc scale deployment recommendation-v2 --replicas=2 -n tutorial

이제 트래픽이 50/50 비율로 포드 간에 분산되도록 라우팅 규칙을 설정했습니다.

이 규칙의 결과는 다음과 같습니다.

이 화면이 50/50이 아니라 14:9라는 점에서 문제점을 찾을 수 있지만 시간이 지나면 상황이 개선될 것입니다.

결함 만들기

이제 두 개의 v2 컨테이너 중 하나를 비활성화하여 하나의 정상 v1 컨테이너, 하나의 정상 v2 컨테이너 및 하나의 결함이 있는 v2 컨테이너를 갖도록 하겠습니다.

결함 수정

따라서 결함이 있는 컨테이너가 있으므로 이제 Pool Ejection을 수행할 시간입니다. 매우 간단한 구성을 사용하여 이 실패한 컨테이너를 15초 동안 모든 라우팅 체계에서 제외하여 정상 상태(다시 시작 또는 성능 복원)로 돌아갈 수 있기를 바랍니다. 이 구성의 모습과 작업 결과는 다음과 같습니다.

보시다시피, 실패한 v2 컨테이너는 풀에서 제거되었기 때문에 요청 라우팅에 더 이상 사용되지 않습니다. 하지만 15초가 지나면 자동으로 풀로 돌아갑니다. 실제로 우리는 Pool Ejection이 어떻게 작동하는지 보여주었습니다.

건축을 시작하자

Istio의 모니터링 기능과 결합된 Pool Ejection을 사용하면 결함이 있는 컨테이너를 자동으로 교체하기 위한 프레임워크 구축을 시작하여 가동 중지 시간과 오류를 제거하지는 못하더라도 줄일 수 있습니다.
 
NASA에는 하나의 큰 모토가 있습니다. 실패는 옵션이 아니며 저자는 비행 디렉터로 간주됩니다. 진 크란츠. “실패는 선택 사항이 아니다”라는 뜻으로 러시아어로 번역할 수 있는데, 여기서 의미하는 바는 의지가 충분하면 모든 일이 이루어지도록 할 수 있다는 것입니다. 그러나 실생활에서 실패는 그냥 일어나는 것이 아니라 모든 곳에서, 피할 수 없는 일입니다. 그리고 마이크로서비스의 경우 이를 어떻게 처리해야 할까요? 우리 생각에는 의지력보다는 컨테이너의 능력에 의존하는 것이 더 낫다고 생각합니다. Kubernetes, Red Hat OpenShift과 이스 티오.

위에서 쓴 것처럼 Istio는 물리적 세계에서 잘 입증된 회로 차단기 개념을 구현합니다. 그리고 전기 회로 차단기가 회로의 문제 부분을 끄는 것처럼 Istio의 소프트웨어 Circuit Breaker는 엔드포인트에 문제가 있을 때(예: 서버가 충돌하거나 오류가 발생하기 시작했을 때) 요청 스트림과 문제 컨테이너 사이의 연결을 엽니다. 천천히 해.

더욱이 두 번째 경우에는 더 많은 문제가 있습니다. 한 컨테이너의 브레이크로 인해 해당 컨테이너에 액세스하는 서비스가 연속적으로 지연될 뿐만 아니라 결과적으로 시스템 전체의 성능이 저하될 뿐만 아니라 반복적인 오류가 발생하기 때문입니다. 이미 느리게 실행되는 서비스에 대한 요청은 상황을 더욱 악화시킬 뿐입니다.

이론상의 회로 차단기

회로 차단기는 엔드포인트에 대한 요청 흐름을 제어하는 ​​프록시입니다. 이 지점이 작동을 멈추거나 지정된 설정에 따라 속도가 느려지기 시작하면 프록시는 컨테이너와의 연결을 끊습니다. 그런 다음 로드 밸런싱으로 인해 트래픽이 다른 컨테이너로 리디렉션됩니다. 연결은 지정된 절전 창(예: XNUMX분) 동안 열려 있으며 그 이후에는 절반만 열린 것으로 간주됩니다. 다음 요청을 보내려는 시도에 따라 연결의 추가 상태가 결정됩니다. 서비스에 문제가 없으면 연결이 작동 상태로 돌아가고 다시 닫힙니다. 여전히 서비스에 문제가 있는 경우 연결이 끊어지고 절전 창이 다시 활성화됩니다. 단순화된 회로 차단기 상태 다이어그램은 다음과 같습니다.

여기서 이 모든 것이 말하자면 시스템 아키텍처 수준에서 발생한다는 점에 유의하는 것이 중요합니다. 따라서 어느 시점에서는 응답으로 기본값을 제공하거나 가능하면 서비스 존재를 무시하는 등 회로 차단기와 함께 작동하도록 애플리케이션을 가르쳐야 합니다. 이를 위해 격벽 패턴이 사용되지만 이는 이 기사의 범위를 벗어납니다.

실제 회로 차단기

예를 들어 OpenShift에서 두 가지 버전의 추천 마이크로서비스를 실행하겠습니다. 버전 1은 잘 작동하지만 v2에서는 서버 속도 저하를 시뮬레이션하기 위해 지연 시간을 구축합니다. 결과를 보려면 도구를 사용하십시오. 포위 공격:

siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io

모든 것이 작동하는 것 같지만 비용은 얼마입니까? 언뜻 보면 가용성이 100%이지만 자세히 살펴보면 최대 트랜잭션 기간은 12초입니다. 이는 분명히 병목 현상이므로 확장이 필요합니다.

이를 위해 Istio를 사용하여 느린 컨테이너에 대한 호출을 제거합니다. 다음은 회로 차단기를 사용하는 해당 구성의 모습입니다.

httpMaxRequestsPerConnection 매개변수가 포함된 마지막 줄은 기존 연결 외에 다른 연결(두 번째 연결)을 만들려고 할 때 연결을 끊어야 함을 나타냅니다. 컨테이너는 느린 서비스를 시뮬레이션하므로 이러한 상황은 주기적으로 발생하며 Istio는 503 오류를 반환하지만 이는 siege에서 표시되는 내용입니다.

좋아요, 회로 차단기가 있습니다. 다음은 무엇인가요?

그래서 우리는 서비스 자체의 소스 코드를 전혀 건드리지 않고 자동 종료를 구현했습니다. 위에서 설명한 회로 차단기 및 풀 제거 절차를 사용하면 브레이크 컨테이너가 정상으로 돌아올 때까지 리소스 풀에서 브레이크 컨테이너를 제거하고 지정된 빈도로 상태를 확인할 수 있습니다. 이 예에서는 XNUMX분입니다(sleepWindow 매개 변수).

503 오류에 응답하는 애플리케이션의 기능은 여전히 ​​소스 코드 수준에서 설정됩니다. 상황에 따라 회로 차단기를 사용하는 전략은 다양합니다.

다음 게시물에서: Istio에 이미 내장되어 있거나 쉽게 추가되는 추적 및 모니터링과 의도적으로 시스템에 오류를 도입하는 방법에 대해 이야기하겠습니다.

출처 : habr.com