카오스 엔지니어링

 

https://itwiki.kr/w/%EC%B9%B4%EC%98%A4%EC%8A%A4_%EC%97%94%EC%A7%80%EB%8B%88%EC%96%B4%EB%A7%81

카오스 엔지니어링 - IT위키

http://channy.creation.net/blog/1173

카오스 엔지니어링의 원칙 :: Channy's Blog

https://americanopeople.tistory.com/161

(넷플릭스) 넷플릭스의 카오스 엔지니어링

 

 

카오스 엔지니어링(Chaos Engineering)이란 프로덕션 서비스의 각종 장애 조건을 견딜 수 있는 시스템의 신뢰성을 확보하기 위해 분산 시스템을 실험 하고 배우는 분야입니다.

대규모 분산 소프트웨어 시스템의 발전으로 인해 소프트웨어 공학에 일대 변화가 일어나고 있습니다. IT 업계에서는 개발 유연성과 배포 속도를 높이는 방식을 발빠르게 채택하고 있습니다. 이러한 방식에 대해 떠오르는 당면한 질문은 바로 “우리가 프로덕션 환경의 복잡한 시스템을 우리가 신뢰할 수 있는가?”하는 것입니다.

분산 시스템 내부의 각 개별 서비스가 올바르게 작동하는 경우에도 해당 서비스 간의 상호 작용으로 인해 예측할 수 없는 결과가 발생할 수 있습니다. 즉, 프로덕션 환경에 직접 영향을 미치는 아주 드물지만 파괴적인 실제 장애로 인해 예기치 않은 결과가 발생하면, 분산 시스템이 혼란(Chaos)를 가져옵니다.

시스템 전반의 비정상적인 행동으로 나타나기 전에 이러한 약점을 식별할 수 있어야 있습니다. 이러한 약점은 다음과 같은 형태로 나타날 수 있습니다. 서비스 사용 불가 시, 잘 못 설정된 폴백(fallback), 잘 못 설정된 타임 아웃으로 인한 대량 재시작, 너무 많은 트래픽을 받는 다운스트림 종속성, 단일 장애 지점이 충돌 할 때 연쇄 장애 등입니다. 이 때, 고객에게 영향을 미치기 전에 중요한 문제를 사전에 해결해야 합니다. 즉, 시스템에 내재된 혼란을 관리함으로서 유연상과 속도를 증가시키고, 복잡성이 존재하고 있더라도 프로덕션 배포에 대해 신뢰를 가져야 합니다.

경험 및 시스템 기반 접근 방식은 분산 시스템에서 확장 시 혼란을 해결하고, 현실에서 생기는 이슈를 견딜 수 있는 시스템 능력을 믿을 수 있게 합니다. 이를 위해 분산 시스템을 통제된 환경에서 실험을 하는 동안 나오는 결과를 관찰함으로써 현실에서 실제 행동 방법을 배울 수 있습니다. 우리는 이것을 카오스 엔지니어링이라고 명명하였습니다.

카오스 엔지니어링 시작하기

카오스 엔지니어링은 분산 시스템의 불확실성을 구체적으로 해결하기 위해 시스템의 약점을 밝히기 위한 실험을 손쉽게 해주는 방법론입니다. 이러한 실험은 네 단계로 진행됩니다.

1. 정상 동작을 나타내는 시스템의 측정 가능 통계치로 ‘정상 상태’ 정의하기
2. 정상 상태가 대조군과 실험군 모두에서 계속 될 것이라고 가정하기
3. 서버 장애, 하드 디스크 오작동, 네트워크 끊김 등과 같은 실제 문제에 대한 변수 정의하기
4. 대조군과 실험군 사이의 정상 상태 차이를 조사하여 가설 검증하기

정상 상태를 방해하는 것이 어려울수록 시스템에 대한 확신이 커집니다. 약점을 발견하면, 시스템 전반적인 동작이 일어나기 전에 개선을 진행합니다.

고급 원칙

아래 원칙은 앞서 설명한 실험 과정에 적용할 때, 카오스 엔지니어링의 이상적인 방식을 설명합니다. 원칙들이 추구하는 정도는 분산 시스템에서 우리가 가질 수 있는 자신감과 강하게 연관되어 있습니다.

정상 상태 행동에 관한 가설 구축

시스템의 내부 속성보다는 측정 가능한 결과에 초점을 맞춥니다. 짧은 시간의 결과 측정을 통해 시스템의 정상 상태에 대해 정의합니다. 예를 들어, 전체 시스템 처리량, 오류율, 대기 시간 비율 등은 정상 상태의 동작을 나타내는 측정 기준의 일부 입니다. 실험 중에 체계적인 동작 패턴에 중점을 둠으로써 시스템이 작동하는 방식에 대한 검증보다는 정말 작동하는지 여부를 확인합니다.

현실 세계의 문제 시도하기

카오스 변수는 현실의 문제(Event)를 반영합니다. 잠재적 영향 또는 예상 빈도로 문제의 우선 순위를 지정합니다. 하드웨어 오류에 해당하는 문제를 고려하십시오. 즉, 서버 다운, 잘못된 응답을 하는 소프트웨어 오류, 트래픽 급증이나 스케일 아웃 같은 장애는 아니지만 비정상적인 트래픽을 포함할 수 있습니다. 정상 상태를 방해 할 수 있는 모든 사건은 카오스 실험에서 잠재적 변수입니다.

실제 프로덕션 환경에서 실험하기

각 시스템은 운영 환경 및 트래픽 패턴에 따라 다르게 작동합니다. 시스템 활용 빈도는 언제든지 변경 될 수 있으므로 실제 트래픽을 샘플링하는 것이 요청 경로를 안정적으로 파악하는 유일한 방법입니다. 시스템이 작동되는 방식에 대한 확실성과 현재 배포된 시스템과의 관련성을 확인하기 위해서라도 프로덕션 환경에서 직접 실험하는 것을 강하게 권장합니다.

자동화를 통한 지속적 실험

이러한 실험을 수동으로 진행하는 것은 개발자의 시간을 뺐고 궁극적으로 지속 불가능합니다. 모든 실험은 자동화하고 이를 연속적으로 주기를 가지고 실행합니다. 인프라 오케스트레이션 및 데이터 분석을 수행하기 위해 각 시스템에 자동화 기능을 구현합니다.

폭발 반경 최소화

프로덕션 환경에서 실험을 하는 것은 불필요한 고객 이슈를 유발할 수 있습니다. 단기간의 부정적 영향에 대해 허용할 여유가 있어야 하며, 실험에서 발생할 문제를 최소화하고 억제하는 것은 카오스 엔지니어의 궁극적인 책임과 의무입니다. (역자 주: 실제 환경에서 지속적인 실험을 하여 사용자가 오류를 겪지 않아야 비정상적인 상황이 오더라도 고객에게 영향을 주지 않음)

카오스 엔지니어링은 이미 주요 IT 기업 (넷플릭스 등) 중 일부에서 소프트웨어가 설계 방식을 바꾸고 있는 강력한 방법입니다. 속도와 유연성을 다루면서도, 분산 시스템의 불확실성을 특별하게 조사하고 해결합니다. 다룹니다. 카오스 엔지니어링 원칙은 대량 트래픽을 처리하는 서비스 규모에서 신속하게 서비스를 개선하고, (비정상적 상황에서도) 고객에게 고품질의 서비스 경험을 제공할 자신감을 가질 수 있게 합니다.

이 원칙에 대한 토론은 Chaos Community에서 진행하고 있습니다. 카오스 엔지니어링에 대한 해외 정보는 Awesome Chaos Engineering 에서 계속 업데이트 중입니다.

•