728x90

미션 후기

미션을 통해 배운 점
- 웹 성능 측정 및 개선
- K6를 통한 부하 테스트
- grafana, cloudwatch를 통한 모니터링
- Nginx Access Log 설정

 

Jmeter와 NewRelic을 통해 부하 테스트를 하고 모니터링을 해본 경험이 있었다

(이전 글 참고: https://tong-dev.tistory.com/30?category=959546)

그때 부하테스트를 찾아보면서 K6, grafana를 들어본 적은 있었으나 사용해본 건 처음이었다

 

우선 두 개를 비교했을 때는 모니터링 툴은 느낌이 비슷했고

부하테스트 프로그램은 K6가 조금 더 편했던 것 같다

Jmeter가 그래픽 환경이라 편의성은 직관적이고 더 좋았지만

결과를 요약된 결과를 보거나 테스트를 돌릴 때 더 편했다

K6는 실행 스크립트를 작성해야 하기 때문에

간단한 테스트라면 Jmeter, 각 잡고 하는 테스트라면 K6

때에 따라 적당히 사용하면 좋을 것 같다


웹 성능 측정 및 부하테스트

웹 성능 예산 측정 사이트

https://pagespeed.web.dev/?utm_source=psi&utm_medium=redirect 

 

PageSpeed Insights

올바른 URL을 입력하세요.

pagespeed.web.dev

 

용어 정리

  • LCP (Largest Contentful Paint)
    • 페이지에서 가장 용량이 큰 콘텐츠가 표시되는 시점
    • FCP의 경우 페이지에 스플래시 화면이 표시되거나 로딩중 아이콘이 표시되는 경우도 포함하기 때문에 사용자와 그다지 관련이 없음
    • FMP를 측정하는 것이 복잡하기 때문에 가장 용량이 큰 컨텐츠가 렌더링 되는 시기인 LCP를 주요 컨텐츠가 로드되는 시기로 판단하는 것을 권장
  • CLS (Cumulative Layout Shift)
    • 페이지가 로드되기 시작하는 시점과 lifecycle 상태가 숨김으로 변경되는 시점 사이에 발생하는 모든 예기치 않은 레이아웃 이동의 누적 점수를 측정
    • 일반적으로 리소스가 비동기적으로 로드되거나 DOM 요소가 기존 컨텐츠가 있는 페이지에 동적으로 추가될 때 발생
  • FID (First Input Delay)
    • 사용자가 페이지와 처음 상호작용한(클릭 또는 키 입력 등) 시간부터 브라우저가 실제로 이벤트 핸들러 처리를 시작할 수 있는 시간까지의 시간을 측정
    • 일반적으로 입력 지연은 브라우저의 기본 스레드가 다른 작업 (예: 대용량 js 파일 파싱)을 실행 중일 때 발생
    • 메인 스레드에서 작업 중인데 타 작업이 발생하면 브라우저가 이에 대응하는데 FID만큼의 시간이 소요
  • TTFB (Time To First Byte)
    • 페이지를 요청했을 때 서버에서 데이터의 첫 번째 바이트가 도착하는 시점
  • FCP (First Contentful Paint)
    • FCP는 페이지가 로드되기 시작하고 컨텐츠의 일부가 화면에 렌더링 될 때까지의 시간을 의미
  • FMP (First Meaningful Paint)
    • 브라우저가 페이지의 주요 컨텐츠들을 화면에 렌더링 하기 시작하는 순간
    • FMP는 페이지 로드의 작은 차이에 지나치게 민감하기 때문에 일관성이 떨어져서 LCP를 측정하는 것을 권장
  • TTI (Time To Interactive)
    • 웹 페이지가 완전히 상호작용이 가능(interactive)하게 되는 시점
  • TBT (Total Blocking Time)
    • 스레드가 input 응답을 막을 정도로 오래 차단되었을 때 FCP와 TTI 사이의 총 시간
  • Speed Index
    • 뷰 포트 내의 콘텐츠가 눈에 띄게 채워지는 속도를 보여주는 페이지 로드 성능을 측정

 

성능 기준 설정

  • 정량 / 시간 / 규칙 등을 기반으로 성능 기준을 세웁니다.
  • 모든 페이지에 대해 성능 기준을 세우는 것이 좋으나, 우선은 서비스에 중요한 페이지부터 작성해봅니다.
  • 처음에 기준 세우기 어렵다고 느낀다면, 아래와 같이 예산을 잡아봅니다.
    • 페이지 로드 3초 미만
    • TTI 5초 미만
    • 압축된 리소스 최대 크기 200KB 미만
  • 사용자에게 컨텐츠가 빠르게 노출되고 렌더링 하는 것이 중요할 경우 FCP를 낮게
  • 사용자가 관련 링크를 빠르게 클릭해야 할 경우 TTI의 우선순위가 높게

Code / Feedback

🚀 1단계 - 웹 성능 테스트

https://github.com/next-step/infra-subway-monitoring/pull/301

 

1단계 - 웹 성능 테스트 by tyakamyz · Pull Request #301 · next-step/infra-subway-monitoring

안녕하세요 리뷰어님 이번 미션을 진행하게된 박시현 입니다 :) 1단계 - 웹 성능 테스트 PR 드립니다 처음 접해보는 부분이라 난항(?)이 예상되네요... 부족한 부분이 많겠지만 열심히 따라가보겠

github.com


🚀 2단계 - 부하테스트

https://github.com/next-step/infra-subway-monitoring/pull/316

 

2단계 - 부하테스트 by tyakamyz · Pull Request #316 · next-step/infra-subway-monitoring

안녕하세요 리뷰어님 2단계 - 부하테스트 PR 드립니다 :) 결과는 어떤식으로 올려야될지 몰라서 스크린샷으로 첨부했습니다 기준을 나름 세운다고 세웠는데 제대로 작성한건지 잘 모르겠네요..

github.com


🚀 3단계 - 로깅, 모니터링

https://github.com/next-step/infra-subway-monitoring/pull/344

 

3단계 - 로깅, 모니터링 by tyakamyz · Pull Request #344 · next-step/infra-subway-monitoring

안녕하세요 리뷰어님 3단계 - 로깅, 모니터링 PR 드립니다 :) 그럼 마지막 리뷰도 잘 부탁 드리겠습니다!

github.com

728x90
복사했습니다!