[CASE STUDY] 리멤버의 서비스 모니터링 분석

리멤버는 서비스 모니터링을 어떻게 하고 있을까? - DRAMA&COMPANY

 

드라마앤컴퍼니는 Amazon CloudWatch를 통해 서버의 상태를 실시간으로 확인하여 문제가 발생할 경우 각 담당자들에게 메일을 발송하는 Amazon Simple Email Service(Amazon SES)도 이용하고 있습니다.

 

AWS 서비스 소개

Cloud Watch?

Amazon CloudWatch는 Amazon Web Services(AWS) 리소스 및 AWS에서 실행되는 애플리케이션을 실시간으로 모니터링 할 수 있다. CloudWatch를 사용하여 리소스 및 애플리케이션에 대해 측정할 수 있는 변수인 지표를 수집하고 추적할 수 있다.

 

지표

• 시간 순서로 정리된 데이터의 집합, AWS 서비스, 애플리케이션의 퍼포먼스를 모니터링하기 위한 지표 생성
• CloudWatch Agent, API를 활용해 커스텀 지표도 생성할 수 있음

# 데이터 집어 넣기
aws cloudwatch put-metric-data --namespace namespace --metric-name test-metric
  --dimensions name=A,size=small --value 10 --timestamp 2020-04-22T12:40:00

 

SNS?

Amazon Simple Notification Service(Amazon SNS)는 구독 중인 엔드포인트 또는 클라이언트에 메시지를 전달 또는 전송하는 것을 조정하고 관리한다. CloudWatch와 함께 Amazon SNS를 사용하여 경보 임계값에 도달한 경우 메시지를 전송한다.

 

 

SES?

Amazon Simple Email Service(SES)는 사용자의 이메일 주소와 도메인을 사용해 이메일을 보내고 받기 위한 경제적이고 손쉬운 방법을 제공하는 이메일 플랫폼

 

CloudWatch를 사용하여 Amazon SNS 주제 모니터링 하는 법

Amazon SNS와 Amazon CloudWatch가 통합되어 모든 활성 Amazon SNS 알림에 대한 지표를 수집, 확인 및 분석할 수 있다. Amazon SNS용 CloudWatch를 구성하고 나면 Amazon SNS 주제, 푸시 알림 및 SMS 전송의 성능에 대한 더 나은 인사이트를 얻을 수 있다.

 

SNS에서 원하는 이름의 주제를 선정한다 → CloudWatch를 통해 모니터링하고 싶은 알람을 설정한다. → 해당 sns 주제가 람다 함수에서 트리거로 작용한다. → 함수 생성 시 필터에 slack을 입력하면 목록이 노출되어 slack으로 알림이 전송된다.

 

리멤버가 모니터링하는 것들

서비스가 어느 정도 시장에 안착하게 되면 그 다음부터는 안정적으로 운영하는 것이 점점 더 중요해진다. 신규 기능 개발도 중요하지만 그에 못지 않게 서비스의 안정성 유지도 개발팀 업무의 큰 비중을 차지하게 되었다. 서비스의 안정성을 높이기 위한 여러 가지 방법 중에서 우리가 안정적인 서비스 운영을 위해 일상적으로 가장 많이 수행하는 활동, 즉 애플리케이션 모니터링 관점에서 살펴보자.

 

모니터링 시스템이 제대로 갖춰져 있지 않다보니 고객의 클레임이 들어와도 사실상 이슈의 원인을 제대로 추적하지 못한 적이 한 두번이 아니었습니다. 그래서 이런 점을 해결하고자 APM(Application Performance Management 혹은 Monitoring)과 Centralized Logging 시스템을 구축하기로 결정하였습니다.

 

APM이란? 소프트웨어 도구와 원격 측정 데이터를 사용하여 비즈니스 크리티컬 애플리케이션의 성능을 모니터링하는 프로세스

 

제공 중인 지표 목록 →

인스턴스에 사용 가능한 CloudWatch 지표 나열 - Amazon Elastic Compute Cloud

 

Application Performance

AP는 일반적으로 다음과 같은 일반적인 지표를 추정한다. CPU 사용량, 평균 응답 시간, 오류율, 트랜잭션 추적, 인스턴스, 요청, 가동시간 중 리멤버는 현재 New Relic으로 throughtput, 평균 응답 시간, 오류 발생율, 슬로우 트랜잭션 및 cpu/메모리 사용율을 주로 확인한다.

 

Infrastructure Metrics

서버 프로세스가 아닌 다른 요인으로 서버에 문제가 발생했을 경우 New Relic으로 확인하고 있다. 특히 트래픽 별 IO양, 디스크 사용율은 물론 Infrastructure의 관점의 여러 가지 metrics를 통해 Load average와 CPU 사용율을 중심으로 문제가 되는 지점을 파악할 수 있다. 이후 동일한 문제가 발생하지 않기 위해 자동화.

 

특정 서비스의 health 를 나타내는 지표

리멤버 도메인 특성상 관리해야 하는 지표가 있을 경우 상황에 따라 개발자들이 인지 후 조치를 위해 CloudWatch에 custom metric 전송 후 alarm을 만들어 관찰한다.

 

 

리벰버와 특히 관련된 관측 지표들 정리

• throughtput : 네트워크에서 초당 실제로 처리되는 패킷의 양
• 평균 응답 시간 : 애플리케이션 서버가 사용자에게 요청 결과를 반환하는 데 걸리는 시간
• Load average : 얼마나 많은 프로세스가 실행 중 혹은 실행 대기중인지를 의미하는 수치

리벰버가 모니터링 도구로써 AWS CloudWatch와 New Relic를 사용하는 법, 그리고 차이점은?

리멤버는 AWS CloudWatch를 주 기능으로 사용하지 않는다. New Relic과 함께 보조하며 사용한다.

또한 CloudWatch는 원하는 대상에 CloudWatch 지표를 지속적으로 스트리밍할 수 있다 → AWS Lambda 함수 newrelic-log-ingestion을 사용하여 Amazon CloudWatch 로그를 뉴렐릭으로 보낼 수 있음

 

(1) 문제 발생 시 Slack 으로 인지

• NewRelic의 경우
  • terraform 모듈을 이용해 각 애플리케이션 마다 Slack으로 알람 메시지 전송하는 Alert 관리
  • Alert 발생 시 과정을 스레드로 기록
• AWS CloudWatch + SNS
  • slack으로 알람 메시지가 전송
  • 일부 구성원들 및 일부 지표에 한해 이메일로 받도록 함

(2) 사용자 문의 및 모니터링 중 이상징후 발견(troubleshooting, triage)

• 특정 사용자의 개인적인 문제 대응
  • Logs에서 해당 유저가 요청한 API목록 확인
• 서비스 지표에 이상징후에 대한 대응.
  • 두 서비스 모두 모니터링 서비스 모니터링
• troubleshooting → 가장 단순하고 빈도 높은 원인에서 가능성을 지워가는 문제 해결 방법을 뜻한다.
• triage → 심각도 정도에 따른 우선 순위 분류
•  

근데 왜 new relic을 같이 사용할까?

New Relic has extensible support for multi-cloud and hybrid environments, allowing businesses to monitor not only AWS resources but also on-premises, other cloud providers, and third-party services.

→ (리멤버 블로그에는 안 나와있음) 다른 문서를 보니까 비용도 비용이지만, 아마 aws이외에 서비스도 이용해서 그냥 new relic이랑 같이 쓰든 듯함

 

CloudWatch 요금 폭탄 주의

애플리케이션 로그를 CloudWatch 에 쌓지 말자!

AWS의 CloudWatch Log는 여러 서비스와 연동이 편리하지만 비용이 다른 로그 저장소들에 비해서 매우 높다.

CloudWatch Log는 수집 항목이 $0.76 per GB에 비해 NewRelic에서 한 달 기간 동안 스토어 비용 포함해 $0.3 per GB이다.

 

NewRelic처럼 대체제(외부 로깅 프레임워크)가 있기 때문에 어플리케이션 로그를 포함한 여러 형태, 여러 소스의 로그들을 CloudWatch에 쌓이지 않게 할 수 있다면 로그를 남기지 않는 것이 비용 절감에 매우 도움이 된다. 이와 관련한 글은 aws 공식 블로그에서도 확인할 수 있다.(출처)

Complexities and Best Practices for AWS Lambda Logging | Amazon Web Services

 

→ 하지만 어떤 로그가 주요 기여자인지 확인할 필요가 있다!

이를 위해 Log group을 나누어 imcomingBytes를 지표로 사용하여 그래프로 확인한다.(출처)

Why Is My AWS CloudWatch Service Cost So High?

(imcomingBytes : CloudWatch Logs로 업로드되는 비압축 바이트 단위의 로그 이벤트 볼륨)

 

→ 만약 로그를 남긴다고 해도 일정 시간이 지난 로그는 즉시 제거할 필요가 있다. 로그 스토리지 비용은 $0.03 per GB다. 50글자 메시지 + 메타 데이터 ⇒ 8M 로그에 1GB 데이터가 저장됨. 1초에 10번정도 실행되는 함수에 이런 메시지 9개 정도가 있으면 매일 1GB 로그가 생성되고 이 정도 양이면 한달에 15달러를 내는 거임.(출처)

AWS Lambda logging best practices - Better Dev

 

AWS Cloud Watch를 포함한 기존 모니터링 방식의 한계

데이터 사이즈의 크기가 늘어나면서 더 높은 처리 속도가 필요하였고, API 로그 등의 데이터를 DB 데이터와 연동해서 봐야하는 Needs가 증가했지만, 이런 케이스의 로그 데이터 분석은 AWS CloudWatch에서 살펴보기에 어려움이 있었다.

 

→ 이런 빅데이터를 다루기 위해 리멤버는 하둡 프레임워크를 추가로 다루기 위해 Amazon EMR 사용~!

 

mazon EMR? Amazon EMR을 사용하면 빅 데이터 환경 및 애플리케이션을 간단하게 구축하고 운영할 수 있다. 관련 EMR 기능을 통해 클러스터 및 협업 개발을 위한 EMR Studio를 쉽게 프로비저닝하고 관리형으로 확장하고 재구성할 수 있다.