🐙 Chaos Engineering에 대한 새로운 시도, 장애 주입과 성능 평가 툴 ; 'Krkn' 소개 - CNCF Sandbox

[cloudbro-radar]

Chaos Engineering 분야에서 널리 사용되는 Gremlin(상용)과 LitmusChaos(CNCF)와 달리, Krkn은 단순 장애 주입을 넘어 Platform · Cluster 전반의 성능과 복원력 강도를 정밀하게 평가할 수 있는 Python 기반 고난도 Chaos Testing Tool, Krkn을 소개합니다.

GitHub - krkn-chaos/krkn: Chaos and resiliency testing tool for Kubernetes...

Red Hat(OpenShift) Engineering Team 주도로 시작되여, 현재 Cloud Native Computing Foundation Sandbox Project이며, 특히 고난도의 Testing이 가능하기에 Platform Engineering에 좀 더 효과적으로 사용할 수 있는 Opensource입니다.

이와 유사한 도구로는 Gremlin(상용), LitmusChaos(오픈소스)와는 기능, 분야 등 아래와 같은 차이가 있습니다.

특징	Gremlin	LitmusChaos	Krkn (Kraken)
유형	상용 소프트웨어 (SaaS)	오픈소스 (CNCF Incubating)	오픈소스 (CNCF Sandbox)
주요 대상	엔터프라이즈, 비숙련 조직	DevOps, SRE, K8s 개발자	플랫폼 엔지니어, 클러스터 운영자
핵심 강점	안전성(Safety), 직관적인 UI, 간편한 설치, 다양한 플랫폼 지원(Non-K8s 포함)	ChaosHub(다양한 실험), K8s Native(CRD), 아르고(Argo) 등 워크플로우 통합 용이	클러스터 인프라 테스트, 성능 부하 테스트 병행, Cerberus(모니터링) 연동
아키텍처	에이전트 설치 방식 (Control Plane은 SaaS)	Operator 패턴 (K8s CRD 기반)	파이썬 기반 자동화 툴 (CI/CD 친화적)
난이도	하 (매우 쉬움)	중 (K8s 지식 필요)	중/상 (설정 파일 및 시나리오 이해 필요)
비용	유료 (상당히 고가)	무료 (Harness에서 상용 지원)	무료
주요 시나리오	리소스 고갈, 네트워크 지연, 셧다운 (정형화됨)	파드 삭제, 노드 드레인, 클라우드 API 장애 등 (매우 다양)	Etcd 장애, API 서버 부하, Zone Outage, 전원 차단 시뮬레이션

Litmus가 "애플리케이션 파드 죽이기"에 강하다면, Krkn은 “노드 전체 날리기”, “Etcd 죽이기”, “전체 가용 영역(Zone) 차단하기” 같은 무거운 인프라 레벨 테스트에 더 강점이 있습니다.

• Cerberus 연동: 단순히 장애를 주는 게 아니라, Cerberus라는 도구와 함께 돌아가며 장애 발생 시 클러스터의 전반적인 건강 상태(Health)와 성능 지표 변화를 정밀하게 추적합니다.
• 단순 장애 주입을 넘어 성능 벤치마킹 성격이 섞여 있습니다.

• 상세 정보 : krkn Insights

[출처] Krkn | CNCF

카오스 테스팅 가이드 (Chaos Testing Guide)

장애 조건 하에서 성능을 개선하는 데 중점을 둔 쿠버네티스용 카오스 및 리질리언스(회복탄력성) 테스팅 도구입니다. CNCF 샌드박스 프로젝트입니다.

소개 (Introduction)

분산 시스템에서 애플리케이션을 운영하고 실행할 때 사용자가 가질 수 있는 몇 가지 잘못된 가정이 있습니다.

1. 네트워크는 신뢰할 수 있다.
2. 지연 시간(Latency)은 0이다.
3. 대역폭은 무한하다.
4. 네트워크는 안전하다.
5. 토폴로지는 절대 변하지 않는다.
6. 네트워크는 동질적이다.
7. 스파이크 없이 리소스 사용량이 일정하다.
8. 모든 공유 리소스는 어디서든 사용 가능하다.

과거에는 이러한 가정들로 인해 프로덕션 환경에서 수많은 중단 사고가 발생했습니다. 서비스 성능이 저하되거나 고객이 접속할 수 없게 되어, 서비스 수준 계약(SLA) 가동 시간 약속을 지키지 못하고 수익 손실이 발생하며 해당 서비스의 신뢰도 하락으로 이어졌습니다.

이런 일이 발생하지 않도록 하려면 어떻게 해야 할까요? 바로 여기서 **카오스 테스팅(Chaos testing)**이 가치를 발휘합니다.

---

테스트 전략 및 방법론 (Test Strategies and Methodology)

프로덕션에서의 장애는 비용이 많이 듭니다. 서비스 상태에 대한 위험을 완화하기 위해 다음 전략과 접근 방식을 고려하세요.

수동적(Reactive) 대응 vs 능동적(Proactive) 대응 우리는 통제된 환경에서 코드 버그를 찾아내는 데 도움이 되는 다양한 유형의 테스트 제품군(단위, 통합 및 엔드 투 엔드)을 보유하고 있습니다. 카오스 엔지니어링 전략을 구현함으로써 서비스 저하의 잠재적 원인을 발견할 수 있습니다. 시스템을 강화해야 할 영역을 찾기 위해 예측 불가능한 조건에서 시스템의 동작을 이해해야 하며, 다운타임을 최소화하기 위해 장애를 처리할 수 있도록 클러스터 크기를 조정하는 데 성능 데이터 포인트를 사용해야 합니다.

혼란스러운 조건에서의 시스템 회복탄력성 테스트 시스템의 적응성과 성능을 모니터링하면서 중단을 유발하도록 설계된 테스트를 실행합니다.

1. 정상 상태(Steady state) 및 지표 설정: 안정적인 조건에서의 동작과 성능을 이해하고 시스템 동작을 평가하는 데 사용할 지표를 정의합니다. 그런 다음 카오스를 주입하기 전에 허용 가능한 결과를 결정합니다.
2. 카오스 테스트 실행 중 모든 구성 요소의 상태 및 지표 분석.
3. 카오스 이전의 안정적인 조건과 주요 지표 및 서비스 수준 목표(SLO)를 비교하여 회복탄력성과 성능이 부족한 영역을 개선. 예: API 서버 지연 시간 또는 애플리케이션 가동 시간을 평가하여 핵심 성과 지표(KPI) 및 서비스 수준 지표(SLI)가 여전히 허용 가능한 한도 내에 있는지 확인합니다.

---

모범 사례 (Best Practices)

테스트 방법론을 이해했으니, 이제 쿠버네티스 클러스터에 대한 모범 사례를 살펴보겠습니다. 이 플랫폼에는 안정성을 위해 설계되어야 하고 최상의 사용자 경험을 제공해야 하는 사용자 애플리케이션과 클러스터 워크로드가 있습니다.

• 적절한 심각도의 경고(Alerts)가 발생해야 합니다. 경고는 구성 요소의 성능 저하가 시작되는 시점을 식별하는 데 중요하며, 영향을 받는 시스템 구성 요소에 대한 조사 노력에 집중하는 데 도움이 될 수 있습니다. 대응하는 SRE 또는 운영 리소스의 평균 복구 시간(MTTR)을 줄이려면 경고에 적절한 심각도, 설명, 알림 정책, 에스컬레이션 정책 및 SOP가 있어야 합니다. (경고 일관성에 대한 자세한 내용은 링크 참조)
• 성능 영향 최소화 - 네트워크, CPU, 메모리, 디스크, 처리량 등 시스템과 애플리케이션은 중단 중에 성능 영향을 최소화하여 안정성을 보장하고 다른 애플리케이션이 사용할 수 있는 리소스를 독점하지 않도록 설계되어야 합니다. CPU, 메모리, 디스크, 처리량, 네트워크 등의 측면에서 이를 검토해야 합니다.
• 성능 스로틀링 및 OOM(Out of Memory) 강제 종료를 방지하기 위한 적절한 CPU/메모리 제한 설정 노드에서 리소스(CPU/메모리)를 독점하는 불량 애플리케이션이 있을 수 있으며, 이는 애플리케이션 성능 저하 또는 OOM 강제 종료로 이어질 수 있습니다. kube-scheduler가 예상 수준에서 성능을 유지할 수 있도록 애플리케이션 및 시스템 구성 요소에 예약된 리소스가 있는지 확인하는 것이 중요합니다.
• 테스트 대상 시스템에 의존하는 서비스는 성능 저하 및 다운타임을 방지하기 위해 장애를 우아하게(gracefully) 처리해야 합니다 (적절한 타임아웃). 분산 시스템에서 배포된 서비스는 서로 조정하며 외부 종속성을 가질 수 있습니다. 배포(deployment), 파드(pod) 또는 컨테이너로 배포된 각 서비스는 적절한 타임아웃, 폴백(fallback) 로직 등이 없어 충돌하는 대신 다른 종속 서비스의 다운타임을 우아하게 처리해야 합니다.
• 특히 클러스터가 크고 밀집된 경우 연쇄 장애(cascading failures)를 방지하고 클러스터 안정성을 보장하기 위한 적절한 노드 사이징 플랫폼은 카오스 이벤트 중에 발생할 수 있는 리소스 사용량 급증을 고려하여 크기를 조정해야 합니다. 예를 들어, 메인 노드 중 하나가 다운되면 다른 두 메인 노드가 부하를 처리할 수 있는 충분한 리소스를 가지고 있어야 합니다. 리소스 사용량은 컨트롤 플레인(API 서버, Etcd, 컨트롤러 및 스케줄러)이 관리하는 부하 또는 실행 중인 객체 수에 따라 달라집니다. 따라서 이러한 조건을 테스트하고, 동작을 이해하고, 데이터를 활용하여 플랫폼 크기를 적절하게 조정하는 것이 중요합니다. 이는 컨트롤 플레인이 전체 클러스터를 다운시킬 수 있는 연쇄 장애를 겪지 않고 예상치 못한 이벤트 동안 애플리케이션을 안정적으로 유지하는 데 도움이 될 수 있습니다.
• 애플리케이션 장애를 방지하고 안정성을 유지하기 위한 적절한 노드 사이징 애플리케이션 파드는 충돌 후 재초기화 중에 더 많은 리소스를 사용할 수 있으므로, 이를 수용할 수 있도록 클러스터 노드 크기를 조정할 때 이를 고려하는 것이 중요합니다. 예를 들어, 프로메테우스(Prometheus)와 같은 모니터링 솔루션은 다시 시작할 때 WAL(Write Ahead Log)을 재생하기 위해 많은 양의 메모리가 필요합니다. 따라서 이러한 조건을 테스트하고, 동작을 이해하고, 데이터를 활용하여 플랫폼 크기를 적절하게 조정하는 것이 중요합니다. 이는 성능 저하를 겪거나 노드의 리소스를 독점하여 다른 애플리케이션 및 시스템 파드에 영향을 주지 않고 예상치 못한 이벤트 동안 애플리케이션을 안정적으로 유지하는 데 도움이 될 수 있습니다.
• 최소한의 초기화 시간 및 빠른 복구 로직 구성 요소를 감시하는 컨트롤러는 가능한 한 빨리 장애를 인식해야 합니다. 구성 요소는 고가용성 구성인 경우 가동 중지 시간을 연장하거나 복제본에 과부하가 걸리는 것을 방지하기 위해 초기화 시간을 최소화해야 합니다. 장애 원인은 실행 중인 인프라 문제, 애플리케이션 장애 또는 종속된 서비스 장애일 수 있습니다.
• 고가용성 배포 전략 사용자/시스템 요청을 처리하면서 중단에서 살아남으려면 서로 다른 가용성 영역(AZ)에서 실행되는 여러 복제본(쿠버네티스 및 애플리케이션 컨트롤 플레인 모두)이 있어야 합니다. 단일 실패 지점(SPOF)을 피하십시오.
• 영구 저장소(Persistent Storage)로 백업 시스템/애플리케이션을 영구 저장소로 백업하는 것이 중요합니다. 노드, 파드 또는 컨테이너 장애 시 데이터가 지워지므로 애플리케이션이 데이터베이스이거나 상태 저장(stateful) 애플리케이션인 경우 특히 중요합니다.
• CDN을 사용하는 경우 백엔드로의 폴백 경로가 있어야 합니다 (예: Google Search 경우 Akamai). 콘텐츠 전송 네트워크(CDN)는 이미지, 자바스크립트 파일, CSS와 같은 리소스를 호스팅하는 데 일반적으로 사용됩니다. 무거운 리소스를 타사에 오프로드하는 것은 백엔드 서버 트래픽과 지연 시간을 줄이는 데 매우 효과적입니다. 그러나 이로 인해 CDN은 이를 의존하는 모든 사이트에 대한 추가적인 실패 지점이 됩니다. CDN이 실패하면 고객도 실패할 수 있습니다. 애플리케이션이 장애에 어떻게 반응하는지 테스트하려면 시스템과 CDN 간의 모든 네트워크 트래픽을 차단해 보세요. 애플리케이션은 장애와 관계없이 사용자에게 콘텐츠를 제공해야 합니다.
• 클라이언트 측 지연 시간이 있을 때 성능과 사용성을 유지하기 위해 적절한 캐싱 및 CDN을 활성화해야 합니다. 모든 사용자나 기계가 무제한 대역폭에 액세스할 수 있는 것은 아닙니다. 지리적 위치에 따라 제한된 대역폭, 스로틀링 또는 지연 시간으로 인해 클라이언트 측에서 API에 액세스하는 데 지연이 발생할 수 있습니다. 클라이언트와 API 호출 사이에 지연 시간을 주입하여 동작을 이해하고 가능한 경우 캐싱을 사용하거나 CDN을 사용하거나 HTTP 대신 HTTP/2 또는 HTTP/3과 같은 다른 프로토콜을 선택하는 등 최적화하는 것이 중요합니다.
• 중요 애플리케이션에 대해 중단 예산(Disruption Budgets)이 활성화되었는지 확인 파드 중단 예산(Pod Disruption Budget)을 설정하여 중단 중에 애플리케이션을 보호하고 다운타임을 방지하세요. 예를 들어 etcd, zookeeper 또는 유사한 애플리케이션은 쿼럼을 유지하기 위해 최소 2개의 복제본이 필요합니다. 이는 PDB maxUnavailable을 1로 설정하여 보장할 수 있습니다.

---

도구 (Tooling)

모범 사례를 살펴보았으니, 이 섹션에서는 카오스 테스팅 프레임워크인 **Kraken(Krkn)**이 쿠버네티스의 회복탄력성을 테스트하고 애플리케이션과 서비스가 모범 사례를 따르고 있는지 확인하는 데 어떻게 도움이 되는지 살펴보겠습니다.

워크플로우 (Workflow)

Kraken의 워크플로우를 이해해 봅시다.

1. 사용자는 kubeconfig를 사용하여 특정 쿠버네티스 클러스터를 가리키며 Kraken을 실행합니다. 이를 통해 쿠버네티스 클러스터가 호스팅된 플랫폼과 통신할 수 있습니다(oc/kubectl API 또는 클라우드 API 사용).
2. Kraken의 구성에 따라 아래와 같은 특정 카오스 시나리오를 주입합니다.
3. (선택 사항) Cerberus와 통신하여 클러스터의 전반적인 상태를 나타내는 go/no-go 신호를 받습니다.
4. (선택 사항) 메트릭 프로필에 주어진 promql 쿼리를 사용하여 클러스터 내부의 Prometheus에서 지표를 수집하고 구성된 Elasticsearch에 장기 저장합니다.
5. (선택 사항) 경고 프로필에 지정된 promql 표현식을 평가합니다.
6. 모든 것을 집계하여 합격/불합격(pass/fail), 즉 0 또는 1로 종료합니다.

메트릭 수집, Cerberus 및 메트릭 평가에 대한 자세한 내용은 다음 섹션에서 확인할 수 있습니다.

클러스터 복구 확인, 지표 평가 및 합격/불합격 기준

대부분의 시나리오에는 대상 구성 요소가 지정된 시간 후에 장애로부터 복구되었는지 확인하는 내장 검사가 있습니다. 하지만 특정 장애로 인해 다른 구성 요소가 영향을 받을 수 있는 경우가 있으며, 카오스 이후 시스템/애플리케이션이 전체적으로 건강한지 확인하는 것이 매우 중요합니다. 바로 이때 Cerberus가 도움이 됩니다. 모니터링 도구인 Cerberus가 활성화되면 신호를 소비하고 그 신호에 따라 카오스를 계속 실행할지 여부를 결정합니다.

복구 및 클러스터 상태 확인 외에도 지연 시간, 리소스 사용량 급증, 처리량, etcd 상태(디스크 fsync, 리더 선출 등)와 같은 성능 지표를 평가하는 것도 똑같이 중요합니다. 이를 돕기 위해 Kraken은 클러스터 내 Prometheus에서 promql 표현식을 평가하고 각 쿼리에 설정된 심각도에 따라 종료 상태를 0 또는 1로 설정하는 방법을 제공합니다.

Kraken의 전반적인 합격 또는 불합격은 특정 구성 요소의 복구(특정 시간 내), 전체 클러스터의 상태를 추적하는 Cerberus 상태 신호, 그리고 클러스터 내 Prometheus의 지표 평가를 기반으로 합니다.

---

시나리오 (Scenarios)

Kraken-hub(Kraken을 쉽게 실행할 수 있도록 감싼 경량 래퍼)를 사용하여 쿠버네티스 클러스터에서 카오스 시나리오를 실행하는 방법을 살펴보겠습니다. 컨테이너 이미지를 podman으로 실행하고 매개변수를 환경 변수로 설정하기만 하면 됩니다. 구성 파일을 가지고 다니며 편집할 필요가 없어 CI 프레임워크 통합이 쉽습니다. 지원되는 시나리오는 다음과 같습니다.

• 파드 시나리오 (Pod Scenarios): 쿠버네티스 및 파드로 배포된 애플리케이션을 중단시킵니다. 애플리케이션의 가용성, 초기화 타이밍 및 복구 상태를 이해하는 데 도움이 됩니다.
• 컨테이너 시나리오 (Container Scenarios): 파드의 일부로 실행되는 컨테이너를 특정 kill 신호를 사용하여 중단시킵니다. 컨테이너 내의 프로그램/프로세스가 중단(멈춤, 일시 중지, 강제 종료 등)될 때의 영향과 복구 타이밍을 이해하는 데 도움이 됩니다.
• 노드 시나리오 (Node Scenarios): 클라우드 API와 통신하여 클러스터 인프라의 일부인 노드를 중단시킵니다. AWS, Azure, GCP, OpenStack, Baremetal이 지원됩니다. (노드 종료, 포크 폭탄, 노드 중지, kubelet 충돌 등)
• 영역 중단 (Zone Outages): 퍼블릭 클라우드의 특정 리전 내 가용성 영역(AZ)의 중단을 시뮬레이션합니다. 네트워크 ACL을 조정하여 해당 영역의 모든 노드에서 인바운드/아웃바운드 트래픽을 차단합니다. 쿠버네티스 컨트롤 플레인과 워커 노드의 애플리케이션에 미치는 영향을 이해하는 데 도움이 됩니다. (현재 AWS만 지원)
• 애플리케이션 중단 (Application Outages): 지정된 시간 동안 라벨이 일치하는 애플리케이션의 트래픽(Ingress/Egress)을 차단하여, 다운타임 동안 해당 서비스 또는 의존 서비스의 동작을 이해합니다.
• 전력 중단 (Power Outages): 지정된 시간 동안 전체 클러스터를 종료한 다음 모든 노드를 다시 시작하고 클러스터 상태를 확인하여 전력 중단을 모방합니다. 비용 절감을 위해 특정 시간에 클러스터를 종료하는 경우 등에 유용합니다.
• 리소스 폭주 (Resource Hog): 대상 노드의 CPU, 메모리, IO를 폭주(Hog)시킵니다. 불량 애플리케이션으로 인해 시스템 구성 요소가 중단되거나 성능이 스로틀링되지 않도록 예약된 리소스가 있는지 확인하는 데 도움이 됩니다.
• 시간 왜곡 (Time Skewing): 특정 파드/노드의 시스템 시간 및/또는 날짜를 조작합니다. 객체 스케줄링이 계속 작동하는지, 시간이 제대로 재설정되는지 확인합니다.
• 네임스페이스 장애 (Namespace Failures): 지정된 시간 동안 네임스페이스를 삭제합니다. 다른 구성 요소에 미치는 영향을 이해하고 대상 네임스페이스 구성 요소의 복구 시간을 테스트/개선합니다.
• 영구 볼륨 채우기 (Persistent Volume Fill): 파드가 사용하는 영구 볼륨을 지정된 기간 동안 주어진 비율까지 채웁니다. 디스크에 데이터를 쓸 수 없을 때 애플리케이션이 어떻게 처리하는지(예: Kafka가 디스크에 데이터를 커밋할 수 없을 때의 동작) 이해하는 데 도움이 됩니다.
• 네트워크 카오스 (Network Chaos): 네트워크 지연, 패킷 손실, 인터페이스 플래핑, DNS 오류, 패킷 손상, 대역폭 제한 등을 지원합니다.

---

테스트 환경 권장 사항 (Test Environment Recommendations)

카오스 테스트를 실행하는 방법과 장소에 대한 몇 가지 권장 사항을 살펴보겠습니다.

1. 테스트 파이프라인에서 지속적으로 카오스 테스트 실행: 소프트웨어, 시스템 및 인프라는 변하며 각각의 상태/건강도 빠르게 변할 수 있습니다. 정기적인 주기로 실행되는 CI/CD 파이프라인에서 테스트를 실행하는 것이 좋습니다.
2. 시스템에서 배우기 위해 수동으로 카오스 테스트 실행: 카오스 시나리오나 결함 테스트를 실행할 때는 실행을 합격 또는 불합격으로 표시하는 것보다 시스템이 어떻게 반응하고 대응하는지 이해하는 것이 더 중요합니다. 일부 문제가 다른 문제를 가리지 않도록 실행 전에 테스트 범위를 정의하는 것이 중요합니다.
3. 프로덕션 환경에서 카오스 테스트를 실행하거나 스테이징 환경에서 부하를 모방: 프로덕션 테스트는 무서운 일이지만, 프로덕션은 사용자가 있는 환경이며 트래픽 급증/부하는 실제입니다. 프로덕션 시스템의 견고성/회복탄력성을 완전히 테스트하려면 프로덕션 환경에서 카오스 엔지니어링 실험을 실행하는 것이 필요한 통찰력을 제공합니다.

• 주의: 사용자와 고객이 다운타임을 겪지 않도록 폭발 반경(blast radius)을 최소화하고 백업 계획을 마련하세요. SLA가 너무 엄격하여 다운타임을 커버할 수 없는 경우 스테이징 환경에서 부하를 모방하세요.

4. 관측 가능성(Observability) 활성화: 관측 가능성 없는 카오스 엔지니어링은… 그냥 혼란(Chaos)일 뿐입니다. 클러스터에 로깅 및 모니터링을 설치하여 왜 그런 일이 발생하는지 이해하는 데 도움을 받으세요. 사람이 항상 클러스터를 모니터링할 수 없는 CI에서 테스트를 실행하는 경우, Cerberus를 활용하여 실행 중 상태를 캡처하고 Kraken의 지표 수집을 통해 클러스터가 사라진 후에도 지표를 장기 저장하는 것이 좋습니다.
5. 프로덕션 중단을 모방하기 위해 여러 카오스 테스트를 한 번에 실행: 예를 들어, IO와 네트워크를 따로 실행하는 대신 동시에 폭주시켜 영향을 관찰하세요. 성능, 확장성 또는 QE와 관련된 기존 테스트 케이스가 있을 수 있습니다. 테스트 실행 중에 백그라운드에서 카오스를 실행하여 영향을 관찰하세요. Kraken의 시그널링 기능은 다른 테스트 작업의 상태에 따라 시나리오를 시작, 중지, 일시 중지하는 등 카오스 실행을 조정하는 데 도움이 될 수 있습니다.

---

실전 카오스 테스팅 (Chaos testing in Practice)

OpenShift 조직

OpenShift 조직 내에서는 코드가 고객에게 제공되기 전에 Kraken을 사용하여 릴리스 전반에 걸쳐 카오스 테스트를 수행합니다.

1. 회귀(Regression) 테스트 제품군 동안 Kraken 실행: 다양한 클라우드(주로 AWS, Azure, GCP)에서 각 카오스 시나리오를 커버합니다.
2. 장기 실행 신뢰성(Reliability) 테스트 동안 카오스 시나리오 실행: 이 테스트 동안 사용자는 클러스터에서 다양한 유형의 작업을 수행합니다. 장기 실행 테스트 전반에 걸쳐 특정 시간에 Kraken을 실행하여 클러스터 상태를 모니터링하도록 추가했습니다.
3. 업그레이드 중 카오스 테스트 수행: 업그레이드 중에 카오스 테스트를 수행하는 테스트 케이스를 추가하기 시작했습니다.

[출처] Chaos Testing Guide | krkn