퀴즈: 「정상」을 숫자로 적지 않으면 그냥 사고다

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

1. 카오스 엔지니어링 원칙이 정상 상태를 정의할 때 권하는 지표는 무엇인가?

   1. 컨테이너 런타임이 보고하는 재시작 횟수
   2. 노드의 CPU 사용률과 메모리 사용률
   3. 시스템 바깥에서 보이는 출력, 예컨대 요청 성공률과 응답 시간
   4. 애플리케이션 프로세스의 힙 크기와 스레드 수

2. 요청 100건 중 5건이 2초, 95건이 20밀리초였다. 지연을 평균이 아니라 분위수로 적는 이유를 가장 잘 설명한 것은?

   1. 평균 120밀리초는 멀쩡해 보이지만 p95 는 2초라 느린 꼬리가 그대로 드러난다
   2. 평균은 표본이 100건 미만일 때 계산할 수 없기 때문이다
   3. 분위수는 평균보다 계산이 빨라 부하 생성기의 부담이 적다
   4. 쿠버네티스가 평균 지연을 지표로 내보내지 않기 때문이다

3. 실험 계획서에 '성공률이 0.5 밑으로 내려가면 즉시 되돌린다' 를 미리 적어 두는 이유는?

   1. 채점 도구가 그 문장을 읽어 자동으로 복구를 실행하기 때문이다
   2. 실험 도중에는 판단이 흐려지므로 차분할 때 정한 멈출 기준이 필요하다
   3. 쿠버네티스가 그 값을 읽어 롤아웃을 자동으로 중단하기 때문이다
   4. 성공률이 0.5 밑으로 내려가는 실험은 설계상 금지되어 있기 때문이다

4. 폭발 반경(blast radius)을 작게 잡는다는 것은 무엇을 뜻하는가?

   1. 실험을 짧은 시간 안에 끝내 측정 창을 줄인다는 뜻이다
   2. 고장을 주입하는 대신 시뮬레이션으로 대체한다는 뜻이다
   3. 가설을 여러 개 세우지 않고 하나만 검증한다는 뜻이다
   4. 가설을 확인할 만큼만 영향 범위를 열고 그 이상은 열지 않는다는 뜻이다

5. 쿠버네티스에서 Pod 가 Running 이고 Ready 인데도 사용자의 요청이 실패할 수 있는 이유로 알맞은 것은?

   1. Running 상태의 Pod 는 준비 여부와 무관하게 트래픽을 받지 않기 때문이다
   2. Ready 컨디션은 kubelet 이 아니라 스케줄러가 정하기 때문이다
   3. Ready 라는 사실과 Service 의 엔드포인트에 실려 트래픽을 받는다는 사실이 서로 다른 층이기 때문이다
   4. readinessProbe 는 컨테이너가 아니라 노드의 상태만 확인하기 때문이다

6. 정상 상태를 가용성과 지연 두 축으로 함께 적는 이유는?

   1. 두 축은 서로 독립이라 한 축만 보면 실험 결과의 절반을 놓치기 때문이다
   2. 가용성만으로는 표본 수가 모자라 통계적으로 유의하지 않기 때문이다
   3. 지연이 가용성의 계산에 입력값으로 들어가기 때문이다
   4. 쿠버네티스의 프로브가 두 값을 한 번에 보고하기 때문이다