💡 테스트를 시작하기 전에
어떻게 ?
webpagetest로 인터넷 구간,
부하 테스트로 브라우저 렌더링을 제외한 전구간 테스트 가능
무엇을 ?
사용자는 응답시간이 20% 이상일 때 차이를 인식
3초안에 로딩되지 않으면 53% 사용자가 떠난다는 규칙
- 무엇을 테스트할 지 정한다.
- 트래픽이 많은 페이지가 무엇인가?
- 가장 중요한 페이지가 무엇인가?
- 경쟁 사이트 또는 유사 사이트의 성능을 조사한다.
💡 인터넷 구간
인터넷 구간에서 성능에 영향을 주는 요소
httml, css, js, 이미지, 웹 폰트
정적 리소스를 받아 브라우저가 렌더링
webpagetest
webpagetest에서는 웹 서버에 영향을 받는 지표와
정적 컨텐츠와 네트워크 상태에 영향을 받는 지표를 보여줌
웹 서버에 영향을 받는 지표
- TLS 및 HTTP 헤더 보안성 + JS 라이브러리의 보안 취약성
- 서버 응답 시간 + 네트워크 비용
- keep-alive 설정
- gzip 압축
- 이미지 압축(사용자는 이미지 품질 차이보다 네트워크 지연에 더 민감하다)
- 정적 컨텐츠를 캐싱했는지
- CDN을 사용하는지(이왕 받을거면 가까운 곳에서!)
💡 웹 성능 예산
어느 정도까지 허용이 가능한지 목표를 정해야 한다.
우선순위
- quantity-based : 정적 리소스 기준
- timing-based : FCP 3초 미만 등
- Rule-based : 80점 이상
그래서 서버 응답시간이 어느정도가 적당한지 기준을 세워보자
처음에는 가설로 시작할 수 밖에 없다.
정답에 연연하지 않기
💡 부하 테스트
성능 예산이 사용자 경험과 관련 있는건 알겠는데...
왜 ?
- 장애가 없을 수는 없다.
- 장애 내성을 가진 서비스는 어떻게 만들까?
- 현재 시스템이 어느 정도의 부하를 견딜까?
- 한계치에서 병목이 발생하는 시점은 어디일까?
- 이슈가 터지고 나서 대응하는 건 어려우니까 한계치를 미리 확인함으로써 어느정도까지 버티는지, 어떤 증상이 나타나는지, 어떻게 개선할지 계획할 수 있다.
가용성
- 시스템이 서비스를 정상적으로 제공할 수 있는 상태
- 단일 장애점(SPOF)을 없애고 확장성 있는 서비스를 만들어야 한다.
- 한 대의 서버가 문제가 생겨도 사용자는 인지 못할 수 있다.
단일 장애점
서버 장비가 장애날 경우 서비스가 중단
성능
- 얼마나 많은 사람이 동시에 사용할 수 있는지 (Users)
- 일정 시간동안 얼마나 많이 처리할 수 있는지 (TPS)
- 서비스가 얼마나 빠른지 (Time)
Users
- Concurrent User, Active User(VUser와 유사)
- 보기만 하는 서비스는 이 지표가 별로 중요하지 않음
TPS
- 서비스를 사용하는 사람이 많아지면 처리량도 증가
- 더 이상 처리하지 못하는 지점이 발생
- 응답 시간이 길어짐
- Stress Test를 통해 한계점 파악 가능
- scale out, scale up을 통해 처리량 증가 가능
- 성능에 문제가 있으면 단일 사용자에 대한 응답 속도가 느려짐
- 확장성에 문제가 있으면 부하가 많아질 경우 응답 속도가 느려짐
Time
- 서버의 리소스 문제
- 프로그램 로직 상 문제
- DB 또는 다른 서비스와의 connection 문제
종류
smoke
- VUser 1~2로 구성
- 최소한의 부하로 테스트 시나리오 오류를 검증한다.
- 최소 부하로 시스템 오류가 없는지 확인한다.
load
- 평소 트래픽과 최대 트래픽으로 구성
- 기능이 정상 동작하는지 검증
- 배포, 인프라 변경 시 성능 변화 확인
stress
- 점진적으로 부하가 증가하도록 구성
- 최대 사용자, 최대 처리량 등 한계점 확인
- 스트레스 테스트 이후 수동 개입 없이 복구되는지 확인
load와 stress 차이
- load : 평소 피크타임 트래픽에 기능이 정상 동작하는지
- stress : 부하 테스트 상에서 문제가 없음을 확인한 후 어느 정도까지 가능한지 파악하기 위함
도구
k6
- 자바스크립트 기반 시나리오 작성 가능
- 시나리오 기반 테스트
- 동시 접속자 수, 요청 간격, 최대 처리량 등 부하 조정 가능
- 부하 테스트 서버 scale out 지원
성능 목표
- DAU
- 피크 시간대 집중률 (최대 트래픽 / 평소 트래픽)
- 1명당 1일 평균 요청 수
throughput : 1일 평균 rps ~ 1일 최대 rps
테스트 기간
- 30분 ~ 2시간
시나리오
- 접속 빈도가 높은 기능
- 서버 리소스 소비량이 높은 기능
- DB를 사용하는 기능
- 외부 시스템과 통신하는 기능
💡 진단
문제 상황을 인지하고 원인을 파악하는 것
문제가 바로 직시되는 것이 있고 생각을 해봐야 하는 것이 있다.
각 자원은 여유가 있거나 포화상태거나 둘 중에 하나
상태 정보는 요약, 이벤트 기록, 스냅샷(top)
요약으로 상태, 스냅샷으로 원인 파악
💡 USE 방법론
Utilization : 얼만큼 자원을 썼는지
Saturation : 얼마나 많은 부하가 몰리는지
Error : 에러가 발생했는지
순서는 E -> U -> S
에러 로그
- 로그만 확인해도 원인과 해결 방안을 파악하기 쉽다.
- 직전 배포와 연관이 있는지
- 특정 시간, 특정 사용자, 특정 조건에 따른 문제인지
- 어떤 맥락에서 발생하는 에러인지
시스템 로그와 애플리케이션 로그로 나뉨
로깅 주의점
- 사이드 이펙트 피해라
- 데이터와 내용이 충실
- 개인정보는 마스킹
사용률
- CPU 사용률, 가용 메모리, RX/TX 패킷량, 디스크 사용률, IOPS 확인
CPU 사용률
- CPU 사용률이 높다면 잘 쓰고 있다.
- 100%면 포화 상태, 대기할 프로세스가 생길 수 있음
- 프로세스의 block 상태 확인
가용 메모리
- swap in, out이 발생한다면 메모리가 부족하다는 의미
- swap이 발생하면 RES(실제 물리 메모리 영역의 크기)가 큰 프로세스가 있는지 확인
디스크 사용률
- 부족하면 증설
- 불필요 파일 삭제
네트워크 사용률
- active/s: 서버에서 다른 외부 장비로 연결한 횟수
- passive/s: 서버에 새로 접근한 클라이언트 수
포화? 부하!
uptime
1, 5, 15분마다 상태가 R, D인 프로세스의 평균 값
처리를 실행하려고 해도 실행할 수 없어서 대기하고 있는 프로세스 수
load average가 core 수보다 높은지
