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 의 부하가 늘어 데이터베이스 프록시가 최대 연결 수에 닿았다.
감지
–
조치
- 정상인 복제본으로 페일오버해 3월 16일 장애에서 복구했다.
- 3월 17일 미리 한 페일오버 뒤 새 주 노드에 생긴 연결 문제를 풀려고 연결을 재설정했다.
- 3월 17일 장애 중에 부하 패턴을 찾아 인덱스를 추가해 주된 성능 문제를 고쳤다.
- 3월 22일 클라이언트 연결이 실패하자 다시 주 노드를 페일오버해 복구했다.
- 3월 23일 같은 부하 특성으로 클라이언트 연결이 실패하자 다시 주 노드를 페일오버해 복구했다.
- 3월 23일 부하를 줄이려고 웹훅 트래픽을 제한했다.
후속 조치
- 다른 대책을 더 찾는 동안 최대 부하 시간대에 웹훅 트래픽 제한을 계속 써서 같은 장애가 다시 나지 않게 한다.
- 최대 부하 시간대의 mysql1 부하 패턴을 점검하고, 그 결과에 따라 성능 수정을 차례로 한다.
- 부하를 줄이고 페일오버 시간을 줄이려고 mysql1 의 트래픽을 다른 데이터베이스로 옮긴다.
- 변경 관리 절차를 검토한다. 특히 운영 환경에 부하가 높을 때의 모니터링과 변경을 살핀다.
- 플랫폼 성장에 맞춰 데이터베이스 샤딩과 하드웨어 확장을 비롯한 인프라 확장을 이어 간다.
교훈
–
출처
관련 사례
IL-0312max_connections 를 올리려고 재시작한 주 PostgreSQL 데이터베이스가 다시 올라오지 않아 Gadget 의 모든 앱 요청이 멈췄다Gadget · 2024같은 원인 · 공통 데이터베이스, 데이터베이스 프록시와 커넥션 풀러
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0288CDN77 의 ClickHouse 데이터 파이프라인에서 이중화된 인스턴스 세 곳의 ZooKeeperWait 가 수천 초로 치솟아 복제가 한 시간 넘게 느려졌다CDN77 · 2026같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0305Intercom 의 PlanetScale 샤드 하나에서 복제본이 CPU 100% 로 주 데이터베이스를 따라가지 못해 받은편지함에 최대 2.2시간 전의 데이터가 보였다Intercom · 2026같은 원인 · 공통 데이터베이스
IL-0390PostHog US Cloud 의 Persons Postgres 데이터베이스 쓰기가 크게 느려져 이벤트와 persons 수집이 최대 2일 지연됐다PostHog · 2025같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0287Atlas 와 Cloud Manager 의 모니터링을 받치는 내부 데이터베이스 클러스터의 샤드 하나가 과부하되어 지표 수집과 클러스터 작업이 늦어졌다MongoDB · 2025같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0298Wikimedia sessionstore 의 Cassandra 노드가 디스크가 가득 차 잇따라 죽고 쿼럼을 잃어 편집이 실패했다Wikimedia Foundation · 2025같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0110Grafana Agent 파드가 메모리를 많이 쓰던 노드에 Hangfire 파드가 함께 올라가 시스템 OOM 으로 CrashLoopBackOff 를 반복했고, 노드가 응답을 멈추고 NotReady 가 됐다.DFDS · 2024같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0202갑자기 몰린 쿼리와 데이터베이스 쓰기로 Honeycomb 수집 호스트가 메모리 부족으로 죽었고, 쿠버네티스 CrashLoopBackOff 가 용량 회복을 막아 US1 이벤트 수집이 한 시간 넘게 불안정했다Honeycomb · 2023 · sev1같은 원인 · 공통 데이터베이스
IL-0386Google Cloud 로 옮긴 뒤 GKE 노드에서 Postgres 연결 타임아웃과 memcached i/o timeout 이 간헐적으로 튀었다incident.io · 2023같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0206GKE 파드 안의 Consul 에이전트가 메모리 급증으로 거듭 OOM kill 되어 Rails 파드가 데이터베이스 복제본을 찾지 못했고, 모든 쿼리가 primary 로 몰려 GitLab.com 이 느려졌다.GitLab · 2022같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0496전역 복제 Cassandra 클러스터에서 모든 리전의 인스턴스 CPU 가 100% 로 치솟아 쿼리가 타임아웃됐고, 같은 부하가 이틀 저녁 더 찾아왔다Ably · 2020같은 원인 · 공통 데이터베이스
IL-0443Aurora MySQL reader 가 이유 없이 재시작한 뒤 writer 의 insert latency 가 7배쯤 오르고 replication lag 가 하루 넘게 이어졌다Repro · 2019같은 원인 · 공통 데이터베이스
IL-0037imagePullPolicy가 Always인 DaemonSet이 크래시 루프를 돌며 이미지를 계속 받아, NAT 세 대를 같이 쓰던 리전 전체가 이미지 레지스트리에서 429로 막혔다Datadog · 2019같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0211Mandrill 의 PostgreSQL 샤드 하나가 트랜잭션 ID 랩어라운드를 막으려고 쓰기를 멈춰 약 40시간 동안 메일 발송이 줄었다Mailchimp · 2019같은 원인 · 공통 데이터베이스
IL-0064CPU 를 많이 쓰는 파드가 Google Cloud 노드 하나에 몰려 노드가 커널 패닉으로 죽었고, 다시 배치된 파드가 다음 노드를 또 죽이며 웹사이트와 API 가 멈췄다.Moonlight · 2019같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0334RDS MySQL 의 bookmarks 테이블이 2TB 파일 크기 한도에 닿아 INSERT 가 실패하고 Instapaper 가 31시간 동안 멈췄다Instapaper · 2017같은 원인 · 공통 데이터베이스
IL-0333사양을 낮춘 RDS PostgreSQL 인스턴스가 피크 부하를 못 버텨 헬스 체크가 실패하고 Buildkite 대시보드가 몇 시간 동안 내려갔다Buildkite · 2016같은 원인 · 공통 데이터베이스
IL-0282US-East 리전의 DynamoDB 스토리지 서버들이 멤버십 정보를 받지 못해 스스로 요청 처리에서 빠지면서 고객 요청의 약 55% 가 실패했다Amazon Web Services · 2015같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0302
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0302/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.