AWS KRUG - Serverless 소모임 - 20240416

 

 

안녕하세요 늑대양입니다

 

 

늑대양 by DALL-E

 

 

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

 

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

 

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

 

감사합니다 🫠

 

 

---

 

당근마켓에서 진행된 AWS KRUG Serverless 소모임

 

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

 

 

 

---

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

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

 

Background:

fromm 서비스

 

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

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

 

 

Agenda:

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

 

부하테스트 진행 절차:

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

 

테스트 툴 선정

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

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

 

 

 

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

 

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