プロビジョニングAPIの誤解を招く指標を修正する

목표

SLI의 분모를 선언하고, 실패가 빠지는 계측 코드를 고치고, 실제 HTTP 응답과 지표를 대조합니다. 중복 수집과 재시도를 구별한 뒤 독립적인 세 관측 창의 오류 예산으로 일반 기능 배포를 판단합니다.

왜 중요한가

성공 경로만 세는 계측은 실패가 늘수록 더 좋은 성공률을 보여 줄 수 있습니다. 올바른 PromQL도 잘못 모은 원자료를 고쳐 주지 못합니다. 이 실습은 알림 규칙을 쓰기 전, 무엇을 한 건으로 세는지와 빠진 증거가 없는지를 검사합니다. 함수 이름을 맞추는 것만으로 통과하지 않고 다양한 입력·실제 HTTP 실행·직접 설계한 반례를 확인합니다.

이 실습은 파드 안의 Python 서버를 실제로 실행합니다. 쿠버네티스 API나 KWOK의 Running 상태를 실행 증거로 쓰지 않습니다. 외부 시스템, 실제 GPU, 운영 Prometheus 수집, 실제 배포는 다루지 않습니다. 지연은 서버 처리 시간이며 클라이언트의 네트워크 왕복 시간과 다릅니다. 30일 창의 숫자는 학습용 가상 데이터입니다.

작업 경로는 /root/cnpe-sli입니다. Python은 표준 라이브러리만 사용합니다. 세션이 끝나면 파일과 진단 기록은 사라지므로 필요한 산출물을 따로 보관하세요. 도우미는 /opt/fixtures/cnpe_sli_workbench.py이며, 매 채점은 파일을 읽고 임시 프로세스를 종료합니다.

단계

1. scope.json에 단위·분모·목표를 선언합니다.
2. classifier.py의 classify로 상태 코드와 경로를 분류합니다.
3. 같은 함수에 느린 성공 응답의 분류를 완성합니다.
4. 실제 HTTP를 재연하고 http-receipt.json을 저장합니다.
5. summarize.py로 수집 중복을 제거하되 실제 재시도는 따로 셉니다.
6. budget.py로 관측 공백·분수 예산·고갈 경계를 처리합니다.
7. report.py와 report.json으로 세 창의 가용성·지연 판단을 합칩니다.
8. counterexamples.json으로 다섯 가지 잘못된 구현을 구별합니다.

참고

• 단계 카드에 정확한 함수 서명과 JSON 필드 계약이 있습니다. 파일 예시는 형식만 보여 주며 정답은 아닙니다.
• 각 단계는 python3 /opt/fixtures/cnpe_sli_workbench.py grade /root/cnpe-sli 단계번호로 직접 검사할 수 있습니다.
• exercise /root/cnpe-sli는 임시 포트를 사용해 정상·1.1초 지연·503·504·400·404를 실제로 발생시킵니다. X-Lab-Scenario는 학습용 장애 선택 헤더이며 운영 기능이 아닙니다.
• 이 과제에서만 2xx·5xx를 유효 시도로 정합니다. 운영에서 429나 4xx를 무조건 제외하면 서비스 책임의 실패를 숨길 수 있습니다. 실제 유효 요청의 계약을 합의해야 합니다.
• SLI 설계·계측 원칙·오류 예산 정책 예시를 함께 읽으세요.

분모부터 계약으로 남기기

/root/cnpe-sli/scope.json을 만듭니다. route는 /provision, unit은 attempt, eligible_classes는 [2,5], latency_limit_ms는 1000, availability_target은 0.999, latency_target은 0.99, no_data는 investigate입니다. 이 두 목표는 실습의 가상 정책입니다.

사용자 작업 한 건과 HTTP 시도 한 건은 다릅니다. 이 과제는 시도 단위입니다. 관측하지 못한 창은 성공률 1로 채우지 않습니다.

성공 경로만 세는 버그 없애기

classifier.py에 classify(path, status, latency_ms)를 구현합니다. 반환은 eligible·available·fast 불리언 세 필드입니다. 쿼리 문자열을 제거한 경로가 /provision이고 상태 코드가 2xx 또는 5xx일 때만 eligible=True입니다. available은 그중 2xx입니다. fast는 이번 단계에서 False로 두어도 됩니다. /healthz·다른 경로·4xx는 제외합니다.

503·504는 성공은 아니지만 분모에는 들어갑니다. URL 쿼리의 사용자 값은 경로 분류나 지표 라벨에 포함하지 마세요.

느린 201을 좋은 응답으로 세지 않기

classifier.py의 fast를 완성합니다. available=True이면서 latency_ms <= 1000인 경우만 True입니다. 1000은 포함하고 1000.1은 제외합니다. 입력 지연은 유한한 0 이상의 밀리초입니다. eligible·available 계약은 유지하며 문자열이나 0·1 대신 실제 bool을 반환하세요.

빠른 503도 좋은 지연 응답이 아닙니다. 이 SLI는 모든 유효 시도 중 빠르고 성공한 응답의 비율이며, 성공한 요청만 분모로 잡지 않습니다.

응답 일곱 건과 지표 네 종류 대조하기

도우미의 exercise /root/cnpe-sli 출력을 http-receipt.json에 저장하세요. 실제 상태 코드는 순서대로 200,201,201,503,504,400,404이고, 느린 201의 서버 처리 시간은 1000ms 이상입니다. observed=7, eligible=4, available=2, fast=1이어야 합니다. 현재 classifier로 다시 실행한 결과도 같아야 합니다.

classify 단위 시험이 맞아도 HTTP 경로에서 빠질 수 있습니다. 저장된 숫자만 보지 않고 실패 응답이 분모에 포함되는지 현재 코드로 재연합니다.

중복 수집과 재시도를 분리하기

summarize.py에 summarize(events)를 구현하세요. 각 사건은 attempt_id·path·status·latency_ms 필드를 가집니다. 같은 attempt_id와 같은 내용의 중복은 한 번만 분류하고 duplicates를 늘립니다. 같은 ID에 내용이 다르면 ValueError입니다. 다른 ID의 재시도는 각각 셉니다. 반환 필드는 eligible·available·fast·excluded·duplicates 정수 다섯 개입니다. classifier.classify를 재사용하세요.

실패 시도 a와 성공 재시도 b를 최종 성공 하나로 덮으면 시도 기반 SLI가 바뀝니다. 반대로 수집기가 동일 사건을 두 번 보낸 것은 분모에 두 번 넣지 않습니다.

0.1건의 예산과 관측 공백 다루기

budget.py에 decide(eligible, good, target, covered)를 구현합니다. 0 <= good <= eligible인 int와 0 < target < 1인 수, bool covered만 받으며 잘못되면 ValueError입니다. covered=False 또는 eligible=0이면 sli·allowed_bad·remaining_bad·consumed를 null, decision을 investigate로 반환합니다. 나머지는 sli=good/eligible, allowed_bad=eligible*(1-target), remaining_bad=allowed_bad-(eligible-good), consumed=(eligible-good)/allowed_bad입니다. sli·consumed는 소수 6자리로 반올림합니다. 예산은 정수로 반올림하지 않습니다. 잔여 예산 <= 0이면 freeze, 아니면 ship입니다.

100회에 목표 99.9%면 허용 실패량은 0.1입니다. 정수 0으로 만들지 마세요. Decimal(str(target))은 0.999를 이진 부동소수 오차로 바꾸지 않고 예산 경계를 비교하는 한 방법입니다. bool은 Python에서 int의 하위 타입인 점도 주의하세요.

좋은 가용성이 나쁜 지연을 가리지 않게 하기

도우미 windows 출력을 windows.json으로 저장하고 report.py의 build(windows)를 구현하세요. 입력은 name·eligible·available·fast·covered를 가진 독립 창의 목록입니다. 반환은 창 이름을 키로 하고 availability=decide(eligible,available,0.999,covered), latency=decide(eligible,fast,0.99,covered), decision을 가진 객체입니다. 합성 판단은 investigate 우선, 그다음 freeze, 마지막 ship입니다. 중복 창 이름은 ValueError입니다. 이 결과를 report.json에 저장하세요.

steady는 ship, slow는 가용성이 좋아도 지연 때문에 freeze, gap은 숫자가 완벽해 보여도 investigate입니다. 출력 파일뿐 아니라 함수도 새로운 창 입력에 맞게 계산해야 합니다.

내 시험이 틀린 구현을 잡는지 확인하기

counterexamples.json에 5~24개의 {op,args,expected} 사례를 작성하세요. op는 classify·summarize·decide이고 args는 해당 함수의 위치 인수 목록입니다. expected는 정확한 반환 객체, ValueError 기대 시 {"error":"ValueError"}입니다. 세 함수의 사례를 모두 포함하고, 5xx 누락·느린 성공을 fast로 처리·중복 이중 계수·예산 정수 반올림·관측 공백 승인이라는 다섯 오류를 모두 잡아야 합니다.

정상만 보는 시험은 잘못된 구현도 통과시킬 수 있습니다. 함수 하나마다 원래 구현과 잘못된 구현의 출력이 달라지는 입력을 고르세요. 기대값을 틀리게 적어 빨간불을 만드는 것도 검증이 아닙니다.