𝗥𝗲𝗰𝗼𝘃𝗲𝗿𝗶𝗻𝗴 𝗦𝘁𝗮𝗹𝗲 𝗕𝗿𝗼𝘄𝘀𝗲𝗿 𝗣𝗿𝗼𝗳𝗶𝗹𝗲 𝗟𝗼𝗰𝗸𝘀
브라우저 프로필 잠금은 두 개의 워커가 동시에 동일한 계정을 여는 것을 방지합니다.
대부분의 자동화 시스템은 복구 과정에서 실패합니다. 워커가 충돌하거나 네트워크 연결이 끊기면, 시스템은 오래된 잠금을 감지하고 이를 삭제합니다. 이렇게 하면 큐(queue)는 계속 진행되지만, 계정 상태가 손상됩니다.
만료된 잠금은 단순히 삭제해야 할 파일이 아닙니다. 이는 통제된 복구 경로가 필요한 미완료 작업입니다.
잠금을 단순한 파일로 취급하지 마십시오. '임대(lease)'로 취급하십시오.
안전한 임대에는 다음이 필요합니다:
- 소유자 (An owner)
- 만료 시간 (An expiry time)
- 하트비트 (A heartbeat)
- 버전 번호 (펜싱 토큰) (A version number (fencing token))
버전 번호는 매우 중요합니다. 모든 쓰기 작업에는 반드시 최신 토큰이 포함되어야 합니다. 새로운 워커가 작업을 인계받은 후 이전 워커가 돌아오면, 시스템은 이전 토큰을 거부합니다. 이를 통해 인지하지 못한 데이터 손상을 방지할 수 있습니다.
'잠금(locked)' 상태에서 바로 '사용 가능(available)' 상태로 건너뛰지 마십시오. 다음과 같은 단계를 거치도록 상태 머신을 사용하십시오:
- 유지됨 (Held)
- 만료 의심 (Suspected stale)
- 격리됨 (Quarantined)
- 검사됨 (Inspected)
- 사용 가능 | 재개 대기 중 | 수동 검토 (Available | Resume pending | Manual review)
격리(quarantine) 단계는 매우 중요합니다. 조사를 진행하는 동안 두 번째 워커가 프로필에 접근하는 것을 차단합니다.
조사 과정에서 반드시 증거를 수집해야 합니다:
- 브라우저 프로세스가 여전히 실행 중이었는가?
- 마지막으로 확인된 URL은 무엇인가?
- 작업이 결제나 설정 변경과 같은 민감한 단계에 있었는가?
- 실패 상황에 대한 스크린샷이 있는가?
민감한 작업 중에 작업이 중단되었다면 자동으로 재개하지 마십시오. 수동 검토로 보내십시오. 자동화 시스템은 잘못된 결정을 방지하기 위한 경계(boundaries)를 가져야 합니다.
피해야 할 일반적인 실수:
- 프로필의 안전성을 확인하지 않고 잠금을 삭제하는 것.
- 이전 워커의 지연된 쓰기 작업을 거부하기 위해 펜싱 토큰을 사용하지 않는 것.
- 확인된 안전한 체크포인트 없이 양식 제출을 재시도하는 것.
- 복구 과정 중에 프록시를 변경하는 것.
목표는 복구를 복잡하게 만드는 것이 아닙니다. 복구 과정을 명확하게(explicit) 만드는 것입니다.
잠금은 단지 증상일 뿐입니다. 시스템은 해당 잠금 뒤에 있는 계정 환경을 보호해야 합니다.
하나의 프로필. 하나의 소유자 임대. 하나의 활성 작업. 하나의 증거 기록. 하나의 복구 결정.