서비스에 잘 동작하는지 알려면 지속적인 지표 수집이 필요하다.
DataDog, New Relic 등의 외부 서비스를 이용하는 것도 좋다.
성공은 몇개를 하고 있는가?
실패는 몇개를 하고 있는가?
실패의 비중이 너무 많지는 않은가?
에러가 발생하는 포인트가 어디인가? (에러의 종류)
CloudWatch를 통해서 '서비스 노드 지표'는 볼 수 있지만,
서비스 지표에 대해서는 자체적으로 수집해야한다.
비용 발생이 부담되지 않는다면, Datadog, New Relic 등의 모니터링 서비스를 사용하도록 한다.
모니터링지표가 특정 임계치를 넘는다면, 슬랙이나 메신저 등으로 알람을 보내 문제를 조기 파악 가능하도록 한다.
알람에 등급을 나눠 전송한다
같은 증상이라고 해도 대처 여부는 상황에 따라 다르다.
- Ex) 디스크가 80%이상 차있다면, 이에 대한 증설이나 데이터 삭제가 필요하다. 다만 몇일 사이에 문제가 될 수준이 아니라면, 인식 후 처리해도 된다.
- Ex) 현재 디스크가 80%이상 차있는데, 몇시간 전까지는 20~30% 정도의 수준이었다면, 디스크 사용패턴에 이상이 발생한 것이므로 즉각적인 확인이 필요하다.
서비스 출시 전 해당 서비스가 어느 정도의 안정성을 가질 수 있는지 테스트가 필요하다.
성능 테스트
해당 서비스가 어느 정도의 성능을 내는지 알아보는 테스트
(Ex. 성능이 1000 TPS 정도 된다)
부하 테스트
해당 서비스의 어느 부분에서 어느 정도의 부하가 걸리는지 알아보는 테스트
(Ex. 함수 A에서 시간이 ~만큼 걸린다)
스트레스 테스트
성능 테스트, 부하 테스트가 특정 시간 이상 반복되었을 때 안정성에 문제가 없는지 확인하는 테스트
OS에서 설정하는 값에 대한 확인 필요
- ulimit -a (Open Files, Max User Processes 튜닝 필요)
- /etc/limits.conf 수정 후 서버 재시작
AWS ec2는 재시작보단 ami에 기본적인 설정을 해두고, 이를 이용하는 편이 좋다.
주로 사용 되는 툴들은 다음과 같다.
강의 출처
The RED : 백엔드 에센셜 : 대용량 서비스를 위한 아키텍처 with Redis by 강대명 https://github.com/charsyam/the_red_infra/blob/main/install_pyenv.sh