EKS Spot 운영 적용 실험 퀴즈

관련 문서: EKS Spot 운영 적용 실험과 결과 판정

1. PDB를 설정한 Spot 노드에서 drain 시험을 통과했습니다. 올바른 해석은?

• A) 실제 Spot 회수에서도 항상 같은 가용성을 보장한다
• B) 자발적 eviction 경로를 검증했으며 실제 회수 시험은 별도로 필요하다
• C) EC2는 PDB가 허용할 때까지 인스턴스 종료를 기다린다
• D) 애플리케이션은 반드시 2분의 종료 시간을 받는다

정답 보기

정답: B) 자발적 eviction 경로를 검증했으며 실제 회수 시험은 별도로 필요하다

설명: PDB는 EC2의 인스턴스 상실을 막지 못합니다. 실제 중단 통지 전달, eviction 지연, 강제 종료와 서비스 영향은 FIS 회수 및 통지 없는 상실 시험에서 확인합니다.

2. Spot-only selector를 가진 Pod가 Pending입니다. On-Demand 노드를 추가하면?

• A) selector와 관계없이 즉시 이동한다
• B) PDB가 selector를 On-Demand로 바꾼다
• C) selector를 만족하지 못하므로 스케줄되지 않는다
• D) NodePool weight가 selector보다 우선한다

정답 보기

정답: C) selector를 만족하지 못하므로 스케줄되지 않는다

설명: 폴백에는 공급 용량과 Pod의 배치 호환성이 모두 필요합니다. NodePool의 capacity type만 넓혀도 Spot-only Pod 제약은 그대로 남습니다.

3. NodePool을 On-Demand 전용으로 바꿔 서비스가 정상 기동했습니다. 검증된 내용은?

• A) EC2의 Spot 용량 부족 응답에 대한 자동 폴백
• B) 구성 변경을 통한 On-Demand 전환·스케줄링·기동 경로
• C) 모든 AZ에서 Spot 공급 보장
• D) 기존 Spot Pod의 즉시 자동 이동

정답 보기

정답: B) 구성 변경을 통한 On-Demand 전환·스케줄링·기동 경로

설명: 전환 훈련은 공급 부족 응답을 주입하지 않았습니다. 실제 provisioning 경로의 오류 처리·폴백은 별도로 검증하고, 재현하지 못했다면 미검증으로 남깁니다.

4. FIS 실험이 completed이고 대체 노드가 Ready입니다. 서비스 실험의 합격 조건은?

• A) FIS 상태만으로 통과
• B) Node Ready만으로 통과
• C) client 오류·지연·처리량·정합성 증거까지 기준을 충족
• D) LB 5xx가 없으면 timeout은 무시

정답 보기

정답: C) client 오류·지연·처리량·정합성 증거까지 기준을 충족

설명: FIS 완료는 주입의 완료입니다. Pod Ready, LB target healthy, 실제 요청 성공과 작업 정합성을 확인해야 서비스 복구를 판정할 수 있습니다.

5. Spot 비용 절감의 올바른 비교 방식은?

• A) Spot 할인율을 그대로 서비스 절감률로 기록
• B) 같은 조건에서 정합성을 통과한 고유 성공 작업당 실효 비용 비교
• C) 재시도 비용과 On-Demand 대체 비용을 제외
• D) 중복 노드 비용을 EC2 청구서와 추가 비용에 두 번 합산

정답 보기

정답: B) 같은 조건에서 정합성을 통과한 고유 성공 작업당 실효 비용 비교

설명: 부대 비용과 약정 할인, 교체·재시도 영향을 반영하되 실제 사용 비용에 이미 포함된 금액은 중복 합산하지 않습니다. 단기 월 환산은 추정으로 표시합니다.

6. 실험 데이터가 없는 상태의 올바른 결과 기록은?

• A) 기대한 복구 시간을 실측 결과에 입력
• B) 오류율을 0으로 넣고 통과
• C) 미실행·측정값 없음으로 기록하고 운영 확대 보류
• D) 공식 문서가 있으므로 실험 완료로 처리

정답 보기

정답: C) 미실행·측정값 없음으로 기록하고 운영 확대 보류

설명: 문서 확인, 가설, 실측은 다른 증거입니다. 필수 실험의 실행 ID와 원시 결과가 없으면 운영 적용을 입증하지 못합니다.

7. E2 실측에서 혼합 경로의 전체 오류율은 0.0556%, 최악 60초 오류율은 0.8333%였습니다. 60초 오류율 기준이 0.1%라면?

• A) 전체 오류율이 낮으므로 통과한다
• B) p99가 낮으므로 요청 실패를 무시한다
• C) 해당 60초 기준을 충족하지 못했고, 현재 구성 보완 후 재실험해야 한다
• D) Spot은 모든 운영 서비스에서 사용할 수 없다

정답 보기

정답: C) 해당 60초 기준을 충족하지 못했고, 현재 구성 보완 후 재실험해야 한다

설명: 긴 정상 구간은 전체 오류율을 낮출 수 있습니다. 판정 창과 실제 업무 SLO를 맞추고, 이번 단일 합성 실험을 다른 구성의 보편적 결과로 확대 해석하지 않습니다.

8. 생성 때부터 Guaranteed인 Pod에서 대상 regular container의 CPU request와 limit를 함께 200m에서 50m으로 줄입니다. 메모리 request=limit는 64Mi로 유지하고 다른 container의 Guaranteed 조건도 유지했다면?

• A) CPU를 줄였으므로 반드시 Burstable로 바뀐다
• B) 생성 시 Guaranteed를 유지하며 축소 후에도 CPU·메모리 request=limit 조건을 충족한다
• C) Burstable로 생성한 Pod도 같은 resize로 Guaranteed로 바꿀 수 있다
• D) CPU만 같으면 메모리 request와 limit가 달라도 Guaranteed를 유지할 수 있다

정답 보기

정답: B) 생성 시 Guaranteed를 유지하며 축소 후에도 CPU·메모리 request=limit 조건을 충족한다

설명: QoS class는 생성 시 결정되며 resize로 변경할 수 없습니다. 이 container-level 설계는 모든 해당 container의 CPU·메모리 request와 limit를 같은 양수로 유지하고 대상 CPU의 request와 limit를 함께 줄입니다. Guaranteed 유지가 축소 후 앱 SLO 충족이나 Spot 회수 방지를 보장하지는 않습니다.

9. E10에서 초기화 완료, CPU 축소 적용, 축소 후 서비스 품질을 판정할 때 필요한 증거는?

• A) Pod가 Running이면 세 조건 모두 충족한다
• B) pods/resize PATCH가 성공하면 초기화와 축소가 완료되고 SLO도 충족한다
• C) 실제 startupProbe와 started=true, 원하는 값과 실제 보고 리소스·generation·resize 상태, 축소 후 앱 SLO를 함께 확인한다
• D) containerID와 Guaranteed가 유지되면 요청 오류와 지연은 확인하지 않아도 된다

정답 보기

정답: C) 실제 startupProbe와 started=true, 원하는 값과 실제 보고 리소스·generation·resize 상태, 축소 후 앱 SLO를 함께 확인한다

설명: Running이나 started 값만으로 초기화 완료를 입증하지 못하며, 대상마다 실제 초기화를 확인하는 startupProbe가 필요합니다. PATCH 성공은 요청 접수이므로 kubelet 보고 리소스와 관측 generation, PodResizePending·PodResizeInProgress를 확인합니다. 적용 후에도 readiness/LB 상태, 오류율·p99·처리량·throttling 등 앱 SLO 증거로 품질을 별도 판정합니다.

10. 2026-09-12 Spot 실측과 공개 초기 템플릿으로 단계별 CPU resize에 대해 내릴 수 있는 결론은?

• A) 당시 E2의 전체 p99가 낮으므로 시작 CPU 확대 효과가 입증됐다
• B) 초기 템플릿에 단계별 구성이 없고 실측에도 필요한 증거가 없어 E10은 미실행으로 남긴다
• C) 초기 템플릿만으로 admission 이후 실제 Pod의 리소스와 QoS까지 관측했다고 볼 수 있다
• D) 로드맵의 과거 보고와 로컬 prototype 검사가 있으므로 Spot 결합 시험도 완료됐다

정답 보기

정답: B) 초기 템플릿에 단계별 구성이 없고 실측에도 필요한 증거가 없어 E10은 미실행으로 남긴다

설명: 초기 세 Deployment의 requests는 50m/64Mi, limits는 500m/256Mi이며 설정 자체가 Guaranteed 조건을 충족하지 못합니다. 단계별 resize opt-in·resizePolicy·startupProbe가 없고 실제 resize 전후 리소스·QoS·warmup 비교 증거도 없습니다. 초기 템플릿을 admission 이후 Pod 관측으로 해석하지 않으며, 과거 로드맵 보고·로컬 prototype 검사·Spot 실측을 구분해 E10을 별도로 실행해야 합니다.