View a markdown version of this page

카오스 엔지니어링 시작하기 - AWS 권장 가이드
카오스 실험에 대한 관찰성카오스 실험에 주입하는 실패 시나리오조직 복원력 후원문제 해결 우선 순위 지정

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

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

실험을 수행하기 전에 카오스 엔지니어링 사례를 최대한 활용하기 위한 몇 가지 필수 사항을 마련하는 것이 좋습니다. 이러한 필수 사항은 다음과 같습니다.

  • 관찰성(지표, 로깅, 요청 추적)

  • 탐색하려는 실제 이벤트 또는 결함 목록

  • 리더십 동의를 통한 조직 복원력 후원

  • 카오스 실험을 실행할 때 발견된 새로운 기능보다 잠재적인 비즈니스 영향을 기반으로 중요한 조사 결과의 우선 순위 지정

카오스 실험에 대한 관찰성

지표, 로깅 및 요청 추적으로 구성된 관찰성은 카오스 엔지니어링에서 중요한 역할을 합니다. 실험을 실행할 때 비즈니스 지표, 서버 측 지표, 클라이언트 경험 지표 및 운영 지표를 이해하는 것이 좋습니다. 관찰성이 없으면 애플리케이션에 대한 가설이 true로 유지되는지 확인하기 위해 안정 상태 동작을 정의하거나 의미 있는 실험을 만들 수 없습니다.

Metrics

다음 다이어그램은 다양한 유형의 애플리케이션에 대한 카오스 실험을 위해 추적할 수 있는 지표 유형을 보여줍니다.

카오스 실험을 위해 추적할 지표의 유형입니다.

  • 비즈니스 지표 - 정상 상태는 시스템의 정상 작동을 나타내며 비즈니스 지표에 의해 정의됩니다. 초당 트랜잭션(TPS), 초당 클릭 스트림, 초당 주문 또는 유사한 측정으로 표현할 수 있습니다. 애플리케이션이 예상대로 작동하면 안정 상태를 나타냅니다. 따라서 실험을 실행하기 전에 애플리케이션이 정상인지 확인합니다. 장애의 백분율이 허용 한도 내에 있을 수 있으므로 장애가 발생할 때 애플리케이션에 영향을 미치지 않는다는 의미는 아닙니다. 안정 상태는 사용자의 기준입니다. 예를 들어 결제 시스템의 안정 상태는 성공률이 99%이고 왕복 시간이 500ms인 300TPS의 처리로 정의될 수 있습니다. 시각적으로 정상 상태를 EKG(심전도)라고 생각하세요. 시스템의 안정 상태가 갑자기 변동하면 서비스에 문제가 있음을 알 수 있습니다.

  • 서버 측 지표 - 실험 중에 리소스의 성능을 이해하려면 실험 전, 도중, 후에 리소스의 성능에 대한 인사이트가 필요합니다. 리소스가에 미치는 영향을 측정하려면 Amazon CloudWatch를 사용할 AWS수 있습니다. CloudWatch는 애플리케이션을 모니터링하고, 성능 변화에 대응하고, 리소스 사용을 최적화하고, 운영 상태에 대한 인사이트를 제공하는 서비스입니다. 실험 중에는 포화도, 요청 볼륨, 오류율 및 지연 시간과 같은 서버 측 지표를 캡처해야 합니다.

  • 고객 경험 지표 - 에서는 CloudWatch RUM을 사용하여 Locust AWS, Grafana k6, Selenium 또는 Puppeteer와 같은 도구를 통해 사용자 요청을 시뮬레이션하여 실제 사용자 지표를 캡처할 수 있습니다. 실제 사용자 지표는 카오스 엔지니어링 실험을 수행하는 조직에 매우 중요합니다. 실제 사용자가 실험 중에 어떤 영향을 받는지 모니터링하면 팀은 결함과 중단이 프로덕션 고객에게 어떤 영향을 미치는지 정확하게 파악할 수 있습니다. 주요 클라이언트 경험 지표는 첫 번째 바이트까지의 시간(TTFB), 가장 큰 콘텐츠 페인트(LCP), 다음 페인트와의 상호 작용(INP), 총 차단 시간(TBT)입니다.

  • 작업 지표 - 중재는 복제 컨트롤러 또는 자동 조정과 같은 메커니즘을 사용하여 포드, 작업 또는 EC2 인스턴스를 재부팅하는 동안 성공적인 클라이언트 요청 지연 시간과 같은 자동화된 방식으로 장애를 얼마나 성공적으로 완화하는지 측정합니다. 장애 발생 시 자동으로 개입할 수 있다는 것은 좋은 사용자 경험과 직접적인 상관관계가 있습니다. 시간이 지남에 따라 이러한 완화 메커니즘에 드리프트가 있는지 이해하는 것이 중요합니다. 성공 및 실패한 자동 완화 모두에 대한 지표를 정의하면 시스템 전체에서 잠재적 회귀를 식별하는 데 도움이 되는 가이드포스트를 생성할 수 있습니다.

로깅

카오스 실험 전, 도중, 후에 애플리케이션의 구성 요소 상태를 이해하려면 중앙 집중식 로깅이 중요합니다. 모든 애플리케이션 구성 요소에서 로그를 수집하여 실험이 주입될 때 각 구성 요소가 수행한 작업에 대한 통합 보기를 구축하는 것이 좋습니다. 이를 통해 end-to-end 실험 흐름을 명확하게 파악할 수 있습니다.

요청 추적

요청 추적을 사용하면 애플리케이션의 구성 요소에서 단일 요청의 흐름을 관찰하여 주입된 장애가 시스템 및 해당 종속성에 미치는 영향을 포괄적으로 이해할 수 있습니다. 요청을 추적하면 장애가 다양한 서비스 및 구성 요소를 통해 전파되는 방식을 확인할 수 있으므로 중단 범위를 더 잘 평가할 수 있습니다. 요청을 추적하려면를 사용할 AWS수 있습니다AWS X-Ray.

카오스 실험에 주입하는 실패 시나리오

애플리케이션에 일반적인 장애를 주입하는 목적은 애플리케이션이 이러한 예상치 못한 이벤트에 어떻게 반응하는지 이해하여 완화 메커니즘을 생성하고 이러한 장애에 대해 시스템을 복원할 수 있도록 하는 것입니다. 또한 카오스 엔지니어링을 사용하여 과거 장애 시나리오를 재생하여 완화 메커니즘이 예상대로 계속 작동하고 시간이 지남에 따라 드리프트되지 않았는지 확인해야 합니다.

카오스 엔지니어링 실험을 계획할 때 다음 이벤트를 고려하세요.

실패 모드 설명

서버 장애

EC2 인스턴스를 재부팅하고 Kubernetes 포드 또는 Amazon Elastic Container Service(Amazon ECS) 작업을 삭제하여 애플리케이션이 이러한 충돌에 어떻게 반응하는지 파악합니다.

API 오류

AWS 및 자체 서비스 APIs에 결함을 주입하여 애플리케이션 동작을 이해합니다.

네트워크 문제

지연 시간 또는 혼잡을 도입하거나 연결을 차단하여 실제 네트워크 문제를 모방합니다.

AWS 가용 영역 장애

전체 가용 영역의 장애를 재생하여 영역 간 복구를 확인합니다.

AWS 리전 연결 장애

에서 네트워크 장애를 재생 AWS 리전 하여 보조 리전의 리소스가 이러한 이벤트에 어떻게 반응하는지 확인합니다.

데이터베이스 실패

데이터베이스 복제본 또는 손상된 데이터를 장애 조치하거나 데이터베이스 인스턴스에 연결할 수 없도록 하여 애플리케이션 및 복구 전략에 미치는 영향을 파악합니다.

데이터베이스 및 Amazon S3 복제에서 일시 중지

가용 영역에서 데이터베이스 또는 Amazon Simple Storage Service(Amazon S3) 복제 AWS 리전 를 일시 중지하거나 다운스트림 애플리케이션 영향을 파악합니다.

스토리지 성능 저하

I/O를 일시 중지하거나 Amazon Elastic Block Store(Amazon EBS) 볼륨을 제거하거나 파일을 삭제하여 데이터 내구성 및 복구를 확인합니다.

종속성 장애

타사 서비스를 포함하여 의존하는 다운스트림 또는 업스트림 서비스의 성능을 저하시키거나 저하시켜 end-to-end 흐름과 고객에게 미치는 영향을 파악합니다.

트래픽 급증

사용자 트래픽의 스파이크를 생성하여 자동 조정 기능을 테스트하고 콜드 부팅 시간이 전체 애플리케이션 상태에 어떤 영향을 미칠 수 있는지 확인합니다.

리소스 소진

CPU, 메모리 및 디스크 공간을 최대화하여 애플리케이션의 정상적인 성능 저하를 확인합니다.

계단식 실패

다운스트림 애플리케이션 및 구성 요소로 캐스케이드되는 기본 장애를 시작합니다.

잘못된 배포

문제가 있는 변경 사항 또는 구성을 롤아웃하여 롤백 메커니즘을 확인합니다.

조직 복원력 후원

카오스 엔지니어링은 조직 전체에 적용할 때 가장 큰 가치를 제공합니다. 조직 전체에서 복원력 목표를 설정하고, 도메인에 대한 두려움, 불확실성 및 의심을 제거하고, 모든 사람의 책임을 복원하는 변환 프로세스를 시작할 수 있는 경영진 후원자와 협력하는 것이 좋습니다.

카오스 엔지니어링 관행을 구축하는 비즈니스 사례를 지원하려면 카오스 엔지니어링 노력을 중요한 비즈니스 프로젝트에 연결합니다. 복원력을 가속화를 위한 자산과 동인으로 만들면 시간 경과에 따른 성공을 추적하는 데 도움이 됩니다. 월별 또는 분기당 중요한 인시던트 수, 평균 복구 시간, 이러한 인시던트가 고객과 조직에 미치는 영향부터 시작합니다. 카오스 엔지니어링 실험에 대응하여 애플리케이션 스택에서 개선이 이루어지므로 6~12개월 동안 인시던트 수를 줄이도록 팀과 목표를 설정합니다.

인시던트가 매우 반복적인지 측정합니다. 예를 들어 클라이언트가 신뢰할 수 있는 연결을 설정할 수 없기 때문에 만료된 TLS 인증서가 가동 중지를 초래한다고 가정해 보겠습니다. 여러 TLS 인증서 만료로 인해 1년에 여러 인시던트가 발생하는 경우 TLS 인증서 만료 실험을 실행하여 팀이 알림을 받거나 이러한 문제를 자동으로 완화할 수 있는지 확인할 수 있습니다. 이렇게 하면 이러한 결함에 대한 복원력을 높일 수 있습니다.

시간 경과에 따른 카오스 엔지니어링 진행 상황을 추적하려면 다음 지표를 캡처하여 애플리케이션의 수명 주기 전반에 걸쳐 카오스 엔지니어링의 가치를 강조하세요.

  • 인시던트 발생률 감소 - 시간 경과에 따른 프로덕션 인시던트 수를 추적하고이 수를 카오스 엔지니어링 채택과 연관시킵니다. 심각한 인시던트의 발생률은 감소할 것으로 예상됩니다.

  • 평균 해결 시간(MTTR) 개선 - 인시던트를 해결하는 데 걸리는 평균 시간을 계산하고이 데이터를 추적하여 시간이 지남에 따라 카오스 엔지니어링으로 개선되는지 확인합니다.

  • 애플리케이션 가용성 향상 - 카오스 실험을 통해 애플리케이션 복원력이 증가함에 따라 서비스 수준 지표를 사용하여 가용성 개선을 보여줍니다.

  • 시장 출시 시간 단축 - 카오스 엔지니어링은 애플리케이션이 복원력이 있음을 알기 때문에 혁신적인 제품을 더 빠르게 출시할 수 있다는 확신을 줄 수 있습니다. 제품 릴리스 속도 증가를 추적합니다.

  • 운영 비용 절감 - 카오스 관행이 적용됨에 따라 애플리케이션 관리를 위한 알림 노이즈, 운영 부하 및 수동 작업과 같은 지표가 감소하는지 정량화합니다.

  • 신뢰도 향상 - 개발자, 사이트 신뢰성 엔지니어(SREs) 및 기타 기술 인력을 조사하여 카오스 엔지니어링이 애플리케이션 복원력에 대한 신뢰도를 높였는지 확인합니다. 인식이 중요합니다.

  • 고객 경험 개선 ‒ 카오스 엔지니어링을 서비스 중단, 롤백 및 중단 감소와 같은 고객에게 긍정적인 결과에 연결합니다.

문제 해결 우선 순위 지정

카오스 실험을 수행할 때 애플리케이션이 의도한 대로 작동하지 않는 개선 영역을 식별할 수 있습니다. 이러한 항목의 수정은 백로그에서 작동하며 기능 개발과 같은 다른 작업과 함께 우선 순위를 지정해야 합니다. 향후 실패를 방지하려면 이러한 개선 사항에 시간을 할애하는 것이 좋습니다. 이러한 학습 및 문제 해결 작업은 발생할 수 있는 영향 수준에 따라 우선순위를 정하는 것이 좋습니다. 애플리케이션의 복원력 또는 보안에 직접적인 영향을 미치는 결과는 고객에게 영향을 미치지 않도록 새로운 기능보다 우선해야 합니다. 팀이 기능 개발보다 문제 해결 작업의 우선순위를 정하는 데 어려움을 겪는 경우 경영진 후원자에게 문의하여 비즈니스 위험 허용 범위를 기반으로 우선순위를 설정하는 것이 좋습니다.