GPU 결과는 있는데 저장 호출은 오류로 끝날 수 있다
Workload Studio의 GPU 작업은 결과 파일을 먼저 보존하고 DB에 등록한다. GPU 실행과 결과 저장은 서로 다른 단계다. 저장 호출이 실패했을 때 결과를 다시 얻으려고 GPU를 실행하면, 이미 남아 있는 측정을 반복하고 외부 실행 비용을 다시 낼 수 있다.
더 어려운 경우는 DB가 이미 저장했지만 성공 응답만 잃은 상황이다. 저장 오류라는 호출 결과를 “DB에 결과가 없다”로 해석하면 같은 결과를 다시 등록하거나 원래 출처를 덮을 수 있다. 오류를 받았다는 관측과 실제 저장 상태를 구분하는 복구 경로가 필요했다.
변경은 닫힌 일반 GPU 작업의 기존 파일을 검사한 뒤, 누락된 등록과 연결을 복구하는 운영자 명령을 추가했다. 새 GPU 대여나 추론은 실행하지 않는다. 이 기능을 실제 운영 DB 장애의 비용 절감 실적으로 설명하지 않고, 구현과 검증 범위를 따라 살펴본다.
파일이 있다고 바로 등록하지 않는다
작업 식별자인 명시적 UUID와 반복 번호로 대조할 대상을 고른다. 작업의 lease는 소유권·기한·버전을 가진 실행 관리 행이다. 복구 대상은 닫힌 일반 작업이며, 유효한 소유권이 남아 있거나 Pod 삭제 확인이 없으면 거절한다. sweep·agent 등 다른 실행 계약을 일반 반복 번호로 해석하지 않는다.
- 작업 전제 확인closed 상태, 만료된 소유권, 삭제 확인, 원래 계획·설정을 검사한다.
- 원본 파일 대조결과·설정·등록 기록의 digest와 스키마, 작업·반복 결합을 확인한다.
- DB 직접 조회같은 결과가 있으면 내용·출처·labels·설정의 executed 연결을 확인한다.
- 대조 버전 지정일치 또는 실제 부재가 확인된 경우에만 관찰한 lease 버전으로 복구를 요청한다.
digest는 내용에서 계산한 식별값이다. digest가 일치하는 JSON이라는 이유만으로 유효한 측정 결과가 되지는 않는다. 실제 스키마와 원래 저장 입력까지 대조한다. 작업 디렉터리의 권한과 소유자를 확인하고 symlink·경로 이탈·중복 JSON key 같은 입력도 거절한다.
읽기 전용 대조의 stored_match는 기존 DB 등록이 원본과 일치한다는 뜻이다. 성능 비교가 유효하거나 하드웨어와 모델이 인증됐다는 판정은 아니다. not_stored도 DB 조회가 실제 부재를 반환했을 때만 사용한다. 조회 자체가 실패하면 부재로 바꾸지 않는다.
수정 직전에 버전과 원본을 다시 검사한다
읽기 전용 대조와 복구 사이에도 상태가 바뀔 수 있다. 복구는 lease 행을 잠그고 지정한 버전을 확인한 뒤, 같은 DB 트랜잭션에서 원래 저장 입력과 결과·설정·연결을 읽는다. 결과가 없을 때만 원본 그대로 삽입하고, 설정과 결과의 executed 연결 및 작업 결과 목록의 누락을 함께 반영한다.
lease = SELECT ... FROM gpu_leases FOR UPDATE
if lease.version != expected_version: reject
compare(original files, stored inputs, existing result)
insert missing result + executed link
recheck files
append missing digest to closed lease result list
commit위는 구현 순서를 줄인 설명이다. 결과 삽입은 충돌 시 덮어쓰지 않는다. 경합에서 browser/import 출처가 먼저 들어왔다면 그 행에 API 출처의 연결을 추가하지 않고, 전체 내용·출처·labels·연결을 다시 대조해 불일치를 거절한다. 일부 단계가 실패하면 같은 트랜잭션의 DB 변경을 모두 취소한다.
이미 정확히 저장된 결과는 created_at·labels·payload를 유지한다. 목록이 빠졌으면 그 부분만 추가하고, 원래 실패 사유·만료·Pod 삭제 확인·취소 여부와 다른 결과의 순서를 보존한다. 복구 때문에 끝난 작업의 기간을 연장하거나 성공한 GPU 실행처럼 상태를 다시 쓰지 않는다.
등록 성공과 목록 복구를 구분해 반환한다
| 복구 응답 | 뜻 |
|---|---|
| registered | 누락 결과를 등록하고 필요한 연결·목록 반영 |
| list_repaired | 기존 등록은 일치하며 작업 목록의 누락만 추가 |
| already_registered | 등록·연결·목록이 일치해 변경 없음 |
| lease_changed / files_changed | 버전 또는 파일 변경 발견 · DB 변경 취소 |
| store_unavailable | 저장 또는 commit 응답 불확실 · 재대조 필요 |
마지막 상태는 결과 부재를 뜻하지 않는다. 자동 재시도 대신 현재 DB와 lease 버전을 다시 대조해야 한다. 이전 버전을 그대로 보내면 거절될 수 있다. 원래 등록 기록에 failed나 cancelled가 남아 있어도 DB에는 정확한 결과가 존재할 수 있으므로, 기록 상태와 DB 존재 여부를 각각 반환한다.
파일까지 하나의 트랜잭션이 되는 것은 아니다
DB 등록·연결·목록 쓰기는 원자적으로 처리하지만 파일은 그 트랜잭션의 참여자가 아니다. 수정 전에 안전하게 읽고 트랜잭션 중 다시 대조해 변경을 감지한다. 그래도 마지막 검사 뒤의 동시 파일 변경까지 자동으로 막는 보장은 없다. 닫힌 작업의 비공개 디렉터리를 복구 중 함께 수정하지 않는 운영 조건이 남는다.
검증은 합성 fixture와 실제 개발 PostgreSQL을 사용했다. 결과의 synthetic·fake·measured 분류도 원본 그대로 유지하며 복구가 측정 근거를 승격시키지 않는다. Workload Studio에서 이 변경은 추론 결과를 새로 만드는 일과, 이미 존재하는 결과의 저장 상태를 회복하는 일을 분리한 사례다.