사례5건

5건 중 1~5번째

1. IL-0041 fluent-bit 이 오류 없이 멈춰 운영 노드 한 대의 애플리케이션 로그가 Elasticsearch 로 전혀 가지 않았다.

   PrometheusKube2020

   증상

   화요일 아침 개발자가 운영 환경 로그 일부가 빠져 있다고 알려 왔다. 이상하게도 빠진 로그는 노드 한 대에서 나온 것뿐이었다.

   모니터링 중단

   원인

   소프트웨어 결함

   구성 요소

   텔레메트리 에이전트Elasticsearch 와 OpenSearch

   기여 요인

   모니터링 사각지대미패치 알려진 버그

   감지

   운영 환경 로그 일부가 빠져 있다는 개발자의 메시지로 알았다. fluent-bit 의 Prometheus 지표는 오류를 보이지 않고 값만 멈춰 있어서 모니터링은 이 상황을 잡지 못했다. 지표가 늘지 않는 것도 이슈 #1935 로 보고된 다른 버그였다.

   조치

   • Elasticsearch 스레드 큐 오류를 보고 Elasticsearch 가상 머신에 CPU 를 늘렸다. 오류는 사라졌지만 로그 누락의 원인은 아니었다.
   • 노드 어피니티로 Fluentd 를 놓고 안티 어피니티로 fluent-bit 을 빼는 방식으로, 노드 하나씩 Fluentd 를 배포했다.
   • 오래된 로그가 한꺼번에 밀려 버퍼가 넘치지 않도록 Fluentd 의 flush_thread_count 를 1로 줄이고 flush_interval 을 5초로 늘렸다.
   • Fluentd 의 Position DB 기능을 켜서 이미 보낸 데이터를 건너뛰게 했다.

   후속 조치

   • Fluentd 의 Prometheus 연동으로 모니터링 패키지를 만든다. 5분 동안 보낸 바이트 비율에 낮과 밤 기준을 따로 두는 알림이나, 로그를 계속 남기고 Elasticsearch 에 들어왔는지 확인하는 블랙박스 점검을 적용한다.

   교훈

   오픈소스 소프트웨어가 어떻게 망가질지는 미리 알 수 없고, 때로는 다른 도구로 빨리 갈아탈 수 있어야 한다. 로그 전송 에이전트는 오류 지표만으로 감시할 수 없다. 이번처럼 지표가 오류 없이 멈추면 아무것도 잡히지 않는다. fluentbit_output_proc_bytes_total 의 5분 비율처럼 전송량에 알림을 걸 수 있다. 트래픽은 밤에 줄고 낮에 늘어 기준값 하나로는 맞지 않으므로, 낮과 밤 기준을 따로 둔다. 테스트 로그를 계속 남기고 Elasticsearch 에 들어왔는지 확인하는 블랙박스 점검도 방법이다. 다만 이런 알림이 울려도 그 자리에서 할 수 있는 조치가 마땅치 않다.

   사례 보기
2. IL-0029 CPU 한도를 건 컨테이너가 사용량이 한도에 한참 못 미치는데도 스로틀링되어 사용자 대면 서비스의 지연 시간이 늘었다.

   Buffer2020

   증상

   Buffer 엔지니어가 컨테이너의 스로틀링 지표를 살펴보니, CPU 사용량이 한도 근처에도 가지 않은 컨테이너가 많이 스로틀링되고 있었다.

   CPU 스로틀링지연 시간 증가노드 NotReady

   촉발

   Buffer 는 노드를 지키려고 컨테이너에 CPU 한도를 걸어 두었는데, 노드 커널에는 CPU 한도가 걸린 컨테이너를 필요 없이 스로틀링하는 버그가 남아 있었다.

   원인

   소프트웨어 결함

   구성 요소

   컨테이너 CPU 한도리눅스 커널노드 운영체제 이미지

   기여 요인

   미패치 알려진 버그미검증 가정

   감지

   엔지니어가 컨테이너의 스로틀링 지표를 살피다가, CPU 사용량이 한도보다 훨씬 낮은 컨테이너도 많이 스로틀링되는 것을 보고 알았다.

   조치

   • 사용자에게 직접 또는 간접으로 닿는 경로에 있는 모든 서비스에서 CPU 한도를 없앴다.
   • 한도를 없앤 서비스에 톨러레이션을 더해 테인트를 건 노드에서만 돌게 하고, 한도가 있는 서비스와 떼어 놓았다.
   • 서비스마다 몇 달 치 사용량을 분석해 최대 CPU 사용량에 20% 넘는 여유를 더한 값을 CPU 요청값으로 정했고, 메모리 요청값도 같은 방식으로 정했다.

   후속 조치

   • 커널 수정이 들어간 노드 이미지로 올린다. Buffer 는 kops 1.18 이상에서 기본 이미지가 되는 Ubuntu 20.04 를 기다리고 있다.
   • 수정된 커널로 올린 뒤 스로틀링이 정말 사라졌는지 확인하고, 그 결과로 글을 고친다.

   교훈

   리눅스에서 컨테이너를 돌리면 쿠버네티스든 Mesos 든 Swarm 이든 스로틀링 때문에 컨테이너가 제 성능을 내지 못할 수 있다. 먼저 커널을 수정된 버전으로 올리고 스로틀링 지표를 지켜보는 편이 낫다. CPU 한도를 없애면 지연 시간은 줄지만 위험하다. 한도를 없앤다면 CPU 요청값을 제대로 잡고, 노드의 CPU 와 메모리 사용량을 꼼꼼히 모니터링한다. 사용량이 높으면 Horizontal Pod Autoscaler 로 파드를 늘려 여유 있는 노드에 배치되게 한다. 클러스터에 여유가 없으면 알림을 받거나 노드 오토스케일러로 노드를 늘린다.

   사례 보기
3. IL-0012 CPU limit 과 커널 CFS 쿼터 버그로 파드가 과하게 스로틀링돼 헬스 체크가 실패하고 애플리케이션이 멈췄다

   Omio2020

   증상

   Omio 는 6개월 동안 원인을 알 수 없는 멈춤을 겪었다. 애플리케이션이 멈추거나 헬스 체크에 응답하지 않았고, 네트워크 연결이 끊겼다.

   CPU 스로틀링프로브 실패오류율 상승지연 시간 증가간헐적 타임아웃간헐적 연결 실패

   촉발

   쿠버네티스는 CPU limit 을 커널 CFS 의 쿼터로 구현한다. 주기는 100ms 이고, limit 2코어는 주기마다 CPU 시간 200ms 가 된다. 스레드 10개가 동시에 돌면 20ms 만에 쿼터를 다 쓰고, 남은 80ms 동안 파드의 모든 스레드가 멈춘다. 여기에 커널 CFS 스케줄러의 알려진 버그가 불필요한 스로틀링을 일으켜, 컨테이너가 허용된 쿼터를 다 쓰기도 전에 스로틀링됐다.

   원인

   소프트웨어 결함

   구성 요소

   컨테이너 CPU 한도리눅스 커널kubelet

   기여 요인

   한계 미인지모니터링 사각지대미패치 알려진 버그

   감지

   팀은 6개월 동안 애플리케이션이 멈추거나 헬스 체크에 응답하지 않는 현상을 겪었지만, 쿠버네티스가 cgroup 지표를 내보내지 않아 스로틀링을 바로 알아채지 못했다. 파드 안에서 /sys/fs/cgroup/cpu/cpu.stat 의 nr_throttled 와 throttled_time 을 읽어 스로틀링 비율을 확인했다.

   조치

   • 버그를 고친 최신 커널이 모든 클러스터에 배포될 때까지 CPU limit 을 껐다.

   후속 조치

   • CFS 쿼터 버그를 고친 최신 커널을 모든 클러스터에 배포한다.
   • 사용률, 포화도, 오류를 보는 USE 지표와 함께 API 지연과 오류율을 지켜보며 결과가 기대한 대로인지 확인한다.

   교훈

   CFS 쿼터 버그가 고쳐지지 않은 커널을 쓴다면 쿠버네티스에서 CPU limit 을 없애거나 kubelet 에서 CFS 쿼터를 끄는 편이 낫다. CPU request 와 limit 은 설정이 비슷해 보여도 구현이 전혀 다르다. CPU 스로틀링은 쿠버네티스 기본 지표에 드러나지 않으므로 cpu.stat 을 직접 확인해야 한다. limit 을 끄면 최적화되지 않은 애플리케이션이 노드의 CPU 를 독차지할 수 있으니, JVM, Go, Node 런타임을 미리 튜닝해 둬야 한다.

   사례 보기
4. IL-0030 쿠버네티스 v1.7.4 클러스터에서 노드들이 한꺼번에 NotReady 가 되어 쓸 수 있는 노드가 20% 미만으로 줄었다.

   Zalando2019

   증상

   클러스터에서 쓸 수 있는 노드가 전체의 20% 미만으로 줄었다. 노드들이 같은 시각에 한꺼번에 비정상이 됐다.

   노드 NotReady

   원인

   소프트웨어 결함

   구성 요소

   쿠버네티스 API 서버클라우드 로드 밸런서

   기여 요인

   미패치 알려진 버그

   조치

   • 노드들은 15분 뒤 저절로 복구됐다.

   사례 보기
5. IL-0074 워커 노드가 잇달아 Not Ready 에 빠지고 네트워크와 DNS 실패로 사이드카가 죽으면서, AirMap 플랫폼의 모든 서비스가 다섯 시간 동안 응답하지 않았다.

   AirMap2018

   증상

   2018년 7월 19일 15:00 UTC 쯤 모니터링 인프라가 일부 API, 특히 pilot 과 tiles 의 5xx 응답 증가를 알렸다. 사용자 프로필을 가져오는 pilot 서비스가 먼저 응답하지 않아 플랫폼 로그인이 실패했고, 문제는 거기서 퍼져 나갔다.

   오류율 상승노드 NotReadyDNS 조회 실패컨테이너 재시작 반복서비스 중단

   원인

   소프트웨어 결함

   구성 요소

   kubelet

   기여 요인

   미패치 알려진 버그

   감지

   15:00 UTC 쯤 모니터링 인프라가 일부 API, 특히 pilot 과 tiles 의 5xx 응답 증가를 알렸다.

   조치

   • 멈춘 워커 노드의 kubelet 을 되살리려 했지만 노드는 곧 다시 Not Ready 가 되었다.
   • 18:00 UTC 쯤부터 클러스터의 모든 워커 노드를 시차를 두고 재시작했다. 약 1.5시간 뒤 모든 노드의 재시작이 끝나며 서비스가 안정되었다.

   후속 조치

   • 수정이 업스트림에 들어가 클라우드 제공자인 MS Azure 에 반영될 때까지, 노드와 kubelet 이 정상으로 돌도록 정기적인 롤링 재시작을 적용한다.

   교훈

   AirMap 은 운영 클러스터의 증상을 오픈소스 커뮤니티의 알려진 이슈와 대조해 근본 원인과 수정 후보를 찾을 수 있었다. 업스트림 수정이 클라우드 제공자에게 반영되기 전까지는 워커 노드를 정기적으로 롤링 재시작해 같은 장애를 막는다.

   사례 보기

원인별1