부하 테스트 회고

컴클로딩·2022년 9월 23일
0
post-thumbnail

📍 Intro

  • 항해99 실전프로젝트를 6주간 진행하면서 부하 테스트를 진행했다.
  • 처음에 1주일이라는 기간을 잡았는데 사실상 2주라는 시간이 할애되었고 핵심 기능인 만큼 시간이 걸리더라도 목표를 달성하는 것에 초점을 맞췄다.

❓ 부하 테스트 "왜" 했어?

  1. 여러 사례를 토대로 각 시스템의 응답 성능을 예측
  2. 부하가 많이 발생하면 성능을 개선
  3. 원하는 성능을 완성하는 데 필요한 하드웨어를 미리 선정
  4. 시스템 확장성을 가졌는지 확인
  5. 시스템 확장성에 대한 특성을 파악

부하 테스트 전제 조건

  • 테스트 대상 시스템 범위
    • t2.micro EC2 * 2(개)
    • db.t3.micro RDS * 1(1개)
    • Classic Load Balance
  • 데이터 양
    • 유저 450만
      • 무신사 회원 수 600만, 브랜디 회원 가입자수 305만 ⇒ 평균 450만
    • 상품 100만
      • 브랜디의 경우 약 100만개의 상품 데이터 보유하고 있으며 패션 플랫폼 중에서 가장 많은 데이터를 보유하고 있음.
    • 주문내역 1670만
      • [각 패션 플랫폼 1년 매출 / 객단가] = 1년 주문건수
      • 여러 패션 플랫폼의 1년 주문 건수를 기반으로 평균값 추출
      • 1년 주문 건수의 평균값 * 5년(주문데이터 최대 보관 기간) = 1670만
      • "정보통신망법 제29조에 의거 보관기간 5년을 초과한 주문데이터는 개인정보보호차원에서 파기해야 합니다. - [보관 기간 5년 초과시, 삭제]로 설정할 경우 설정한 날로 부터 5년 초과된 주문서는 익일부터 오전 6시에 일괄 삭제처리 됩니다."
  • 지속적인 성능 유지 기간
  • 부하를 주는 방법
    • 어떤 네트워크에서 부하?
    • HTTPS는 사용 ❌

부하 테스트 목표값 설정

Latency 목표값 설정

📢 KISSmetrics는 고객의 47%가 2초 이내의 시간에 로딩이 되는 웹 페이지를 원하고 있으며, 40%는 로딩에 3초 이상 걸리는 페이지를 바로 떠난다고 설명했습니다.

  • 일반적인 경우 : 0.05~0.1초
  • 복잡한 트랜잭션이 필요한 경우 : 2초이내

Throughput 목표값 설정

📢 News1 자료(2021년 기준)에서 쇼핑 플랫폼별 MAU(Monthly Active User, 월간 순수 이용자) 추이는 평균 약 400만 명이다.

  • MAU : 400만(단위 : 명)
  • DAU : 13만(단위 : 명)
  • 안전계수 : 3
  • 1일 평균 접속 수에 대한 최대 피크 때 배율 : 2배

  • 1명당 평균 접속 수 : 20회

⇒ 130,000(명) 20(회) / 86,400(초) 3(안전계수) * 2(1일 평균 접속 수에 대한 최대 피크 때 배율) = 약 180 rps

  • 130,000(명) / 86,400(초) = 1.5명(1초에 접속하는 사용자 수)
    ⇒ 평균 : 1.5(명) 3(안전계수) = 4.5(명) → 5명
    ⇒ 최대 : 5(명)
    2(1일 평균 접속 수에 대한 최대 피크 때 배율) = 10(명)

부하 테스트 시나리오 결정

  1. 정적 페이지 테스트
  2. Hello World 페이지 테스트
  3. 참조계 페이지 테스트 (단순 DB 조회)
    • 메인페이지
    • 검색 페이지
      • DB 병목 ⇒ DB 스케일 UP

    • 상품 데이터 가져오기
    • 주문 내역 가져오기
    • 재입고 가능한 상품 데이터 가져오기
  4. 갱신계 페이지 테스트 (데이터 등록, 수정, 삭제)
    • 회원가입
    • 주문하기
    • 주문 취소
    • 재입고 알림 등록
    • 재입고 알림 삭제
    • 재입고 수량 등록
  5. 시나리오 테스트
    • 일반 유저
      1. 주문 관련 시나리오
        • 로그인 → 검색 → 페이지 넘기기 → 상세 페이지 → 주문하기
        • 로그인 → 주문 내역 가져오기 → 주문 취소
      2. 재입고 알림 관련 시나리오
        • 로그인 → 검색 → 상세 페이지 → 재입고 알림 등록
        • 로그인 → 검색 → 상세 페이지 → 재입고 등록 삭제
    • 셀러
      • 로그인 → 재입고 가능한 상품 데이터 가져오기→ 재입고 수량 등록
  6. 스케일 업/아웃 테스트 준비 및 테스트

부하 테스트 도구 결정

  • JMeter
  • Locust
  • Artillery
  • NGrinder

테스트 결과 기록

https://docs.google.com/spreadsheets/d/1TI6gnlM-oUQtTpSN-fTS1uW9YMFFbqm6MCS30mMAXBU/edit?usp=sharing

참고자료

  • [아마존 웹 서비스 부하 테스트 입문] 도서

회고

  • 최종발표 일주일을 남겨두고 부하테스트를 시작하게 되었다. 부하 테스트는 이번 항해99를 하면서 처음 알게되어서 어떻게 시작을 해야할지 참 막막했다. 매주 멘토링을 받는데 멘토님께서 [아마존 웹 서비스 부하 테스트 입문]이라는 책을 추천해주셔서 Yes24 E-book을 구매했다. 책에서 전반적으로 부하 테스트가 무엇이고 부하 테스트를 할 때 주의해야할 점들을 잘 설명해줘서 갈피를 좀 잡을 수 있었다. 부하 테스트 도구는 여러개 있었지만 실전 프로젝트 초반에 다른 팀의 팀원 분께서 Artillery로 간단하게 부하 테스트하는 세미나를 해주셔서 프로젝트 기간을 고려해 Artillery로 일단 진행했다. 다음에 기회가 된다면 다른 도구들도 고려해보면 좋을 것 같다!
profile
어떠한 가치를 창출할 수 있을까를 고민하는 개발자. 주로 Spring으로 개발해요. https://comclothing.tistory.com/ 👈🏻티스토리 블로그로 이전 완료

0개의 댓글