[5주차] 요약..

[myeongjae-kim]

• It found that adding redundant networking gear doesn’t reduce faults as much as you might hope, since it doesn’t guard against human error (e.g., misconfigured switches), which is a major cause of outages.
  • 사람이 문제다.. 여분의 장비를 놔두더라도 그렇게 에러가 많이 줄진 않았다.

신뢰할 수 없는 네트워크

패킷에 딜레이가 발생하는 이유

패킷에 딜레이가 발생하는 이유는 보통 queueing 때문이다

• network switch에서 하나의 링크에 많은 패킷이 몰리면 queue로 줄세우고, queue용량을 넘어가면 그냥 버린다.
• 패킷이 목적지에 도달해도 목적지의 CPU코어에 여유가 없으면 request는 OS에 의해서 queue로 줄세워진다. 처리할 때까지 얼마나 시간이 걸릴지 모름.
• 가상화때문에 발생하는 딜레이도 있음. 수십 ms 수준
• TCP의 혼잡제어(flow control, congestion avoidance, backpressure) 때문에도 딜레이가 생김
• TCP는 타임아웃이 있으므로 타임아웃을 넘어가도록 응답을 못받으면 패킷을 다시 보낸다. 애플리케이션이 패킷을 잘 받았더라도 다시 보낸 패킷을 받을 때까지 연결은 끊기지 않으므로 딜레이가 생김

여럿이서 같이 쓰는 클라우드는 온갖 이유로 딜레이가 발생할 수 있으므로 실험을 통해서 어느정도 딜레이가 발생하는지 알아내야 한다.

동기 vs 비동기

동기식으로 뭔가를 하면 최대 딜레이를 보장할 수 있지만 처리량이 낮다. 비동기로 뭔가를 하면 처리량이 높아지는 대신 최대 딜레이를 보장할 수 없다.

딜레이는 리소스 활용의 관점에서도 생각할 수 있음.

Latency guarantees are achievable in certain environments, if resources are statically partitioned (e.g., dedicated hardware and exclusive bandwidth allocations). However, it comes at the cost of reduced utilization—in other words, it is more expensive. On the other hand, multi-tenancy with dynamic resource partitioning provides better utilization, so it is cheaper, but it has the downside of variable delays.

Variable delays in networks are not a law of nature, but simply the result of a cost/ benefit trade-off.

현재는 네트워크가 최대 딜레이 보장을 해줄 수 없다.

Currently deployed technology does not allow us to make any guarantees about delays or reliability of the network: we have to assume that network congestion, queueing, and unbounded delays will happen.

신뢰할 수 없는 시계

Monotonic Versus Time-of-Day Clocks

• Monotonic clock은 절대 시간이 뒤로 돌아가지 않는다. 시간이 얼마나 지났는지 측정할 때 사용함.
• Tme-of-Day clock은 현재 시간이 필요할 때 사용함. sync를 맞추다보면 시간이 뒤로 돌아갈 수도 있다.

�
Network Time Protocol (NTP)를 통해서 시간을 동기화함. NTP 서버에서도 정확한 시간을 주지 못할 수 있으므로 클라이언트는 여러 NTP서버를 사용해서 가장 확률이 높은 시간으로 동기화를 해야 한다.

NTP 동기화도 네트워크 딜레이를 넘어설 수는 없음. 인터넷을 통해서 동기화하면 아무리 줄여도 35ms의 차이가 발생한다.

윤초.. 열받네

가상화된 상태에서는 VM자체가 멈췄을 때 시간도 같이 멈춰버린다. 애플리케이션 입장에서는 시간이 갑자기 앞으로 점프한 것처럼 느끼게 됨.

Logical clock

이벤트들의 순서를 정확히 알아야 할 때는 logical clock을 사용하면 된다.

So-called logical clocks [56, 57], which are based on incrementing counters rather than an oscillating quartz crystal, are a safer alternative for ordering events (see “Detecting Concurrent Writes” on page 184). Logical clocks do not measure the time of day or the number of seconds elapsed, only the relative ordering of events (whether one event happened before or after another). In contrast, time-of-day and monotonic clocks, which measure actual elapsed time, are also known as physical clocks. We’ll look at ordering a bit more in “Ordering Guarantees” on page 339.

Logical clock은 이벤트들의 순서만 안다. 현실의 시간(time-of-day clock)이나 흐른 시간(monotonic clock)과는 완전히 다른 종류. 이 둘을 합쳐서 Physical clock이라고도 부름.

시간과 신뢰구간

보통의 컴퓨터가 어떤 한 순간의 정확한 시간을 아는 것은 불가능하다. 따라서 시간을 정확히 표현하려면 시간의 구간과 그 구간이 얼마만큼의 신뢰도를 갖는지로 표현해야 한다. 하지만 대부분의 시스템은 시간을 구간으로 표현하지 않음.

Spanner에는 구글이 만든 TrueTime API가 있다. 시간을 구간으로 표현함

An interesting exception is Google’s TrueTime API in Spanner [41], which explicitly reports the confidence interval on the local clock. When you ask it for the current time, you get back two values: [earliest, latest], which are the earliest possible and the latest possible timestamp. Based on its uncertainty calculations, the clock knows that the actual current time is somewhere within that interval. The width of the interval depends, among other things, on how long it has been since the local quartz clock was last synchronized with a more accurate clock source.

글로벌 스냅샷을 위해 동기화된 시계

DB에서 높은 격리 수준(repeatable read, serializable)을 구현하게 위해 snapshot isolation 기법을 사용함. 이 때도 시간이 중요하다. 트랜잭션이 언제 시작했는지에 따라서 보여줘야 할 DB의 상태가 다르므로.

대부분의 snapshot isolation 구현에서 monotonic하게 증가하는 transaction ID가 필요하다.

싱글 머신일 때는 어찌저찌 해도 분산 DB는 골치아파짐. transaction ID를 한 곳에서 만들게 되면 병목 지점이 되어버린다. 시간은 신뢰할 수 없으므로 골치아프다.

Spanner는 시간을 구간으로 표현해서 분산 DB의 snapshot isolation을 구현했다.

if you have two confidence intervals, each consisting of an earliest and latest possible timestamp (A = [Aearliest, Alatest] and B = [Bearliest, Blatest]), and those two intervals do not overlap (i.e., Aearliest < Alatest < Bearliest < Blatest), then B definitely happened after A—there can be no doubt. Only if the intervals overlap are we unsure in which order A and B happened.

트랜잭션을 커밋할 때도 시간의 신뢰구간을 충분히 벗어날 때까지 약간 기다린다

In order to ensure that transaction timestamps reflect causality, Spanner deliberately waits for the length of the confidence interval before committing a read-write trans‐ action.

프로세스 멈춤

분산 DB에서 leader가 자신이 leader인지 어떻게 확신할 수 있을까?

리스(lease)를 획득해야만 리더로 인정받는 방식을 사용할 수 있다. 최대 하나의 node만 lease를 가질 수 있다.

이 때 자신이 lease를 가졌는지 판단하는 로직을 수행하는 도중에 온갖 이유로 프로세스가 멈출 수 있고 그러다가 오류가 생길 수 있음. GC에서 발생하는 딜레이나 페이지 스왑에서 발생하는 딜레이 등등등등...

응답시간 보장

real-time 시스템은 응답시간을 보장하는 대신 처리량이 낮다.

GC 영향 줄이기

지식, 진실, 거짓

분산 node들은 위원회를 구성해서 누가 leader인지 판단함. 정족수를 채워야 인정받을 수 있다.

fencing token을 사용해서 자신이 leader인줄 잘못 알고 있는 노드의 요청을 판단할 수 있음.

비잔틴 장군 문제

두 명의 장군이 멀리 있을 때 서로 소통하면 발생하는 온갖 문제들..

---

할 수 있으면 최대한 분산하지 말고 싱글 노드에서 처리하도록 하는게 낫다.

[wbluke]

• 성훈 : 우리가 인터넷 서비스하는데 서킷을 왜 못만드는지 - 인터넷 패킷은 고용량을 처리하는데 서킷을 만들면 저용량/고용량일 때 여러 문제가 생김
• 명재 : '삼체'라는 SF 소설이 있는데, 빛이 과거보다 훨씬 느리다고 가정함. 빛이 더 빨랐다면 딜레이도 안생겼을텐데..

[wbluke]

• 성훈 : Logical clock 이라는 것은 이를테면 트랜잭션 ID 같은 것

[wbluke]

• 명재 : 시간과 신뢰구간. 시간에 확률과 통계 개념을 적용한게 신선함
  • 우주에서 10광년 떨어진 곳은 10년 전 과거에 일어난 일이 아니라, 같은 현재이고 시간의 구간이 늘어났을 뿐이라는 주장