A Beginner's Guide to Clocks, Causality, and Ordering in Distributed Systems

참고: 이 글은 ByteByteGo의 유료(Paid) 구독자 전용 포스트입니다. 본문 앞부분(무료 티저)만 공개되어 있고, "Clock Drift" 섹션부터는 페이월(paywall)에 막혀 원문 전체를 확보할 수 없었습니다. 아래는 공개된 티저 본문 전체에 대한 직역입니다.

시간을 읽는 것처럼 단순한 일이 왜 분산 시스템에서는 어려운 문제가 되는가?

단일 컴퓨터에서는 모든 이벤트를 하나의 시계를 기준으로 측정할 수 있기 때문에 이벤트의 순서는 의심의 여지가 없다. 그러나 작업이 여러 개의 독립된 머신에 분산되는 분산 시스템에는 공유되는 기준점이 없다. 각 머신은 자신의 하드웨어 시계로부터 시간을 읽을 수 있지만, 그 시계들은 서로 정렬된 상태를 유지하지 못한다. NTP(Network Time Protocol)가 시계들을 맞추려 시도하지만, 문제를 완전히 없애지는 못한다.

정확성이 일이 일어난 순서에 의존할 때마다 이는 실제 문제가 된다. 서로 다른 머신에서 발생한 이벤트들을 타임스탬프 비교로 순서를 매긴다면, 잘못된 방향으로의 작은 차이가 결과를 바꿔놓을 수 있다. 예를 들면 다음과 같다.

• 나중에 일어난 업데이트가 더 이른 시점의 업데이트에 밀려 폐기될 수 있다. 시계 차이 때문에 더 이른 시점의 쓰기(write)가 오히려 더 큰 타임스탬프를 갖게 되어, 더 새로운 데이터가 아무런 에러 표시 없이 사라져버리는 것이다.
• 여러 머신에서 수집된 로그들이 원인(cause)보다 결과(effect)를 앞에 배치할 수 있는데, 이는 문제 추적을 훨씬 더 어렵게 만든다.
• 올바른 순서에 의존하는 작업, 예컨대 어떤 변경을 승인한 이후에야 접근 권한을 부여해야 하는 작업이, 오래되어 낡은 정보를 기반으로 동작할 수 있다.

이 글에서는 다음의 아이디어들을 자세히 살펴본다.

• 왜 머신 자신의 시계가 이벤트 순서를 매기는 데 좋지 못한 근거인지, 그리고 동기화가 현실적으로 얼마나 가까이 이루어질 수 있는지
• 한 이벤트가 다른 이벤트보다 먼저 일어났다는 것이 무엇을 의미하는지, 그리고 왜 어떤 이벤트 쌍들은 정의된 순서를 갖지 않는지
• 논리적 시계(logical clocks)와 벡터 시계(vector clocks), 그리고 각각이 무엇을 판단할 수 있고 무엇을 판단할 수 없는지
• 이벤트 순서가 실제로 왜 중요한지 — 복제(replication), 감사(auditing), 디버깅의 관점에서
• 하이브리드 논리적 시계(hybrid logical clocks)와 그것이 해결하도록 설계된 문제
• Google Spanner와 같은 전 지구적 분산 데이터베이스가 대규모로 순서를 다루는 방식

(원문 이미지: 분산 시스템에서의 시계 동기화 개념도)

클록 드리프트(Clock Drift)

⚠️ 이 지점부터 원문은 유료 구독자 전용 페이월로 차단되어 있어, 이후 본문(클록 드리프트 상세 설명, 인과성/happens-before 관계, 논리적 시계·벡터 시계, 하이브리드 논리적 시계, Google Spanner 사례 등)은 확보하지 못했습니다.

핵심 요약 (20줄)

1. 단일 머신에서는 하나의 시계로 모든 이벤트 순서를 판단할 수 있어 순서에 의문의 여지가 없다.
2. 분산 시스템은 여러 독립된 머신에 작업이 흩어져 있어 공유되는 시간 기준점이 존재하지 않는다.
3. 각 머신의 하드웨어 시계는 서로 정렬 상태를 유지하지 못하고 시간이 지나며 어긋난다.
4. NTP(Network Time Protocol)는 시계를 맞추려 하지만 어긋남(clock drift) 자체를 완전히 없애지는 못한다.
5. 정확성이 사건 발생 순서에 의존하는 모든 상황에서 시계 어긋남은 실질적인 문제가 된다.
6. 타임스탬프 비교로 이벤트 순서를 매기면, 잘못된 방향의 작은 시계 오차가 결과를 뒤바꿀 수 있다.
7. 더 늦게 일어난 업데이트가 시계 오차 때문에 더 이른 타임스탬프를 가진 것으로 오인되어 폐기될 수 있다.
8. 이 경우 더 새로운 데이터가 아무런 에러 없이 조용히 사라지는 위험한 상황이 발생한다.
9. 여러 머신에서 모은 로그를 시간순으로 나열하면 원인보다 결과가 먼저 기록되는 일이 생길 수 있다.
10. 이는 장애 원인을 추적하는 디버깅 작업을 훨씬 더 어렵게 만든다.
11. 접근 권한 부여처럼 올바른 순서에 의존하는 작업은, 순서가 뒤틀리면 오래된(stale) 정보를 근거로 잘못 동작할 수 있다.
12. 이 글은 머신 자신의 시계가 왜 이벤트 순서 판단의 좋은 근거가 되지 못하는지를 다룰 예정이다.
13. 또한 현실적으로 시계 동기화가 어느 정도까지 가능한지도 함께 살펴본다.
14. 한 이벤트가 다른 이벤트보다 "먼저" 일어났다는 개념(happens-before)이 무엇을 의미하는지 설명한다.
15. 일부 이벤트 쌍은 애초에 정의된 선후 순서를 갖지 않는다는 점도 다룬다.
16. 논리적 시계(logical clocks)와 벡터 시계(vector clocks)가 각각 무엇을 판별할 수 있고 무엇을 판별할 수 없는지 비교한다.
17. 이벤트 순서가 복제(replication), 감사(auditing), 디버깅 실무에서 왜 중요한지를 다룬다.
18. 하이브리드 논리적 시계(hybrid logical clocks)가 어떤 문제를 해결하기 위해 고안되었는지 설명한다.
19. Google Spanner 같은 전 지구적 분산 데이터베이스가 대규모 환경에서 이벤트 순서를 어떻게 다루는지 사례로 소개한다.
20. 다만 이 글은 ByteByteGo 유료 구독자 전용 포스트로, 위 요약은 페이월 이전의 공개된 서론·개요 부분만을 근거로 작성되었다.