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

안녕하세요. 저번 주말에는 20도까지 올라가더니 다시 날씨가 쌀쌀해졌습니다 ㅋㅋㅋ
 
봄비가 내리고 있는데 이번 봄에 벚꽃은 언제 필 지 궁금하네요 ㅎㅎ
 
이번에도 서버 성능 모니터링에 관한 방법론을 공부하려고 합니다. 바로 저번에 말씀드렸던 RED 방법론이죠!

---

1. 용어 정리

RED는 Rate, Errors, Duration의 약자로, 서비스의 초당 처리한 요청 수(Rate), 요청을 처리하는 중에 발생하는 에러 수(Errors), 요청 별 처리 시간(Durtaion)을 수집하여 성능 부하를 분석하는 지표입니다.

• RED 방법론은 고수준의 지표를 제공합니다. 저수준의 지표를 사용하는 USE 방법론과 비교됩니다.
• 지표들을 보시면 알겠지만 "요청"이라는 단어가 붙어 있습니다. 그래서 USE와는 관점이  다릅니다.

 

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

이전 글에서 말씀드렸던 것처럼 RED 방법론은 MSA, 분산 시스템에서 유용하게 사용될 수 있습니다.

그런데! 어떻게 하면 MSA와 분산 시스템처럼 여러 개의 인스턴스가 실행되고 있는 환경에서 요청에 대한 지표들을 수집할 수 있을까요?

 

2.1. 각 인스턴스에서 로깅하기

하나의 인스턴스에 대한 지표들은 그냥 바로 바로 로그를 남기면 됩니다.

그렇지만 이렇게 로그를 남기면 문제가 발생했을 때 인스턴스 하나 하나 들어가서 로그를 확인해야 합니다.

• 실제로 로그를 이렇게 분석한 적이 있는데 정말 정말 정말 불편합니다 ㅜ

이슈가 보고될 때마다 6개의 PROD 인스턴스에 들어가서 하나하나 찾아야 하는 불편함...ㅜㅠ

 

2.2. 중앙 집중식 로그 시스템 활용하기

이를 개선하기 위해서 중앙 로그 저장소를 사용하는 방법이 있습니다.

 

이런 로깅 시스템을 중앙 집중식 로그 시스템이라고 하는데 대표적으로 Elasticsearch, Logstash, Kibana(ELK) 스택과 Elasticsearch, Fluentd, Kibana(EFK) 스택이 있습니다.

 

아래 그림과 같이 시스템/서비스를 구성하는 인스턴스들은 Log Relay 레이어로 로그(데이터)를 전달합니다.

• 서비스가 어떤 요청을 받았는지, 에러 정보, 처리 시간 등의 정보가 로그에 포함되어 있습니다.

인스턴스로부터 로그를 전달 받은 Log Relay 레이어는 로그를 로그 저장소로 전달합니다.

• 시스템이 커질수록 전달되는 로그의 양이 기하급수적으로 증가하기 때문에 로그를 얼마나 안정적으로 전달하는지가 중요합니다.

로그 시스템 개요도

 

AWS에도 ELK, EFK 스택을 직접 구성할 수 있고, AWS 전용 서비스들을 이용해서 만들 수도 있습니다.

• Kinesis와 Opensearch(AWS용 Elasticsearch)를 사용해서 로그 시스템을 구성할 수 있습니다.
• Opensearch의 비용이 부담스럽다면 Kinesis, S3, Glue, Athena를 이용해서 사용한만큼 비용을 지불하는 로그 시스템을 구성할 수도 있습니다.

2.3. 해치웠나...?

이렇게 로그 시스템을 구성하면 끝일까요?

 

이제 진짜 작업이 남았습니다. 초당 처리한 요청 수, 요청 처리 중에 발생한 에러 수, 요청 별 처리 시간을 수집할 수 있게끔 로그를 작성해야 합니다.

 

숙련된 엔지니어라면 어떤 로그를 어떻게 남겨야 하는지 알고 있겠지만 처음 접하는 경우에는 많이 헤맬 수 있습니다.

• + 숙련된 엔지니어라면 바퀴를 재발명하지 않습니다 ㅋㅋㅋ

이럴 때 Application Performance Manager(APM)을 활용하면 빠르고 정확하게 지표들을 수집할 수 있습니다.

3. APM 활용하기

APM은 시스템/서비스의 성능을 모니터링하고 관리해주는데 다음과 같은 장점들이 있습니다.

• APM에서 기본적으로 제공하는 지표, 시각화로 애플리케이션의 성능 문제를 신속하게 식별하고 해결할 수 있습니다.
• 서비스뿐만 아니라 네트워크 통신, 데이터베이스 등 시스템의 모든 요소를 한 눈에 볼 수 있습니다.
• 경우에 따라서 클라이언트 레벨의 성능 지표까지 수집됩니다.

하지만 APM의 비용과 시스템에 적용하기 위해 코드를 수정해야 하는 추가 작업이 필요할 수 있습니다.

실제로 저희 제품에 데이터독 도입을 검토한 적이 있는데 1) 생각보다 비싼 비용과 2) 도입을 위해 코드를 수정해야 하는 작업량이 커서 보류하게 되었습니다.

그런데 1) 비용 부분은 쉽게 공감되는데 2) 코드는 왜 수정해야 했을까요?

일반적으로 APM이 지표를 수집하기 위해서는 APM 에이전트를 시스템에 연동해야 합니다.
시스템에 따라서 에이전트 연동 방식이 달라지는데 golang 같은 경우에는 agent sdk 코드를 많이 추가해줘야 했습니다 ㅜ

다음에 기회가 있다면 APM을 적용해보고 싶네요...!

 

데이터독, 제니퍼, 뉴렐릭 등 다양한 APM 제품들이 있는데 각 제품들이 지원하는 기능들과 요금을 잘 고려해서 선택하면 됩니다!

• AWS에서는 X-Ray를 통해 이러한 지표를 수집할 수 있습니다.

 

이제 APM을 사용해야겠죠?

데이터독을 예로 들면 시스템과 연동이 잘 되었다면 아래 이미지들과 같이 시스템의 지표들을 자동으로 수집하게 됩니다.

 

그리고 지표 별로 알림 조건과, 어떤 알림앱을 사용할지 설정할 수 있습니다.

• CPU 사용량, 인스턴스 health check 실패 수, 요청 별 200 OK 수 등 다양한 조건을 설정할 수 있습니다.

https://docs.datadoghq.com

 

지표 설정, 알림 조건, 알림앱 연동을 직접 개발해야 한다면 상당히 큰 작업이 필요하겠지만 APM이 있어서 다행이죠!

4. RED는 한계가 없을까요?

위에서도 말씀드렸던 것처럼 RED 방법론은 고수준의 지표를 바탕으로 성능 문제를 추적합니다.

 

그래서 어떤 서비스의 어떤 기능에서 문제가 발생했는지 식별되더라도 구체적인 개선을 위해서는 저수준의 지표가 필요해집니다.

 

결국 USE 방법론과 RED 방법론을 같이 사용하는 것이 가장 좋습니다.

• USE, RED 전부 적용하기에는 시간이 부족하시다면 APM을 활용하여 속도를 가속할 수 있을거에요!