IL-0206 GitLab · 2022-04-25kubernetesgcp
2022-04-25 와 2022-04-26 에 GitLab.com 전체가 간헐적으로 느려졌다. GKE 의 각 파드에는 Consul 에이전트가 함께 돌고, Rails 는 이 에이전트로 쓸 수 있는 PostgreSQL 복제본을 찾는다. Consul 에이전트는 특정 상황에서 메모리 수요가 급증했고, 메모리가 모자라면 OOM kill 로 빠르게 거듭 죽었다.
msmiley 의 분석에 따르면 Consul 에이전트가 동작하지 않자 web, api, git, websockets 의 Rails 파드는 어떤 PostgreSQL 데이터베이스가 정상이고 최신 상태인 복제본인지 거듭 알아내려다 실패했다. 서비스 디스커버리가 안 되자 기존 Rails 파드는 모든 쿼리를 마지막으로 알던 primary 로 보냈다. 읽기 트래픽이 primary 에 몰려 포화됐고, 그 때문에 Sidekiq 처리가 늦어졌다. 팀은 근본 원인이 #6909, #6910 과 같다고 정리했다.
대응 초기에는 2022-04-21 의 pgbouncer 풀 크기 축소를 원인으로 보았다. 16:13 에 gitlab 사용자의 연결 한도를 올리고 main pgbouncer 의 백엔드 풀을 늘리는 방안을 세웠고, 17:26 에 msmiley 가 변경을 적용했다. 근본 원인을 찾은 뒤에는 임시 조치로 파드 메모리 한도를 500MB 에서 1GB 로 올렸다. Consul 에이전트가 메모리를 갑자기 더 써도 계속 돌 수 있게 하려는 조치였다.
2022-04-25 15:13 UTC 에 engwan 이 Slack 에서 Sidekiq Apdex 하락으로 장애를 선언했다. Apdex 는 목표 시간 안에 끝난 작업의 비율로 만족도를 나타내는 지표다. 사용자는 사이트가 간헐적으로 느려지는 것을 겪었고, 파이프라인 생성이나 가져오기와 내보내기 같은 비동기 작업이 평소보다 오래 걸렸다.
대응팀은 처음에 데이터베이스 연결 포화를 의심했다. 2022-04-21 에 pgbouncer 변경이 있었다는 보고가 나왔고, Sidekiq 대기열은 15:33 에 나빴다가 회복된 상태였다. 16:23 에 팀이 세운 가설은 chef-repo MR 1679 가 pgbouncer 풀 크기를 줄여 연결이 포화됐다는 것이었다. 팀은 main 데이터베이스의 풀 크기를 늘리고, CI 쪽 포화가 그대로면 CI phase 4 기능 플래그의 롤아웃 비율을 낮추기로 했다. 16:29 에 msmiley 는 포화 지표가 조금 부정확해서 실제로는 생각만큼 포화되지 않았을 수 있다고 지적했다. 16:36 에는 다른 장애를 맡던 사람들이 자기 문제가 이 장애에서 비롯됐다고 결론 내렸다.
17:08 에 포화 수준이 크게 내려가고 사이트 지연이 멈추자 장애 상태를 완화됨으로 바꿨다. 그러나 2022-04-26 01:21 에 모니터링이 오류율 상승을 잡았고, 01:26 에 cindy 가 장애를 다시 선언했다. 처음에는 별개 문제로 보였지만 분석해 보니 같은 원인이었다.
추가 조사에서 원인은 GKE 노드의 OOM kill 로 드러났다. GKE 파드마다 Consul 에이전트가 함께 도는데, 이 에이전트는 특정 상황에서 메모리 수요가 갑자기 늘었다. 그만큼의 메모리를 얻지 못하면 Consul 프로세스는 빠르게 거듭 죽었다.
원인 용량 한계
2022-04-25 15:13 UTC 에 engwan 이 Slack 에서 Sidekiq Apdex 하락으로 장애를 선언했다. 다음 날 01:21 UTC 에는 모니터링이 오류율 상승을 잡았고, 01:26 에 cindy 가 장애를 다시 선언했다.
파드 안에서 함께 도는 Consul 에이전트의 메모리 한도가 모자라자 서비스 디스커버리가 끊겼고, 그 영향이 데이터베이스 primary 포화와 사이트 전체의 지연으로 번졌다. 처음 의심한 pgbouncer 풀 변경과 다음 날 별개로 보였던 오류율 상승이 모두 같은 원인으로 이어졌다. 메모리 한도를 올린 것은 임시 조치였고, Consul 의 메모리 급증이 정상 동작인지 GitLab 설정 탓인지는 아직 조사해야 했다.
IL-0110 Grafana Agent 파드가 메모리를 많이 쓰던 노드에 Hangfire 파드가 함께 올라가 시스템 OOM 으로 CrashLoopBackOff 를 반복했고, 노드가 응답을 멈추고 NotReady 가 됐다.DFDS · 2024같은 원인 · 공통 컨테이너 메모리 한도, 애플리케이션 데이터베이스
IL-0102 배포와 워커 오토스케일링 폭주가 겹치자 크기를 고정해 둔 CoreDNS 가 메모리 한도를 넘겨 재시작된 뒤 회복하지 못했고, Buildkite 사이트 전체가 약 30분 멈췄다.Buildkite · 2026같은 원인 · 공통 컨테이너 메모리 한도
같은 원인 · 공통 애플리케이션 데이터베이스
같은 원인 · 공통 컨테이너 메모리 한도
같은 원인 · 공통 컨테이너 메모리 한도
https://incidentlib-mcp.benchlet.com/mcpAPI 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.
같은 원인 · 공통 컨테이너 메모리 한도
IL-0169 FR-PAR 의 Scaleway Kubernetes API 가 메모리 부족으로 쓰러져 노드 인증이 막히고 Kapsule 노드가 NotReady 가 됐다.Scaleway · 2024같은 원인 · 공통 컨테이너 메모리 한도
IL-0202 갑자기 몰린 쿼리와 데이터베이스 쓰기로 Honeycomb 수집 호스트가 메모리 부족으로 죽었고, 쿠버네티스 CrashLoopBackOff 가 용량 회복을 막아 US1 이벤트 수집이 한 시간 넘게 불안정했다Honeycomb · 2023 · sev1같은 원인 · 공통 애플리케이션 데이터베이스
IL-0016 네임스페이스와 규칙이 늘어 live 클러스터의 Prometheus 가 메모리 부족으로 OOMKilled 되며 플랫폼 모니터링이 끊겼다UK Ministry of Justice · 2023같은 원인 · 공통 컨테이너 메모리 한도
같은 원인 · 공통 컨테이너 메모리 한도
IL-0094 JupyterHub 클러스터에서 학생 파드가 노드의 CPU 와 메모리를 다 써서 자원 보장이 부족했던 코어 파드가 자원을 얻지 못했고, 허브 전체가 멈췄다.2i2c · 2020같은 원인 · 공통 컨테이너 메모리 한도
IL-0026 메모리 제한이 없는 fluentd-sumologic 파드가 메모리를 다 써서 운영 쿠버네티스 노드 두 대에 이틀 연속 SystemOOM 이 났다Blue Matador · 2019같은 원인 · 공통 컨테이너 메모리 한도
IL-0037 imagePullPolicy가 Always인 DaemonSet이 크래시 루프를 돌며 이미지를 계속 받아, NAT 세 대를 같이 쓰던 리전 전체가 이미지 레지스트리에서 429로 막혔다Datadog · 2019같은 원인 · 공통 애플리케이션 데이터베이스
IL-0064 CPU 를 많이 쓰는 파드가 Google Cloud 노드 하나에 몰려 노드가 커널 패닉으로 죽었고, 다시 배치된 파드가 다음 노드를 또 죽이며 웹사이트와 API 가 멈췄다.Moonlight · 2019같은 원인 · 공통 애플리케이션 데이터베이스
같은 원인 · 공통 컨테이너 메모리 한도