리더가 lease를 얻었으니 만료 전에는 혼자 쓰는 것이 보장되나요?

lease는 정한 시간과 프로토콜 조건 아래 소유권을 주는 방식이며 작업자가 멈추거나 네트워크가 지연되면 로컬 판단이 낡을 수 있습니다. 실제 쓰기 지점에서 새 세대를 확인하는 펜싱이 필요할 수 있습니다.

동작 원리와 전제

A가 lease를 얻고 오래 정지한 동안 B가 새 lease를 얻으면 A는 깨어난 뒤 옛 작업을 보낼 수 있습니다. 시계를 확인한 직후에도 정지할 수 있으므로 체크 후 실행 사이 경쟁이 남습니다. lease 만료와 프로세스 종료는 다릅니다.

선택과 실패 처리

갱신 실패 시 신규 작업을 막고 진행 중 효과를 정리하며 저장소가 증가 토큰을 비교해 낮은 세대 쓰기를 거절하도록 합니다. 토큰 비교와 변경이 원자적이어야 합니다. 단조 시계의 로컬 경과 측정과 서버 간 시간 가정도 구분합니다.

구체적인 사례와 검증

저장 지점이 토큰 12를 이미 본 뒤 토큰 11의 쓰기를 받으면 거절하도록 할 수 있습니다. 토큰을 앱에서 먼저 조회한 뒤 조건 없는 쓰기를 하면 그 사이 새 owner가 바뀔 수 있으므로 비교와 변경이 같은 원자 경계여야 합니다. 기존 owner가 외부 API에 보낸 작업은 lease 회수만으로 중단되지 않습니다. 해당 API가 펜싱을 지원하지 않으면 같은 논리 작업 ID의 중복 방지나 단일 권위 실행 경로를 설계합니다. 갱신 ACK를 받지 못한 경우 실제 lease 상태가 불확실할 수 있어 무리하게 계속 쓰지 않습니다. 가용성과 안전성의 선택을 장애 모드별로 명시하겠습니다.

긴 pause·갱신 응답 유실·분할·재시작을 시험합니다. 펜싱을 지원하지 않는 외부 API는 멱등 키·단일 실행 지점 등 보장 범위를 낮춰 설계합니다. lease 제공자의 성공 응답만으로 모든 외부 자원의 독점이 생기지는 않습니다.