F. 장애와 복구

무엇이 죽어도 크레딧이 새지 않고 노드가 묶이지 않는다. 이 묶음은 정상 경로가 아니라 깨진 경로를 본다.

선행 없음. 다만 장애를 재현하려면 스택 일부를 의도적으로 중단할 수 있어야 한다.

설계 원칙 — 확실할 때만 놓는다

자원을 회수하는 판단은 두 가지 원칙 위에 있다.

1. 실제 stopped를 확인해야 노드를 반환한다. 중지 명령을 보냈다는 것만으로는 놓지 않는다. 확인 없이 놓으면 다른 팀이 그 노드를 배정받아 살아 있는 인스턴스와 충돌한다.
2. 워크플로우 기록이 정말 없을 때만 고아로 본다. Temporal이 잠깐 안 될 때 살아 있는 워크플로우를 고아로 오판하면 그 노드를 뺏는 셈이 된다.

애매하면 잡아둔다. 잘못 놓는 것보다 낫다.

---

S-35 기동 실패와 보상

사용자 · 5분 · 선행 S-09

AWS가 거부하거나 노드가 응답하지 않아 인스턴스가 뜨지 못하는 경우다.

절차 아래 중 하나로 실패를 유발한다.

• 존재하지 않는 노드를 배정받게 한다.
• AWS 자격증명을 잘못된 값으로 바꾼다.
• 시뮬레이션 모드에서 실패 케이스를 넣는다.

기대

• ✅ 인스턴스 상태가 failed로 끝난다. running에서 멈춰 있지 않는다.
• ✅ 선점한 크레딧이 반환된다. 뜨지 못한 인스턴스에 과금되지 않는다.
• ✅ 노드가 풀로 돌아온다. 다른 사람이 바로 쓸 수 있다.
• ✅ 팀에 인스턴스 기동에 실패했습니다 알림이 사유와 함께 간다.
• ✅ 대시보드의 현재 소진율이 원래대로 내려간다.

실패 유형별 처리

상황	알림	노드
배정할 노드가 없음	가용 노드가 없어 시작하지 못했습니다	애초에 안 잡았다
프로바이더가 시작을 거부	launch_refused	중지 확인 후 반환
세션 개시 실패	세션 개시에 실패해 시작을 취소했습니다	중지 확인 후 반환
중지 명령 실패	stop_failed	잡아둔다. 살아 있을 수 있다
중지 미확인	stop_unconfirmed	잡아둔다. 수렴 스윕에 넘긴다

stop_failed와 stop_unconfirmed가 노드를 잡아두는 이유가 위의 원칙 1이다. GPU가 살아 있는 채로 다른 팀에 넘어가는 것보다, 잠깐 놀려두는 편이 안전하다.

중지 전이가 느릴 때 중지 명령 후 stopped가 될 때까지 여러 번 다시 확인한다. 그 안에 확인되면 정상 종료로 끝난다. 끝내 확인되지 않으면 stop_unconfirmed로 수렴 스윕에 넘긴다.

중지 시각까지만 과금된다 이 확인을 기다리는 구간은 청구되지 않는다.

관련 인스턴스 실행 · 알림함

---

S-36 고아 자원 수렴

운영 · 15분 · 선행 S-09

세션 워크플로우가 사라졌는데 인스턴스만 남아 있는 상태다. Temporal 재시작, 워커 강제 종료, 워크플로우 이력 만료 등으로 생긴다.

전제 인스턴스를 시작한 뒤 그 세션 워크플로우를 강제로 없앤다.

절차

1. 인스턴스를 하나 띄운다.
2. 그 세션 워크플로우를 종료·삭제한다.
3. 최대 10분을 기다린다. 정리 작업이 10분 주기로 돈다.

기대

• ✅ 워크플로우 없는 인스턴스가 자동으로 감지된다.
• ✅ 실제 상태에 따라 아래대로 수렴한다.

실제 상태	처리
아직 실행 중	계속 과금하고 노드를 유지한다. 뺏지 않는다
stopping	정산하고 세션을 닫는다. 노드는 확정 후에 반환한다
stopped	정산하고 노드를 반환한다

• ✅ 열린 세션이 닫히고 선점이 풀린다.
• ✅ 사용량 리포트의 GPU 시간이 무한정 늘지 않는다.
• ✅ 같은 정리가 여러 번 돌아도 결과가 같다. 이중 정산되지 않는다.

살아 있는 워크플로우는 건드리지 않는다 정리 작업은 워크플로우가 실행 중이면 그냥 넘어간다. Temporal이 잠시 응답하지 않아 확인에 실패한 경우도 넘어간다. 기록이 정말 없을 때만 고아로 본다.

노드만 남은 경우도 본다 인스턴스는 종료됐는데 노드 점유만 남은 경우가 있다. 중지는 성공했지만 반환 직전에 죽은 상황이다. 이것도 같은 주기에 정리된다.

왜 하나의 주체가 정리하는가 실패한 각 지점이 알아서 뒷정리하면 서로 다른 판단을 하다가 같은 노드를 두 번 놓거나 영원히 안 놓는다. 불확실한 경로는 전부 이 정리 작업에 위임한다. 판단하는 곳이 하나면 규칙도 하나다.

관련 노드 풀 관리

---

검증 요약

이 두 시나리오가 통과하면 아래가 보장된 것이다.

보장	어떻게 확인되나
뜨지 못한 인스턴스에 과금되지 않는다	S-35에서 선점이 반환된다
노드가 영구히 묶이지 않는다	S-36에서 10분 안에 반환된다
살아 있는 인스턴스의 노드를 뺏지 않는다	S-36에서 실행 중이면 건드리지 않는다
이중 정산이 없다	S-36을 여러 번 돌려도 결과가 같다
잔액이 음수가 되지 않는다	원장 제약이 데이터베이스 레벨에서 막는다

이 묶음이 끝나면

정상 경로와 깨진 경로 양쪽에서 자원 회계가 맞는 것을 확인한 것이다.

다음: G. 운영·정리 — 되돌리기와 흔적.