AWS/AWS KRUG

AWS KRUG - Serverless 소모임 - 20240416

728x90

안녕하세요 늑대양입니다

전일(240416) 진행되었던 AWS KRUG Serverless 소모임에서 진행된 세션 내용 하나를 공유드릴까합니다

아래부터는 세션을 들으면서 작성한 내용입니다.

Serverless 기반의 부하테스트 와 관련하여 도움이 되었으면 좋을 것 같습니다.

감사합니다 🫠

안녕하세요. AWSKRUG 서버리스 모임입니다.
AWSKRUG 서버리스 소모임은 AWS와 클라우드 컴퓨팅에 관심 있는 분들중에서도, 특히 Lamda와 같은 서버리스 관련 서비스를 활용하는 방법에 대해서 지식과 정보를 교류합니다.
서버리스 서비스 보기: https://aws.amazon.com/ko/serverless/
이전 모임 보기: https://github.com/awskrug/serverless-group

Session : 스타트업을 위한 Serverless 기반에서 부하테스트 진행 방법

김선형 님 (Backend Engineer, 노머스, Wonderwall)

Background:

한정된 자원만이 사용 가능한 스타트업
서비스:
- Wonderwall
- fromm
  - https://store.frommyarti.com/arti
  - 아티스트와 소통할 수 있는 서비스
  - 단발적으로 높은 트래픽 발생
목적:
- 부하테스트를 진행해 본 경험이 적은 엔지니어의 전반적인 수준 높이기

아티와 팬이 만드는 특별한 공간 | 프롬스토어 fromm store

store.frommyarti.com

Agenda:

부하테스트 진행 절차
부하 테스트 진행 시 중요한 것과 놓치기 쉬운 것
유용한 팁
Appendix

부하테스트 진행 절차:

테스트 툴 선정
테스트 시나리오 정의
목표 지표 정리(응답 속도, 유저수)
인프라 파악
테스트 준비
테스트 진행 & 결과 기록
개선 방향 정리 & 결과 적용

테스트 툴 선정

요구되는 트래픽이 높으면 클라우드 환경에서 쉽게 확장 가능한지 확인
LOCUST 사용
https://locust.io/

Locust.io

An open source load testing tool. Define user behaviour with Python code, and swarm your system with millions of simultaneous users.

locust.io

테스트 시나리오 정의

운영환경과 동일하게 하나도 빼놓지 않고 모든 경우 고려하기
시나리오가 어떤 역할을 하는지 이해 필요

목표 지표 정리(응답 속도, 유저수)

초당 VU 10만 명이 10초 동안 들어왔을 때, Latency P95 200ms
현재 서비스가 원활할 때 기준

인프라 파악

모든 인프라 리소스 체크해두기
이건 당연히 문제없지! 라고 생각한 부분에서 병목이 생길 가능성이 높음

테스트 준비

실제 운영 환경 복제(API 서버, DB 등)
테스트용 유저 데이터 추가

테스트 진행 & 결과 기록

지표에 매몰되어 오랜시간이 걸리는 것을 지양
테스트 대상 리소스 변경이 빠르게 이뤄질 수 있는 환경 구축하기
리소스의 모든 하드웨어를 병목 대상 후보로 두기(CPU, Mem 등)
부하 발생기 본인이 병목인 경우가 자주 있으므로 모니터링 항상 진행
Network는 괜찮겠지? 하면 매우 안 괜찮을 수 있음

개선 방향 정리 & 결과 적용

점진적인 배포를 통해 모니터링을 병행하여 진행

유용한 팁:

AWS Support plan 활용
일반적인 경우, 테스트 1 회당 1 개의 변수만 변경
비용을 너무 절약하는 것보다 테스트를 빠르게 진행하는 것이 최종적으로 비용&시간을 아끼는 길
Fargate 주요 변수:
- TASK COUNT
- CPU
- MEMORY
- NETWORK
  - 메트릭을 제공하지는 않음
  - 내부적으로 EC2를 띄우는 구조로 확인하기 어려운 네트워크 밴드윗이 있다고 함
  - 현재 QOS가 적용되어있는지 확인은 가능
빠른 테스트 진행을 위해 컨테이너가 빠르게 뜨도록 설정
Aurora 관련 팁:
- 주요 변수:
- Serverless 주요 변수: Serverless database capacity
- 모니터링은 퍼포먼스 인사이트와 모니터링 탭에서 진행
- PI에 LWLOCK:LCOK_MANAGER 관측될 경우, RDS Proxy 사용 권장
- PI CPU 대기가 길다면 문제가 되는 쿼리의 최적화 지점을 살펴보거나 스케일 업/아웃 진행
- 대량의 테스트 데이터가 들어갔다면 VACUUM ANALYZE 쿼리 실행
ElastiCache(Redis):
- 메모리, CPU, 네트워크
- 스파이크 테스트 중 예상치 못한 네트워크 지연이 발생해 문제 원인을 찾기 힘든 경우가 있었음
- 레디스는 싱글 스레드라 한 번에 하나의 vCPU만 사용해, 스케일 업보다 스케일 아웃을 통해, 엔진 CPU를 여러 노드로 분산시키고 네트워크 사용량을 여러 노드로 분산하는 데 유리
- 작고 동일한 크기와 타입을 가진 키 사용 (redis-cli --bigkeys)

Appendix

Locust
- Python 기반
- 시나리오 작성이 쉬움
- AWS 엔지니어도 사용중일 정도로 사용자 풀이나 커뮤니티가 넓음
- AWS 공식 리포에도 테스트가 나와 있음
- 빌트인으로 GUI 환경 제공
JMeter, nGrinder, k6, Gatline 등 다양한 툴이 있으므로 팀에 적합한 툴을 사용하는 것이 중요

+추가 Reference:

https://aws.amazon.com/ko/blogs/tech/wonderwall-perform-load-testing/

Wonderwall 은 부하 테스트를 어떻게 진행했을까? | Amazon Web Services

엔터테크 기업 (주)노머스는 종합 아티스트 IP 서비스 ‘원더월’을 선두로, “예술이 세상을 바꾼다(Art Changes Life)”라는 슬로건을 바탕으로 아티스트 IP 기반의 콘텐츠, 커머스, 공연, 팬덤 플랫

aws.amazon.com

감사합니다! 행복한 수요일 보내세요!!

다음에 또 찾아오겠습니다🙏