Hinted Handoff란 무엇인가
분산 데이터베이스는 여러 대의 서버(노드)에 데이터를 나눠 저장한다. 이때 특정 노드가 일시적으로 다운되면 그 노드에 쓰여야 할 데이터는 어떻게 될까? Hinted Handoff는 바로 이 문제를 해결하는 메커니즘이다. 장애가 난 노드 대신 다른 정상 노드가 임시로 데이터를 대신 받아두었다가, 장애 노드가 복구되면 원래 주인에게 데이터를 넘겨주는 방식이다. Apache Cassandra, Amazon DynamoDB, Riak 같은 분산 DB에서 널리 사용되는 기법이다.
동작 원리와 예시
택배 기사가 집에 물건을 배달하러 갔는데 문이 잠겨있다면 어떻게 할까? 기사는 물건을 이웃집에 맡기고 메모(hint)를 남긴다. ‘이 물건은 옆집 철수님 것이니 나중에 전해주세요’. 나중에 철수님이 집에 돌아오면 이웃이 물건을 전달해준다. 분산 DB에서도 원리는 비슷하다.
- 클라이언트가 쓰기 요청을 보내면, 코디네이터 노드는 데이터를 저장해야 할 담당 노드(replica)를 확인한다.
- 담당 노드가 다운되어 응답이 없으면, 코디네이터는 다른 정상 노드에 데이터와 함께 ‘이 데이터는 원래 노드 A의 것’이라는 힌트를 함께 저장한다.
- 이 힌트는 별도의 저장 공간(hint store)에 보관되며, TTL(예: 3시간)이 지나면 자동 폐기된다.
- 장애 노드가 복구되어 클러스터에 다시 참여하면, 힌트를 들고 있던 노드가 데이터를 원래 노드로 전달(handoff)한다.
이 과정 덕분에 클라이언트는 노드 장애 여부와 상관없이 쓰기 요청을 계속 수행할 수 있고, 데이터도 결국 올바른 위치에 저장된다.
실무에서 왜 쓰는가
분산 시스템에서 노드 장애는 예외가 아니라 일상이다. 네트워크 지연, 하드웨어 문제, 재배포 등으로 노드는 수시로 잠깐씩 다운될 수 있다. Hinted Handoff가 없다면 매번 쓰기 실패를 클라이언트에 돌려주거나, 재시도 로직을 애플리케이션이 직접 구현해야 한다. 이 기법 덕분에 시스템은 가용성(Availability)을 크게 높일 수 있다.
다만 주의할 점도 있다. 힌트가 쌓여있는 동안은 데이터가 완벽히 일관된 상태가 아니라 최종적 일관성(Eventually Consistent) 상태이며, 힌트를 보관하는 노드에 부하가 몰릴 수도 있다. 그래서 Cassandra 같은 시스템은 힌트 저장 개수나 TTL을 설정으로 제한하고, Quorum 읽기/쓰기나 Read Repair 같은 보완 기법을 함께 사용해 일관성을 맞춘다. 결국 Hinted Handoff는 ‘완벽한 즉시 일관성’보다 ‘높은 가용성과 최종적 일관성’을 택하는 분산 시스템 설계 철학을 잘 보여주는 대표적인 예시다.