[Service] 장애 포인트를 찾기 위한 모니터링

서비스가 잘 동작하고 있는지 확인하기 위해서 사용한다.
- 서비스가 잘 동작하고 있는가?
- 에러가 발생하고 있지는 않은가?
- CPU, DISK 사용량 등 일정량을 넘지 않았는지?
지속적인 지표 수집이 필요하다.
- 서비스에서의 지표
  * API Call 수
  * API Latency -> 평균 속도가 아닌 Median 값, 99% 값, 최대값 등의 지표를 수집해야 한다.
- 서비스 노드 지표
  * 서버의 상태
  * CPU 사용량
  * 메모리 사용량
  * 디스크 사용량
  * 네트워크 사용량 (파일이나 데이터의 전송량이 얼마나 되는가?)
  * 현재 동작중인 정상적인 서버의 수
- 에러 수집
알림 기능 사용
- 모니터링 지표가 특정 값을 넘는다면, 슬랙이나 메시저 등으로 알람을 보내서 항상 특정 상항에 대한 알람을 보낸다.
- 등급을 나눠서 알람을 전송한다.

AWS에서 제공하는 기본적인 지표들

* CloudWatch를 통해서 확인할 수 있다. -> 서비스 지표들은 자체적으로 수집해야 한다.

* Datadog, New Relic, Watap 등의 모니터링 서비스를 사용하는 것이 좋다.

Prometheus

exporter라는 agent를 사용하여 여러 가지 필요한 툴들의 모니터링이 가능하다.
MySQL, Redis 등의 컴포넌트에 대한 metric 수집을 위한 exporter가 이미 존재하고, 각 서버 노드의 필요 정보(CPU 사용량, 메모리 사용량, alive 여부, 네트워크 사용량)에 대한 exporter가 이미 존재한다.
데이터 수집을 PULL 방식을 사용하므로, Prmetheus 자체에 문제가 발생하더라도 모니터링 호스트에 장애가 전달되지 않는다.

Grafana

Prometheus에서도 간단한 그래프를 사용하여 데이터의 Visualization이 가능하지만, Grafana를 적용하면 좀 더 다양한 그래프를 사용할 수 있다.
노드 정보를 보여주는 것과 서비스 지표를 보여주는 것이 서로 다른 정보의 형태이므로 Graph를 다양하게 사용할 필요가 있어 사용한다.

* 실제 모니터링은 Prometheus에서 진행하고 Visualization을 Grafana로 이용한다.

* Grafana의 DataSource에 Prometheus를 추가하여 제공 받은 정보를 바탕으로 Visualization을 할 수 있다.

서비스 출시 전에 해당 서비스가 어느 정도의 안정성을 가질 수 있는지 확인하는 테스트
- 성능 테스트/부하 테스트/ 스트레스 테스트로 나눌 수 있다.

해당 서비스가 어느 정도의 성능을 내는지 알아보는 테스트
- Ex) 성능이 100TPS 정도 된다.
주의 사항
- 단순히 API 하나 호출하는 것이 아니라, 실제 서비스에서 사용되는 패턴으로 테스트가 필요하다.
  1. API 마다 부하의 종료가 다르다.
  2. 여러 API의 조합이 필요할 수 있다.
- 클라이언트의 성능 한계를 확인한다.
  1. 부하를 주는 클라이언트의 한계로 인해서 성능 측정이 어려울 수 있으니, 클라이언트를 점점 늘리면서 테스트를 진행해야 한다.
- OS 에서 설정하는 값들에 대한 확인이 필요하다.
  1. Open Files -> OS에서 열 수 있는 파일 개수, AWS의 경우 사양에 따라 다르게 설정되어 있다.
  2. Max User Processes 값의 튜닝이 필요하다.
  3. /etc/limis.conf 수정
성능 테스트 툴
- Ngrinder
  1. 평균 TPS 확인 가능
  2. 최대 TPS 확인 가능
  3. 성공 수, 실패 수
  4. 실패 수가 전체의 30%이면, 테스트는 실패하게 된다.
- Locust
- JMeter
- Gatling
- ab

Dev-Logs