测验：日志来自未来

네 서버의 로그를 시간순으로 합쳤더니 한 서버의 모든 줄이 다른 서버들보다 일정하게 앞서 있었다. 가장 먼저 세워야 할 가설은?

• 그 서버의 애플리케이션이 로그를 비동기로 쌓다가 순서를 잃었다
• 그 서버의 시계가 나머지와 어긋나 있어 모든 줄이 같은 크기로 밀렸다
• 그 서버에만 요청이 몰려 처리 지연이 커진 탓에 시각이 밀렸다
• 로그 수집기가 그 서버의 파일만 다른 순서로 읽어 들였다

RFC 5905 의 theta = 1/2 * [(T2-T1) + (T3-T4)] 에서 두 항을 더해 반으로 나누는 이유는?

• 두 번 잰 값을 평균 내어 측정 잡음을 줄이기 위해서다
• 왕복 지연을 구한 뒤 그 절반을 편도 지연으로 삼기 위해서다
• 두 항에 반대 부호로 들어 있는 네트워크 지연이 상쇄되고 시계 차이만 남기 때문이다
• 밀리초 단위를 초 단위로 맞추기 위한 단위 환산 때문이다

왕복 네 시각으로 오차를 잴 때 표본 하나가 아니라 여러 표본의 중앙값을 쓰는 이유는?

• 가는 편과 오는 편의 지연이 달라 표본 하나마다 그 차이의 절반만큼 틀리기 때문이다
• 네 시각 중 하나가 기록되지 않는 경우가 흔해 빠진 값을 메워야 하기 때문이다
• 중앙값을 쓰면 시계 오차가 시간에 따라 변하는 속도를 함께 구할 수 있기 때문이다
• 표본이 많을수록 네트워크 지연 자체가 줄어들어 추정이 정확해지기 때문이다

시계가 어긋난 것을 알아낸 뒤, 그 서버의 원본 로그를 어떻게 다루는 것이 맞나?

• 보정한 시각으로 파일을 다시 써서 이후 조사가 헷갈리지 않게 한다
• 그 서버의 로그는 신뢰할 수 없으므로 조사 대상에서 빼고 나머지로 판단한다
• 시계를 맞춘 뒤 같은 구간을 다시 재현해 새 로그로 갈아 끼운다
• 원본은 그대로 두고 오차를 기록해 읽을 때 보정한다

컨테이너 환경에서 시계 오차가 특히 헷갈리게 나타나는 이유는?

• 컨테이너마다 독립된 시계를 갖고 있어 파드 단위로 제각각 어긋나기 때문이다
• 컨테이너는 호스트 커널의 시계를 그대로 보므로 한 노드에 뜬 파드가 통째로 함께 어긋나기 때문이다
• 컨테이너 런타임이 로그를 모을 때 시각을 다시 찍어 원본 시각을 잃기 때문이다
• 컨테이너 이미지마다 시간대 데이터베이스 판이 달라 오프셋 해석이 갈리기 때문이다

시계가 어긋나도 사건의 순서를 복원할 수 있게 만드는 기록 습관은?

• 모든 서버의 로그를 한 곳에 모아 수집기가 도착 순서대로 번호를 매긴다
• 시각을 밀리초가 아니라 마이크로초까지 적어 해상도를 높인다
• 요청 아이디와 인과 사슬을 함께 남겨 순서를 시각에만 맡기지 않는다
• 각 서버가 시각을 적기 직전에 NTP 서버에 한 번씩 물어본다