Raft 리더가 명령을 로그에 넣고 팔로워에 보냈습니다. 복제·커밋·상태 머신 적용은 어떻게 다르며 클라이언트에 성공을 언제 응답하나요?

Raft 로그는 leader·follower 저장, quorum commit, state machine apply를 나눠야 합니다. follower 디스크 한 대에 저장됐다고 리더 교체 뒤 확정된 것은 아닙니다. commit은 이후 리더가 보존해야 할 결정이고 apply는 그 결정을 데이터에 반영하는 단계입니다.

현재 term과 적용

leader는 일반적으로 현재 term 엔트리가 과반에 복제된 것을 이용해 commit index를 전진시킵니다. 이전 term 엔트리를 복제 수만으로 직접 commit한다고 단순화하지 않습니다. commit됐어도 apply loop가 느리면 조회는 옛 상태를 볼 수 있습니다.

client에는 계약에 따라 commit 후 성공을 말할 수 있지만 응답 직전 leader가 죽으면 재시도됩니다. 요청 ID와 결과를 내구화해 같은 결과를 찾고 상태 머신은 결정적으로 재생되게 합니다. 외부 결제·알림은 outbox·inbox·멱등 키로 별도 처리합니다. 저장·commit·apply·응답 직전 중단을 각각 시험합니다.

로그 위치별로 관찰합니다

리더의 마지막 로그 index가 105, commit index가 100, applied index가 97일 수 있습니다. 101105는 아직 확정되지 않은 제안이고 98100은 확정됐지만 로컬 상태에 미반영된 명령입니다. 단순히 로그가 디스크에 있다는 이유로 105의 결과를 확정 응답하거나, 97의 상태를 100까지 반영한 최신 읽기라고 말하면 안 됩니다. 각 위치의 차이는 복제 병목과 적용 병목을 구분하는 지표입니다.

Raft는 현재 term의 엔트리가 과반에 저장된 것을 기준으로 commit index를 전진시킵니다. 그 앞의 이전 term 엔트리는 로그 접두부로 함께 커밋될 수 있습니다. 이전 term 엔트리의 복제 개수만 세어 독립적으로 커밋하지 않는 이유는 리더 변경 과정에서 같은 관찰이 안전한 확정을 의미하지 않을 수 있기 때문입니다. 새 리더가 현재 term의 no-op을 기록하는 것은 이런 확정 경계를 마련하는 데 쓰일 수 있습니다.

결과 응답과 상태 머신

명령이 '요청을 합의 로그에 접수했다'는 계약이면 commit 확인을 반환할 수 있지만, 실제 계정 잔액과 조건부 갱신 결과를 반환하려면 상태 머신 적용 결과가 필요합니다. 성공의 의미를 API별로 고정해야 합니다. 상태 머신은 명령 순서대로 결정적으로 실행하고 현재 시각·난수·외부 API 결과를 각 노드가 임의로 다시 읽지 않습니다.

commit과 apply 사이에 리더가 죽어도 새 리더는 확정 접두부를 보존하고 적용을 이어가야 합니다. 응답만 유실된 요청은 재시도될 수 있으므로 요청 ID와 처리 결과를 상태와 함께 기록합니다. 스냅샷에도 중복 방지 상태를 포함해야 재시작 후 같은 명령의 효과를 다시 만들지 않습니다.

외부 메일이나 결제를 apply 함수에서 매 노드가 직접 실행하면 중복 효과와 비결정성이 생깁니다. 상태 머신은 내구적인 실행 의도나 outbox를 기록하고 실제 외부 호출은 소유권·멱등 키가 있는 별도 경로에서 처리합니다. 저장·커밋·적용·응답 시점별 장애 시험으로 로그 안전성과 외부 처리 안전성을 각각 검증하겠습니다.