사례5건
5건 중 1~5번째
IL-0207로컬 개발 환경에서 돌린 작업이 운영 컨텍스트로 넘어가 Kubernetes 클러스터의 Consul 릴리스를 통째로 지웠고, Patroni 가 무너져 GitLab.com 전체가 5XX 오류를 냈다.GitLab2022- 증상
모니터링과 알림이 곧바로 울렸다. 알림 하나는 Patroni 페일오버를 가리켰다. GitLab.com 으로 가는 트래픽은 모두 5XX 오류로 끝났다.
- 촉발
엔지니어가 로컬 개발 환경에서 사내 도구로 일상적인 작업을 돌렸다. 로컬 배포나 롤백 도중 컨텍스트가 로컬 개발에서 운영으로 바뀌었고, 이때 잘 알려진 오픈소스 도구가 예상하지 못한 동작을 해 운영 환경에 변경이 들어갔다.
- 원인
- 구성 요소
- 기여 요인
- 감지
모니터링과 알림 인프라가 곧바로 경보를 보냈다. 팀은 Consul 클러스터가 내려가 Patroni 클러스터에 영향을 주자마자 큰 장애가 난 것을 알았고, 근본 원인도 몇 분 안에 찾았다.
- 조치
- 지워진 Consul 릴리스를 운영에 다시 적용했다. Consul 클러스터가 올라오자 데이터베이스 클러스터가 회복했다.
- 후속 조치
- Kubernetes 배포 방식을 개선해 로컬 환경에서 운영 환경을 대상으로 위험한 배포 작업이 돌아갈 가능성을 줄인다. 개념 검증은 reliability 이슈 16875 에서 진행한다.
- Teleport 를 Kubernetes 클러스터와 연동한다. 이렇게 하면 SRE 에게 기본으로 읽기 전용 역할을 줄 수 있어 실수로 운영 환경을 바꿀 위험이 줄어든다.
- 교훈
로컬 개발 환경에서 운영 클러스터에 접근할 수 있으면 도구가 컨텍스트를 예상과 다르게 바꾸는 순간 일상 작업이 운영 장애가 된다. GitLab 은 Kubernetes 배포 방식을 개선하고, Teleport 로 SRE 의 기본 권한을 읽기 전용으로 둘 수 있게 하면 이런 위험이 크게 줄어든다고 봤다. 알림과 원인 파악은 빨랐다. 지워진 릴리스를 다시 배포하는 데는 손으로 해야 할 일이 있었지만 비교적 빨리 끝났다.
IL-0206GKE 파드 안의 Consul 에이전트가 메모리 급증으로 거듭 OOM kill 되어 Rails 파드가 데이터베이스 복제본을 찾지 못했고, 모든 쿼리가 primary 로 몰려 GitLab.com 이 느려졌다.GitLab2022- 증상
2022-04-25 15:13 UTC 에 engwan 이 Slack 에서 Sidekiq Apdex 하락으로 장애를 선언했다. Apdex 는 목표 시간 안에 끝난 작업의 비율로 만족도를 나타내는 지표다. 사용자는 사이트가 간헐적으로 느려지는 것을 겪었고, 파이프라인 생성이나 가져오기와 내보내기 같은 비동기 작업이 평소보다 오래 걸렸다.
- 촉발
GKE 파드 안의 Consul 에이전트가 특정 상황에서 메모리를 갑자기 많이 요구했고, 쓸 수 있는 메모리가 없어 Consul 프로세스가 죽었다. 당시 파드 메모리 한도는 500MB 였다.
- 원인
- 구성 요소
- 기여 요인
- –
- 감지
2022-04-25 15:13 UTC 에 engwan 이 Slack 에서 Sidekiq Apdex 하락으로 장애를 선언했다. 다음 날 01:21 UTC 에는 모니터링이 오류율 상승을 잡았고, 01:26 에 cindy 가 장애를 다시 선언했다.
- 조치
- 16:13 에 gitlab 데이터베이스 사용자의 연결 한도를 올리고 main pgbouncer 의 백엔드 풀을 늘리는 방안을 세웠고, 17:26 에 msmiley 가 변경을 적용해 17:47 에 적용을 확인했다.
- 임시 조치로 파드 메모리 한도를 500MB 에서 1GB 로 올려 Consul 에이전트가 메모리 급증 때도 계속 돌 수 있게 했다.
- 후속 조치
- 메모리 한도를 1GB 로 올린 것으로 충분한지 GKE 파드의 Consul 에이전트를 지켜본다.
- Consul 의 메모리 수요 급증을 조사해 하드 메모리 한도를 올리는 것 말고 개선할 방법이 있는지 찾는다.
- 교훈
파드 안에서 함께 도는 Consul 에이전트의 메모리 한도가 모자라자 서비스 디스커버리가 끊겼고, 그 영향이 데이터베이스 primary 포화와 사이트 전체의 지연으로 번졌다. 처음 의심한 pgbouncer 풀 변경과 다음 날 별개로 보였던 오류율 상승이 모두 같은 원인으로 이어졌다. 메모리 한도를 올린 것은 임시 조치였고, Consul 의 메모리 급증이 정상 동작인지 GitLab 설정 탓인지는 아직 조사해야 했다.
IL-0208GitLab Helm 차트 업그레이드가 Service 와 Deployment 의 포트 이름을 바꿔 GCP 로드 밸런서가 다시 구성되는 동안 GitLab.com 요청이 느려지고 50x 오류가 났다GitLab2022- 증상
2022-03-31 07:53 UTC 에 GitLab.com 웹 서비스의 50x 오류가 늘기 시작했고, 1분 뒤 당직 엔지니어가 오류율 증가 페이지를 받았다. 사용자에게는 GitLab.com 이 느려졌고 간헐적으로 500 오류 페이지가 떴다.
- 촉발
gitlab-com/gl-infra/k8s-workloads/gitlab-com!1643 머지 요청을 배포하는 파이프라인이 07:49 UTC 에 gprd-cny 로 배포를 시작했다. 이 변경에는 GitLab 차트 버전 업그레이드가 들어 있었고, 새 차트는 Prometheus ServiceMonitor, PodMonitor 설정과 관련된 변경으로 Kubernetes Service 와 Deployment 의 포트 이름을 바꿨다.
- 원인
- 구성 요소
- 기여 요인
- 감지
07:53 UTC 에 50x 오류가 늘기 시작했고 07:54 에 PagerDuty 알림이 당직 엔지니어를 호출했다. 변경을 배포하던 엔지니어가 오류를 보고 그 변경과 연결해 원인을 짚었다.
- 조치
- 08:05 UTC 에 당직 엔지니어가 카나리 환경을 트래픽에서 뺐다가 08:25 에 다시 넣었다.
- 08:15 에 cluster c 와 cluster d 배포 작업을 시작 전에 취소했다.
- 08:51 에 HAProxy 에서 gprd-us-east1-d 클러스터를 뺐다가 08:56 에 다시 넣었다.
- 09:31 에 최소 레플리카 수를 100 넘게 올리는 변경 !1650 을 머지했다.
- 09:53 에 HAProxy 에서 gprd-us-east1-c 클러스터를 빼고, 09:57 에 이 클러스터에 !1643 을 배포한 뒤 10:07 에 다시 넣었다.
- 10:19 에 최소 레플리카 상향을 되돌리는 변경 !1652 를 머지했다.
- 후속 조치
- 리전 클러스터 하나에서 트래픽을 통째로 안전하게 빼는 graceful drain 기능을 만든다.
- PagerDuty 를 유지보수 모드로 바꾸는 ChatOps 명령을 만든다.
- 교훈
알림은 정확하게 울렸다. 원인이 바로 직전에 배포한 변경이라는 것을 알았기 때문에, 그 변경을 배포하던 파이프라인을 멈추는 것이 자연스러운 첫 대응이었다.
IL-0209웹 파드의 HPA CPU 목표값이 너무 높아 트래픽을 넘겨받는 동안 파드가 늘지 않았고, GitLab.com 웹 지연 SLO 가 약 15분 동안 깨졌다.GitLab2021- 증상
2021년 8월 24일 07:30 UTC에 웹 서비스의 지연 SLO 가 깨졌다. 웹 서비스의 Apdex 가 떨어졌고, 웹 프런트엔드로 가는 요청 일부가 잠시 느려졌다. Apdex 는 응답 시간이 목표 안에 든 요청의 비율로 계산하는 만족도 점수다.
- 촉발
웹 서비스를 VM 에서 쿠버네티스로 옮기면서 트래픽을 쿠버네티스 웹 파드로 넘겼다.
- 원인
- 구성 요소
- 기여 요인
- 감지
07:30 UTC에 웹 지연 SLO 가 깨졌고, 10분 뒤인 07:40에 엔지니어가 Slack 에서 장애를 선언했다.
- 조치
- 웹 파드의 targetCPU 를 더 보수적인 값으로 낮추는 머지 요청 gitlab-com/gl-infra/k8s-workloads/gitlab-com!1149 를 머지했다.
- 후속 조치
- 목표 사용률을 조정하는 머지 요청 gitlab-com/gl-infra/k8s-workloads/gitlab-com!1149 를 재발 방지 조치로 올려 머지했다.
- 교훈
트래픽을 새 파드로 넘길 때 HPA 의 CPU 목표값이 너무 높으면 부하가 늘어도 파드가 제때 늘지 않는다. 팀은 목표값을 보수적으로 낮춰 이 문제를 풀었다.
IL-0205Google Cloud us-east1 의 SSD 영구 디스크 재고가 바닥나 GKE 클러스터 오토스케일러가 프로덕션 노드를 늘리지 못했고, API 디플로이먼트가 파드를 띄울 용량을 얻지 못했다.GitLab2021- 증상
2021-06-21 08:05 UTC 부터 API 의 Apdex 가 나빠지고 Rails 대기열이 늘어나는 추세가 보였다. Apdex 는 목표 시간 안에 끝난 요청의 비율로 사용자 만족도를 나타내는 지표다. 08:43 에 ahmad 가 Slack 에서 장애를 선언했고, 09:01 에 API 디플로이먼트가 비정상 상태이고, 노드를 늘려 파드 용량을 더할 수도 없다는 것을 확인했다.
- 촉발
GitLab 이 운영하는 GCP us-east1 리전에서 SSD 재고가 바닥난 상태였는데, 사용자 트래픽이 늘어 API 서비스가 노드를 늘려야 했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
로그를 한참 뒤져서 찾았다. 클러스터 오토스케일러 오류는 일부 노드가 백오프 상태라 확장할 수 없다고만 했고, 인스턴스 그룹 수준 오류도 ZONE_RESOURCE_POOL_EXHAUSTED 뿐이어서 어떤 자원이 바닥났는지 알 수 없었다. 결국 GCP 지원팀이 SSD 재고 부족을 알려 주었다. 탐지까지 22시간이 걸렸고, 팀은 자원 가용성 알림이 있었다면 탐지와 진단을 앞당길 수 있었다고 보았다.
- 조치
- 09:55 에 pd-standard 디스크를 쓰는 노드 풀을 하나 더 만들었다.
- 10:37 에 새 노드 풀이 늘어나지 않자 API 부담을 덜려고 이 노드 풀을 세 존 모두에서 손으로 늘렸다.
- 13:42 에 배포가 막혀 있고 다른 워크로드도 같은 영향을 받고 있어서 pd-standard 디스크를 쓰는 새 노드 풀들을 올리기로 했다.
- 18:16 에 canary 시험에서 클러스터 오토스케일러가 새 노드 풀과 함께 동작하지 않자 프로덕션 배포를 막는다고 공지하고, 오토스케일러 문제로 Google 에 지원 케이스를 열었다.
- 18:26 에 남은 워크로드의 노드 풀과 nodeSelector 를 바꾸는 인프라 작업을 시작했다.
- pd-standard 노드 풀 위주로 하루 동안 운영하며 문제가 없는 것을 확인한 뒤 SSD 노드 풀을 정리해 없앴다.
- 후속 조치
- 쿠버네티스 서비스를 pd-standard 디스크로 옮겼다.
- 자원 고갈 오류를 지표로 수집한다.
- 교훈
장애를 수습하는 도중 다른 버그를 만나 대응 전체가 느려졌다. 팀에는 클라우드 자원 가용성을 감시할 수단도, 자원을 미리 예약해 둘 수단도 없었다. 워크로드는 pd-ssd 대신 pd-standard 디스크에서도 문제없이 도는 것으로 보였다.
이 5건에서 가장 많이 나오는 구성 요소: 애플리케이션 데이터베이스, 클라우드 로드 밸런서. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.