사례16건

16건 중 6~10번째

1. IL-0044 kube-prometheus-stack 업그레이드 뒤 Prometheus 가 WAL 재생 중 메모리를 50Gi 넘게 써서 시작할 때마다 OOMKilled 로 죽었다

   Saifeddine Rajhi2024

   증상

   kube-prometheus-stack 헬름 차트를 업그레이드하는 중에 여러 파드가 Ready 가 되지 않았다. 그중 prometheus-prometheus-operator-prometheus-0 파드는 3/4 Running 상태였고 최근에 OOMKilled 로 종료된 기록이 있었다.

   OOMKilled프로브 실패모니터링 중단

   촉발

   kube-prometheus-stack 헬름 차트를 업그레이드하던 중 Prometheus 가 시작하면서 WAL 을 재생했고, 이 과정에서 메모리 사용량이 메모리 제한을 넘었다.

   원인

   용량 한계

   구성 요소

   Prometheus컨테이너 메모리 한도

   기여 요인

   한계 미인지여유 용량 부재

   감지

   팀은 kube-prometheus-stack 헬름 차트를 업그레이드하던 중 Prometheus 파드를 포함한 여러 파드가 Ready 가 되지 않는 것을 보았다. kubectl describe pod 와 Prometheus 로그로 OOMKilled 를 확인했다.

   조치

   • Prometheus 파드에 kubectl exec 로 들어가 promtool tsdb analyze . 를 실행해 haproxy_server_http_responses_total 처럼 카디널리티가 높은 지표를 찾았다.

   후속 조치

   • WAL 재생 중 메모리 오버헤드가 10% 에서 15% 정도의 허용 범위 안에 있는지 확인하고, Prometheus 를 메모리 제한에 가깝게 운영하지 않는다.
   • Prometheus 의 저장, 스크레이프, remote write 설정을 정기적으로 최적화하고, 최적화가 들어간 새 릴리스로 업그레이드한다.
   • OOM 크래시 루프에서 자동으로 복구하는 장치를 만든다. 예를 들어 OOM 이벤트가 나면 WAL 을 자동으로 지운다.
   • 메모리 사용량이 일정 기준을 넘으면 스크레이프를 멈추는 강제 스크레이프 제한을 둔다.

   교훈

   Prometheus 를 메모리 제한에 가깝게 운영하면 WAL 재생 중의 작은 오버헤드로도 OOM 이 난다. 가비지 컬렉션은 들쭉날쭉하고 카디널리티나 쿼리는 갑자기 늘 수 있으므로 메모리에 여유를 둔다. Prometheus 메모리 문제의 상당 부분은 카디널리티에서 온다. Prometheus 가 떠 있지 않을 때는 promtool tsdb analyze 로 카디널리티가 높은 지표를 찾는다. 메모리 제한만 올려서는 답이 되지 않았다. 메모리가 치솟는 것은 재생 단계뿐이었기 때문이다.

   사례 보기
2. IL-0046 계획된 재시작 뒤 Prometheus 가 WAL 을 다 읽기 전에 startupProbe 에 걸려 재시작을 반복했고 지표가 빠졌다

   UK Ministry of Justice2024

   증상

   2024-04-15 12:32 에 계획된 Prometheus 변경을 적용한 뒤 Prometheus 를 쓸 수 없게 되었다. 팀은 prometheus 파드가 여러 번 재시작한 것을 보았다. 그동안 Cloud Platform 에는 모니터링이 없었고 지표가 빠졌다.

   모니터링 중단프로브 실패

   촉발

   계획된 변경으로 Prometheus 를 재시작했는데 그때 WAL 수가 평소보다 많아, WAL 다시 읽기가 startupProbe 기본 허용 시간인 15분 안에 끝나지 않았다.

   원인

   용량 한계

   구성 요소

   Prometheus

   기여 요인

   기본 설정 방치한계 미인지

   감지

   계획된 Prometheus 변경 뒤 팀이 prometheus 파드가 여러 번 재시작한 것을 보고 알았다. 처음 감지한 시각은 2024-04-15 12:32 였다.

   조치

   • startupProbe 허용 시간을 기본값 15분에서 30분으로 늘려 WAL 다시 읽기가 끝날 때까지 기다리게 했다.

   후속 조치

   • 팀은 계획된 Prometheus 재시작을 WAL 수가 적을 때 해서 재시작 시간을 줄이는 방안을 논의했다.
   • Prometheus 의 기본 CPU 와 메모리 요청값을 최대 사용량에 맞춰 설정했다.
   • 운영 환경의 WAL 수를 재현하는 테스트 환경을 만든다.
   • memory-snapshot-on-shutdown 과 auto-gomaxprocs 기능 플래그를 검토한다.
   • WAL 파일을 다른 위치의 원격 저장소에 두는 방법을 검토한다.
   • 운영과 같은 구성의 블루그린 Prometheus 를 만들어 운영에 적용하기 전에 변경을 시험하는 방안을 알아본다.
   • Amazon Managed Prometheus 를 간단히 조사한다.

   사례 보기
3. IL-0123 응답 버퍼를 재사용하지 않는 버그로 라우팅 계층 노드가 메모리 한도에 걸려 레디니스 검사에 실패했고, 트래픽이 몰리자 남은 노드가 모자라 모든 모델에서 요청 상당수가 502, 503 오류로 실패했다.

   OpenAI2023

   증상

   2023년 11월 8일 태평양 시각 오전 5시 42분부터 7시 16분까지 OpenAI 로 가는 요청 상당수가 502 나 503 오류로 실패했다. 모든 모델과 API 엔드포인트에서 실패가 크게 늘었다.

   오류율 상승서비스 중단프로브 실패

   촉발

   그날 아침 completion 요청이 그전 어느 날보다 훨씬 많이 들어왔다.

   원인

   소프트웨어 결함

   구성 요소

   모델 요청 라우팅컨테이너 메모리 한도

   기여 요인

   한계 경보 부재여유 용량 부재

   조치

   • 들어오는 트래픽을 제한했다.
   • 서비스를 한꺼번에 재배포했다.
   • 트래픽을 천천히 다시 올렸다.

   후속 조치

   • 루프에서 responseBuffer 를 매번 새로 할당하던 코드를 버퍼를 미리 할당해 재사용하도록 고쳤다. 배포 뒤 메모리와 CPU 사용량이 모두 3배 개선됐다.
   • 설정된 메모리 한도를 알맞은 수준으로 조정해 서비스에 여유 용량을 넉넉히 확보했다.
   • 트래픽을 더 매끄럽게 덜어 낼 수 있도록 rate limit 제어를 여러 가지 넣었다.
   • 추가 예방책으로 서비스 용량을 늘렸다.
   • 메모리 동작 이상이 서비스 문제로 커지기 전에 잡아내도록 여러 알림을 바꾼다.
   • 이 서비스에 오토스케일링을 설정한다. 용량을 늘리면 상위 서비스에 영향을 주던 문제를 바로잡았기 때문에 이제 설정할 수 있다.

   사례 보기
4. IL-0045 live 클러스터의 Prometheus 가 readiness probe 실패로 여러 번 재시작해 Cloud Platform 모니터링이 끊기고 메트릭이 빠졌다

   UK Ministry of Justice2023

   증상

   2023-11-01 10:15 에 Pingdom 이 Prometheus - live healthcheck 가 DOWN 이라며 PagerDuty 로 높은 우선순위 알림을 보냈다. 팀은 알림을 확인하고 Prometheus 서버 상태를 살폈다.

   모니터링 중단프로브 실패

   원인

   unknown

   구성 요소

   Prometheus

   기여 요인

   –

   감지

   Pingdom 의 Prometheus - live healthcheck 가 DOWN 이 되면서 PagerDuty 높은 우선순위 알림이 울렸다. 몇 분 사이에 같은 알림이 세 번 울리자 팀은 장애를 선언했다.

   조치

   • Prometheus 가 재시작하지 않도록 readiness probe 타임아웃을 3초에서 6초로 늘렸다.

   후속 조치

   • 이런 실패를 더 일찍 찾아내도록 점검을 더 꼼꼼히 할 방법을 찾는다.
   • 데이터베이스로 들어가는 데이터 수집의 양이 너무 많거나 시간이 너무 오래 걸리는지 조사한다.
   • 일부 쿼리가 Prometheus 에 부담을 줘서 Prometheus 가 readiness probe 에 응답하지 못하는지 조사한다.
   • Prometheus 에 상태 검사를 보내는 다른 서비스가 재시작을 일으키는지 조사한다.
   • 정기 velero 백업이 EBS 읽기와 쓰기를 방해해 재시작을 일으키는지 조사한다.

   사례 보기
5. IL-0191 Loki distributor 서비스에 레이블 셀렉터가 하나 더 들어가 롤아웃 중 새 파드 몇 개에만 쓰기 트래픽이 몰렸고, 그 파드들이 OOM으로 죽으면서 로그 쓰기 경로가 약 25분간 멈췄다.

   Grafana Labs2022

   증상

   Grafana Cloud Logs 의 한 환경에서 Grafana Loki 의 쓰기 경로가 내려갔다. 롤아웃 중이던 distributor 파드가 OOM으로 죽었다가 다시 뜨기를 되풀이했다.

   서비스 중단OOMKilled부하 불균형프로브 실패

   촉발

   키-값 저장소에서 내장 memberlist 로 옮기는 마이그레이션의 1단계가 distributor 디플로이먼트와 서비스에 새 레이블을 붙였다. 서비스를 만드는 함수가 이 레이블을 셀렉터로도 복사했기 때문에, 롤아웃이 시작되자 distributor 서비스는 새 레이블을 단 새 파드만 가리켰다.

   원인

   설정 변경

   구성 요소

   설정 템플릿서비스 디스커버리컨테이너 메모리 한도

   기여 요인

   기본 설정 방치초기 신호 무시스테이징 불일치

   감지

   처음에는 distributor 가 OOM으로 죽는 장애로 보였다. 첫 단서는 kubectl get pods 와 kube_deployment_status_replicas_updated 지표에서 distributor 의 10%만 재시작됐다는 점이었다. 팀은 PR 마다 Kubernetes 매니페스트 diff 를 만들어 PR 에 올리고 별도 레포에도 저장하는 자동화를 갖고 있었다. 이 diff 에서 distributor 서비스에 셀렉터가 추가되고 서비스가 다시 만들어진 것을 찾았다. 평소 배포에서는 서비스가 다시 만들어지지 않는다.

   조치

   • distributor 디플로이먼트의 레플리카를 늘렸다. 새로 뜬 파드도 새 레이블을 달고 있어서 부하가 더 많은 파드로 나뉘었고, OOM으로 죽는 파드가 줄면서 Kubernetes 가 옛 파드 교체를 이어 갔다.
   • 마이그레이션 단계의 변경을 되돌려 장애를 완전히 끝내고 원인을 조사할 시간을 벌었다.
   • service_ignored_labels:: [$._config.gossip_member_label] 을 설정하고 서비스 생성 함수 k.util.serviceFor 에 넘겨, memberlist 레이블이 서비스 셀렉터로 복사되지 않게 했다.

   후속 조치

   • 디플로이먼트나 스테이트풀셋의 레이블을 서비스 셀렉터로 복사하던 함수가 이번 같은 예외 상황도 처리하도록 고쳤다.

   교훈

   서비스 셀렉터를 디플로이먼트 레이블에서 자동으로 만들면, 롤아웃 중에 새 레이블이 붙는 순간 서비스가 새 파드만 가리킬 수 있다. 다른 환경에서 본 작은 오류를 롤아웃 때 흔한 잡음으로 넘기면 이런 신호를 놓친다. 환경마다 수평 확장과 메모리 한도 설정이 다르면 다른 환경에서 문제없던 변경이 특정 환경에서만 장애를 낸다. 원인을 빨리 찾는 데에는 Loki 와 Kubernetes 지표, PR 마다 남겨 둔 매니페스트 diff 가 도움이 됐다.

   사례 보기

원인별8