사례2건

2건 중 1~2번째

1. IL-0366 us-central1 의 Cloud Storage 업로드와 쓰기가 이틀에 걸쳐 18시간 넘게 느려지고 실패했다

   Google Cloud2026

   증상

   us-central1 리전에서 Cloud Storage 업로드와 쓰기 요청의 지연과 오류율이 올라갔다. 고객은 주로 WriteObject 작업에서 HTTP 503 UNAVAILABLE 오류와 클라이언트 쪽 타임아웃을 봤다.

   지연 시간 증가오류율 상승부하 불균형

   촉발

   Cloud Storage 부하 분산 계층에 트래픽 정렬 최적화 설정 업데이트가 배포됐다. 이 설정은 용량을 보고 경로를 정하는 표준 로직을 의도치 않게 건너뛰었다.

   원인

   설정 변경

   구성 요소

   오브젝트 스토리지데이터베이스

   기여 요인

   여유 용량 부재장애 중첩

   감지

   Google 엔지니어링 팀이 시스템 텔레메트리를 지켜보다가 10월 8일 04:50에 문제를 처음 알아챘다. 장애가 시작되고 50분 뒤였다.

   조치

   • 부하가 가장 큰 스토리지 백엔드 노드를 골라 트래픽을 뺐다.
   • 트래픽 정렬 최적화를 끄는 설정 변경을 배포해 스토리지 백엔드의 자원 부담을 크게 줄였다.
   • 같은 시기에 난 메타데이터 문제를 막으려고 메타데이터 데이터베이스 서비스의 최근 업데이트를 롤백했다.
   • 부하 불균형이 다시 일어나자 트래픽을 더 돌리고 영향받은 스토리지 구성 요소에서 트래픽을 뺐다.
   • 문제의 부하 분산 설정 변경을 완전히 되돌려 용량을 보고 경로를 정하던 이전 동작을 되살렸고, 트래픽이 리전 전체에 고르게 퍼졌다.
   • 트래픽과 자원 사용률이 평소 수준으로 돌아온 뒤 트래픽을 뺐던 노드를 다시 서비스에 넣었다.

   후속 조치

   • 부하 분산 로직 변경은 사용률이 높은 큰 리전에 내보내기 전에 더 작은 다른 리전에서 먼저 엄격하게 검증하도록 배포 절차를 바꾼다.
   • 스토리지 부하 분산 구조가 용량 제약을 반드시 지키게 한다. 트래픽 분배 로직이 Google 이 pre-spilling 이라고 부르는 안전장치를 건너뛰어 처리 자원이 모자란 클러스터로 트래픽을 보내는 일이 없게 한다.
   • 사용률이 높은 스토리지 셀 안의 내부 데이터 이동을 빠르게 해, 일시적인 부하 급증을 더 잘 견디게 한다.

   사례 보기
2. IL-0566 쿠키런: 킹덤 길드 업데이트 직후 CockroachDB 노드 몇 대에 부하가 몰려 CPU가 100%에 이르고 게임에 에러가 났다

   Devsisters2021

   증상

   2021년 3월 6일 11시 길드 업데이트 점검을 마친 뒤 데이터베이스 CPU 사용량이 예상보다 조금 높았다. 11시 30분쯤 24코어 머신인 데이터베이스 노드 하나가 24코어를 모두 쓰며 CPU 사용량이 최대치에 이르렀고, 같은 시각 서버 지표에서 상당한 양의 에러가 보이기 시작했다. 곧 다른 두 노드에서도 CPU 사용량 이상이 나타났다.

   부하 불균형데이터베이스 과부하오류율 상승

   촉발

   길드 업데이트 점검 뒤 서비스를 열자 모든 유저가 곧바로 새 기능을 썼고, 분석용 테이블에 guild-<uuid> 형식의 Primary Key가 매우 빠르게 쓰였다. 리팩토링으로 Primary Key 형식이 바뀐 테이블도 있었다.

   원인

   배포 결함

   구성 요소

   데이터베이스

   기여 요인

   미검증 가정장애 중첩

   감지

   모니터링 중 한 노드의 CPU 사용량이 최대치에 이르렀다는 소식과 함께 서버 지표에서 에러가 관측돼 알았다. 이후 노드 문제는 Host Status Check 실패 슬랙 알림과 이상 로그 감지 채널의 알림으로 알았다.

   조치

   • 기존 유저를 내보내지 않고 새 로그인만 막아 입장 인원을 0명으로 둔 대기열처럼 썼고, 지표를 보며 막고 풀기를 반복해 동시 접속자 수를 조절했다.
   • 오후 2시 50분 노드 여러 대가 health check를 통과하지 못하자 아무도 게임을 할 수 없는 전체 긴급 점검에 들어갔다.
   • 전체 데이터베이스 백업이 멈추자 테이블 단위로 백업했다. 부하가 몰린 것은 특정 테이블의 일부 Range였고 그 테이블은 다른 테이블로 복구할 수 있었기 때문이다.
   • 서비스를 열기 전에 데이터베이스 부하를 최대한 줄이려고 플레이 기록 저장을 잠시 멈췄다.
   • 오후 6시 반쯤 문제가 된 테이블들에 Split 작업을 시작해 부하가 모든 노드에 고르게 나뉘도록 했다.
   • Host Status Check에 실패하고 filemap_fdatawait_range_keep_errors 로그가 나온 노드를 클러스터에서 빼기로 하고, Range 분리와 그 노드의 Decommission을 함께 진행했다. Decommission이 끝나자 복제되지 않은 Range가 0이 되고 지표가 안정됐다.
   • 서비스를 다시 연 뒤 한 노드가 CPU를 100% 쓰자 다시 대기열 방식으로 접속을 조절해 CPU 사용량을 안정시켰다.
   • 같은 노드가 거듭 CPU 100%에 이르러 노드 자체의 문제로 보고 그 노드를 종료해 문제를 끝냈다.

   교훈

   일반 RDBMS에서는 Primary Key prefix를 바꿔도 큰 문제가 되지 않지만, 분산 처리를 하는 CockroachDB의 프로덕션 클러스터에서는 이런 변경에 상당한 주의가 필요하다. 팀은 CockroachDB 스터디에서 문서와 자료를 읽어 이 내용을 알고 있었다. 그러나 직접 겪어 보니 글로 읽어 알던 것보다 훨씬 큰 일이었다.

   사례 보기

원인별2