시도 A가 타임아웃됩니다. 시도 B는 다른 프로바이더로 라우팅되어 먼저 완료됩니다. 그 후 A가 돌아와 B를 덮어씁니다. 가용성(Availability)은 향상되었으나, 정확성(Correctness)은 향상되지 않았습니다.

이러한 이벤트 순서는 7월 25일 공식 타임라인 동안 발생 가능성이 있습니다. OpenAI는 09:17:49 UTC에 시작된 첫 번째 장애, 10:02:52의 완화 모니터링, 그리고 11:08:36의 해결을 보고했습니다. 두 번째 장애는 11:35:24에 시작되었으며, 조사 당시 오류 증가와 완화 작업이 진행 중인 것으로 확인되었습니다. 공식 상태 서비스는 해당 시점에 부분적 시스템 저하(Partial System Degradation)를 표시했습니다. 이 중 어느 것도 두 번째 장애의 근본 원인(Root cause), 전역적 영향(Global impact), 정확한 영향 사용자, 또는 최종 복구 상태를 확정 짓지는 않습니다.

불변량(Invariant)은 다음과 같습니다: 태스크 에포크(Task epoch)에 대해 최대 하나의 프로바이더 시도만이 결과를 커밋할 수 있으며, 그 출력은 해당 에포크의 시맨틱 게이트(Semantic gate)를 통과해야 합니다.

커밋 권한으로부터 실행 분리

coordinator -> lease(epoch=7) -> attempt A
            -> lease expires
            -> lease(epoch=8) -> attempt B
...

리스(Lease)는 작업이 진행되어야 하는 시점을 제한하지만, 시계(Clocks)와 지연된 메시지(Delayed messages)로 인해 오래된 워커(Stale worker)의 쓰기를 방지할 수는 없습니다. 내구성이 있는 저장소(Durable store)는 단조 증가하는 에포크(Monotonically increasing epoch)를 사용하여 모든 커밋을 펜싱(Fence)해야 합니다.

-- 실행되지 않은 프로토콜 스케치
UPDATE task_outcomes
SET output = :validated_output,
...

단 하나의 행 업데이트만이 게시(Publication)를 승인합니다. 프로바이더 콜백(Provider callbacks)은 애플리케이션 상태를 직접 작성하지 않습니다. 대신 태스크 ID, 에포크, 프로바이더, 요청 다이제스트(Request digest), 그리고 검증 기록을 포함하는 시도 결과(Attempt results)를 추가(Append)합니다.

최소 실패 픽스처 (Minimal failure fixture)

다음과 같이 예정된 이벤트들을 가진 시뮬레이터를 구축합니다:

t=0   epoch 7에서 A 발행
t=5   클라이언트 타임아웃
t=6   epoch 8로 진행
...

이것들은 제안된 입력값과 예상되는 동작이며, 실제로 실행된 테스트 결과가 아닙니다. A가 B보다 먼저 반환되는 경우, 두 응답 모두 유효성 검사(validation)에 실패하는 경우, 에포크(epoch) 진행 후 코디네이터(coordinator)가 충돌하는 경우, 그리고 호출자가 타임아웃된 후 스토어(store)가 커밋을 승인하는 경우 등의 순열(permutations)을 추가하십시오.

테스트 가능한 속성:

• 하나의 태스크(task)에 대해 두 개의 커밋된 결과(committed outcomes)를 포함하는 히스토리는 존재하지 않음;
• 낮은 에포크(epoch)는 높은 에포크의 상태를 절대 변경할 수 없음;
• 타임아웃만으로는 시도(attempt)를 부재(absent)로 표시할 수 없음;
• 복구(recovery)를 통해 영구 저장된 기록(durable records)으로부터 승자를 재구성할 수 있음;
• 프로바이더(provider) 전환이 의미론적 유효성 검사(semantic validation)를 우회할 수 없음.

마지막 속성이 중요한 이유는 멀티 프로바이더 폴백(multi-provider fallback)에 의미론적 위험(semantic risks)이 따르기 때문입니다. 모델들은 도구 호출(tool-call) 해석, 구조화된 출력(structured outputs), 컨텍스트(context) 처리, 그리고 생성된 부수 효과(side effects) 측면에서 서로 다를 수 있습니다. 펜싱(Fencing)은 쓰기 순서(write ordering)를 해결하는 것이지, 의미(meaning)를 해결하는 것이 아닙니다. 프로바이더별 피스처(fixtures)를 유지하고, 수용 오라클(acceptance oracle)이 주관적이거나 사용할 수 없는 태스크에 대해서는 폴백(fallback)을 거부하십시오.

호스팅된 경로와 소스 경로 모두 검사하기

해외의 MonkeyCode 온라인 서비스는 현재 “Start free”라고 표시되어 있습니다. 공식 README에는 빌드, 테스트, 프리뷰와 함께 통합된 모델을 제공하는 관리형 서버 측 클라우드 환경(managed server-side cloud environments)에 대해 설명되어 있습니다. 시작은 무료라고 되어 있으나, 해당 파라미터들은 변경될 수 있으므로 콘솔에서 현재의 모델/서버 할당량(quotas), 리전(regions), 그리고 업타임(uptime) 또는 SLA 약관을 확인하십시오.

official MonkeyCode GitHub project는 AGPL-3.0 오픈 소스입니다. 검토된 메인 커밋 18baaf54937a65a7d47f1f9d83dd808777aa6cea에서 README는 개발 환경(development environments), 모델(models), 작업(tasks) 및 요구 사항(requirements)에 대한 내장된 관리 기능을 나열하고 있습니다. 시스템 평가를 위해, 소스 코드는 검사 및 셀프 호스팅(self-hosting)을 위한 탈출 경로이며, 해외 호스팅은 일회성 작업(disposable tasks)으로 탐색할 수 있는 별도의 관리형 경로입니다. 어느 쪽도 보장된 독립적 장애 도메인(failure domains)을 생성하지 않으며, 호스팅된 MonkeyCode의 신뢰성은 테스트되지 않았습니다.

제공자별 출력(provider-specific output) 외부에서 에포크(epoch)와 커밋 경계(commit boundary)를 정의한 후에만 평가용으로 권장합니다. 펜싱(fencing)이 없는 두 번째 경로는 장애를 침묵하는 불일치(silent inconsistency)로 대체함으로써 장애를 덜 눈에 띄게 만들 수 있습니다.

어떤 이벤트 순서가 귀하의 불변성(invariant)을 깨뜨립니까: 오래된 성공(stale success), 중복 콜백(duplicate callback), 코디네이터 재시작(coordinator restart), 또는 의미론적으로 다른 승자(semantically different winner)? 프로토콜은 명시적으로 거부(reject), 재실행(replay), 또는 보상(compensate)해야 합니다.

공개 사항: 저는 MonkeyCode 사용자로서 저의 개인적인 경험을 공유하는 것이며, 해당 프로젝트와 관련이 없습니다.

AI 지원 공개: 이 기사는 AI의 도움을 받아 초안이 작성되었으며, 인용된 1차 자료를 바탕으로 검토되었습니다.