GitHub PR이 생성됐는데 목록에 안 보이는 버그

저번주 작업을 하는데 깃헙에서 이상한 오류가 발생했다. PR이 분명 생성됐는데 PR 탭을 클릭하면 아무것도 안보이는 것이다.

에이 설마 GitHub에서 오류가 나겠어? 내 컴퓨터 오류겠지~~ 쿠키, 캐시 다 지우고 해봐도 오류가 해결되지 않았고, 다른 개발자에게 질문하니 동일한 오류가 발생한다고 했다.

결론부터 말하자면 PR 하나를 머지하고 기다리니 자동으로 해결됐다.

이슈는 다음과 같았다

• PR 생성 후 PR 탭에 PR 숫자 노출
• PR 탭을 클릭시 생성된 PR은 보이지 않음
• 동일 PR 생성하려고 하면 기존에 열린 PR이 노출됨
• PR 세부 페이지로는 이동 가능

나만 겪은 게 아니었다

검색해보니 GitHub Community에 동일한 이슈가 올라온 게 확인됐고, 비슷한 시점에 같은 오류로 댓글을 단 사람들도 있었다. 깃헙 자체 이슈라는 것을 알게되었을 때 개발자로서 묘한 동질감이란.. (깃헙 자네도 실수란 것을 하는 구먼..껄껄). 이런 상황에서 GitHub Community 같은 곳에서 같은 시점에 같은 오류를 겪은 사람이 있는지 먼저 검색해보는 게 생각보다 훨씬 빠른 디버깅 방법이다.

https://github.com/orgs/community/discussions/193463

Cannot see all pull requests · community · Discussion #193463

 

 

예상되는 원인

그렇다면,, 원인은 무엇일까? 이렇게 대규모 리소스들이 모여있는 깃헙에서 이런 이슈가 발생하는 원인이 무엇일까 찾아봤다.

GitHub 같은 대규모 서비스는 단일 서버가 아니라 여러 역할의 서버가 분리되어 운영된다.

• 카운터 서버 — PR 탭의 숫자를 빠르게 보여주기 위해 별도 관리
• 인덱싱 서버 — PR 목록을 검색/조회하는 서버
• 원본 데이터 서버 — PR의 실제 데이터가 저장되는 서버

PR이 생성될 때 이 세 서버가 동시에 업데이트되지 않으면서 이번 증상이 발생한 것으로 추측된다.

증상 추측 원인

PR 탭에 숫자는 증가	카운터 서버는 정상 업데이트
PR 목록엔 노출 안 됨	인덱싱 서버가 아직 미동기화
PR 세부 페이지는 접근 가능	원본 데이터 서버엔 정상 저장
중복 PR 생성 시도 시 기존 PR 노출	중복 체크는 원본 서버 기준으로 동작

 

왜 세 서버가 동시에 업데이트되지 않는가

사실 이건 버그라기보다 애초에 동시에 업데이트하지 않도록 설계된 것일 가능성이 높다.

PR이 생성되면 GitHub 내부적으로는 아마 이런 흐름으로 동작할 것이다.

PR 생성 요청
    ↓
원본 데이터 서버에 저장 (1순위)
    ↓
메시지 큐에 이벤트 발행 ("PR 생성됨")
    ↓
카운터 서버, 인덱싱 서버가 큐를 소비하면서 각자 업데이트

즉, 카운터 서버와 인덱싱 서버는 원본 저장이 완료된 후 비동기로 업데이트된다. 그래서 아주 짧은 순간 동안 불일치가 생기는 건 사실 정상적인 동작이다. 보통은 너무 빠르게 처리되어서 우리가 눈치채지 못할 뿐이고.

그러면 이번엔 왜 한참 동안 안 맞았냐? 그 비동기 처리가 실패하거나 심하게 지연됐기 때문이다. 원인은 여러 가지를 추측해볼 수 있다.

• 인덱싱 서버 자체 장애 — 인덱싱 서버에 문제가 생겨서 큐에 쌓인 이벤트를 소비 못 하고 있는 상태
• 메시지 큐 지연 — 이벤트는 발행됐는데 처리가 밀려있는 상태. 트래픽이 갑자기 몰렸거나
• 배치 작업 실패 — 인덱싱을 실시간이 아닌 배치로 처리하는데 그 배치가 실패했거나 아직 실행 전인 상태

그리고 PR을 머지하고 나서 해결된 것도 여기서 힌트를 얻을 수 있다. 머지도 하나의 이벤트인데, 이 이벤트가 발생하면서 인덱싱 서버가 해당 레포지토리를 다시 동기화하는 트리거가 된 게 아닐까 싶다. 즉, 내가 머지를 한 게 아니라 머지가 일종의 재시도 버튼 역할을 해준 셈이다.

물론 GitHub 내부 구조를 직접 볼 수는 없으니 어디까지나 추측이다. 하지만 가장 가능성 높은 시나리오는 인덱싱 서버나 메시지 큐 쪽에서 일시적인 장애나 지연이 발생한 것으로 보인다.

 

Eventual Consistency (최종 일관성)

이 현상을 이해하려면 분산 시스템에서 자주 등장하는 개념인 Eventual Consistency(최종 일관성) 를 알면 좋다. 한 마디로 "지금 당장은 다를 수 있지만, 결국엔 맞아진다" 는 설계 철학이다.

 

여기서 잠깐, 왜 GitHub 같은 서비스는 모든 서버를 항상 딱 맞게 유지하지 않는 걸까? 이걸 이해하려면 분산 시스템의 유명한 원칙인 CAP 정리를 알면 좋다.

CAP 정리란, 분산 시스템은 아래 세 가지를 동시에 모두 만족할 수 없다는 이론이다.

• C (Consistency, 일관성) — 모든 서버가 항상 동일한 데이터를 보여준다
• A (Availability, 가용성) — 요청하면 항상 응답을 받을 수 있다
• P (Partition Tolerance, 분단 내성) — 서버 간 네트워크에 문제가 생겨도 시스템은 계속 동작한다

셋 중 하나는 포기해야 한다. GitHub처럼 전 세계 트래픽을 처리하는 서비스는 C보다 A를 선택한다. 즉, 데이터가 잠깐 안 맞더라도 일단 빠르게 응답하는 것을 우선시하는 것이다. 그 대신 시간이 지나면 결국 모든 서버의 데이터가 맞춰지도록 설계하는데, 이게 바로 Eventual Consistency다.

 

실생활로 비유하자면, 친구에게 카카오톡 메시지를 보냈는데 상대방 화면엔 아직 안 뜨는 그 찰나의 순간과 비슷하다. 서버엔 이미 저장됐지만 상대방 기기까지 전달되는 데 약간의 시간이 걸리는 것처럼, 분산 시스템도 서버 간 동기화에 약간의 시간차가 존재한다.

이번 GitHub 케이스도 마찬가지다. PR 하나를 머지한 후 자연스럽게 해결된 것도 이 맥락과 맞아떨어진다. 머지 이벤트가 트리거되면서 밀려있던 서버 간 동기화가 완료된 것으로 보인다. 즉, 기다리면 결국 맞아진다는 Eventual Consistency가 실제로 동작한 셈이다.

 

결론

이번 GitHub 오류가 왜 발생했을까 가볍게 고민하면서 어떻게 서버가 구성되어 있을지 상상해봤는데, 이 과정 자체가 꽤 재밌었다.

특히 GitHub 자체 이슈라는 걸 알게 됐을 때 드는 생각은

아 깃헙 자네도 실수란 것을 하는구먼 ^_^

엄청난 리소스와 수많은 엔지니어가 있는 GitHub에도 이런 버그가 있다는 게 신기하기도 하고, 동시에 묘한 동질감이 들었다. 많은 사람이 사용한다고 해서 버그가 발생하지 않는 건 아니다. 결국 사람이 만드는 것이니까.

이런 상황에서 느낀 점이 있다면, 혼자 끙끙대다가 빠르게 커뮤니티에서 같은 오류를 겪은 사람이 있는지 먼저 찾아보자! 생각보다 훨씬 빠르게 "나만 그런 게 아니구나" 를 확인할 수 있고, 내 기기/코드 결함이 아니라는 것도 바로 알 수 있다.