사례2건

2건 중 1~2번째

1. IL-0174 Fluent Bit 2.0 으로 올린 로그 수집 사이드카 가운데 Kafka output 플러그인을 쓰는 컨테이너가 SIGSEGV 로 계속 재시작됐다.

   Hyperconnect2023

   증상

   하이퍼커넥트는 운영 Kubernetes 클러스터의 로그 수집 에이전트인 Fluent Bit 를 2.0 으로 올렸다. 사용자 영향이 적은 서비스를 골라 Fluent Bit 사이드카부터 업그레이드하고 며칠 지켜보니, Kafka output 플러그인을 쓰는 컨테이너만 SIGSEGV 로 재시작되고 있었다.

   컨테이너 재시작 반복

   촉발

   운영 클러스터에서 Fluent Bit 사이드카를 2.0 으로 업그레이드했다. 이 버전의 Kafka output 플러그인은 map 이 아닌 레코드가 들어와도 타입을 확인하지 않고 처리했다.

   원인

   소프트웨어 결함

   구성 요소

   텔레메트리 에이전트

   기여 요인

   디버그 접근 제한

   감지

   업그레이드 뒤 며칠 동안 모니터링하다가 Kafka output 플러그인을 쓰는 컨테이너만 SIGSEGV 로 재시작되는 것을 발견했다.

   조치

   • produce_message 를 부르기 전에 map 이 아닌 데이터를 건너뛰도록 Fluent Bit Kafka output 플러그인을 고쳤다.
   • 고친 플러그인으로 커스텀 빌드를 만들어 사이드카로 적용했고, segmentation fault 가 사라졌다.
   • 수정 사항을 Fluent Bit 업스트림에 PR 6452 로 냈고, 제출 8일 만에 병합됐다.

   교훈

   Linux 는 segmentation fault 가 나면 core 를 덤프하고, 이 파일을 분석하면 버그를 찾을 수 있다. Kubernetes 환경에서는 core 가 저절로 남지 않으므로 볼륨과 core_pattern 을 미리 잡아 두어야 한다. 직접 분석하기 어려워 core 파일을 다른 사람에게 넘길 때는 조심해야 한다. core 에는 실행 중이던 프로세스의 메모리 일부가 들어 있어 민감 정보가 섞일 수 있다.

   사례 보기
2. IL-0175 JVM 파드의 CPU requests 를 1코어로 줄이자 JVM 이 노드의 CPU 36개를 인식해 Reactor Netty 스레드가 늘고 메모리 사용량이 경보 기준을 넘었다

   Hyperconnect2022

   증상

   DevOps 팀이 아직 운영 트래픽을 받지 않는 notification-preferences 마이크로서비스의 `resources.requests.cpu` 를 2에서 1로 줄였다. 작업을 마치고 몇 분 뒤 메모리 사용량이 90% 를 넘었다는 경보가 왔다. 메모리 할당량이나 JVM 의 GC 관련 인자는 건드리지 않은 상태였다.

   메모리 압박

   촉발

   리소스 최적화 작업 중 notification-preferences 디플로이먼트의 `resources.requests.cpu` 를 2에서 1로 줄였다. CPU limit 은 설정하지 않은 상태였다.

   원인

   소프트웨어 결함

   구성 요소

   언어 런타임 설정컨테이너 CPU 한도

   기여 요인

   리소스 요청과 한도 미설정

   감지

   CPU requests 를 줄이고 몇 분 뒤 메모리 사용량이 90% 를 넘었다는 경보가 울렸다.

   조치

   • JVM 옵션에 `-XX:ActiveProcessorCount=1` 을 넣어 JVM 이 쓸 CPU 수를 강제로 지정했다. 자원을 다시 늘리거나, CPU limit 을 걸거나, requests 를 1001m 이나 999m 으로 두는 방법은 각각 문제가 있어 고르지 않았다.

   후속 조치

   • 이 문제를 사내 공지로 알렸다.

   교훈

   cgroup v1 환경에서 JVM 은 `cpu.shares` 값이 정확히 1024 일 때 이를 설정 없음으로 보고 노드의 CPU 수를 쓴다. CPU limit 없이 requests 만 1로 준 JVM 파드는 노드가 클수록 스레드를 많이 띄우고 메모리를 더 쓴다. 이 문제는 쓸 수 있는 CPU 수로 스레드 수를 정하는 WebFlux 같은 프레임워크에서 특히 크게 드러난다. 이런 설정이라면 `-XX:ActiveProcessorCount` 나 CPU limit 으로 CPU 수를 명시해야 한다. Hyperconnect 는 원래 운영 JVM 애플리케이션에 CPU requests 를 2 이상 주었고, 마이크로서비스가 늘어 자원을 아끼려다 이 문제를 만났다.

   사례 보기

원인별1