GitHub 의 43초 네트워크 단절은 왜 24시간 장애가 됐나

2018년 10월, GitHub 의 두 데이터센터를 잇는 네트워크가 43초 동안 끊겼다. 광케이블을 교체하던 중이었고, 43초 뒤엔 정상으로 돌아왔다.

그런데 서비스는 24시간 넘게 정상이 아니었다. 원인이었던 네트워크 문제는 1분도 안 돼 사라졌는데도.

43초와 24시간. 이 격차가 계속 마음에 걸린다.

장애의 크기는 원인의 크기를 따라가지 않는다. 원인이 사라진 다음에 무슨 일이 벌어지느냐가 훨씬 중요하다.

그리고 하필 그 부분이 설계에서 빠져 있기 쉽다. 정상 동작은 매일 검증받는데, 회복은 정말 필요한 순간이 오기 전까지 아무도 시험해 보지 않으니까.

43초가 24시간으로 늘어나는 길

짧은 단절이 긴 장애로 번지는 데는 정해진 길이 있다.

시작은 자동 대응이 그 짧은 순간에 결정을 내려 버리는 데서다. 장애 감지 도구는 몇 초 안에 판단하도록 맞춰져 있다. 그래야 진짜 장애에 빨리 대응하니까. 그런데 43초는 그 기준을 넘고도 남는 시간이다. 자동화가 "저쪽이 죽었다"고 판단하고 전환을 시작한다.

문제는 전환을 되돌리기 어렵다는 점이다. 데이터베이스 주 노드를 다른 쪽으로 바꾸면 그때부터 새 주 노드에 쓰기가 쌓인다. 원래 주 노드에도 전환 직전까지의 쓰기가 남아 있다. 네트워크가 돌아오면 양쪽에 서로 다른 데이터가 있는 상태가 된다.

이 상태를 푸는 건 사람 몫이다. 어느 쪽이 맞는지, 무엇을 버리고 무엇을 살릴지는 자동으로 정할 수가 없다. 데이터 정합성이 걸려 있으니 신중해야 하고, 그래서 오래 걸린다.

그동안 서비스는 안전한 쪽을 택한다. 데이터가 갈렸을 수 있으면 쓰기를 막고 읽기만 열어 두는 식이다. 사용자 눈엔 장애로 보인다. 하지만 이건 옳은 선택이다.

그렇게 43초의 물리적 단절이 24시간의 데이터 정합성 작업이 됐다. 그 시간 대부분은 복구가 아니라 판단과 검증에 들어갔다.

짧은 단절에 서두르지 않게

짧은 단절에 성급히 반응하지 않는다:

코드

· 자동 전환의 판단 기준을 신중하게
✕ 몇 초 만에 전환 → 짧은 단절에도 반응한다
✓ 여러 관측 지점에서 합의될 때만 전환
✓ 전환 전에 최소 관찰 시간을 둔다

· 양쪽이 서로를 주 노드로 여기는 걸 막는다
✓ 과반수 합의 또는 외부 중재자
✓ 확신이 없으면 쓰기를 멈춘다 (안전한 쪽)

· 되돌리는 절차를 미리 정해 둔다
✓ 어느 쪽 데이터를 기준으로 삼을지
✓ 갈린 쓰기를 어떻게 병합·폐기할지
✕ 장애 중에 이걸 처음 논의하면 시간이 배로 든다

✕ 문제 지점 · ✓ 해법 · 그대로 돌리기 전에 자기 환경에 맞게 고친다.

죽은 것과 느린 것은 구별할 수 없다

이 사고에서 가져갈 게 몇 가지 있다.

자동화의 판단 기준이 너무 예민하면 안 된다. 빨리 대응한다고 늘 좋은 게 아니다. 되돌리기 어려운 조치일수록 판단은 더 신중해야 한다. 전환처럼 데이터에 손대는 조치라면 몇 초가 아니라 더 긴 관찰이 필요하다.

관측 하나만 믿고 판단해서도 안 된다. A 에서 B 가 안 보인다고 B 가 죽은 건 아니다. 네트워크가 끊긴 걸 수도 있다. 그렇다면 B 쪽에서 보면 죽은 건 A 다. 여러 지점이 합의해야 오판이 준다.

여기서 근본적인 한계에 부딪힌다. 비동기 네트워크에서는 "죽은 것"과 "느린 것"을 확실하게 구별할 수 없다. 구현을 잘못해서가 아니라 증명된 한계다. 그러니 모든 장애 감지는 오판 가능성을 품고 있고, 설계는 그 전제 위에서 해야 한다.

이걸 받아들이면 선택이 또렷해진다. 확신이 없을 때 무엇을 할 것인가? 쓰기를 계속 받으면 데이터가 갈릴 위험이 있고, 멈추면 서비스가 중단된다. 어느 쪽이 나은지는 서비스 성격에 달렸다. 다만 정하지 않으면 최악을 고르게 된다.

복구 절차를 미리 준비해 두는 것도 크다. 데이터가 갈렸을 때 어떻게 합칠지를 장애 한복판에서 처음 논의하면 시간이 배로 든다. 미리 정하고 연습까지 해 뒀다면 24시간이 몇 시간으로 줄 수도 있다.

이런 사고에서 배울 수 있는 건 회고를 공개하는 조직 덕분이다. 남의 사고에서 배우는 게 내 사고로 배우는 것보다 훨씬 싸다.

우리 쪽 전환 설정에서 손볼 것

자동 전환의 판단 기준부터 다시 본다. 몇 초 만에 결정하게 돼 있다면 짧은 단절에도 반응한다.
한쪽에서 안 보인다고 죽은 게 아니다. 여러 관측 지점의 합의를 요구하자.
되돌리기 어려운 조치일수록 판단이 신중해야 한다. 전환이 대표적이다.
확신이 없을 때 쓰기를 멈출지 계속 받을지는 서비스마다 다르다. 다만 미리 정해 둬야 한다.
데이터가 갈렸을 때의 복구 절차를 문서로 만들고 연습한다. 장애 중에 처음 논의하면 시간이 배로 든다.
짧은 단절은 생각보다 흔하다. 실제로 얼마나 자주 일어나는지 재 보자.
자동화가 무엇을 했는지 기록이 남아야 한다. 왜 그런 판단을 했는지 나중에 알 수 있게.
남의 장애 회고는 찾아서 봐 둔다. 내 사고로 배우는 것보다 훨씬 싸다.
감지의 민감도는 조치의 성격에 맞춰 달리 잡는다. 되돌리기 쉬운 조치는 예민하게, 어려운 조치는 둔하게.

우리는 43초를 버틸 수 있을까

우리는 43초를 어떻게 다루는가:

코드

· 자동 전환의 판단 기준을 확인한다
✓ 몇 초 만에 결정하는가
✓ 몇 개의 관측 지점이 합의해야 하는가
✕ 하나의 관측으로 전환한다면 위험하다

· 짧은 단절이 실제로 얼마나 자주 있는지 재 본다
✓ 노드 간 연결 실패의 지속 시간 분포
✓ 수십 초짜리 단절은 생각보다 흔하다

· 데이터가 갈렸을 때의 절차가 있는가
✓ 문서가 있는가 · 연습해 봤는가 · 언제 마지막으로 했는가

· 자동화의 판단 기록이 남는가
✕ 왜 그런 결정을 했는지 사후에 알 수 없으면
✕ 같은 일이 또 일어난다

핵심 한 줄장애의 크기는 원인의 크기와 비례하지 않는다.