제품이 잘 개발/운영되고 있는지 어떻게 판단할까? #3 - 서버 성능 모니터링을 위한 USE 방법론

안녕하세요. 슬슬 날씨가 엄청 따뜻해지고 있네요. 오늘은 기온이 21도까지 올랐습니다 ㄷㄷ

최고 기온은 많이 올랐지만 일교차가 매우 크니 건강 무탈하시기 바랍니다.

 

지금까지 고객 관점에서 지표들을 공부했는데 이번에는 제품 관점에서 지표들을 공부해보려고 합니다.

 

특히 서버 성능을 중점적으로 알아보려고 하는데요! 이번에는 USE 방법론에 대해서 공부해보겠습니다:)

---

1. 용어 정리

USE는 Utilization, Saturation, Errors의 약자로, 시스템의 자원 사용률과 요청 처리 능력, 그리고 에러를 수집하여 성능 부하를 분석하는 지표입니다.

 

지표 측정 대상이 되는 자원들과 각각의 지표가 의미하는 바는 다음과 같습니다.

• Resource : 사용 중인 소켓 수, 코어 수, 메모리, 네트워크 인터페이스, 디스크 I/O 등
• Utilization : 시스템 자원이 얼마나 사용되고 있는지를 나타냅니다. ex) CPU 사용률, 메모리 사용량 등
• Saturation : 시스템이 아직 처리하지 못한 작업 수를 뜻합니다. ex) CPU 평균 런 큐 길이, 스왑 메모리 사이즈 등
• Errors : 에러 발생 빈도를 뜻합니다. ex) CPU 네트워크 패킷 드롭 수, 디스크 에러 등

2. 지표들은 어떻게 수집하죠?

AWS를 사용하신다면 EC2, RDS, Elasticache 등 많은 서비스에서 성능 모니터링을 제공해 줘서 기본적인 Utilization은 측정할 수 있습니다.

하지만 측정되지 않는 지표들도 많으니 서비스가 주로 사용하는 자원들은 따로 관리해야 합니다.

 

서비스가 쓰레드를 많이 생성한다면 생성된 스레드 수, 현재 실행 중인 스레드 수, 평균 수명보다 오래 살아있는 스레드 수 등을 측정하는 것이 좋습니다.

서비스의 네트워크 통신량이 많은 편이라면 사용 중인 소켓 수, 초당 송/수신 바이트 크기를 측정하는 것이 좋습니다.

 

Saturation과 Errors는 직접 수집해야 하는 경우가 많으니 시스템/서비스를 개발할 때 미리 준비해야 합니다.

• AWS에서 측정해주는 지표들도 있으니 활용하는 편이 좋습니다. AWS RDS의 경우, 성능 개선 도우미의 활성 세션 수를 통해서 Saturation을 측정할 수 있습니다.

 

측정된 지표들은 Grafana, Prometheus 등의 툴을 이용해서 시각화하여 모니터링할 수 있습니다.

• 저는 아직 AWS의 Cloudwatch, 슬랙봇을 이용해서 모니터링 하고 있습니다.
• 모니터링할 지표와 붙이고 싶은 기능이 많아진다면 상용 툴의 사용을 고려해봐야 할 것 같더라고요 ㅎㅎ

3. 수집된 지표를 어떻게 사용하세요?

서비스가 주로 사용하는 자원에 따라서 지표를 해석하는 방법이 다르겠지만 일반적으로 다음과 같이 해석합니다.

 

3.1. 높은 Utilization(100%)

• Utilization 100%는 대체로 서비스에 병목이 발생했다는 것을 뜻합니다.
• 자원의 종류에 따라서 100%가 아니어도 서비스에 병목을 발생시킬 수 있습니다. Disk 같은 경우에는 선점되기가 어려워서 사용량이 70% 정도만 성능 문제가 발생할 수 있습니다.

+++ Utilization이 낮으면 아무 문제가 없는 것일까요?

자원 사용량이 낮으면 병목도 적게 발생할 것이라고 생각하기 쉽습니다.

하지만 Utilization은 "자원 사용량 / 측정 주기" 이기 때문에 평균의 함정에 빠질 수 있습니다.

 

예를 들어, 측정 주기가 30초일 때, 0초에서 10초 동안 Utilization이 100%를 찍고 10초에서 30초 동안 Utilization이 30%였다면 Utilization이 53%로 측정될 것입니다.

측정 주기 별 Utilization, 평균의 함정

 

Saturation의 경우, 측정 주기도 중요하니 주의해야 합니다!

 

3.2. Saturation

• 정도에 상관없이 서비스에 문제가 있다는 것을 의미합니다.
• Saturation을 적극적으로 관리하는 제품의 경우에는 서비스 운영이 가능한 병목의 정도를(threshold) 식별하고, threshold를 초과했을 때에만 알림을 발생하기도 합니다.

3.3. Errors

• 성능 문제를 분석할 때 도움을 줍니다. 발생한 에러에 따라서 어떤 영역을 분석해야 하는지 쉽게 식별할 수 있죠!
• 예를 들어, 성능 문제가 발생하고 있을 때  네트워크 소켓을 더 이상 추가할 수 없다는 에러가 발생한다면 소켓 관리가 제대로 이뤄지고 있지 않다는 것을 알 수 있습니다. 소켓 생성하는 부분들을 살펴보겠죠?

4. USE 방법론의 한계는 없을까요?

USE 방법론은 인스턴스 하나의 문제를 식별하기에는 많은 도움을 줍니다.

 

하지만 수집되는 지표들이 low level이다보니 MSA, 분산시스템에 적용되었을 때 시스템의 어느 부분에서 문제가 발생했는지 식별하기 어렵습니다.

• 하나의 인스턴스에서 여러 서비스가 컨테이너 기반으로 실행되고 있는 경우
• 분산 처리 시스템: 사용자의 요청을 처리하는 프로세스를 worker pool의 인스턴스에서 실행하는 경우

 

그러면 USE 방법론의 한계를 어떻게 해결할 수 있을까요? 다음에 공부할 RED 방법론에서 알아보도록 하겠습니다 ㅎㅎㅎ

---

이번에 공부한 USE 방법론은 성능 최적화로 유명한 시스템 성능 엔지니어링 분야의 전문가 Brendan Gregg가 개발했습니다.

 

Brendan Gregg이 주장하기를 USE 방법론을 사용하면 5%의 노력으로 80%의 서버 이슈를 해소할 수 있었다고 하네요!

USE 방법론을 조금 더 자세히 공부하고 싶으시다면 Brendan Gregg의 블로그 글을 참고해 주세요!

• 참고 링크: https://www.brendangregg.com/usemethod.html