[Elasticsearch] 쿠버네티스 워커노드 CPU 100% 장애 복기

끊임없이 기록하고 배우고 즐기고 몰입하고 성장하자

 

 

 

 

 

 

 

바야흐로 2024년 7월 경,

Elasticsearch 기반의 모든 서비스가 멈출 뻔 했다.

어떤 이슈였을까?

출처 하단에 기재

 

 

 

 

 

 

 

일단 생김새부터 살펴보자. (큰 범위부터)

- 클러스터 안에 여러개의 노드 존재

- 노드 안에 여러개의 파드 존재

- 파드 안에 서비스가 띄워져 있음 (서비스별 파드)

 

"일꾼" 이라 할수있는 서비스별 파드들이

  => "사업장" 이라 할수있는 워커노드에 들어가서 일을 함

 

하나의 사업장엔 보통 20명정도의 일꾼이 일하는 중

 

 

 

 

 

 

 

그러던 어느날 사업장 하나가 멈춰버렸다.

워커노드 CPU 가 100% 까지 차오른 것.

 

 

 

 

 

 

 

 

 

 

간략하게 4개의 워커노드(사업장)이 있다고 치자.

워커노드1 : Pod A, Pod B, Pod C
워커노드2 : Pod A, Pod B, Pod C

워커노드3 : Pod D, Pod E, Pod F 

워커노드4 :Pod D, Pod E, Pod F

 

=> 위 예시에서 워커노드 4번만 CPU가 100%로 꽉 차서 사업장이 멈췄다면?

 

 

 

 

 

여기서 캐치할 수 있는 것은 (=캐치해야 하는 것은)

사용자 요청 기반의 API를 처리하는 일반적인 서비스단의 파드였다면,

Service request를 나뉘서 가져가기 떄문에

여러 개의 워커노드가 동시다발적으로 죽었을 것이다.

ex) A서비스 = > Pod A => 워커노드 1번과 2번 모두 죽음
다 죽었으면 큰일났다

 

 

본 이슈는 1개의 워커노드만 죽었다보니

특정 서비스단의 배치 파드라고 예상/판단할 수 있었고

 

4번 워커노드 사업장 안에서 일하고 있던

여러개의 파드 일꾼중에서 최우선적으로

배치 서비스 관련 파드의 로그를 직접 확인한 결과

 

역시나 배치 "Pod D" 가 범인임을 확신할 수 있었다.

 

 

 

 

 

 

 

 

단 한개의 파드에서 무슨일이?

일꾼 한명이 왜 사업장을 멈추게했는가

배치의 서버 로그를 수집하는 파일비트가 힘들어했던 것이다.

 

D서비스 담당자가 운영에 반영했던 배치 소스코드에서

개발 테스트시 사용했던 System.out.print("매우 긴 텍스트 덩어리"); 를 그대로 운영 반영한 것.

안그래도 배치인데 반복문까지 태웠다고하니

파일비트가 힘들어할 수 밖에...

 

 

 

 

 

 

 

 

 

+ 추가적으로

해당 파일비트는 예시상 서비스 D에서 발생하는 배치 서버 로그를 수집해서

특정 형식에 맞게 카프카로 던져주는데

덤프 텍스트 적재 뿐만 아니라 특정 형식으로 Trans할 수 없어서

"Dropping event no topic be selected~" 의 로그는 덤으로 적재되었으니

파일비트를 더 힘들게 했을것이다.

 

 

 

 

 

+ 그리고

배치가 아니었다면, 모든 파드가 죽었다면, 끔찍했다.., 서비스 중지..검색안되고...대참사...

 

 

 

 

 

어떡하면 좋을까?

 

물론, 잘못 반영된 출력문 소스코드는 지우는게 맞고

 

워커노드 안에 파드별 코어 제한을 두고자한다.

 

ex) 현재 1코어인 경우, 2코어로 증량 후

파일비트의 CPU 모니터링 후

CPU가 다시 90%에 근접한다면 3코어로 추가 증량

모니터링 후 필요시 4코어로 추가 증량.

 

 

 

 

 

 

 

 

 

똑똑한 그녀석은 뭐라고 했을까?

▶ 해결 방법

이 문제를 해결하기 위해 다음과 같은 조치를 취할 수 있습니다:

1. 코드 수정  => 조치 완료
   • 배치 소스코드에서 System.out.print를 제거하거나 로그 출력 빈도를 줄입니다.
   • 로그는 필요한 정보만 포함하도록 제한하고, 반복문 내에서 과도한 로그 출력이 없도록 합니다.
2. 로그 수집 설정 조정 => 서비스 별 담당자 지속 노력 필요한 부분이라고 생각된다.
   • 파일비트 설정을 조정하여 과도한 로그를 수집하지 않도록 합니다. 
   • 파일비트의 메모리 사용량과 CPU 사용량을 모니터링하고 필요 시 설정을 최적화합니다.
3. 리소스 할당 최적화 => 현실적인 조치 방법이다. 
   • 문제의 파드(Pod D)에 대한 리소스 요청과 제한을 조정하여 워커 노드의 과부하를 방지합니다.
   • Kubernetes에서 리소스 쿼터와 제한을 설정하여 특정 파드가 과도한 리소스를 사용하지 않도록 합니다.
4. 모니터링 및 알림 시스템 구축 => 구축 완료 (바로 아래 링크 참고)
   • 워커 노드와 파드의 CPU, 메모리 사용량을 지속적으로 모니터링하고, 특정 임계값을 초과할 경우 알림을 받도록 설정합니다.
   • Elasticsearch, 파일비트, 카프카 등의 로그 수집 시스템의 상태를 모니터링하고, 이상 징후가 발견되면 즉시 조치합니다.
   • 2024.07.06 - [IT/Elasticsearch] - [Elasticsearch] 백엔드 장애 감지 알림 시스템 구축 (ELK 기반 준실시간 서버 로그 모니터링)
5. 배포 프로세스 개선 => 리더급의 경우에만 stg, release, prd 권한 부여.
   • 운영 환경에 반영하기 전에 배치 소스코드의 로그 출력 부분을 철저히 검토하고, 필요한 로그만 출력되도록 합니다.
   • 코드 리뷰와 테스트 과정을 강화하여 운영 환경에서 문제가 발생하지 않도록 합니다.

[Elasticsearch] 백엔드 장애 감지 알림 시스템 구축 (ELK 기반 준실시간 서버 로그 모니터링)

 

 

 

 

 

 

 

 

그럼 끝이야?

 

모니터링 해서 코어 스펙 잘 설정해주면 되긴하는데

다만, 성능 지연될 수 있다.

 

파드의 성능을 제한하면
다량의 서버로그가 발생할 경우 버벅대면서 느려질 수 있기 때문에
파일비트가 로그를 읽어들여 카프카로 던지는 작업이 지연될 수 있다.

("리소스 한계" 항목으로 후술)

 

(검색쪽도 아니고, 로그 읽는 부분이니까

성능 보다는 어느정도 안정성을 우선시해도 괜찮은지 판단해보면 좋을 것 같다.)

 

그래서 모니터링을 통한 적절한 코어 설정이 필요한 상황이다.

 

 

넌 어떻게 생각해 지피티야?

파드별 코어 제한을 단계적으로 증량하는 방법은 효과적인 리소스 관리 및 문제 해결 전략이 될 수 있습니다. 이 접근법의 장점과 잠재적인 문제점을 함께 살펴보겠습니다.

장점

1. 점진적 대응:
   • CPU 사용량에 따라 코어를 점진적으로 증가시키면 필요 이상으로 많은 리소스를 할당하는 것을 방지할 수 있습니다.
   • 문제의 원인을 파악하면서 리소스를 적절히 할당할 수 있습니다.
2. 리소스 효율성:
   • 필요할 때만 리소스를 증량하므로, 클러스터 전체의 리소스를 효율적으로 사용하게 됩니다.
   • 특정 파드만 코어를 증량하기 때문에 다른 서비스에 영향을 최소화할 수 있습니다.
3. 모니터링 기반:
   • CPU 사용량 모니터링을 통해 실시간으로 리소스를 조정함으로써, 시스템의 안정성과 성능을 유지할 수 있습니다.

잠재적인 문제점

1. 복잡성 증가:
   • 자동화된 모니터링 및 리소스 할당 시스템을 구축하려면 추가적인 설정과 관리가 필요합니다.
   • CPU 사용량에 따른 리소스 증량 정책을 구현하기 위해 Kubernetes HPA(Horizontal Pod Autoscaler)나 VPA(Vertical Pod Autoscaler) 같은 도구를 사용해야 합니다.
2. 리소스 한계:
   • 클러스터의 리소스가 한정되어 있으므로, 특정 파드의 코어 수를 계속 증가시키면 다른 파드나 워커 노드에 영향을 줄 수 있습니다.
   • 코어 수를 계속해서 증가시켜도 근본적인 문제(예: 비효율적인 코드나 로그 과다 생성)를 해결하지 않으면 근본적인 성능 문제는 해결되지 않을 수 있습니다.

마치며

마케팅 프로모션 등의 서비스 배치처럼

한방에 큰 작업을 해야되는 경우

장애를 미리 예방할 수 있도록 잘 대비하자 !

 

 

 

 

 

 

 

참고 링크

쿠버네티스 #21 - 리소스(CPU/Memory) 할당과 관리 출처: https://bcho.tistory.com/1291 [조대협의 블로그:티스토리]

쿠버네티스 #21 - 리소스(CPU/Memory) 할당과 관리

 

쿠버네티스에서 POD, Node의 리스소 관리(CPU, memory, 등)

쿠버네티스에서 POD, Node의 리스소 관리(CPU, memory, 등)

 

https://www.bestdevops.com/pods-atomic-unit-on-the-kubernetes-platform/

PODS - Atomic unit on the Kubernetes Platform - DevOps - DevSecOps - SRE - DataOps - AIOps

 

https://blog.voidmainvoid.net/153

Elasticsearch와 Kibana, filebeat 를 활용한 쿠버네티스 로깅 아키텍쳐

 

 

 

 

 

.