개념
신뢰성 시험은 "고장 나지 않는가"가 아니라 "고장 났을 때"를 본다
모듈 25 레슨 4에서 기능안전이 "고장 나지 않게"에서 "고장 나도 안전하게"로 관점을 옮긴다는 것을 봤다. 클라우드 인프라의 신뢰성 시험도 같은 관점이다. 노드·디스크·네트워크·GPU는 반드시 고장 난다. 수천 GPU 규모 클러스터에서는 하루에도 여러 번이다. 질문은 고장이 났을 때 무엇이 유지되는가, 무엇이 영향을 받는가, 얼마나 빨리 정상으로 돌아오는가 다.
이 질문을 운영 사고로 처음 답하면 비싸다. 통제된 조건에서 장애를 일부러 일으켜 답을 미리 얻는 것이 장애 주입 시험, 넓게는 카오스 엔지니어링이다.
카오스 엔지니어링 다섯 원칙을 QA 시험으로 옮기기
카오스 엔지니어링 원칙은 다섯 줄이다. 각각을 QA가 시험 설계에서 어떻게 쓰는지로 바꿔 보자.
| 원칙 | QA 시험 설계로 옮기면 |
|---|---|
| 정상 상태 행동에 대한 가설을 세운다 | 내부 속성(CPU 사용률)이 아니라 측정 가능한 출력(요청 성공률·TTFT·학습 스텝 진행)으로 "정상"을 정의하고 판정 기준으로 쓴다 |
| 현실의 사건을 변수로 쓴다 | 상상한 장애가 아니라 운영 인시던트 기록 에서 장애 유형을 뽑는다 (모듈 37 레슨 3의 문제 관리 기록) |
| 운영 환경에서 실험한다 | 처음부터 운영에서 하지 않는다. 스테이징 → 사전 운영 → 운영의 좁은 범위 순으로 자격을 얻어 가며 넓힌다 |
| 실험을 자동화해 지속적으로 돌린다 | 한 번 성공한 실험을 회귀 층(모듈 38 레슨 4)에 넣어 매주 돌린다 |
| 폭발 반경을 최소화한다 | 대상·기간·중단 조건을 실험 정의에 명시하고, 중단 조건 자체를 시험한다 |
세 번째 원칙에서 QA가 가장 신중해야 한다. 원칙은 운영 실험의 가치를 말하지만, 검증되지 않은 실험을 운영에서 돌려 고객 장애를 만들면 신뢰성 활동 전체가 금지된다. 실험도 층을 거쳐 승격 시킨다.
정상 상태 가설을 판정 기준으로 쓰기
"장애가 나도 괜찮아야 한다"는 기준이 아니다. 가설은 다섯 칸 기준(모듈 38 레슨 1)의 형태로 쓴다.
[실험 CH-INFER-03 — 추론 복제본 파드 1개 강제 종료]
정상 상태 정의 (실험 전 5분 측정, 이후 계속 측정)
- 요청 성공률 ≥ 99.9%
- TTFT p95 ≤ 800ms
- 진행 중 스트리밍 응답의 중간 끊김 0건
가설
복제본 4개 중 1개를 강제 종료해도
(1) 요청 성공률은 1분 구간 기준 99.5% 이상 유지
(2) TTFT p95 는 종료 후 3분 안에 정상 상태 기준으로 복귀
(3) 종료된 파드에서 진행 중이던 스트리밍 요청은 클라이언트에 명시적 오류로 끝나고, 무응답 대기로 남지 않는다
(4) 새 복제본이 준비 판정을 통과하기 전에는 트래픽을 받지 않는다 (레슨 6)
중단 조건
요청 성공률 1분 구간 97% 미만 → 즉시 실험 중단, 복구 절차
대상 범위
스테이징 infer-stg 네임스페이스, 라벨 app=llm-a, 파드 1개가설 (3)과 (4)가 이 실험의 진짜 가치다. 복제본 하나가 죽었을 때 전체 성공률이 유지되는 것은 대개 당연하다. 죽은 복제본에 붙어 있던 요청이 어떻게 끝나는가, 새 복제본이 너무 일찍 트래픽을 받지 않는가 가 결함이 사는 곳이다.
장애 주입 도구 — Chaos Mesh와 LitmusChaos
Kubernetes 환경에서 널리 쓰이는 두 도구 모두 CNCF 프로젝트다. Chaos Mesh는 2022년 2월 인큐베이팅 단계로 올라갔다. 구조가 달라 쓰임이 조금 다르다.
| Chaos Mesh | LitmusChaos | |
|---|---|---|
| 구조 | 노드마다 특권 데몬이 대상 파드의 네트워크·파일시스템·프로세스에 직접 개입 | 실험마다 일회성 실행 파드를 띄우고 중앙 허브에서 여러 클러스터를 조율 |
| 실험 정의 | 장애 종류별 커스텀 리소스 (PodChaos·NetworkChaos·StressChaos·IOChaos·TimeChaos 등), 워크플로·일정 | 실험 정의와 실행 리소스, 실험 중 상태를 확인하는 프로브 |
| 강점 | 세밀한 커널·네트워크 수준 주입 | 실험 카탈로그와 다중 클러스터 운영, 프로브로 가설 판정 내장 |
도구 선택보다 중요한 것은 특권 데몬이 클러스터에 상주한다는 사실 이다. Chaos Mesh 같은 도구는 강력한 권한을 갖는다. 운영·고객 환경에 설치할지, 설치한다면 어떤 네임스페이스만 대상으로 허용할지, 누가 실험을 만들 수 있는지를 보안 검토 대상으로 올린다. 인증 범위(레슨 9)에 들어가는 환경이라면 더욱 그렇다.
네트워크 장애 실험의 예:
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
name: train-worker-latency
namespace: chaos-experiments
spec:
action: delay
mode: one
selector:
namespaces: [ "train-stg" ]
labelSelectors: { "job-name": "llm-pretrain-qa", "role": "worker" }
delay:
latency: "50ms"
jitter: "10ms"
direction: both
duration: "10m"mode: one 과 duration 이 폭발 반경을 정한다. 모듈 29의 네트워크 품질 저하 시험(대역폭·지연·지터·손실 4축)이 클러스터 내부 통신에 그대로 적용된다.
분산 학습 워커 하나에 지연을 주면 전체 학습이 가장 느린 워커에 맞춰 느려지는지, NCCL 타임아웃으로 작업이 죽는지, 타임아웃 설정이 문서와 같은지를
관찰한다.
인프라 플랫폼에서 우선 시험할 장애 목록
운영 기록이 없는 초기에는 인프라 플랫폼에서 흔한 장애 유형으로 출발한다.
| 장애 | 가설의 핵심 | 관련 레슨 |
|---|---|---|
| 제어 평면 API 서버 재시작 | 실행 중 VM·학습 작업·추론 엔드포인트의 데이터 평면 무중단 | 레슨 1 |
| 오퍼레이터 파드 조정 도중 종료 | 재시작 후 이어서 수렴, 중복·누수 없음 | 레슨 2 |
| etcd·DB 리더 교체 | 쓰기 일시 실패 후 재시도로 복구, 상태 불일치 없음 | 레슨 1·3 |
| 노드 전원 차단 | 파드 재배치 시간, 스토리지 분리·재연결, 학습 작업 재입장·재개 | 레슨 5 |
| 노드 간 네트워크 분할 | 분산 학습 타임아웃 동작, 분할 해소 후 복구 | 레슨 5 |
| GPU 장치 오류 (Xid) | 노드 격리 자동화, 작업 재배치, 오류 GPU에 새 작업 배정 금지 | 레슨 5 |
| 체크포인트 저장 중 종료 | 이전 체크포인트 유효, 반쯤 쓴 체크포인트 무시 | 레슨 5 |
| 모델 가중치 저장소 지연 | 콜드 스타트 시간, 준비 판정, 타임아웃 후 명시적 실패 | 레슨 6 |
| 인증 서비스 장애 | 기존 세션·토큰의 동작, 장애 해소 후 재인증 | — |
| 시계 어긋남 | 토큰 만료·인증서 검증·스케줄 작업 | — |
첫 줄이 이 모듈 전체의 가장 중요한 신뢰성 기준 이다. 관리 콘솔이나 API가 업그레이드·장애로 몇 분 멈추는 것은 고객이 참을 수 있다. 그동안 이미 돌고 있던 사흘째 학습 작업이 죽거나 운영 추론 엔드포인트가 멈추면 참을 수 없다.
GPU 장애를 주입하는 법
물리적으로 GPU를 고장 낼 수는 없다. 대신 장애를 감지하고 처리하는 경로 를 시험한다.
| 방법 | 시험하는 것 |
|---|---|
| DCGM 오류 주입 기능 | DCGM이 보는 장치 필드에 오류 값을 주입해 감시·경보·노드 격리 자동화가 반응하는지 |
| 커널 로그에 Xid 형식 메시지 주입 (시험 전용 노드) | 로그 기반 감지 규칙과 조치 결정 테이블 |
| 장치 플러그인 재시작·광고 GPU 수 변경 | 스케줄러가 줄어든 GPU를 반영하는지, 실행 중 파드가 어떻게 되는지 |
| 학습 컨테이너 안에서 CUDA 오류를 내는 시험 프로그램 | 작업 수준 실패 처리, 재시도·재입장 정책 |
어떤 방법이든 주입한 것과 실제의 차이 를 기준 문서에 적는다(모듈 38 레슨 4의 흉내 검증). 로그 주입으로 격리 자동화가 동작해도, 실제 Xid 79 상황에서 노드의 드라이버가 응답하지 않아 격리 스크립트 자체가 멈출 수 있다. 실제 장애 사례가 운영에서 생기면 그 기록으로 가설을 보강한다.
폭발 반경과 중단 조건을 시험한다
실험이 통제를 벗어나는 경로는 대개 두 가지다. 선택자가 의도보다 넓은 대상을 고르거나, 중단 조건이 작동하지 않는다.
[실험 사전 점검 — 모든 실험 공통]
[ ] 선택자 드라이런: 실험 대상으로 선택될 파드·노드 목록을 먼저 출력하고 사람이 확인
[ ] 네임스페이스 허용 목록: 실험 도구가 허용 목록 밖 네임스페이스를 대상으로 삼지 못함 (설정으로 강제)
[ ] 기간 상한: duration 없는 실험 금지
[ ] 중단 조건 자동화: 지표가 기준을 넘으면 실험 리소스 삭제 → 장애 해제 확인
[ ] 중단 조건 자체 시험: 기준을 일부러 낮게 잡은 실험으로 중단이 실제로 걸리는지 1회 확인
[ ] 해제 확인: 실험 종료 후 네트워크 규칙·스트레스 프로세스가 남아 있지 않음
[ ] 알림: 실험 시작·종료가 운영 채널에 기록 (인시던트로 오인 방지)"해제 확인"이 의외로 자주 실패한다. 장애 주입 데몬이 실험 중에 재시작되면 걸어 둔 네트워크 지연 규칙이 해제되지 않고 남을 수 있다. 실험이 끝난 뒤 정상 상태로 돌아왔는지 도 가설의 일부로 판정한다.
복구 시간을 숫자로 남긴다
신뢰성 시험의 결과는 "통과"보다 숫자 가 가치 있다. 같은 실험을 반복하면 추세를 볼 수 있다.
| 측정 | 정의 |
|---|---|
| 감지 시간 | 장애 주입 → 경보·자동 감지 |
| 격리 시간 | 감지 → 영향 범위 차단 (노드 cordon, 트래픽 제외) |
| 복구 시간 | 주입 → 정상 상태 가설 기준 복귀 |
| 영향량 | 실패한 요청 수, 재시작된 작업 수, 손실된 학습 스텝 수 |
학습 작업의 손실된 학습 스텝 수 는 GPU 플랫폼 고유의 영향 지표다. 노드 장애로 작업이 마지막 체크포인트로 돌아가면, 체크포인트 간격만큼의 GPU 시간이 사라진다. 이 숫자가 체크포인트 간격 정책(비용 대 손실)의 근거가 된다.
폐쇄망 고객 환경의 복구 리허설
소버린·폐쇄망 고객 환경은 장애 대응도 다르다. 외부에서 원격 접속해 고칠 수 없고, 외부 저장소에서 패치를 받을 수 없다. 릴리스 전 층에 복구 리허설 을 둔다.
| 리허설 | 판정 |
|---|---|
| 노드 교체 | 외부 네트워크 없이 새 노드 투입·GPU 진단·클러스터 합류 완료 |
| 제어 평면 백업·복원 | 백업에서 복원 후 기존 리소스 상태 일치 |
| 인증서 만료 대응 | 만료 임박·만료 상태에서 갱신 절차가 문서대로 동작 |
| 설치 매체로 긴급 패치 | 내부 레지스트리에 반입한 패치로 업그레이드 완료 |
| 운영자 문서만으로 수행 | 개발팀 도움 없이 고객 운영자가 문서만 보고 끝낼 수 있는가 |
마지막 줄은 문서 검증이다. 개발자가 옆에 있으면 암묵지로 넘어가는 단계가 문서에 빠져 있는 경우가 많다. 모듈 33 레슨 3에서 사용자 설명서를 시험 기준으로 검증했던 방식이 운영자 복구 문서에 적용된다.
실무에서 왜 필요한가
AI 인프라 플랫폼의 고객 계약은 대개 가용성과 복구 시간을 포함한다. 그 숫자를 시험으로 측정한 적이 없으면 계약은 희망 사항이다. 장애 주입 시험의 결과는 영업·계약·운영 문서가 약속하는 숫자의 근거가 되고, 실제 인시던트 후에는 "예상한 복구 시간 안이었는가"를 판단하는 기준이 된다.
우대사항의 "성능/부하/신뢰성 테스트 경험"에서 신뢰성은 지금 가장 공급이 부족한 경험이다. 부하 테스트는 해 본 QA가 많지만, 정상 상태 가설을 쓰고 폭발 반경을 통제하며 복구 시간을 숫자로 남겨 본 QA는 드물다. "API 서버 재시작 중 실행 중 학습 작업의 무중단을 가설로 세워 시험했고, 오퍼레이터 재시작 시 체크포인트 재개가 중복 워커를 만드는 결함을 찾았다" 같은 이야기가 그 경험을 증명한다.