728x90
반응형
•카오스 엔지니어링은 특정 시스템에 대한 가설(hypothesis)을 만들고 부하(stress)를 주입한 후 결과를 관찰하는 엔지니어링의 한 분야입니다.
•이후 관찰된 결과를 바탕으로 시스템의 성능을 향상시킵니다. 그렇기 때문에 이 과정은 아래 그림처럼 끊임 없이 순환됩니다.
•계속해서 새로운 가설을 만들고 이를 통해 시스템을 발전시킵니다. 카오스 엔지니어링은 우리 시스템이 복원력(resilience) 있고 성능이 좋은 시스템을 구축할 수 있게 해줍니다.
728x90
1. Tool
1. 카오스 몽키 (for AWS)
-임의의 인스턴스나 Spring Boot에 장애를 일어킴
-카오스 몽키 종류
-Latency monkey: RESTful 클라이언트-서버 통신 계층에 인공적인 지연 유발
-Conformity monkey: 최상의 조건이 아닌 인스턴스를 찾아 종료 (예:자동 스케이링 그룹에 속하지 않은 인스턴스를 찾아 재시작)
-Doctor monkey: 인스턴스들의 상태를 점검하고 CPU 부하율 등의 정보들을 모니터링하여 불안정한 인스턴스를 탐지하여 제거
-Janitoy monkey: 클라우드 환경이 잡음으나 낭비 없이 작동하도록 보장, 사용되지 않는 리소스들을 찾아 제거
-Security monkey: Conformity monkey의 확장으로 보안에 위배되거나 최약점을 찾고 공격하는 인스턴스 종료
-10-18 monkey: 다양한 언어와 문자를 사용하여 여러 지역에서 고객에서 서비스를 제공할 경우 설정 및 런타임 문제 감지
-monkey: AWS의 가용성 영역을 전체적으로 중단
2. LitmusChaos 또는 Chaos Mesh (for Kubernetes)
-리트머스는 크게 위와 같이 구성됨
-Chaos Control Plane: 카오스 센터이며 중앙 집중식 카오스 관리 도구 (Workflow정의, 예약 및 시각화)
-Chaos Excution Plane: 카오스 에이전트와 정의된 대상 Kubernetes 환경내에서 실험을 실행 및 모니터링하는 오퍼레이터로 구성됨
3. Use Case
-Chaos Tests는 데브옵스 주기의 어느 단계에서나 수행 가능, CI 파이프라인부터 프로덕션까지 다양합니다.
-개발 파이프라인에서는 개발 중인 애플리케이션에 특정한 카오스 Tests를 사용할 수 있습니다.
-운영 또는 프로덕션으로 이동함에 따라 복원력을 확보해야 하는 많은 실패 시나리오가 예상되므로 카오스 테스트의 수가 크게 증가합니다.
-일반적인 사용 사례로는 CI 파이프라인에서의 장애 또는 스테이징 및 프로덕션과 운영 환경, Kubernetes 업그레이드 인증, 업그레이드 후 서비스 검증 등이 있습니다.
-개발자용: 단위 테스트 또는 통합 테스트의 확장으로 애플리케이션 개발 중에 카오스 수행
-SRE용: 애플리케이션 및/또는 주변 인프라에 대한 카오스 실험을 계획하고 예약합니다. 이로써 시스템의 약점을 식별하고 복원력을 높입니다.
4. 이점
-일반적으로 개발자와 경영진 모두 카오스 도입에 대해 많은 거부감을 느낀다고 합니다.
-카오스 엔지니어링을 실행할 때는 소규모 Chaos Test로 시작하여 개발자와 경영진에게 이점을 보여주면 초기에 신뢰를 얻을 수 있습니다.
-시간이 지남에 따라 테스트 횟수와 관련 복원력도 증가할 것입니다.
-카오스 엔지니어링은 관행입니다.
-위에서 살펴본 바와 같이, 시간이 지남에 따라 SRE의 신뢰도와, IT 투자 기회도 높아지며 이 프로세스를 통해 복원력 지표도 향상됩니다.
728x90
300x250
'IT > Kubernetes' 카테고리의 다른 글
| kubeconfig를 통해 다른서버 접근 (2) | 2023.11.09 |
|---|---|
| Kubesprary를 통한 Upgrade와 Node 추가 (0) | 2023.11.09 |
| Cluster Autoscaler의 개념과 구성 방법 및 검증 방법 (0) | 2023.07.26 |
| AWS LoadBalancer Controller 개념과 설치 구성 방법 (0) | 2023.07.26 |
| 7가지 간단한 Kubernetes 성능 최적화 팁 (0) | 2023.07.11 |