Incident Library

IL-0302 GitHub · 2022-03-16database

GitHub 의 공용 MySQL 클러스터 mysql1 이 최대 부하 시간대에 연결이 바닥나 쓰기 작업이 네 번 멈췄다

2022년 3월 몇 주 동안 GitHub 은 mysql1 클러스터의 자원 경합 때문에 여러 번 장애를 겪었다. mysql1 은 여러 서비스가 함께 쓰고 읽기와 쓰기 트래픽이 모두 많은 MySQL 클러스터였고, 하나의 주 노드가 쓰기를 받고 나머지 복제본 노드가 읽기를 맡는 구성이었다. 3월 16일 14:09 UTC 에 최대 부하 시간대의 부하가 늘면서 데이터베이스 프록시가 최대 연결 수에 닿았고, git 작업과 웹훅과 풀 리퀘스트를 비롯한 모든 쓰기 작업이 5시간 36분 동안 멈췄다. GitHub 은 최대 부하와 특정 상황의 나쁜 쿼리 성능이 겹친 것으로 보았고, 정상인 복제본으로 페일오버해 복구했다.

3월 17일 13:46 UTC 에 같은 최대 부하 패턴이 다시 왔다. GitHub 은 문제가 커지기 전에 미리 페일오버했다. 그런데 이 페일오버가 새 부하 패턴을 만들어 새 주 노드에 연결 문제가 생겼고, 연결을 재설정하는 동안 애플리케이션이 mysql1 에 연결하지 못했다. 이 장애는 2시간 28분 이어졌고, GitHub 은 이때 부하 패턴을 찾아 인덱스를 추가해 주된 성능 문제를 고쳤다. 3월 22일 15:53 UTC 에는 성능을 더 분석하려고 데이터베이스 프록시에 메모리 프로파일링을 켰다. 같은 때에 클라이언트 연결이 실패하기 시작했고, 다시 주 노드를 페일오버해 복구했다. 이 장애는 2시간 53분 이어졌다. 3월 23일 14:49 UTC 에도 같은 부하 특성이 다시 나타났다. 이번에도 페일오버로 복구했고, 장애는 2시간 51분 이어졌다. 이날 GitHub 은 부하를 줄이려고 웹훅 트래픽을 제한했다.

심각도
–
영향 범위
Write operations on GitHub, including git operations, webhooks, pull requests, API requests, issues, GitHub Packages, GitHub Codespaces, GitHub Actions and GitHub Pages, on March 16, 17, 22 and 23, 2022
영향 사용자
–
지역
–
감지까지
–
복구까지
5h 36m

증상

2022년 3월 16일 14:09 UTC, 최대 부하 시간대에 mysql1 데이터베이스의 부하가 늘면서 데이터베이스 프록시가 최대 연결 수에 닿았다. GitHub 의 모든 쓰기 작업이 동작하지 않았다.

멈춘 쓰기 작업에는 git 작업, 웹훅, 풀 리퀘스트, API 요청, 이슈, GitHub Packages, GitHub Codespaces, GitHub Actions, GitHub Pages 가 들어 있었다. mysql1 은 여러 서비스가 함께 쓰고 읽기와 쓰기 트래픽이 모두 많은 데이터베이스였다.

같은 모습이 3월 17일 13:46 UTC, 3월 22일 15:53 UTC, 3월 23일 14:49 UTC 에 다시 나타났다. 3월 17일에는 같은 최대 부하 패턴이 다시 오자 GitHub 이 문제가 커지기 전에 미리 페일오버했다. 그런데 이 페일오버가 새 부하 패턴을 만들어 새 주 노드에 연결 문제가 생겼고, 애플리케이션은 다시 mysql1 에 연결하지 못했다. 3월 22일과 23일에는 mysql1 로 가는 클라이언트 연결이 실패했다.

GitHub 은 처음에 이 장애가 최대 부하에 특정 상황의 나쁜 쿼리 성능이 겹친 결과라고 보았다. 그래서 최대 부하 때의 트래픽 패턴과 쿼리 성능을 조사했지만, 3월 17일의 최대 부하 전까지 쿼리 성능 문제를 짚어 내 고치지 못했다. 3월 22일에는 최대 부하 때의 성능 특성을 자세히 보려고 데이터베이스 프록시에 메모리 프로파일링을 켰고, 같은 때에 클라이언트 연결이 실패하기 시작했다.

증상 쓰기 거부데이터베이스 과부하오류율 상승장애 조치 실패

원인

촉발
최대 부하 시간대에 공용 MySQL 클러스터 mysql1 의 부하가 늘어 데이터베이스 프록시가 최대 연결 수에 닿았다.

감지

–

조치

후속 조치

교훈

–

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 데이터베이스, 데이터베이스 프록시와 커넥션 풀러. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.