View a markdown version of this page

실험 계획 문서 - AWS 권장 가이드
정상 상태관찰성 요구 사항실험 정의가설실험 프로세스실험 타임라인실험 결과확인된 결함

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

실험 계획 문서

정상 상태

프로세스 이름 반려동물 입양 사이트

물리적 아키텍처

(아키텍처 다이어그램 링크)

논리적 아키텍처

(논리적 다이어그램 링크)

안정 상태 정의

반려 동물 입양 사이트에 대해 가장 큰 콘텐츠 페인트(LCP)를 사용하여 측정한 평균 페이지 로드 시간은 2.5초 이하이고, 99 백분위수 지연 시간(P99)은 4.0초 이하이며, 기준은 동시 사용자 5,000명입니다.

정상 상태 지표

사용자 기반에서 캡처된 LCP 지표 및 골든 지표(지연 시간, 처리량, 오류율, 포화도).

정상 상태 관찰성

LCP는 사용자의 브라우저에서 캡처되어 Amazon CloudWatch로 전송되고 CloudWatch RUM으로 검사됩니다. 60초 동안 평균 및 P99 LCP 시간은 해당 기간의 모든 요청에 대해 집계됩니다. 최상위 골든 지표는 CloudWatch를 사용하여 캡처됩니다.

안정 상태를 달성하기 위한 프로세스

Grafana K6는 약 5K00명의 동시 사용자의 정상적인 프로덕션 트래픽 수준을 시뮬레이션하는 로드를 생성하는 데 사용됩니다.

관찰성 요구 사항

팀은 다음을 볼 수 있어야 합니다.

  • 정상 상태: 애플리케이션이 정상 상태인지 확인하기 위해 무엇을 관찰하나요?

  • 실패 조건: 실패 조건은 대시보드에 어떻게 표시되나요? 예:

    • 트리거해야 하는 경보

    • 생성해야 하는 로그

  • 장애 영향: 영향을 받을 것으로 예상되는 구성 요소를 보려면 무엇을 관찰해야 합니까(영향 범위)?

  • 복구: MTTR을 캡처하기 위해 복구를 어떻게 보고 측정하나요?

  • 디버그: 실험 실패에 대한 세부 정보 문제 해결.

다음 표에는 관찰성 요구 사항 차트에 대한 제안과 예제가 나와 있습니다. 특정 실험을 기반으로 관찰해야 할 사항을 정의해야 합니다.

관찰해야 할 사항 관찰성 도구 링크 관찰 대상

입력 소스

Grafana K6 대시보드

  • 실행 중인 컨테이너 수

  • 초당 요청

전체 애플리케이션 상태

  • 반려동물 입양 CloudWatch 대시보드

  • 반려동물 입양 사용자 경험 대시보드(RUM)

  • Amazon EKS 정상 노드 수

  • Amazon EKS 노드 CPU 사용률

워크플로 상태

반려동물 입양 CloudWatch 대시보드

LCP 시간, 골든 지표

트레이스

반려동물 입양 X-Ray 대시보드

  • 요청 지연 시간

  • 요청 수

  • 실패 수

로그

반려동물 입양 CloudWatch Logs

포드에서 발생하는 모든 오류는 CloudWatch Logs에 발행됩니다.

실험 정의

실험 이름 Amazon EKS PetSite 포드 CPU 스트레스

실험 소스 코드

(실험 소스 리포지토리 링크)

실험 설명

이 실험에서는 PetSite 애플리케이션 포드의 CPU 사용량 증가가 전반적인 고객 경험에 미치는 영향을 살펴봅니다. 실행 중인 각 PetSite 포드에 CPU 스트레스를 주입하면 고객에게 영향이 있는지 여부와 해당 영향의 범위를 이해할 수 있습니다.

실험 요구 사항 또는 파라미터

애플리케이션 로드: 프로덕션 평균

포드 레이블 선택기: app=petsite

실험 기간

10분

Environment

알파 테스트 환경

실험 대상 리소스

PetSite 애플리케이션 포드

로드 생성 도구를 통해 도입되는 실험 기준

  • 요청의 54%는 LCP가 <2.5초입니다.

  • 요청의 46%는 LCP가 <4초입니다.

  • 오류는 관찰되지 않습니다.

백오프 조건

없음

가설

다음과 같은 경우 영향 복구

PetSite 애플리케이션 포드가 정상적인 프로덕션 수준 트래픽에서 10분 동안 60% 이상의 CPU 사용률을 경험하거나 유발한 경우 안정적인 상태는 어떻게 되나요?

 

P99가 4.0초 이하인 사용자의 P50에서는 LCP 시간이 2.5초 미만으로 유지됩니다. 소비자가 PetSite 랜딩 페이지를 로드할 수 있어야 합니다.

감지:

  • CPU 스트레스는 CloudWatch에 구성된 경보에 의해 감지됩니다.

  • LCP 지표는 사용자 경험 저하에 대한 경보도 생성합니다.

자가 복구:

  • 마이크로서비스 아키텍처의 분산 특성으로 인해 많은 포드 인스턴스가 여러 가용 영역에서 실행되고 있습니다. 

  • EKS 클러스터 컨트롤 플레인은 영향을 받는 포드에서 트래픽을 이동하고 작업자 노드에서 새 포드를 시작합니다.

복구:  

CPU 사용률이 정상으로 돌아오면 LCP가 자동으로 복구됩니다.

실험 프로세스

다음 예제 step-by-step 프로세스를 특정 실험에 맞게 조정합니다.

  1. 모든 Amazon CloudWatch, CloudWatch RUM 및 AWS X-Ray 대시보드에 대한 액세스 및 기능을 검증합니다.

  2. 애플리케이션 환경의 상태를 검증합니다.

    1. CloudWatch 대시보드를 사용하여 EKS 클러스터가 정상인지 확인합니다.

    2. 예제 URL에서 테스트 반려동물 채택 사이트 애플리케이션 배포를 방문하세요.

  3. 부하를 시작하여 안정 상태를 달성합니다.

    1. 로드 생성기가 실행 중이고 초당 5,000개의 요청을 전송하는지 확인합니다.

    2. 애플리케이션이 안정 상태에 도달할 때까지 5분 정도 기다립니다.

    3. CloudWatch RUM 대시보드를 사용하여 애플리케이션의 안정 상태를 확인합니다.

  4. 결함 시작(실험):

    1. AWS FIS 콘솔을 엽니다.

    2. pet-adoption-pod-stress 실험을 실행합니다.

    3. 콘솔에서 실험이 실행 중인지 확인합니다.

  5. 장애가 애플리케이션에 미치는 영향을 관찰합니다.

    1. CloudWatch RUM 및 CloudWatch 대시보드에서 스크린샷을 캡처하고 변칙적인 데이터 포인트를 기록해 둡니다.

    2. 실험이 완료된 후 추가 스크린샷을 AWS FIS캡처하여 애플리케이션이 스트레스 없이 안정 상태로 돌아가는지 여부를 기록하고 데이터 포인트에 이상을 기록해 둡니다.

    3. 안정 상태가 재개되지 않으면 애플리케이션을 복구하는 단계를 수행하고 수행한 단계를 기록합니다.

  6. 환경이 정상으로 돌아왔는지 확인합니다.

    • 모든 비즈니스, 사용자 경험, 애플리케이션 및 인프라 지표를 검토하여 시스템이 알려진 상태로 돌아왔는지 확인합니다. 도움이 되는 경우 대시보드 스크린샷을 캡처합니다.

실험 타임라인

로드 생성, 결함 주입, 영향 관찰 및 애플리케이션 복구부터 시작하여 로드 생성을 중지할 때 종료되는 end-to-end 실험의 타임라인을 캡처해야 합니다. 이는 다음 예제에 나와 있습니다.

카오스 실험의 타임라인 예제입니다.

실험 결과

실험 실행 ID 실험 결과

PET-ADOPT-EXP-23

(실험 결과에 대한 링크)

확인된 결함

  • Kubernetes 클러스터가 PetSite 포드의 CPU 장애를 감지하지 못했으므로 추가 배포를 예약하지 않았습니다.

  • 이 실험의 결과로 4XX 또는 5XX 오류 발생률이 증가하지 않았습니다.

  • 리소스 제약이 있을 때 LCP에 미치는 영향을 설명하기 위해 포드의 상태 확인을 조정해야 합니다.